SpeedCurve Blog

How to provide better attribution for your RUM metrics

Tue, 03 Sep 2024 00:00:00 +1200

Here's a detailed walkthrough showing how to make more meaningful and intuitive attributions for your RUM metrics – which makes it much easier for you to zero in on your performance issues.

Real user monitoring (RUM) has always been incredibly important for any organization focused on performance. RUM – also known as field testing – captures performance metrics as real users browse your website and helps you understand how actual users experience your site. But it’s only in the last few years that RUM data has started to become more actionable, allowing you to diagnose what is making your pages slower or less usable for your visitors.

Making newer RUM metrics – such as Core Web Vitals – more actionable has been a significant priority for standards bodies. A big part of this shift has been better attribution, so we can tell what's actually going on when RUM metrics change.

Core Web Vitals metrics – like Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) – all have some level of attribution associated with them, which helps you identify what exactly is triggering the metric. The LoAF API is all about attribution, helping you zero in on which scripts are causing issues.

Having this attribution available, particularly when paired with meaningful subparts, can help us to quickly identify which specific components we should prioritize in our optimization work.

We can help make this attribution even more valuable by ensuring that key components in our page have meaningful, semantic attributes attached to them.

How the browser handles attribution

When a metric that has some level of attribution associated with it – like LCP or INP – is triggered, the browser provides us with the element that triggered the measurement.

For the Largest Contentful Paint (LCP) metric, for example, attribution is provided in the element property.

For Interaction to Next Paint (INP), attribution comes in the form of the target property:

In either case, the browser will provide us with a selector for that specific element containing any class or ID attributes that may be applied.

Consider the following three links:

If the first link is clicked and triggers an INP, we will get a target of a.btn-primary. For the second link, the browser will return a#myLink. For the third, since there are no classes or IDs to provide, the browser will simply provide us with a target of a .

Already, there’s a meaningful difference in what we see for attribution. Since IDs are required to be unique on a page, we can quickly grab the #myLink attribute and figure out which element is responsible.

The other two targets are not as clear. There could be any number of links on our page triggering the a target, and classes are not required to be unique, so we could be staring at a bunch of a.btn-primary's in our page as well.

At this point, many RUM providers (like SpeedCurve) will try to help you out by walking back up the elements in your page to provide you with a more complete and specific path to the target element.

To do this, they will start by fetching the parent element of the target element, and record both the type of element and any classes or IDs associated with it.

For example, consider the following markup:

The browser will provide us with a target of a.classButton, but many RUM providers (ourselves included), will walk up the DOM and provide you with an element selector of:

div.main>div.large>p.center>a.classButton

The goal is to provide you with as unique a path as possible to help you pinpoint exactly which element on your page is involved.

In SpeedCurve, that attribution is provided for both LCP and INP so you can quickly identify exactly what components are impacting your performance. Here’s an example heatmap from SpeedCurve showing this selector in action:

