SpeedCurve Blog

15 page speed optimizations that sites ignore (at their own risk)

Tue, 09 Jul 2024 00:00:00 +1200

A recent analysis of twenty leading websites found a surprising number of page speed optimizations that sites are not taking advantage of – to the detriment of their performance metrics, and more importantly, to the detriment of their users and ultimately their business.

I spend a lot of time looking at waterfall charts and web performance audits. I recently investigated the test results for twenty top sites and discovered that many of them are not taking advantage of optimizations – including some fairly easy low-hanging fruit – that could make their pages faster, their users happier, and their businesses more successful.

More on this below, but first, a few important reminders about the impact of page speed on businesses...

Slow pages hurt your business

In user survey after user survey over the past decade or so, site speed has emerged as one of the greatest factors that determine a person's satisfaction with a website (second only to security). Because our "need for speed" is deeply rooted in our neural wiring, it's unlikely to change, no matter how much we wish it could.

In case you have any doubts, countless case studies have proven a consistent and demonstrable correlation between page speed and business and user engagement metrics like conversions, bounce rate, and search rank. Just a few examples:

Walmart found that every 1 second of improvement equaled a 2% increase in conversion rate.
Vodafone improved their Largest Contentful Paint (LCP) time by 31%, resulting in an 8% increase in sales, a 15% increase in their lead-to-visit rate, and an 11% increase in their cart-to-visit rate.
NDTV, one of India's leading news stations and websites, improved LCP by 55% and saw a 50% reduction in bounce rate.
ALDO found that on their single-page app, mobile users who experienced fast rendering times brought 75% more revenue than average, and 327% more revenue than those experiencing slow rending times. On desktop, users with fast-rendering times brought in 212% more revenue than average and 572% more than slow.

How much faster than your competitors do you need to be?

It's not enough to be fast. You need to be faster than the competition. If you're not, your customers could be quietly drifting away. In a traditional brick-and-mortar scenario, abandoning one store for another takes effort. On the web, it takes a couple of clicks.

The margin for speed is tight. Way back in 2012, Harry Shum (then EVP of Technology and Research at Microsoft) said:

"Two hundred fifty milliseconds, either slower or faster, is close to the magic number now for competitive advantage on the Web."

With many synthetic monitoring tools, you can benchmark your site against your competitors. Competitive benchmarking is a great way to see how you stack up – and how much you need to improve.

This is why it's crucial to take advantage of any optimization technique that could help give you a competitive advantage.

US Retail Benchmarks leaderboard

Background: Looking at 20 leading sites

For this investigation:

I looked at the synthetic test results for twenty randomly selected industry-leading sites, taken from SpeedCurve's Page Speed Benchmarks dashboard.
I then tallied the pass/fail status for common performance recommendations (AKA performance audits).

Page Speed Benchmarks is an interactive set of dashboards that anyone can explore and use for their own research. Every day we run a synthetic test for the home pages of industry-leading websites and rank them based on how fast their pages appear to load from a user’s perspective. You can filter the dashboard to rank sites based on common web performance metrics, such as Start Render, Largest Contentful Paint, Cumulative Layout Shift, Time to Interactive, and more.

The Benchmarks dashboard also allows you to drill down and get detailed test results for each page, including waterfall charts, Lighthouse scores, and recommended optimizations/audits. Looking at these test details lets you see how the fastest and slowest pages in the dashboards are built – what they're doing right, as well as missed opportunities for optimization.

Lighthouse scores and performance audits, taken from this synthetic test result

For the twenty sites I looked at, below are the most common page speed optimizations those sites were not taking advantage of, ranked from least to most implemented.

Serve static assets with an efficient cache policy

Metric(s) affected: Rendering metrics for repeat views

The first time you visit a site, it's likely that your browser won't have any of the resources it needs to load the page already stored in its cache. This is often referred to as a cold cache. This state is very typical for sites that don't get a lot of repeat visitors over a short duration. For many other sites, such as your favourite media or shopping sites, repeat views are very common.

For sites that receive a lot of repeat visitors, taking advantage of the browser cache is a big performance win. Yet only 1 out of the 20 pages I looked at had an efficient cache policy.

Fix: Setting appropriate HTTP headers for page resources is the best way to make sure you are optimally caching content for your site.

Reduce unused JavaScript

Metric(s) affected: Largest Contentful Paint

There's a shocking number of zombie scripts out there, slowly killing performance. Unused JS can hurt your site in a number of ways, from render-blocking scripts that prevent your page from loading to competing with essential JS for bandwidth, especially on mobile and low-powered devices. Only 3 out of 20 sites passed this audit.

Fix: Reduce unused JavaScript and, when possible, defer scripts until they're required.

Page prevented back-forward cache restoration

Metric(s) affected: Rendering metrics for repeat views

Many navigations are performed by going back to a previous page and forward again. Back/forward cache (or bfcache) stores the entire page so that it's available and renders nigh instantaneously. It doesn't require special HTTP headers and is now supported across all major browsers.

For sites that have a lot of back/forward navigations, taking advantage of the bfcache remains one of the biggest opportunities to deliver a page load experience that feels seamless. Yet 16 out of 20 sites did not have bfcache restoration enabled.

Fix: Leverage the browser cache to reduce the number of HTTP requests.

Image elements do not have explicit 'width' and 'height'

Metric(s) affected: Cumulative Layout Shift

Without height and width attributes, your images fly around the page trying to figure out how to resolve and settle down in each individual user's browser. This can really hurt your Cumulative Layout (CLS) score. CLS is a Core Web Vital, which means it's an important factor in Google's search algorithm. The worse your CLS score, the greater risk of hurting your SEO rank.

More to the point, a poor CLS score tells you that your pages feel super janky and unstable. Page jank is an irritant for everyone, but it's a major accessibility problem for people with disabilities that affect fine motor skills.

All this goes to say that it's very surprising to see that 14 out of 20 sites failed this audit.

Fix: Set an explicit width and height on all image and video elements. Alternatively, reserve the required space with CSS aspect-ratio or similar.

Minimize main-thread work

Metric(s) affected: Largest Contentful Paint, Total Blocking Time (to name just a couple)

Geoff Graham provides a good analogy for the browser main thread here:

I’ve heard the main thread described as a highway that gets cars from Point A to Point B; the more cars that are added to the road, the more crowded it gets and the more time it takes for cars to complete their trip. This particular highway has just one lane, and it only goes in one direction. there’s only one way to go, and everything that enters it must go through it... Each resource on a page is a contender vying for a spot on the thread and wants to run first. If one contender takes its sweet time doing its job, then the contenders behind it in line just have to wait.

When you understand how hard all a page's resources are fighting for the main thread, it's easy to understand why minimizing main-thread work is a crucial page speed optimization strategy. It's not uncommon to see pages where main-thread work could be reduced by 8-10 seconds or more! Of the 20 sites I looked at, 13 failed this audit.

Fix: Reduce the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this.

Reduce JavaScript execution time

Metric(s) affected: Interaction to Next Paint, Total Blocking Time

JavaScript is, by default, parser blocking. That means that when the browser finds a JavaScript resource, it needs to stop parsing the HTML until it has downloaded, parsed, compiled, and executed that JavaScript. Only after all of that is done can it continue to look through the rest of the HTML and start to request other resources and get on its way to displaying the page.

For the 20 sites I looked at, there was a 50/50 pass/fail rate for this audit.

Fix: There are several things you can do, including minification and compression, serving JS asynchronously (or deferring it), avoiding layout thrashing, and yielding to the main thread. The most radical solution: wherever possible, don't use JavaScript!

Avoid enormous network payloads (AKA page size)

Metric(s) affected: Largest Contentful Paint

