3 Trends in Web Performance
3 Trends in Web Performance
Web performance monitoring has changed — make sure you're prepared with these tips on web performance optimization trends.
Join the DZone community and get the full member experience.Join For Free
xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.
So, let's dig in!
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.
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:
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.
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.
- 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!
Published at DZone with permission of Akshay Ranganath , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.