Some of these selectors (#playBtnStartIcon, #cmpWrapper , etc) are fairly intuitive. But notice the complex path to some of the other INP triggers.

For example, we could probably figure this out, but it’s going to take us hopping into the source of the page to drill into what element exactly is triggering this one:

article.article-body.prose.max-w-none.pb-7.pt-5.prose-figure:max-w-full.prose-ol:pl-10>p>a

In this case, the browser wasn’t even able to find a class name so we just get a series of div selectors that is going to be tricky to hunt down:

div>div>div>div>div>div>div>div>div

Contrast that with the attribution for the play button (#playBtnStartIcon). This selector is immediately intuitive (and short!) because we had a meaningful ID on the element itself, so there was no need to walk up the DOM and get a long list of selectors.

Making attribution meaningful

We can make it much easier for ourselves to quickly identify what elements are involved by ensuring that key components on our page have meaningful flags for attribution.

With SpeedCurve, there are two ways of accomplishing this:

providing a relevant `id` attribute
using the `data-sctrack` attribute

Using a relevant `id` attribute

One option we have is to provide an id attribute on our key components. While SpeedCurve is working to provide you with a meaningful selector, as soon as an element with an id is discovered, we will stop walking up the DOM. The id attributed is required to be unique, so we’re able to provide just that.

You’ve already seen an example of this where the target element itself had an ID directly applied to it, but this also works for shortening the selector in general.

Let’s revisit our markup from earlier, but this time we’ll add an ID to our entry paragraph:

The browser will still provide a target of a.classButton, but now SpeedCurve will walk up the DOM, see the unique ID and provide a much more intuitive element selector of #heroParagraph>a.classButton .

Using the `data-sctrack` attribute

In SpeedCurve, we provide you with an alternative approach to attribution, in case you would rather not sprinkle a bunch of ID’s throughout your markup.

Our RUM script will also look for the data-sctrack attribute while trying to generate our element selector.

There’s one important difference here between how data-sctrack and id are used. In the case of id, we treat that attribute as part of a selector path. If we find a data-sctrack attribute, however, we will simply provide the value of that attribute—not a full selector path.

For example, in the previous markup, the element selector provided was #heroParagraph>a.classButton. If, however, we adjusted our markup to use a data-sctrack attribute like so:

The element selector we would provide would be heroParagraph , not the full path to the link itself.

Neither approach is necessarily inherently better than the other. It comes down to your specific approach to markup, and the components you’re using.

In either case, however, providing unique id ’s or data-sctrack attributes on your page will result in much more meaningful and intuitive attribution, making it much easier for you to zero in on your performance issues.

NEW: Paper cuts update!

Mon, 19 Aug 2024 00:00:00 +1200

Paper cut: (literal) A wound caused by a piece of paper or any thin, sharp material that can slice through skin. (figurative) A trivial-seeming problem that causes a surprising amount of pain.

We all love big showy features, and this year we've released our share of those. But sometimes it's the small stuff that can make a big difference. We recently took a look at our backlog of smaller requests from our customers – which we labelled "paper cuts" – and decided to dedicate time to tackle them.

Are they all glamorous changes? Maybe not, though some are pretty exciting.

Are they worthy of a press release? Ha! We don't even know how to issue a press release.

Will they make your day better and put a smile on your face? We sure hope so.

In total, our wonderful development team tackled more than 30 paper cuts! These include:

Exciting new chart types for Core Web Vitals and User Happiness
Filter RUM data by region
Create a set of tests for one or multiple sites or custom URLs
Test directly from your site settings when saving changes
Usability improvements
Better messaging for test failures
And more!

Keep scrolling for an overview of some of the highlights.

On-demand testing updates

This has been an area we've focused on a lot this year. We made a lot of updates to the Test Now functionality back in February of this year. One of the biggest requests from our users was the ability to test a single url within a site. Using the 'Test Now' modal, you can now select anywhere from one to many URLs to test on demand.

In addition, we've given you the ability to test directly from your site settings when saving changes.

If you are a user of our API, make sure you check out the new snapshots endpoint in our v2 API (currently in beta). This endpoint provides the ability to create a set of tests for one or multiple sites or custom URLs.

UI updates

Okay, so maybe this one is a little more flashy than we let on. We've updated our User Happiness and Core Web Vitals RUM time series charts to 100% stacked column charts in our Performance and Users dashboards. This gives you the ability to see the distribution of users in each bucket of User Happiness, as well as thresholds for Core Web Vitals.

In addition, we've added page views time series data to our Core Web Vitals time series charts. This is incredibly helpful and adds a layer of context to the data. A common pattern is seeing metrics degrade during low traffic times due to the size of the sample, caching inefficiency (for example, cold CDN cache), and routine maintenance.

Regional performance

We've had the ability to segment data by country since the inception of RUM. We are now exposing the second-level geography (region) in our tables in the Performance dashboard. For customers looking to move more to the edge and get the most from their investment in distributed computing and content delivery networks, having an understanding of how pages perform within the borders of a country is extremely useful.

A whole lot more...

There were more than 30 paper cuts tackled by our wonderful development team. These included usability improvements, better messaging for test failures additional filtering options and more. We hope you enjoy these updates. We really enjoyed tackling them.

Have a paper cut you'd like us to tackle? Let us know!

NEW: Improving how we collect RUM data

Wed, 07 Aug 2024 00:00:00 +1200

We've made improvements to how we collect RUM data. Most SpeedCurve users won't see significant changes to Core Web Vitals or other metrics, but for a small number of users some metrics may increase.

This post covers:

What the changes are
How the changes can affect Core Web Vitals and other metrics
Why we are making the changes now

What's changing?

By default, SpeedCurve RUM used to send its main beacon shortly after the load event fires, another soon after the visitor first interacts with the page, and then further beacons as User Timing marks and measures (AKA custom metrics) are added.

This approach was sound when our main focus was measuring how quickly pages loaded or routes changed. But newer metrics – such as Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP) – don't stop at page load or first interaction. As a result, they need to be measured throughout the entire lifecycle of the page.

To work around some of the limitations of the current approach, we've added options that allow sites to delay when they send the beacon, but these must be implemented on a site-by-site basis – which isn't ideal.

Starting August 7, 2024, we've improved our defaults. Now performance metrics will be captured for longer and beacons will be sent at the earliest of 60 seconds after page load starts, or when the visitor leaves the page if that happens sooner.

Sites such as SPAs, which use LUX.auto = false to control when they send the beacons themselves, are opted out of our default behaviour and won't see any changes.

To understand which metrics are affected and how much they change, we've run the old and new measurement pipelines in side-by-side and compared the data each produces.

How your Core Web Vitals may change

Most customers won't see significant changes to Core Web Vitals or other metrics, but for a small number of customers some metrics will increase.

Some metrics are fixed at the point they're measured, while others can change with time or as a result of user interaction.

First Contentful Paint is an example of a metric that's fixed in time. It's the timestamp of when the browser first displayed content. Because there is only ever one first paint, it can't change after that point.

Other metrics can change. A page can display a larger image, content can move around, and visitors can trigger slower interactions.

Sending the beacon later means we have a longer window to watch for changes to these metrics, and in some cases we can capture changes that we could not detect previously.

The metrics that we've seen increase for some customers are:

Largest Contentful Paint (LCP)
Cumulative Layout Shift (CLS
Interaction to Next Paint (INP)

Here are some examples of things we've come across that can lead to metrics increasing as a result of sending the beacon later:

Largest Contentful Paint (LCP)

LCP stops being measured when there's an Input Event (click, tap or keypress) or the visitor scrolls the page.

Hover Events aren't classed as Input Events. If a Hover event triggers a larger image to be loaded or a larger text paint, that can cause LCP to increase.

Two examples where we've seen LCP increase due to visitor interaction:

Product pages that show zoomed product images on hover
Desktop 'mega-menus' where the images embedded in it are larger than the main images on the page

Here's an example from a retailer's category page. The promotional banner at the bottom of the menu is larger than the product cards. As a result, the banner will become the LCP element when the menu is shown.

Promotional banner becomes LCP element when a visitor hovers on the menu

The hover behaviour is a known 'gotcha' for LCP. If you're interested in following how it might change in the future, there's an issue against the specification that discusses it further.

The other common case where we've seen LCP increase is when a script triggers a late large paint, for example by displaying a dialog for a consent manager or an email subscription popup.

These examples highlight that LCP doesn't always measure the most important content. This is why I encourage sites to use Element Timing to measure the visual elements that really matter to their user experience.

Cumulative Layout Shift (CLS)

Layout shifts that are triggered within 500ms of a user's interaction are ignored for CLS; however, scrolling is not considered an interaction for CLS purposes, so content that moves around or changes size as someone scrolls will create new layout shifts and potentially a higher CLS score.

News sites – where advertisements are lazy-loaded or refreshed as the page scrolls and the advert creative is larger than the space reserved for it – are an example where CLS scores can get worse due to the longer measurement time.

Here's a news article where an ad creative loads on scroll. The publisher has reserved space for the ad unit, but the creative that loads is larger than the space. As a result, there's a layout shift as the content below the ad is pushed down.

Layout Shift triggered by an lazy loaded advert whose creative is larger than the space reserved for it

Scripts that are triggered by the load event, or a long timer and insert content into the page, are another example where CLS may increase.

Interaction to Next Paint (INP)

Visitors may interact with a page more than once. A shopper might examine different images of an item before adding it to their basket. Someone might like multiple posts on a social network before responding to one of their friends. There's no guarantee which of these interactions will generate the highest INP time.

By extending the wait before we send the RUM beacon, we're more likely to capture the slowest and most annoying interaction on the page.

Why we changed our approach

We identified that we needed to capture data for a longer time a while ago, but constraints in our RUM processing pipeline made it difficult to implement.

Our existing pipeline has served us well. Using Fastly's beacon termination service to capture and forward RUM data, and VCL to enrich it, has proved really robust over the last eight years. But as our product has grown and new metrics have been introduced, the pipeline has become more complex. As a result, we've started to run into the pipeline's limitations more frequently.

We knew that sooner or later we'd need to re-engineer the pipeline. As part of adding diagnostics for Core Web Vitals, we've re-implemented the pipeline using Fastly's edge compute. (We're saving a deeper overview of our new pipeline for another post.)

Sending the beacon later has a number of benefits, now and down the road:

Improves the accuracy of the metrics we're capturing
Allows us to simplify our RUM processing pipeline
Made it easier to implement attribution for INP and LCP
Smooths the way for adding other features we have planned for the future

That sounds like a win for everyone.

If you've any questions about the changes, or notice something in your data that you can't explain we'd love to hear from you. Send us a note at support@speedcurve.com.

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: