Website performance is always an ongoing effort and an elusive target. In the early days, pageLoad time was the gold standard of web performance monitoring. However, websites have evolved to be a lot more dynamic, JavaScript-heavy and filled with rich images and 3rd party content. We need better metrics, a better model, and better tooling to measure and monitor the performance. In this blog post, I explain the evolution 3 different trends that are shaping the industry:

So, let's dig in!

RAIL Framework

RAIL is a framework that is being publicized by Google. According to the Google developer page, it is "a user-centric performance model that breaks down the user's experience into key actions."

The framework breaks down performance into these 4 key goals:

Basically, the RAIL model says that load your page fast so that it is interactive quickly. Once it is interactive, ensure that any dynamic aspects are fast enough so that the page remains interactive to user input.

For more information about RAIL, please watch this video about RAIL in real word.

Perceived Performance

How fast your site appears to load is as important as it really loads. The problem with perceived performance is that there was no way to measure it. It's something of a conundrum like this:

                                                                                Source.

We have had a lot of measurements like Time to first byte, DOM loaded, onLoad and a host of other measurements. These metrics have been immensely helpful in the evolution of the web performance industry. However, they were designed on the events that could be measured by browsers. However, they failed to answer some basic questions like these:

Going beyond this, we have a few more measurements like the following:

All this boils down to measuring a host of metrics that are spread across different tools and platforms.

                                                                                   Source.

If you notice, we've now gone from hard measurement of DNS or onLoad to softer measurements related to user's interaction and experience. All this is harder to measure but, Google has announced that their search indexing will now take these factors into account. Specifically, Google will now:

• Use mobile page speed as a ranking signal,
• Encourage "developers to think broadly about performance," and
• Hint at using suggestions from tools like LightHouse, CrUX and PageSpeed Insights which we'll discuss next.

Tooling for Perceived Performance

WebPageTest has been the best and de-facto tool to visualize and show the concept of perceived performance. The film strip view, video, and visual progress charts have been the toolset that we have been using for a long time. However, we now have more tools that can help in building a case for measuring and optimizing for perceived performance.

• LightHouse: Project LightHouse by Google is able to run a lot of audits and present findings. These findings are wide-ranging, like providing a filmstrip view to Chrome Javascript timeline. By using the audit, you would be able to dig into problems like a particular Javascript taking a high amount of time and thus causing rendering issues.
• Chrome User Experience Report (CrUX): Google Chrome collects performance measurements from real browsers. This information is sent back to Google if users have opted in for the data collection. This anonymized data is now being exposed as the Real User Monitoring (RUM) data for Chrome under the project CrUX. This tool is especially helpful since it gives you a spread of the user experience. Synthetic tests can only give you the data from simulated users with a pre-defined setup. CrUX can provide histograms of actual performance behaviors, including perceived performance information.
• Google PageSpeed Insights: This tool has now evolved to provide both suggestions to improve the page and pull up the CrUX data for the URL being audited. By using the PSI report, you should get an idea of the current performance and tips to analyze and fix your website.
• Akamai mPulse: Akamai's mPulse Real User Monitoring solution provides all the perceived performance data along with the standard metrics like onLoad. The tool can be instrumented to measure rage clicks as well to identify the user's frustration levels when using a website.

What Do You Look For?

By correlating the data from synthetic tests and the RUM solutions, you should be able to identify potential issues in perceived performance. Some of the issues could be:

• Synchronous scripts holding up the browser's main thread and preventing it from rendering the content
• A/B testing solutions that implement some fix leading delayed rendering of the page (Preventing flickering with A/B Solutions)
• Page appearing to be ready but, actually busy. This can be seen in the first input delay (FID) as well as the difference between Time to First Interaction and Time to First Interactive.
• Page appearing to render but not showing the content that matters. This can be caught by metrics like First Contentful Paint, First Meaningful Paint and Visually Ready

I have highlighted a very small subset of issues that could be tracked and worked on by leveraging the perceived performance metrics. If you have any use cases, I'd like to hear more as well!