I've stopped being shocked when I see pages that are upwards of 10, 20, and even 30 MB in size. Large network payloads can cost users real money and are highly correlated to slow load times. The main culprits: huge image and video files, along with unoptimized JavaScript.

If a page is greater than 5,000 KB in size, then it fails this audit. Of the 20 sites I looked at, 9 failed – meaning they were larger than 5,000 KB.

Fix: Reduce payload size. For first views, you can optimize resources like images and videos to be as small as possible. For repeat views, leverage the browser cache as recommended earlier in this post.

Serve images in next-gen formats

Metric(s) affected: Start Render, Largest Contentful Paint

Image formats like WebP and AVIF often provide better compression than PNG or JPEG, which means faster downloads and less data consumption. 11 out of 20 sites passed this audit.

Fix: Explore alternative image formats. AVIF is supported in Chrome, Firefox, and Opera and offers smaller file sizes compared to other formats with the same quality settings. WebP is supported in the latest versions of Chrome, Firefox, Safari, Edge, and Opera and provides better lossy and lossless compression for images on the web.

Ensure text remains visible during webfont load

Metric(s) affected: Start Render, Largest Contentful Paint

Some web fonts can be large resources, which means they render slowly. Because fonts are often one of the first resources to be called by the browser, a slow font can relay all your downstream metrics. And depending on the browser, the text might be completely hidden until the font loads. The resulting flash of invisible text (FOIT) is a UX annoyance.

Despite all those very good reasons to optimize font rendering, 7 out of 20 sites failed this audit.

Fix: Leverage the font-display CSS feature to ensure text is visible to users while web fonts are loading.

Reduce the impact of third-party code

Metric(s) affected: Total Blocking Time, Largest Contentful Paint, Interaction to Next Paint

These days, a typical web page can contain dozens of third-party scripts. All that extra code – which you don't have much control over – can significantly affect the speed of your pages. A single non-performant blocking script can completely prevent your page from rendering. The good news is that only 4 out of 20 sites failed this audit (though that number is still too high).

Fix: While you can't always do much about your third-party vendors, you still have a number of options available, including limiting the number of redundant third-party providers and loading third-party code after your page has primarily finished loading.

Reduce unused CSS

Metrics affected: Start Render, Total Blocking Time, Largest Contentful Paint

By default, the browser has to download, parse, and process all stylesheets before it can display any content. Like unused JavaScript, unused CSS clutters your pages, creates extra network trips, unnecessarily adds to your total payload, and ultimately slows down user-perceived performance. Decluttering your pages pays off, yet 4 out of 20 sites failed this audit.

Fix: Reduce unused rules from stylesheets and defer CSS not used for above-the-fold content. Use critical CSS for faster rendering.

Avoid 'document.write()'

Metric(s) affected: Start Render and other downstream metrics

For users on slow connections, external scripts dynamically injected via document.write() can delay page load by tens of seconds. That's a lot!

Fix: Remove all uses of document.write() from your code. If it's being used to inject third-party scripts, use asynchronous loading instead.

Eliminate render-blocking resources

Metric(s) affected: Start Render, Largest Contentful Paint, and other downstream metrics

A blocking resource is any resource that blocks the first paint of your page. Anything that has the potential to block your page completely is concerning, right? Yet 3 out of 20 sites failed this audit.

Fix: Eliminate render-blocking scripts. Assess your blocking resources to make sure they're actually critical and then serve the legitimately critical scripts inline. Serve non-critical code asynchronously or defer it. Remove unused code completely.

Use HTTP/2

HTTP/2 offers many benefits over HTTP/1.1, including binary headers and multiplexing. What this means: your page's resources are leaner and faster. Most sites I looked at are already leveraging HTTP/2, but there were still a couple of holdouts.

Fix: Learn how to set up HTTP/2.

Do NOT lazy load the LCP image

Metric(s) affected: Largest Contentful Paint

Yikes! I don't see this issue often, but I'm still surprised every time I do. Images that are lazy loaded render later in the page lifecyle. Lazy loading is a great page speed optimization technique for non-critical images, such as those that are lower down on the page. But it's a huge problem if you're lazy loading your Largest Contentful Paint (LCP) image. This can add many seconds to your LCP time. (I've seen LCP times of up to 20 seconds – caused by lazy loading!)

LCP is a Core Web Vital, which means it's a user experience signal in Google's search algorithm. The worse your LCP time, the greater risk of hurting your SEO rank. Just as important, slow images hurt the user experience, and ultimately conversions and bounce rate for your site. Seeing that 2 out of 20 sites failed this audit broke me a little. I hope this post helps you avoid this mistake!

Fix: The LCP image should never be lazy loaded. In fact, the LCP image should be prioritized to render as early in the page lifecycle as possible. If the LCP element is dynamically added to the page, you should preload the image. Get more LCP optimization tips.

You should also create a performance budget for LCP, so you get alerted right away if it suddenly degrades.

Why are so many recommendations neglected?

There are a few reasons I can think of off the top of my head:

Some optimizations may not affect the critical rendering path

The critical rendering path is the set of steps a browser takes to convert all a page's resources – from images and HTML to CSS and JavaScript – into a complete, functional web page. Optimizing the critical rendering path means taking a good look at the order in which the resources on your pages render, and then making sure that each resource in the rendering path is as performant as possible. It sounds simple – and conceptually it is – yet it can be tricky to achieve (as this performance audit of LEGO.com reveals).

Depending on how a page is built, the critical rendering path might be well optimized, even disregarding some of the optimizations listed above. For example, a page might contain render-blocking first- and third-party JavaScript – such as ads and beacons – but if these scripts are called later in the pages rendering life cycle, then they probably won't affect the user experience.

Some optimizations may be harder (or impossible) to implement

If your page has a massive payload, there might not be much you can do about it. News sites, for example, typically have huge pages because they're required to contain a ton of ads and widgets in addition to their huge content payload of images and videos.

And speaking of images, serving them in next-gen formats (e.g., AVIF instead of JPEG) can be challenging if you have a large number of content creators uploading images to your CMS.

People just don't know

Some practices – such as leveraging the bfcache – are so new that they might not be on people's radar. Others – such as knowing not to lazy load the LCP image – are probably because people are too broadly applying a generally good best practice like lazy loading.

But still...

Many of the sites I looked at are pretty fast, despite not following web performance optimization best practices religiously. But that doesn't mean ignoring best practices is... well, good practice.

Page size and complexity affects users at the 95th percentile – including mobile users and people using slower networks. Ignoring 5% (or more) of your users is a bad idea.
Bad practices pile up until there's a tipping point. After that, all it takes is one unoptimized image or non-performant script to seriously hurt your page.
Zombie third parties can introduce security issues. You should always understand why a third-party script is on your pages and eliminate the ones that don't belong there.
Page jank is a thing. It's not enough to have a fast Start Render or Largest Contentful Paint time. Your critical rendering path might be short and sweet, and your pages might start to render reasonably quickly, but what about the user experience during the entire rendering lifecycle of the page? Everyone hates jank, and too much of it hurts your UX and your business.

How to prioritize page speed optimizations

1. Consider how many pages on your site are affected by each optimization recommendation

Run some synthetic tests on your key pages and see which optimizations are recommended. If you're a SpeedCurve user, you can use your Improve dashboard to see how many pages on your site are affected by each audit. If a large number of your pages would benefit from an optimization, then you may want to take the approach of tackling improvements one audit at a time.

2. Validate that an optimization will help your page and UX in a measurable way

You don't want to spend a lot of developer time implementing an optimization that won't ultimately benefit your users. Understanding the critical rendering path for your pages is the best way to know if optimizing a resource will make a difference in how the page feels from an end-user perspective.

3. Grab the easy fixes first

Sometimes it's easier to get yourself – and other folks – in your organization excited about performance fixes is to score some easy wins early on. Later, you can work your way up to the more time-consuming ones.

Some easy(ish) recommendations:

Tweaking your cache policy
Enabling bfcache
Setting height and width attributes on images
Optimizing image and video sizes
Serving third parties asynchronously or deferring them

Start somewhere and keep moving

If you've tested your pages and get a long list of recommended fixes, it can be a bit overwhelming – and more than a bit demoralizing. Start with the small, easy wins first. Speeding up your pages doesn't (usually) happen overnight. The important thing is to show up, do the work, and always be monitoring. Remember: you can't fix what you don't measure!

Performance Hero: Michelle Vu

Wed, 26 Jun 2024 00:00:00 +1200

Michelle Vu is one of the most knowledgeable, helpful, kind people you could ever hope to meet. As a founding member of Pinterest's performance team, she has created an incredibly strong culture of performance throughout Pinterest. She's also pioneered important custom metrics and practices, like Pinner Wait Time and performance budgets. We are super excited to share that Michelle is this month's Performance Hero!

Michelle is a web performance industry veteran who has spent the last seven years making Pinterest fast and reliable. She was a founding member of Pinterest's performance team, establishing foundations of their program by setting up its synthetic and real user metrics, proactive alerts, and performance analysis tools, while fostering a culture of performance across teams.

Michelle and her team at Pinterest pioneered the use of custom metrics when they introduced Pinner Wait Time (PWT). This metric measured the slowest loading time for content they considered critical for the user experience on a page.

As the web performance tech lead at Pinterest, Michelle focuses on large optimizations to the Core Web Vital and Pinner Wait Time metrics for key features. She also aids in performance issues from platform migrations and product feature launches. When she's not working on optimizations, Michelle tackles performance regressions and develops tooling to analyze performance and prevent regressions.

Michelle is a participant in the W3C Web Performance Working Group as an Invited Expert. She's given talks about performance at Fastly's Altitude NYC, performance.now(), PerfMatters, and numerous web performance meetups.

Most recently, Michelle presented on tooling to catch and prevent regressions due to increases in JavaScript bundle sizes. She's also in the midst of releasing a three-part series of articles – Web Performance Regression Detection – on the Pinterest Engineering Blog.

^{Loved seeing Michelle use SpeedCurve visuals on stage to share how they help make Pinterest fast!}

Here are a few ways you can find Michelle and learn more about the great work she does in our community:

Please join us in celebrating Michelle Vu, a true Performance Hero!

Do you have someone you'd like to recognize as a Performance Hero? Let us know!

New! Web Performance Guide

Tue, 25 Jun 2024 00:00:00 +1200

Our customers often tell us how much they appreciate the user-friendliness of the articles we create for them, so we recently decided to make them available to everyone (not just SpeedCurve users). Introducing the Web Performance Guide!

The Web Performance Guide is – as its name suggests – a collection of articles we've been writing over the years to answer the most common questions we field about performance topics like site speed, why it matters, how it's measured, website monitoring tools, metrics, analytics, and optimization techniques.

You'll find the articles grouped into these topics...

Business success

Making your pages faster isn't just for the web performance geeks in your organization. Site speed affects every business metric you care about – from bounce rate to conversions to search rank. This section gives you the data, tools, and tips to make everyone in your company care about how page speed affects your users and build a healthy culture of web performance.

Core Web Vitals

There are a lot of metrics you need to track, and Core Web Vitals are among them. These three metrics – Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint – are important ingredients in Google's search ranking algorithm. We cover what they measure, how to track them over time (and get alerts when they degrade), and how to optimize your pages to improve them.

Optimization techniques

Website speed testing is just the first step toward optimizing your pages to make them faster – and make your users happier. This section covers best practices for creating performance budgets to fight regressions, as well as techniques for optimizing images, JavaScript, CSS, SPAs, third-party scripts, and more!

Metrics and charts

There's a lot of terminology and TLAs (three-letter acronyms) in the web performance space. No fear! We're here to explain everything in plain language so you can understand what you're seeing in your site speed testing tools. We'll help you understand the difference between synthetic and real user monitoring tools. We also cover topics like understanding averages, medians and percentiles and how to interpret charts like histograms and waterfalls.

Everything in the Web Performance Guide was written by actual humans!

Meet our amazing team of web performance experts and authors:

Cliff Crocker
Andy Davies
Tammy Everts
Tim Kadlec
Steve Souders
Joseph Wynn
Mark Zeman

Not only do they deliver world-class consulting and hands-on care to our wonderful customers, they're pretty great writers, too!

Questions? Suggestions?

We'd love to hear from you! Drop us a note at support@speedcurve.com.

Performance Hero: Estela Franco

Tue, 21 May 2024 00:00:00 +1200

Continuing our series of Performance Heroes, this month we celebrate Estela Franco! Estela is a passionate web performance and technical SEO specialist with more than ten years of contributing to our community. She loves to talk and share about web performance optimization, technical SEO, JavaScript, and Jamstack whenever she can.

By day, you can find Estela working as a web performance specialist for Schneider Electric in Barcelona, Spain. Outside of work, her contributions as a Google Developer Expert in Web Technologies, a Storyblok Ambassador, co-organizer of the Barcelona Web Performance Meetup, and co-founder of the Mujeres en SEO community have made a huge impact on developers and web performance aficionados around the globe.

Estela has the winning combination of a web development background coupled with a background in business administration. She started on the marketing side, discovering the fundamentals of SEO and digging deeper into the code to learn how websites work and how to optimize for both robots and humans. This led her to specialize in technical SEO. With the announcement of the Core Web Vitals back in 2020, Estela made the decision to focus on web performance.

In her talk at Performance.now in November 2023, Estela helped demystify optimizing for Largest Contentful Paint (LCP) with a focus on LCP subparts. Her data-backed approach was refreshing, practical, and very useful. (We certainly took note!)

Here are a few ways you can find Estela and learn more about the great work she does in our community:

Please join us in celebrating Estela Franco, a true Performance Hero!

Do you have someone you'd like to recognize as a Performance Hero? Let us know!

NEW: RUM attribution and subparts for Interaction to Next Paint!

Wed, 01 May 2024 00:00:00 +1200

Now it's even easier to find and fix Interaction to Next Paint issues and improve your Core Web Vitals.

Our newest release continues our theme of making your RUM data even more actionable. In addition to advanced settings, navigation types, and page attributes, we've just released more diagnostic detail for the latest flavor in Core Web Vitals: Interaction to Next Paint (INP).

This post covers:

Element attribution for INP
A breakdown of where time is spent within INP, leveraging subparts
How to use this information to find and fix INP issues
A look ahead at RUM diagnostics at SpeedCurve

How quickly does my site respond to user input?

In short, Interaction to Next Paint measures the responsiveness of your pages. (If you want to dive deeper, check out our INP primer.) Delays in responsiveness can lead to user frustration, which affects user engagement, which in turn affects your business objectives, such as revenue. This is why you should care about INP.

Correlation charts showing how INP affects user engagement

Element attribution

We've been collecting Interaction to Next Paint data for a while. Early on, we found that poor INP was an issue for a lot of folks, especially when looking at mobile users.

However, as a general time-based metric, INP didn't leave a lot of hints as to the source of the problem. Our early solutions leveraged our IX elements as a proxy for element attribution for INP. This is still a viable option for all non-Chromium browsers – which, to be clear, is probably more than half of your traffic! However, with the element selector directly attributed to INP for Chromium browsers, you are provided a lot of missing context.

After a bit of research and plenty of consultation with our customers, we've decided to expose the INP element selector. In addition, we've improved our classification for IX elements, making it easier to cross reference attribution with non-Chromium browsers.

INP heatmap available in your RUM Performance dashboard

INP subparts

After identifying which interactions are responsible for Interaction to Next Paint issues, you'll want to understand where that time is being spent. This is provided with INP subparts, which are now collected for all SpeedCurve RUM users.

There are three main areas to look at when diagnosing INP times:

Input delay
Processing time
Presentation delay

Source: INP: What's in an interaction?

Input delay

As you can see in the illustration above, input delay measures from the time that the user interaction started (when the input was received) until the event handler is able to run.

Processing time

Processing time includes the time it takes event callbacks, initiated by the interaction, to complete.

Presentation Delay

Simply put, presentation delay is the time it takes the frame to be presented after the event callbacks are completed.

Using SpeedCurve RUM to find and fix INP issues

Once you've identified that Interaction to Next Paint is an issue for your page (or pages), you can use the heatmap shown above in your RUM Performance dashboard to identify problematic elements on your page.

Step 1: Make sure you've set the RUM Performance dashboard filter to the 75th percentile

This is especially important if you are chasing INP issues you've identified via CrUX or Google Search Console.

Step 2: Navigate to the INP heatmap

Look for thresholds that have been exceeded, using the color-based Google-defined thresholds for INP:

Green = <200ms
Yellow = 200-500ms
Red = >500ms

Step 3: Determine where the most time is spent

Below are a few examples to go along with this Web.dev post on Optimizing INP by Jeremy Wagner and Philip Walton.

Input delay

Factors that affect input delay generally include contending main thread work. Look for Long Tasks that appear to be in conflict with the interaction, fetch handlers, timer functions, or other competing interactions.

Processing delay

If time is spent here, look at optimizing event callbacks. As with Long Tasks, breaking things up into smaller chunks of work and deferring work not required for rendering is recommended.

Presentation delay

Issues with presentation delay are typically related to the complexity of the DOM. Other improvements to presentation delay may come by reducing the amount of client-side rendering required and deferring rendering of off-screen elements.

For a deeper dive into troubleshooting INP issues, see this post by Andy Davies which takes you through using Chrome DevTools to profile interactions.

What about iOS?

The lack of support for web performance metrics in Safari is not a new complaint, but it's a big one. Developers are left to their own devices to troubleshoot performance on iOS devices. While Apple hasn't announced any plans to support any of the Core Web Vitals soon, there is some ability to triangulate on potential issues that might affect the user experience.

As an example, the Interaction Metrics (IX) captured by SpeedCurve are available for Safari. With the latest upgrades to RUM, we've made it easier to identify those IX elements, which tend to align very closely with the INP element selectors we see for Chromium. This guide to finding and fixing INP issues using IX elements as a proxy still applies!

Looking ahead at RUM diagnostics

Team SpeedCurve is very excited! Here's what we'll be up to over the coming months:

We'll be making a lot of updates and improvements to our data pipeline, which will allow us to continue our mission of making RUM even more actionable.
We'll be focused on improving the diagnostic capabilities for the remaining Core Web Vitals, Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS).
We'll also be focused on enhanced support for the increasing complexity of measuring the entire lifecycle of the page.

We're excited to roll out this update for Interaction to Next Paint and hope you get a lot of use from it. As always, we value your feedback, so shoot us a note and let us know what you think!

Performance Hero: Paul Calvano

Tue, 23 Apr 2024 00:00:00 +1200

Celebrating performance wins is critical to a healthy, well-supported, high-performing team. This isn't a new idea. In fact, it's something that started in the early days of web performance when Lara Hogan, who was an engineering manager at Etsy at the time, discussed the practice of empowering people across the organization by celebrating 'performance heroes'.

In that spirit, we're reigniting the tradition of spotlighting Performance Heroes from our awesome community. It seems appropriate that we'd start with someone who is currently focused on keeping Etsy's site as fast as possible: Paul Calvano

Not only has Paul had a long career dedicated to making the web faster for some of the largest and most popular sites in the world, he is humble, incredibly talented, and one of the kindest people you'll ever meet.

I've known Paul since I got started in web performance, back in the days of load and performance testing at Keynote Systems (now part of Dynatrace). Paul took me under his wing and quickly showed me the art of breaking websites to prepare them for large influxes of traffic like Black Friday.

Paul recently spoke about font performance at the NY WebPerf Meetup Group, which he co-chairs. Sharing insights from Etsy and how they use performance budgets continues the spirit of transparency and accountability that started at Etsy so many years ago.

Paul's list of accomplishments include (but are certainly not limited to):

Speaking at multiple conferences
Co-chair of the New York UX Speed and Web Performance Meetup
Co-maintainer of the HTTP Archive
Multi-year contributor to the Web Performance Almanac
Author of many tools aimed at helping people optimize their websites

Paul is one of the most intelligent and humble people I know. He's given a lot to our community and continues to evangelize performance at every turn. Thank you for everything you've done for our community, Paul. It wouldn't be the same without you!

Do you have someone you'd like to recognize as a Performance Hero? Let us know!

Five ways cookie consent managers hurt web performance (and how to fix them)

Mon, 15 Apr 2024 00:00:00 +1200

Cookie consent popups and banners are everywhere, and they're silently hurting the speed of your pages. Learn the most common problems – and their workarounds – with measuring performance with content manager platforms in place.

I've been spending a lot of time looking at the performance of European sites lately, and have found that the consent management platforms (CMPs) consistently create a false reality for folks when trying to understand performance using synthetic monitoring. Admittedly, this is not a new topic, but I feel it's important enough that it warrants another PSA.

In this post, I will cover some of the issues related to measuring performance with CMPs in place and provide some resources for scripting around consent popups in SpeedCurve.

What are CMPs and how do they work?

A consent management platform (CMP) is a tool that helps organizations handle user consent for data collection and processing, following privacy rules like GDPR or CCPA. On websites, CMPs handle cookie popups. They tell users about cookies and ask for permission before saving them. Unless you've been abstaining from the internet for the past several years, you know consent managers well.

What challenges do CMPs create for performance?

These are some of the most common performance issues caused by content management platforms.

1. Single Point of Failure (SPOF)

As a third party, CMPs can have performance issues of their own that can affect the user experience. It's common to see the consent scripts blocking by design. This can have an impact on most metrics – such as Start Render and Largest Contentful Paint – downstream.

In this example, the synchronous requests for the CMP timed out, causing an extremely long delay in Start Render due to the SPOF. Consent scripts should be loaded async whenever possible.

2. Identifying the wrong LCP element

Most people assume the LCP element on a page is their main hero or product image, but they're frequently wrong. Oftentimes the text or element in the consent popup is identified as the LCP element. While this may be technically accurate, it's probably not what you want to measure.

In this case, LCP is slower after opt-in, when the hero image has taken 2.5s longer to load.

3. Consent banners can hurt Cumulative Layout Shift scores

Some sites choose to use a consent banner instead of a popup. As Andy Davies discovered, this can sometimes cause CLS issues, depending on how the banner is implemented. In this example, the consent banner causes a large layout shift for first-time viewers, pushing the CLS score well beyond recommended Core Web Vitals thresholds.

Sia Karamalegos from Shopify provided another great example of how cookie notices that are animating position properties vs. using the preferred method of CSS transform can cause massive CLS scores. (Side note: This post is a great read for anyone looking to optimize for CLS their Shopify site)

4. Masking third-party performance

Assuming that you have visibility into your third-party performance is another pitfall when testing the first view of a site synthetically. For some site owners, the difference between the initial experience and an an opted-in experience can be extreme due to the presence of third-party JavaScript.

If you were just looking at metrics, the event timeline comparison below may be a bit of a head-scratcher. LCP is deceptively slower in the first view, due to the late render of the consent popup, whose text block is identified as the LCP element. Meanwhile, Time to Interactive (TTI) is much faster. If you look at the highlighted activity timeline, it's apparent that the third-party JavaScript for the opted-in experience creates a lot of additional CPU activity and Long Tasks.

The opted-in experience also loads an additional 73 third-party requests!

5. Interaction to Next Paint (INP) and cookie consent

In his latest blog post on debugging INP, Andy Davies provides an example (#3) of how the interaction of accepting the consent dialog causes high processing time. This is due to the functions called from the Event Handler. Given the recent announcement that INP has replaced First Input Delay as a Core Web Vital, this is certainly something to look out for.

How do I bypass the CMP?

Testing an opted-in experience is highly recommended. This is possible by setting the correct cookie values or in some cases localStorage entries.

If you're a SpeedCurve user, we've created a Scripting Cookie Consents Guide with scripting examples for some of the more common CMPs. This includes LiveRamp, OneTrust, Quantcast Choice, TrustArc and Usercentrics.

If possible, you should test both experiences – pre- and post-opt-in – and treat them as the unique experiences they are.

It's been said before...

Katie Hempenius, Simon Hearne, Sia Karamalegos, Andy Davies and others have done deep dives into this topic. I've learned a ton from them, and frankly repeated a lot of what they said. Again, this is a PSA that warrants over-communication! ;)

Here are some must-reads by these fine folks:

A Complete Guide to Web Performance Budgets

Wed, 27 Mar 2024 00:00:00 +1300

It's easier to make a fast website than it is to keep a website fast. If you've invested countless hours in speeding up your site, but you're not using performance budgets to prevent regressions, you could be at risk of wasting all your efforts.

In this post we'll cover how to:

Use performance budgets to fight regressions
Understand the difference between performance budgets and performance goals
Identify which metrics to track
Validate your metrics to make sure they're measuring what you think they are – and to see how they correlate with your user experience and business metrics
Determine what your budget thresholds should be
Focus on the pages that matter most
Get buy-in from different stakeholders in your organization
Integrate with your CI/CD process
Synthesize your synthetic and real user monitoring data
Maintain your budgets

This bottom of this post also contains a collection of case studies from companies that are using performance budgets to stay fast.

Let's get started!

Why prioritize fighting regressions?

There's a great quote from Michelle Vu (an engineering lead at Pinterest) from her talk at PerfNow a few years ago:

In other words, why work on continuously filling the bathtub if you're not going to plug the drain?

Background: How performance budgets work

1. What is a performance budget?

A performance budget is a threshold that you apply to the metrics you care about the most. You can then configure your monitoring tools to send you alerts – or even break the build, if you're testing in your staging environment – when your budgets are violated.

2. What should a performance budget look like?

A good performance budget chart, such as the one above, should show you:

The metric you're tracking
The threshold you've created for that metric
When you exceed that threshold
How long you stayed out of bounds
When you returned to below the threshold

3. How do you determine budget thresholds?

A good practice is to:

Look at your last 2-4 weeks of data for a given metric
Identify the worst number
Set your performance budget for that number

In the example above, you can see a time series chart that shows Largest Contentful Paint times over a one-month period. The slowest LCP time is 3.55 seconds, therefore the performance budget – represented by the red line – is set for 3.55 seconds. As the person responsible for the performance of this page, you don't want to see it get worse than this while you work to make things faster.

4. Performance budgets vs. performance goals

Your performance budgets are NOT the same as your performance goals.

Performance goals are aspirational. They answer the question "How fast do I want to be eventually?"

Performance budgets are practical. They answer the question "How can I keep my site from getting slower while I work toward my performance goals?"

Let's continue with the example above, where the worst LCP time was 3.55 seconds, making that the most pragmatic performance budget. At the same time, the person responsible for this page might know that they would like the LCP time to be blazing fast at just 1 second or less. That's the goal, but it's not the budget.

It's important to have your 1-second performance goal in mind, but it's not helpful to make that number your performance budget. If you do, you'll end up with a chart that looks like this:

There are a few reasons why this chart isn't helpful:

It's demoralizing. It looks like a history of failure that's intended to shame you, not help you.
It's not actionable. Because you've already violated your budget, you won't get alerts if performance degrades even further.
It's ignorable. Because it's demoralizing and not actionable, you'll quickly learn to ignore it or rationalize it away.

5. Why do you need performance budgets?

Performance budgets mitigate two of the biggest challenges you probably face in your daily life: not enough time, plus too many people touching the site.

You're busy. You don't have time to check your charts daily to make sure your latest deploy hasn't introduced any regressions. After you've set up performance budgets, you can relax knowing that everything is fine until you get an alert in your inbox or Slack channel.

Your site has a number of people contributing content, such as unoptimized images and third-party tags that have the potential to seriously hurt the speed of your pages. You might not know that a new 1MB hero image is suddenly slowing down an important landing page, but the performance budget you created for tracking image weight violations knows.

Now that you understand the "what" and "why", let's talk about getting started with your own budgets.

Get started with performance budgets

6. Which metrics should you start with?

With hundreds of potential performance metrics to track, this is a huge question. While you can (and arguably should) track many metrics across your site, you don't need to set budgets for all of them. In fact, I strongly urge you not to do that.

Instead, I recommend starting with what I call Minimum Viable Budgets.

Even if you create performance budgets for just one or two metrics, that's a great start. That approach lets you:

Get comfortable with the mechanics of budgets
Confirm that your budgets are working (i.e., you're catching regressions in a timely manner)
Teach other people in your organization why these metrics matter
Avoid alert fatigue

Here are a few metrics to consider, and why:

> Backend (Synthetic and RUM)

Also known as Time to First Byte (TTFB), this is the time from the start of the initial navigation until the first byte is received by the browser (after following redirects). Even if you're not responsible for backend time (e.g., you're a front-end developer), it's a good idea to track it because it can delay all your other metrics.

> Start Render (Synthetic and RUM)

Start Render time is measured as the time from the start of the initial navigation until the first non-white content is painted to the browser display. Even if that first visible paint isn't a meaningful amount of content, it's still a useful signal that the page is working, and it can help stop users from bouncing.

People don't talk much about Start Render these days, perhaps because newer, shinier metrics have emerged. But I've participated in many usability studies that have found a strong, consistent correlation between Start Render and business and user engagement metrics such as conversions and bounce rate.

Other things that make Start Render a must-watch: It's available in both synthetic and real user monitoring tools, and it's broadly supported across browsers. This is hugely important if you care about understanding site speed for all your users, not just certain cohorts.

> Largest Contentful Paint (Synthetic and RUM)

Largest Contentful Paint (LCP) is one of Google's Core Web Vitals. LCP is the time at which the largest visible element in the viewport is rendered. It's only tracked on certain elements, e.g., IMG and VIDEO.

However, there are a number of caveats to using LCP, such as the fact that different elements can be measured for first-time versus repeat views, or for desktop versus mobile views.

Also, LCP is only available in Chromium-based browsers. If you have a significant number of users that come in via other browsers, you should consider tracking Last Painted Hero, below.

> Last Painted Hero (Synthetic)

Last Painted Hero (LPH) is a synthetic metric that's measurable in any browser. (Fun fact: Largest Contentful Paint was partially inspired by Last Painted Hero.) LPH shows you when the last piece of critical content is painted in the browser. It's a handy metric for knowing when all your important content has rendered.

> Cumulative Layout Shift (Synthetic and RUM)

Cumulative Layout Shift (CLS) is another one of Google's Core Web Vitals. CLS is a score that captures how often a user experiences unexpected layout shifts as the page loads. Elements like ads and custom fonts can push important content around while a user is already reading it. A poor CLS score could be a sign that page feels janky to your users.

> Interaction to Next Paint (RUM)

Interaction to Next Paint (INP) is another Core Web Vital. INP measures a page's responsiveness to individual user interactions.

Like LCP, INP is only available in Chromium-based browsers, so if you have a significant number of users that come in via other browsers, you should also consider tracking other responsiveness metrics, such as Total Blocking Time (TBT).

> Total Blocking Time (Synthetic)

Total Blocking Time (TBT) lets you know how much time the various scripts on your page are blocking rendering. Because slow JavaScript is a major cause of delayed responsiveness, TBT is a good proxy for responsiveness metrics like INP.

As a bonus, TBT shows you all the Long Tasks on a page. (More on this below.)

> Long Tasks (Synthetic and RUM)

Long Tasks time is the total time of all your JavaScript tasks over 50ms, from navigation start until the page is fully loaded. Tracking Long Tasks will give you a better understanding of the impact that Long Tasks have on the entire page load and your users.

This can be especially handy if you have a lot of third-party tags on your pages, as third parties can be a heavy contributor to excessive Long Tasks time. Because you're measuring in synthetic, you can also get a detailed list of all the scripts on a page, along with their Long Task times.

And if you're wondering, yes, Long Tasks correlate to business metrics like conversion rate.

> Lighthouse Scores (Synthetic)

Google Lighthouse is an open-source tool that checks your page against rules for Performance, PWA, Accessibility, Best Practice, and SEO. For each of those categories, you get a score out of 100 and recommendations on what to fix. It can be a good idea to track your Performance score to make sure you're not regressing, and then if you do experience a regression, drill down into your audits to identify the cause.

> Page Size (Synthetic)

If you're concerned about serving huge pages to your mobile users, or if you're worried about site contributors accidentally publishing huge unoptimized image and video files, then you should consider tracking metrics like page size and weight.

In an ideal world, pages served to mobile devices would be under 1 MB – and definitely not more than 2 MB – but I often see pages in excess of 10 MB. Media sites are particularly prone to this issue.

Above is a content breakdown for the home page of a mainstream news site. The page contains 725 requests and is over 17 MB in size. Looking at the resource breakdown, I would want to set performance budgets on JavaScript weight (8,680 KB) and image size (6,295 KB). Wow!

> Image Size (Synthetic)

As said, if your pages contain a number of images – and if you have multiple content contributors touching your site – a specific performance budget for image size is a highly recommended guardrail.

> Element Timing (Synthetic and RUM)

Similar to LCP, Element Timing measures when a DOM element is rendered. Unlike LCP, Element Timing allows you (rather than Chrome) to decide which elements you want to measure. And unlike LCP, Element Timing allows you to measure more than one element on a page. (Learn more here.)

Element Timing is a somewhat more advanced metric, so if you're just getting started, you might want to make note of it now and come back to it later, when you're ready.

> User Timing (Synthetic and RUM)

You can create custom metrics to track everything from headlines to call-to-action buttons. Twitter has used custom timers to create a Time to First Tweet metric. Pinterest has created a Pinner Wait Time metric. Using the W3C User Timing spec, you can add timestamps around the specific page elements that matter most to you. (Here's how to add custom timers in SpeedCurve.)

Like Element Timing, User Timing requires some expertise to identify what you want to track and then add the timestamps to your pages, as well as ongoing maintenance. Still, they're worth investigating (if not now, then later) if you have the resources and the need.

7. Focus on key pages

You don't need to apply performance budgets to all your pages. When it comes to the impact of page speed on metrics like conversion rate and bounce rate, some pages are more critical than others.

These are some of the key pages for retail, ranked in order of impact:

Product detail
Product category
Shopping cart
Home

And these are some key pages for media and other sites:

Articles
Search
Home

Keep in mind that your budgets will most likely vary from page to page, because the performance of your pages may differ widely due to how each page is built.

8. Get buy-in from different stakeholders

Everyone who touches a page should understand the performance impact of changes they introduce to that page. They should also collaborate on setting performance budgets and remediating budget violations.

For example, if your marketing team is responsible for adding and maintaining third-party tags, they should:

Have a basic understanding of the metrics – such as Long Tasks time – that measure the performance of each tag.
Collaborate on setting the performance budget – again, based on the worst result over the previous 2-4 weeks – for each metric.
Receive alerts (typically via email, Slack, or whatever webhook you use) when the performance budget is violated.
Participate in identifying and fixing the issue (or at least be cc'ed) and get alerted when the budget has been resolved.

In SpeedCurve, you can set up separate dashboards for each stakeholder group in your organization. You can create charts and performance performance budgets within each dashboard, and then configure alerts to be sent only to specific stakeholders.

Below is an example of a dashboard created for an SEO team. It focuses on the Lighthouse SEO score, as well as Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, as those are both Core Web Vitals and therefore important search ranking factors.

A couple of things to note:

For any metrics that are measurable in synthetic and RUM, it's helpful to track them in the same chart. Set the performance budget on your RUM metric so you get an alert when the budget is violated. Then drill down into the synthetic test data to identify and fix the issue. (More on this further down in this post.)
In any of the charts where synthetic test data is collected, you can click on any data point to drill down into your test details where, among other things, you can get detailed audits that recommend what you can fix on the page.

9. Use synthetic testing to visually validate your metrics

The metrics mentioned above are not hard-and-fast suggestions. That's because a metric that is relevant and helpful for one page may not be helpful for another. Before you invest the time and energy in setting up performance budgets for a metric, first take a good look at how that metric aligns with your own data.

The easiest way to validate your metrics is to look at rendering filmstrips in your synthetic test data, like this:

In the example above (taken from our Industry Benchmarks) you can see:

Start Render does correlate to content appearing in the viewport.
Largest Contentful Paint doesn't quite align with the appearance of the largest image.
Last Painted Hero, on the other hand, does align with the largest image.
Visually Complete comes in much later and arguably isn't helpful for this page.

Based on these observations, you might choose to focus on Start Render and Last Painted Hero.

If you need to validate more metrics, you can look at your waterfall chart and see how the various metrics line up with the rendering filmstrip, like this:

Using this view, it's relatively fast and easy to see which metrics work or don't work for a given page. It's important to keep in mind that just because a metric isn't relevant for one page, that doesn't necessarily mean it's a bad metric. Often, any variability you might see is due to how the page is built.

10. Use real user monitoring to validate user engagement and business impact

This is a good way to give yourself the confidence that you're tracking the right metrics. Ultimately, you want to know that changes you make to your site – for better or for worse – will directly affect user behaviour and business outcomes.

This is where real user monitoring (RUM) really shines. RUM can track data about bounce rate and conversion rate (along with other user experience and business KPIs). Using this data alongside your performance data, you can create correlation charts that demonstrate the relationship between performance and business outcomes.

In the correlation chart above, you can clearly see that as LCP times get slower, bounce rate gets worse. This chart demonstrates that, for this particular site, LCP time is a good metric to set a performance budget for.

11. Synthesize your synthetic and real user monitoring data

In an ideal world, you're using both synthetic and real user monitoring (RUM). Several metrics are available in both tools, so you can create charts in which you track the same metric in both synthetic and RUM.

(It's important to know that your synthetic and RUM metrics most likely will not match, for reasons explained here. This is nothing to be concerned about. The important thing to track is consistency and changes within a single tool and settings.)

For a metric that's available in synthetic and RUM, such as Start Render or Largest Contentful Paint, you might want to consider this type of setup:

> Track the metric for synthetic and RUM within the same chart.

> Create the performance budget for the RUM metric, so you get an alert when the budget is violated. This lets you know that real users are experiencing this issue.

> Because you're tracking synthetic data in the same chart, you can easily drill down and get detailed test results and diagnostics.

> Add a note to the chart, stating when you implemented the necessary fixes. After your fixes go live, you can see (and get an alert) when your metric returns to normal.

This is just one potential configuration. If you're using your RUM and synthetic data in other ways, I'd love to learn more about it!

12. Set up alerting (but not too much!)

Avoiding alert fatigue is crucial to the success of your performance budget strategy. If you're just starting out, it's absolutely fine to focus on just a handful of metrics. You can create performance budgets for all of them, but if you're setting up alerting, focus on just setting up alerts for critical metrics such as:

Backend Time
Start Render
Largest Contentful Paint
Image Size

13. Integrate with your CI/CD process

You can integrate your performance budgets and alerts with your CI/CD process. This gives you the ability to do a few of things:

Run synthetic tests in your staging/development environment and get alerts if any changes you've introduced have caused budget violations before the page goes live. You can even opt to break the build if any of your budgets are violated.
Run tests each time you do a deploy, catching issues immediately after they go live.
Run tests against GitHub pull requests, so you can test the performance of your PRs before they're merged.

Keep your budgets relevant

Your budgets will ideally change over time, as your various metrics (hopefully) improve. After you've taken the time to create your performance budgets, you want them to stay relevant and helpful.

14. Update your budgets

If you're taking the practical, iterative approach recommended above, then you should revisit your budgets every 2-4 weeks and adjust them (hopefully downward) accordingly.

You should also periodically revisit your metrics – going through the validation steps described in steps 9 and 10 above – to make sure you're still tracking the right things go through the validation Are you still tracking the right metrics?

15. Celebrate wins!

If you consistently improve a metric and have just updated your budget, share your charts and let your teams (and your boss!) know. It's important to celebrate even small wins, because big wins are rare. Performance improvement is cumulative. Getting faster should always be celebrated!

Case studies

Here's how some of our customers have used performance budgets to stay fast:

More resources

If you're a SpeedCurve user, these resources will help you get started with performance budgets. If you're not using SpeedCurve yet, signing up for a free trial is easy!

(This post has been updated from an earlier version published in May 2023.)

Navigate your way to better performance with prerendering and the bfcache

Mon, 25 Mar 2024 00:00:00 +1300

I was inspired by Tim Vereecke's excellent talk on noise-cancelling RUM at PerfNow this past November. In this talk, he highlighted a lot of the 'noise' that comes along with capturing RUM data. Tim's approach was to filter out the noise introduced by really fast response times that can be caused by leveraging the browser cache, prerendering, and other performance optimization techniques.

I thought Tim's focus on 'human viewable navigations' was a great approach to use when looking at how to improve user experience. But there also may be times when you want to understand and embrace the noise. Sometimes there are opportunities in the signals that we often forget are there.

In this post, I'll demonstrate how you can use SpeedCurve RUM to identify all types of navigations, their performance impact, and potential opportunities for delivering lightning-fast page speed to your users.

We'll cover things like:

Understanding SPA navigations and performance
Whether or not to track hidden pages (such as pages opened in background tabs)
How to take advantage of prerendering and the back-forward cache (aka bfcache)

Understanding navigation types

We've recently released a new filter in RUM that allows you to explore navigation types. You can find navigation types in the filters of your RUM and Favorites dashboards:

The different navigation types we track are:

Navigation – Full-page navigation

Reload – Page is reloaded from the browser history

Back-Forward Navigation – Page navigation using back/forward navigation (also known as bfcache navigation) controls

Other – All other navigations

Not all navigations are created equal.

For example, full-page navigations have very different characteristics than bfcache navigations. It's helpful to see this in a histogram, where we can see the distribution for each navigation type for a metric such as Largest Contentful Paint (LCP):

Understanding slow page reloads

In doing research for this post, I have to admit that I had an 'uh-oh' moment. Looking at the reloads from the previous chart on the surface was a bit of a head-scratcher:

How could LCP be so much slower on a reload versus a full-page navigation?

After a closer look at the histogram, I noticed there were a lot of reloads that happen to be slower in the long tail of the histogram:

When comparing the fast versus slow reloads, I found that these reloads were for our RUM Live dashboard. This dashboard forces a reload automatically. This was for a specific user who was loading the page on a very slow connection.

Lesson learned: Segmenting your pages in to cohorts is extremely helpful when exploring anomalies like this one.

Introducing Page Attributes

Another useful filter that we recently added is for something we refer to as Page Attributes. This goes a step further in explaining the different types of navigations – both visible and hidden from the end user.

This is extremely useful when looking at pages that have unique performance characteristics including:

Page was a soft navigation – When implementing RUM for a SPA, you can use this attribute to compare initial page loads/hard navigations to SPA/soft navigations.

Page visibility was hidden* – For pages that are loaded in a hidden state, such as when you open a link in a background tab for viewing later, the performance can vary greatly given the browsers ability to mitigate resource consumption in an effort to preserve the user experience.

Page was prerendered – Prerendering can happen automagically in the browser or by using the Speculation Rules API . When this occurs, pages that are activated appear to load instantaneously and have unique characteristics compared to other types of navigations. For example, in SpeedCurve, prerendered pages will have a value of '0' for most metrics.

Page was restored from back-forward cache* – The bfcache essentially stores the full page in memory when navigating away from the page. This browser optimization has the effect of instantaneous page loads when a user is navigating back (or forward) to a previously viewed page.

*Important: Currently you need to opt-in for tracking of hidden pages and bfcache restores. This is an option in your advanced RUM settings.

Understanding your SPA performance

Single-page application (SPA) performance can be hard to get your head around. The benefits of a SPA can sometimes be hindrances when you are trying to understand the user experience. In a SPA soft navigation (versus a full-page navigation), you don't always get the metrics you are looking for, such as render metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Often you'll have to revert back to traditional timing metrics or those that are triggered by using custom metrics.

This custom metric comparison illustrates that performance characteristics can be drastically different between soft navigations and full-page navigations:

The differences between the full and soft SPA navigations can have a big impact on other derived metrics as well, such as user happiness:

Hidden pages: To track or not to track?

If a tree falls in the forest, does anybody hear? By default, SpeedCurve does NOT track pages that are hidden from the user, such as a page opened in a background tab. However, you may want to understand if those pages are having issues.

Be warned that rendering of hidden pages is deprioritized by the browser when trying to conserve resources, which may or may not have something to do with your site. The charts below illustrate that, all things equal, hidden pages are more than a second slower to load than visible navigations.

Take advantage of prerendering

Prerendering pages based on where you expect users to click next may sound a little creepy, but it sure does make your user experience a lot faster. In this example of product pages for a major online retailer, prerendered pages were 200% faster than full navigations:

What is this mysterious prerendering magic we speak of, and how do you take advantage of it? Prerendering has been around in Chrome for a little while, but just recently the Speculation Rules API was introduced, which supersedes the now deprecated <link rel="prerender">.

Using prerender json instructions within <script type="speculationrules">, browsers will prefetch and load the page into memory cache, making subsequent navigations appear instantaneous.

Chrome also uses prerendering for addresses typed into the omnibox for pages with a high confidence. The search bar may also leverage prerendering, depending on the provider.

Barry Pollard provides a comprehensive overview of the ins and outs of prerendering here.

Putting the BF (blazing fast) in BFCache

Another notable cheat code for web performance is the use of the browser's bfcache, which essentially stores the fully rendered page in memory. Used in the aforementioned back/forward navigation, if the page is in the bfcache, you're in for another 'instant' page load.

Bfcache is available in all modern browsers. As shown here, the performance difference between a full-page navigation and a bfcache restore – 2.59 seconds versus 0.07 seconds – is pretty impressive!

If you are a Lighthouse user or familiar with the audits provided in SpeedCurve, you may have noticed the following audit as of Lighthouse 10:

For Chrome, there are a number of reasons why a bfcache restore may fail. Some of them are within your control, while others are not. Here is a great resource for understanding how to optimize your pages for bfcache.

Important: The criteria for a page entering the bfcache is different between Chrome and other browsers. Safari has been leveraging bfcache for quite some time and appears to be far less restrictive.

For the same site listed above – which failed the bfcache audit – Safari (desktop and mobile) has a very large number of bfcache restores, while Chrome and Firefox are missing all together!

Get started

Low-hanging fruit tastes the best. While everything else you're doing to speed up your pages is by no means a wasted effort, understanding how to leverage the browser in a more effective way for repeated navigations is totally worth it!

If you're already using SpeedCurve RUM, then you can take advantage of all the insights described in this post. If you're not using our RUM yet, we'd love to have you try it! Sign up for your free trial and follow the steps in our welcome guide to get started.

Hello INP! Here's everything you need to know about the newest Core Web Vital

Tue, 12 Mar 2024 00:00:00 +1300

After years of development and testing, Google has added Interaction to Next Paint (INP) to its trifecta of Core Web Vitals – the performance metrics that are a key ingredient in its search ranking algorithm. INP replaces First Input Delay (FID) as the Vitals responsiveness metric.

Not sure what INP means or why it matters? No worries – that's what this post is for. :)

What is INP?
Why has it replaced First Input Delay?
How does INP correlate with user behaviour metrics, such as conversion rate?
What you need to know about INP on mobile devices
How to debug and optimize INP

And at the bottom of this post, we'll wrap thing up with some inspiring case studies from companies that have found that improving INP has improved sales, pageviews, and bounce rate.

Let's dive in!

What is Interaction to Next Paint?

"Chrome usage data shows that 90% of a user's time on a page is spent after it loads. Thus, careful measurement of responsiveness throughout the page lifecycle is important. This is what the INP metric assesses."

~Jeremy Wagner, Google

In other words, we need a reliable metric that helps us understand how a page's responsiveness (or lack thereof) during the entire time a user is on the page helps (or hurts) their experience.

When you interact with a page, you want the page to respond seamlessly. The longer the wait, the worse the user experience, as you start wondering if the page is broken and start anticipating a frustrating, laggy experience. (This frustration is hardwired, as you can learn in this post about the psychology of site speed and human happiness.)

This is where measuring Interaction to Next Paint can help. INP measures the time from when a user starts an interaction – such as a mouse click, touchscreen tap, or physical or onscreen key press – until the next frame is painted in the browser. The faster the INP time, the more seamless the interaction feels.

According to Google, an INP of 200 milliseconds or less is ideal. Having said that, you may wish to aim for a faster INP for your own pages, for reasons I'll go into further down in this post.

In this excellent post, Jeremy Wagner explains how Interaction to Next Paint is calculated and how Google's INP thresholds (pictured above) are determined.

Farewell, First Input Delay!

Before we go any further, you might find it interesting to learn a bit more about First Input Delay (FID), the interactivity metric that preceded INP in Core Web Vitals, and why it was deprecated.

Here at SpeedCurve, we definitely get excited about emerging metrics. But we also approach each new metric with an analytical eye. Way back in 2020, Cliff Crocker took a closer look at First Input Delay and found that FID did not meaningfully correlate with actual user behaviour.

Does INP correlate to user behaviour?

The point of measuring responsiveness is because unresponsiveness hurts the user experience – which ultimately hurts your business metrics, such as bounce rate and conversions. If this is true, then we should be able to draw a direct line between Interaction to Next Paint and business metrics.

This is where correlation charts come in super handy.

Correlation charts give you a histogram view of all your user traffic, broken out into cohorts based on performance metrics such as INP. The chart also includes an overlay that shows you a user engagement metric or business metric – such as bounce rate or conversion rate – that correlates to each of these cohorts. This lets you see at a glance the relationship between performance, user engagement, and your business.

A few months ago, Cliff Crocker turned his attention to analyzing INP. In his exploration of INP's correlation to conversion rate for a handful of different sites, Cliff found that yes, there typically is a correlation: when INP gets worse, conversions suffer.

However, Cliff also made the following observations:

Results vary across sites – Not surprisingly, the impact is different based on the slope of the conversion line, as well as the distribution of INP across user sessions.
There is no consistent correlation with Google's thresholds for 'Good', 'Needs Improvement', and 'Poor'. This is a hugely important observation. As Cliff states: "For one site, conversions suffer when INP is 100ms – well within Google's 'good' parameter of 200ms. This doesn't mean it's a bad idea to have a general set of thresholds. It just means those thresholds might not apply to your site. You must look at your own data."

Mobile INP is really important!

After further analysis, Cliff discovered still more important INP insights, including:

1. Only two-thirds of mobile sites have 'good' INP

Looking at data from the HTTP Archive, which tracks performance metrics for the top million sites on the web, the percentage of sites that have good INP is 96.8% for desktop, but only 64.9% for mobile. One of the biggest culprits: latency, which is typically worse on mobile.

2. Mobile INP = Android INP

This is due to the lack of Safari support for INP (among other performance metrics). If a significant number of your users are coming to you from Safari, you need to track a different responsiveness metric.

3. Mobile INP has an even stronger correlation with bounce rate and conversions than desktop INP

You can see this in the charts below. Ignoring mobile responsiveness isn't something most of us can afford to do.

One of the many important takeaways from this post is that responsiveness on mobile is absolutely crucial to business and UX metrics. But if you're focusing on just INP to measure responsiveness, you're only getting insights into mobile performance for just one cohort of your users.

How to debug and optimize INP

Now that you understand how slow INP hurts your users and your business, let's talk about solutions. In this in-depth post, Andy Davies walks through what INP is, how to identify and debug slow interactions, and some approaches he's used to improve them.

"Many sites tend to be in the 'Needs Improvement' or 'Poor' category. My experience over the last few months is that getting to 'Good' (under 200ms) is achievable, but it's not always easy."

In his very detailed and comprehensive post, Andy walks through:

How he helps people identify the causes of poor INP times
Examples of some of the most common issues
Approaches he's used to help sites improve their INP

INP case studies

The best way to understand the importance of optimizing INP is to look at your own RUM data for your own site. The second-best way is to look at case studies from other companies that have had success. Here's a handful for you to check out:

Trendyol reduced INP by 50%, resulting in a 1% increase in click-through rate
redBus improved INP and increased sales by 7%
The Economic Times reduced INP from 1s to 257ms, leading to a 50% decrease in bounce rate and 43% increase in pageviews

Takeaways

1. You definitely should be monitoring Interaction to Next Paint for your site, ideally using real user monitoring as the best source of truth.

2. You may find it helpful to create correlation charts to validate INP as a meaningful business-related metric.

3. When you create correlation charts, take careful note of when your business metrics start to suffer. Even though Google's recommended 'Good' INP threshold is 200 milliseconds, good INP for your own site may be higher or lower than that.

4. Look at INP separately for mobile and desktop. Your numbers could be quite different. You may also find that INP correlated to business metrics differently in each environment.

5. Think beyond INP. This is crucial if you have a lot of users coming to your site from different browsers. Remember that INP is only supported in Chrome-based browsers.

How to monitor INP in SpeedCurve

If you're not already using our RUM to monitor INP alongside your other important metrics, we'd love to have you give us a try!

Start your free 30-day trial
Follow our handy guide to enabling RUM
Create your Core Web Vitals dashboard (it's easy!) so you can get alerts when any of your metrics start to suffer
Check out our guide to debugging INP
Understand INP subparts so you can quickly home in on issues
Contact us at support@speedcurve.com with questions or feedback