SpeedCurve Blog

NEW! SpeedCurve RUM for your Magento projects

Thu, 19 Jun 2025 00:00:00 +1200

Now you can integrate robust real user monitoring into your Magento project in minutes!

As a product manager, I have to say there are few things more flattering than having our users build apps that empower other folks to use our product.

Hot on the heels of our SpeedCurve RUM for Shopify app is a new open‑source Magento module – from Jesper Ingels and the awesome team at Bluebird Day – that lets you integrate SpeedCurve real user monitoring into your Magento project in minutes – no coding required!

Keep reading to learn the benefits of gathering real user data and how to get started.

The SpeedCurve Magento 2 module is designed for standard Magento 2 front-end themes (Luma-based or custom themes using Layout XML, RequireJS, etc.).

With this module, you can:

Enter your SpeedCurve RUM ID (available on your Settings page) and the RUM script loads automatically on your pages
Configure all settings via the Magento Admin Panel, including RUM ID, page labels, and cookie consent handling.
Manage page labels for product and category pages
Insert the RUM script only after the visitor accepts cookies (privacy‑proof!)
Immediately start tracking Core Web Vitals and other critical RUM metrics
Measure the impact of page slowdowns on your business
Fight regressions with performance budgets and alerts
Get detailed recommendations for fixing performance issues

If you've tried the module, we'd love to hear your thoughts! Send us a note at support@speedcurve.com.

How to enable SpeedCurve in your Shopify store

Thu, 12 Jun 2025 00:00:00 +1200

SpeedCurve now has a Shopify app to make installing and using SpeedCurve in your Shopify store much easier. With this app, you can quickly set up real user monitoring – no coding required.

Here's how to install the SpeedCurve RUM app in your Shopify store, along with troubleshooting and next steps.

In ecommerce, speed isn’t just nice to have – it’s a competitive advantage. Slow websites lead to frustrated users, lost sales, and damaged brand trust. With the SpeedCurve RUM app for Shopify, you can track metrics like Core Web Vitals, identify performance issues, measure the impact of site speed on conversion rates, and stay ahead of page slowdowns – no coding required.

How to install and use SpeedCurve RUM

1. Create your SpeedCurve account

If you don't already have an account, it's easy to create a free 30-day trial. (No credit card required!)

2. Install the SpeedCurve RUM Shopify app

If you haven't yet done this, install the SpeedCurve Shopify app.

3. Connect the Shopify app to your SpeedCurve account

First, copy your SpeedCurve RUM ID from your SpeedCurve settings. It will be listed under "RUM", near the bottom of the settings page.

Then open the SpeedCurve app in your Shopify Admin Dashboard. Go to the Settings page and and paste in your RUM ID (step 2 in the image below). Click the 'Save RUM ID' button.

4. Enable SpeedCurve in your theme

Shopify app embed blocks are not automatically enabled, so you will have to enable it manually. The easiest way to do this is to click the magic link button from that settings page to open the embed block:

This will open the theme editor with the embed block selected. The last step is to toggle the embed to true:

Optional automatic page labels

Most stores will want to keep the automatic page labels enabled, which is the default setting. However, if you’re an existing customer with page labels already set up or you have more complex page labeling requirements, you can disable this setting under the advanced settings:

If you disable automatic page labels, you will need to set up your own. For the documentation on setting up page labels, see RUM page labels and URL rules.

Troubleshooting

The most common issue is no data being collected. This could be caused by:

Your RUM ID may not be saved correctly in the app. Make sure you follow step 3 above, ensuring the correct RUM ID is saved. You can confirm this is the case if you are able to open up the browser console on your store and see the message “SpeedCurve RUM error 160: Invalid `id` parameter specified in lux.js URL.”
The app embed block may be disabled. Follow step 4 above to make sure the app embed block is enabled (toggled to the right).

You can see RUM troubleshooting topics if you have additional issues, or email us for support at support@speedcurve.com.

Next steps

You may want to collect additional custom data that is available from Shopify. For more details, see Capturing custom data from Shopify.

The Web Performance Guide for Retailers is your resource for understanding web performance and how to optimize for increased conversions.

Questions or feedback? Don’t hesitate to reach out at support@speedcurve.com.

Sia Karamalegos is a web performance engineer and consultant, creative technologist, and systems thinker. At Shopify, she enhanced merchant sites and the Shopify platform for Core Web Vitals performance. She is a Google Developer Expert in Web Technologies, as well as a Cloudinary Media Developer Expert.

NEW! SpeedCurve RUM for your Shopify store

Thu, 12 Jun 2025 00:00:00 +1200

If you run a Shopify store, you already know how critical it is to provide a seamless shopping experience. That's why I was so excited when the folks at SpeedCurve asked me to draw on my Shopify experience to build their new RUM app for Shopify storefronts. Now I'm here to let you know how it works and why it's an important part of your UX toolset.

In ecommerce, speed isn’t just nice to have – it’s a competitive advantage. Slow websites lead to frustrated users, lost sales, and damaged brand trust.

With the SpeedCurve RUM app, you can track metrics like Core Web Vitals, identify performance issues, measure the impact of site speed on conversion rates, and stay ahead of page slowdowns – no coding required.

> How to enable SpeedCurve RUM in your Shopify store

Site speed is critical in ecommerce

Before we dig into the new SpeedCurve RUM details, let’s cover why front-end web performance is so important for online stores.

Poor performance increases bounce rate

Shoppers are impatient. A delay of just one or two seconds can cause potential customers to abandon your site.

In the SpeedCurve correlation chart below, we can see that when websites take longer to start showing content in the browser (AKA Start Render), users are more likely to bounce. Lower bounce rates mean more opportunities to convert.

For this data set of visits from mobile users, bounce rate is lowest (5%) when render starts within 0.4 seconds. It climbs almost linearly until 2.5 seconds, which has a 38% bounce rate.

Poor performance decreases conversions

Performance improvements directly correlate with sales. For example:

“Carpe improved Largest Contentful Paint by 52% and Cumulative Layout Shift by 41% and saw a 10% increase in traffic, a 5% increase in online store conversion rate, and a 15% increase in revenue.”

~ Mateusz Krzeszowiak, Web Performance Technical Architect at Shopify (source)

Speed isn’t just about improving user experience. It’s about increasing conversions, and ultimately revenue. This SpeedCurve correlation chart shows conversion rate peaking at a start render time of 0.6 seconds. As user sessions get slower, conversions decline.

The cohort of mobile users who experienced Start Render times of 0.6 seconds had the highest conversion rate (13%). As pages get slower for this site, conversion rate quickly decreases. At 1.9 seconds, conversion rate plateaus at about 2%.

Slowdowns can cost more than downtime

Downtime gets all the attention, but “slowtime” is often just as damaging and harder to notice. Visitors rarely wait around when pages load at a crawl.

How real user monitoring (RUM) with SpeedCurve can help you

SpeedCurve is uniquely positioned to give you a full picture of your web performance and how it affects user behavior. By combining synthetic testing and real user monitoring, you can learn exactly how long your pages are taking to load for real users and then get the optimization recommendations you need to diagnose and improve performance.

Until now, if you were a Shopify merchant without a developer, you probably relied on synthetic testing like Lighthouse or PageSpeed Insights. With the new SpeedCurve RUM app, you can easily add real user monitoring, which unlocks the full potential of SpeedCurve.

RUM gives you visibility into how your actual customers experience your site. With RUM, you can:

Correlate key business metrics with performance – Out of the box, SpeedCurve RUM shows you correlation charts (like those used above) between your performance and bounce rates. With a little extra setup, you can also create correlation charts for conversion rate, cart size, A/B tests, and more.
Pinpoint problems with data – Without data, optimizing your site feels like guesswork. RUM provides real, actionable insight into where performance breaks down on real user devices, so you can fix it faster and more confidently.
Segment web performance data by page type, device, and more – SpeedCurve gives you the power to segment data, track performance trends over time, and see exactly how different parts of your site perform for different users.
Track improvements and spot new issues – Once you've addressed current issues, SpeedCurve helps you stay ahead with weekly reports and real-time alerts, set according to your notification preferences. Never miss a performance regression again!

Easy setup, no developer required

You no longer need to dive into code or wait for a web or theme developer to set up performance monitoring for you. The new Shopify app makes RUM setup as simple as a few clicks.

No developer required

The installation is non-technical. Here's how to install SpeedCurve RUM in just four steps.

Get useful data immediately

Once the app is installed, SpeedCurve begins collecting real user data right away, giving you insights within minutes.

Friendly support when you need it

Whether you hit a snag or just want advice, SpeedCurve's super-friendly performance experts are there to help. Just send them a note at support@speedcurve.com.

Add RUM to your Shopify store – for free

It’s free to install and explore the SpeedCurve Shopify app. Start collecting real user performance data today and unlock new ways to improve speed, conversion, and user experience.

If you're already a SpeedCurve Synthetic user – Install the SpeedCurve RUM app via your Shopify dashboard, and then connect the app to your SpeedCurve account. Here's how to get setup in minutes.

If you're not a SpeedCurve user yet – Sign up for your free trial and then install the app.

Sia Karamalegos is a web performance engineer and consultant, creative technologist, and systems thinker. At Shopify, she enhanced merchant sites fand the Shopify platform for Core Web Vitals performance. She is a Google Developer Expert in Web Technologies, as well as a Cloudinary Media Developer Expert.

The Definitive Guide to Long Animation Frames (LoAF)

Mon, 19 May 2025 00:00:00 +1200

With Long Animation Frames (commonly referred to as LoAF, pronounced 'LO-aff') we finally have a way to understand the impact of our code on our visitors' experiences.

Long Animation Frame – a frame that took longer then 50ms from its start to when it started painting

LoAF allows us to understand how scripts and other tasks affect both hard and soft navigations, as well as how scripts affect interactions. Using the data LoAF provides, we can identify problem scripts and target changes that improve our visitors' experience. We can also finally start to quantify the impact of third-party scripts as they execute in our visitors' browsers.

Keep reading to learn:

Why animation frame rate matters
Anatomy of a Long Animation Frame
Key LoAF milestones and what we can do with milestone data
Script attribution (and why script details might sometimes be unavailable)
How to match script data to Interaction to Next Paint, including sub-parts
How to capture LoAF entries
Getting started with LoAF
LoAF support in SpeedCurve

Where we've come from

Performance isn't just about the download size of our pages and their components, or how a quickly the browser can fetch components from a server. Yet this is where we often start looking when we want to improve site speed.

It's not surprising that network performance is often the main focus. Historically, we've lacked APIs that provide data on the runtime costs of the code we ship as it executes in our visitors' browsers.

The Long Tasks API was a first attempt at providing runtime data. It generates entries for any task longer than 50ms, but it doesn't provide any attribution so it's hard to understand what's causing the Long Tasks.

This is why Long Animation Frames are an evolutionary next step.

Why does animation frame rate matter?

In an ideal world, we want the browser to be able to paint at 60 frames per second – in other words, a frame every 16.66ms. A Long Animation Frame takes longer than 50ms from its start to when it begins painting.

The Long Animation Frames (LoAF) API is a modern attempt to provide data on what's consuming the browser's processing time. It uses an animation frame-based approach rather than a task-based one.

Anatomy of a LoAF

With the LoAF API, not only do we get data for each LoAF, we also get data on which scripts executed during the LoAF. We finally have a way to begin to understand the impact that the code we're shipping has on our visitors' experiences.

Long Animation Frame (LoAF)

A LoAF measures from the point in time where a browser starts a new frame to the point where paint operations for that frame start.

It's important to note that the work to paint the frame, send it to the GPU, and finally show (present) it to the visitor are NOT included in the LoAF, as shown below.

Relationship between a Long Animation Frame and how frames are presented to the visitor

More things to note:

LoAF entries are only created for visible pages.
A LoAF may have zero, one, or more scripts associated with it.
A LoAF may or may not correspond with an interaction.

Script Timing

Script Timing gives you details of a script that executed for longer than 5ms during a Long Animation Frame. Timing information isn't available for all script tasks. For example, there's no data exposed for extension scripts and garbage collection.

Long Task

A Long Task API entry is generated for main-thread activities that are longer than 50ms. They are generated for hidden and visible pages. There's no direct way to link them to a LoAF.

What does a LoAF entry look like?

A LoAF entry contains some metadata and a mixture of timestamps and durations. It also includes an array of Script Timing entries for any scripts that executed for longer than 5ms during the LoAF.

{
    "name": "long-animation-frame",
    "entryType": "long-animation-frame",
    "navigationId": "508afc4b-f812-456f-a22a-4938478e4e1b",
    "startTime": 2899,
    "duration": 143,
    "renderStart": 3035,
    "styleAndLayoutStart": 3035.4000000059605,
    "paintTime": 3042,
    "presentationTime": 3044,
    "firstUIEventTimestamp": 0,
    "blockingDuration": 87.524,
    "scripts": [
        // Array of PerformanceScriptTiming Entries
    ]
}

Key LoAF milestones

There are several key milestones within a Long Animation Frame:

startTime
Start of the frame.

renderStart
Start of the rendering process. Sometimes the Style and Layout phase starts at the same time as rendering, but this is the point where requestAnimationFrame handlers, ResizeObservers, etc. execute, so they may delay the start of the style and layout phase.

styleAndLayoutStart
When the browser starts the final style and layout operations for the frame. This might not be the only style and layout work in the frame – for example a script might force style and layout by querying the size or styles of an element or a browser may sometimes choose to recalculate them mid-frame.

endTime
The point in time when the browser starts paint tasks for the frame. Calculated as startTime + duration.

Key milestones during a Long Animation Frame

What can we do with this milestone data?

With just this data we can begin to get an understanding of how a page is performing. We can:

Count how many LoAFs there were
Calculate their total time
Identify the longest LoAF
Get an indication of how much time is spent in style and layout tasks

If you're familiar with DevTools profiling, LoAF maps onto the main thread activities something like this simplified visualisation:

LoAF milestones vs main thread activity

I used Chrome Canary – which has the experimental PaintTimingMixin enabled – to generate the JSON example above. This mixin adds two more timestamps to the LoAF entry:

paintTime
When the browser starts paint operations for the frame.

presentationTime
When the frame is actually displayed to the visitor.

Although these timestamps are part of the LoAF entry, they occur after the end of the LoAF, i.e. startTime + duration < paintTime < presentationTime

Timestamps added by the PaintTimingMixin

If the frame wasn't painted or presented, then both these timestamps will be zero.

Some browsers can't capture a presentationTime, as the work of displaying the frame is handed off to the operating system and paintTime is aimed to provide a interoperable timestamp across browsers.

Finally there are two other time related properties included in the LoAF entry:

blockingDuration
The length of time the browser could not respond quickly to a visitor’s interactions (taps, clicks, or keypresses).

firstUIEventTimestamp
If the visitor interacted with the page and the event was handled within this LoAF, then the timestamp will be non-zero and will be before the startTime for this LoAF.

Summarising LoAFs

Much of the focus on LoAF has been around scripts. Understanding which scripts contribute to slow interactions – but summarising the higher level data – can provide an overview of our runtime costs.

Some examples of summary metrics I've experimented with:

Count of LoAFs – How many frames were delayed by longer than 50ms?
Total LoAF Duration – What was the total time of all Long Animation Frames?
Total Blocking Duration – What was the total length of time the browser could not respond quickly to a visitor’s interactions, for example, taps, clicks or keypresses?
Longest LoAF Duration – If a visitor tries to interact with the page during a LoAF, then their interaction won't be handled until the frame is presented. Measuring the longest LoAF might indicate how bad INP could potentially be. There's normally at least one LoAF entry before First Contentful Paint (FCP). As visitors are less likely to interact before content is shown, any LoAFs that occur before FCP should probably be excluded from this metric.

Script attribution

If a script executes for longer than 5ms within a LoAF, then a PerformanceScriptTiming entry is generated.

Relationship between LoAF and Script Timing entries

Script attribution is probably the part of LoAF that has attracted the most interest. We can finally measure which scripts are slow and when they execute. Using this data, we can begin to understand what proportion of any script performance issues are due to third-party tags and what's due to our own code.

(Spoiler: For many of the sites I've looked at, the first party code is often as big a source of problems as the third-party code.)

A typical Script Timing entry might look like this:

{
    "name": "script",
    "entryType": "script",
    "navigationId": "13b594a2-ca64-4812-ae67-139617da01fb",
    "windowAttribution": "self",
    "startTime": 4286.5,
    "duration": 319,
    "executionStart": 4370.29999999702,
    "forcedStyleAndLayoutDuration": 0,
    "pauseDuration": 0,
    "invoker": "https://example.com/assets/vendor/jquery/jquery.min.js?v=3.7.1",
    "invokerType": "classic-script",
    "sourceURL": "https://example.com/assets/vendor/jquery/jquery.min.js?v=3.7.1",
    "sourceFunctionName": "",
    "sourceCharPosition": 0
}

Timing

startTime
When the script was invoked.

duration
How long the script execution took.

executionStart
A script might not execute immediately. For example, a classic script might need to be compiled before it can be executed, in which case executionStart might be later than startTime. Due to security and privacy concerns, compilation time isn't exposed for third-party scripts and executionStart will be the same as startTime.

forcedStyleAndLayoutDuration
If a script queries the size, position or CSS properties of an element then the browser may need to recalculate these before it can return the data.

pauseDuration
How long a script was paused while a synchronous operation took place, e.g., showing an alert box, or making a synchronous XHR call

Invoker

invoker
In the case of a classic script or a module, this will be the URL of the script. If the execution was triggered by an event handler, then it will be the event handler type combined with the element the handler was attached to, e.g. BODY.onclick

invokerType
Why the script was executed. This should be one of classic-script, module-script, event-listener, user-callback, resolve-promise, reject-promise.

Script details

sourceURL
URL of the script source file. This can be overridden using the //# sourceURL= directive, which can be useful if the script names are hashed. Inline scripts are attributed to the HTML page they are in, but they can also be explicitly named using the //# sourceURL= directive. For example, the entry generated by the snippet below would be have a sourceURL of "Use-the-sourceURL-Luke".

document.body.addEventListener("click", function() {
      for (var a = Date.now() + 2E3; Date.now(););
});
//# sourceURL=Use-the-sourceURL-Luke

sourceFunctionName
Name of the top level function that executed, i.e., the entry point of the script. This is often empty. Even when it's populated it's commonly a minified function name, so I've not found it that useful.

sourceCharPosition
Character position of the script entry point within the source file.

Why script details might be unavailable

Sometimes details of the script that executed aren't available. This can be for privacy reasons and/or due to gaps in the API that have yet to be closed.

From a privacy perspective, browser extensions often install content scripts. These scripts execute within the context of our pages. Although they may cause performance problems, we have no right to know what our visitors have installed. Hopefully we can get opaque attribution for these, so at least we'll know an extension script was the source of the issue.

Inline handlers injected by third parties, such at Google Tag Manager, are also a common source of missing attribution.

Summarising script data

There are multiple ways to summarise the Script Timing data.

In the table below I've grouped the data by scriptURL and summed the durations. (Alternatively, it could also be grouped by eTLD + 1 to distinguish first- versus third-party domains or by invokerType to understand what's triggering the scripts.)

Summarising the entries while the page loads can help to quickly identify that, in this case, most of the long scripts are first party ones and so within the site owner's control.

Summary of script execution on Selfridges (captured at 6x CPU slowdown)

The summary could be refined further to focus on just the scripts that executed before First Contentful Paint or Largest Contentful Paint.

The data could also be grouped by multiple dimensions, such as scriptURL and invoker. One thing to keep in mind is that, as data becomes more granular, it can be harder to see the patterns in it.

Matching script data to INP

We can also use LoAF data to understand which scripts were executed during Interaction to Next Paint (INP) and – perhaps more interesting – which scripts executed during which INP phase/sub-part.

There's no explicit link between the Event Timing entries that are used to calculate INP and any corresponding LoAF entries, so they need to be matched using timestamps.

In the diagram below, there are three LoAF entries that overlap with INP:

A frame was already in progress when the visitor interacted and the browser needs to complete this frame before the interaction can be handled.
The visitor's interaction is handled in this frame.
Once the current frame has been sent to the GPU for presentation, the browser's main thread is free to start the next frame. This LoAF is actually generated by the next frame.

LoAFs overlapping with INP

We can follow this process to attribute the scripts, or parts of a script, to the different phrases of INP:

When a LoAF overlaps with the start of an interaction, only the portion of the script that executes after the interaction is applicable to INP.
If a LoAF wholly intersects with INP, then all the scripts executed are relevant to this INP.
When a LoAF finishes after the INP presentation time, then it's the next frame, so the LoAF and its scripts can be discounted.

So in this example only the portions of JS coloured in dark gold are applicable to INP:

Attributing LoAF and Script Timing entries to INP phases / sub-parts

Once we've identified the relevant scripts and identified which phase of INP they belong to, we can summarise the data and use it to identify the common sources of Input Delay, Processing Time, or Presentation Delay.

Breakdown of script execution by INP phase

There are at least two ways to calculate INP phases

The simplest approach uses Input Delay, Processing Time and Presentation Delay as calculated from the Event Timing entry that corresponds to INP.

The more complex method looks at all the Event Timing entries that end in the same frame and calculates the phases as follows:

Input Delay = start of the first Event Timing entry to the earliest Processing Time across all entries
Processing Time = start of the earliest Processing Time to the end of the latest Processing Time across all entries
Presentation Delay = end of the latest Processing Time to end of the frame across all entries

Chrome and web-vitals.js use the second of these approaches.

How to capture LoAF entries

As with other performance APIs, LoAF entries can be captured in a couple of ways.

Indirectly, using PerformanceObserver

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry);
  }
});
observer.observe({ type: "long-animation-frame", buffered: true });

Directly, by querying the Performance Timeline

console.log(performance.getEntriesByType("long-animation-frame"));

The number of LoAF and ScriptTiming entries generated depends on how much work the page demands of the browser or the capabilities of the device being used. Pages that use more scripts or are visited by people who have slower devices will often generate more LoAF entries than pages with fewer scripts or those that are visited by people with faster devices.

Exploring LoAF in DevTools

Chrome DevTools doesn't currently visualise Long Animation Frame or Script Timing entries. LoAF can generate a lot of data and one of the challenges I faced was matching its data to my understanding of how browsers work and how this is visualised in the DevTools Performance panel.

To help close this gap, I created a Chrome extension (available on GitHub) that adds a Custom Track to the Performance panel. This visualises LoAF and any corresponding script entries alongside the usual main thread view.

To use it, you'll need to enable Developer Mode and load it as an unpacked extension. By default it injects a content script for all pages, so I tend to only install it in a separate Chrome profile.

This first example is for a fresh page load of Selfridges at 4x CPU slowdown:

Example of custom performance track showing LoAF, Script Timing and Long Task Entries (view trace)

In this second example, I profiled opening the menu. The slow interaction is due to SnapChat's tag querying a DOM element. This can be seen in both the trace and the LoAF data. By collecting LoAF data from visitors using RUM, Selfridges would be able to identify how commonly SnapChat contributes to INP.

Example of LoAF and Script Timing entries created during an interaction (view trace)

Using the extension, it's also possible to see the gaps in the LoAF API – the impact of Garbage Collection or Extension scripts – and visualise where the Long Tasks API differs from LoAF. It's also helped me find a couple of Chrome bugs.

Getting started with LoAF

We've captured and exposed Long Tasks in SpeedCurve RUM for many years. One of the most common questions we've had from customers is "Can you tell me what causes these Long Tasks?"

Finally, thanks to the Long Animation Frames API, we can say: Yes! SpeedCurve now supports monitoring LoAFs and drilling down into attributions.

LoAF allows us to understand how scripts and other tasks affect both hard and soft navigations, as well as how scripts affect interactions. Using the data it provides, we can identify problem scripts and target changes that improve our visitors' experience. We can also finally start to quantify the impact of third-party scripts as they execute in our visitor browsers.

A free trial of SpeedCurve RUM will allow you to start to measure how scripts are affecting your visitors' experience. It will also help you track changes to Core Web Vitals and visitor behaviour as you make code improvements.

If you have any questions or comments about this post, you can find me on Bluesky.

I'd also like to say a very big thank you to Barry Pollard, Noam Rosenthal and Michal Mocny for their patient answers to my many questions about LoAF.

NEW! Monitor Long Animation Frames and get to the bottom of your JavaScript issues

Mon, 19 May 2025 00:00:00 +1200

CPU consumption by the browser is one of the main causes – if not the number one cause – of a poor user experience. The primary culprit? JavaScript execution. Now you can use SpeedCurve to monitor Long Animation Frames (LoAFs) and fix the third parties and other scripts that are hurting your page speed.

Until recently, we've had little evidence from the field that definitively attributes the root cause of rendering delays. While JavaScript Long Tasks gave us a good indication that there were blocking tasks affecting metrics such as Interaction to Next Paint and Largest Contentful Paint, there was no way to attribute the work or understand how it was ultimately affecting rendering.

Fortunately, we've gotten a lot of help from Chrome in improving the attribution – and ultimately the actionability – of the data we collect in the field with RUM. The introduction of the Long Animation Frames API (LoAF) not only gives us better methods for understanding what's happening on the browser's main thread, in some cases it also gives us attribution to both first- and third-party scripts that occur during a LoAF.

This has been a highly anticipated addition to SpeedCurve, which is available for all our RUM users today. This post covers what's new in the product and points you to a few new resources to help you get up to speed on all things related to LoAF.

What's new in your SpeedCurve dashboards?

Despite the complexity that comes with measuring script-related performance in the wild, our LoAF release is relatively straightforward.

In short, we've:

Added new metrics and made them available throughout the product
Created helpful new data visualizations in three of your dashboards
Added a valuable new visualization to your RUM waterfall

New metrics

The LoAF API allows us to derive several useful metrics that are powerful tools in your monitoring toolkit.

Total Blocking Duration (TBD)

The most notable addition is Total Blocking Duration, currently considered experimental. The intent of TBD is to give us a similar summary metric to Total Blocking Time, which is available in our synthetic tool. Total Blocking Time is often used as a synthetic proxy for understanding how JavaScript execution interrupts the user experience by introducing delays causing slow interactions, slow loading hero images, or other user frustration such as 'jank' during scroll.

Total Blocking Duration (TBD) is different from Total Blocking Time (TBT) in a few ways:

LoAFs that contribute to TBD are measured from the beginning of the page load for 60 seconds or until the user leaves the page (whichever occurs first).
TBT measures the sum of Long Tasks, while TBD measures the blocking duration for all LoAFs measured as described above. LoAFs are fundamentally different from Long Tasks.

If you're a RUM user, you'll see Total Blocking Duration throughout your dashboards, most notably featured as a hero metric in your Vitals dashboard (as shown above).

Other new metrics

We've also added these metrics, which will help you dig into LoAF in a number of nuanced ways:

LoAF Total Duration – Total duration of ALL LoAFs measured
LoAF Entries – Total count of ALL LoAFs measured
LoAF Style and Layout Duration – Time spent calculating style and layout for the frame
LoAF Work Duration – Total duration of non-rendering phases across ALL LoAFs
LoAF Script Total Duration – Total duration of scripts that executed across all LoAF entries

You'll be able to track all these metrics in custom charts in your Favorites dashboards.

Vitals dashboard updates

The Vitals dashboard has been updated in a few areas. As mentioned earlier, Total Blocking Duration is a Beta metric that appears for RUM users in place of Total Blocking Time. Additionally, in the TBD section we've added a table for Execution Duration by dimension.

In this example, we can quickly see which page groups are most heavily affected by total Execution Duration:

A secondary table shows you scripts that are attributed to Long Animation Frames. These scripts are both first-party scripts (origin) as well as third-party scripts (external vendors). You can see the total duration for the script (note, this is inclusive of blocking but not exclusively blocking duration) as well as any forced style and layout attributed to that script.

In the Interaction to Next Paint (INP) section of the Vitals dashboard, you have a new table that shows scripts attributed during the INP phase.

You can also filter this table to scripts that occurred during the different INP subparts: Input Delay, Processing Time, and Presentation Delay.

RUM JavaScript dashboard updates

The Execution Duration by Script shown earlier in the Total Blocking Duration Vitals section also appears at the top of the JavaScript dashboard. Additionally, dimension tables for Page Labels, Device Types, and Browsers have been updated to included LoAF Entries, LoAF Total Duration, and LoAF Total Blocking Duration.

Home dashboard updates

Your Home dashboard now includes a table for the slowest scripts and their total execution duration.

Drilling into your RUM waterfall

When you're diagnosing an issue, you can drill into a set of sessions for further interrogation. This is useful when investigating a spike or a baseline change to a metric in a time series chart, or if you simply want to learn more about the demographics and see some example sessions that meet the chosen criteria.

Clicking on a time series chart gives you a few options. Click on 'View Sessions' to drill in further.

The 'Sessions' section of the dashboard lists individual sessions you can explore. In this case, we're looking at an example of a session where INP was high.

Clicking on the session gives us details for each page in the user's session. We've introduced a new visualization that shows you Long Animation Frames (the red bars) aligned with the waterfall chart above, which lets you see when the LoAF occurred during the rendering timeline.

Hovering over each red LoAF gives more attribution detail, listing scripts that executed during the LoAF. In this example, we can see attributed scripts and their duration (important, this is not just blocking duration). You'll also see Unattributed time, which can't be attributed to a specific script.

More resources

This is a complex topic. While we've done our best to simplify how you think about and monitor LoAF, there are a few resources that go much deeper and provide a lot of understanding that may be useful.

My colleague Andy Davies provides a wealth of information in his latest post, a detailed guide to understanding LoAF. Andy has also created a great debugging guide for investigating INP.

Our Support Hub is a good resource for everything from understanding how to navigate JavaScript-related issues in SpeedCurve to interpreting what all these metrics mean

Get started!

Interested in tackling your JavaScript issues, but don't have RUM? Start a free trial today!

If you're already a SpeedCurve customer but you're not using RUM yet, send us a note at support@speedcurve.com and we'll enable your RUM trial and help you get started.

Why you need to know your site's performance plateau (and how to find it)

Tue, 15 Apr 2025 00:00:00 +1200

Have you ever wondered why your site got faster, but your business and user engagement metrics didn't improve? The answer might lie on the performance plateau.

Have you ever asked yourself these questions?

"I made my pages faster, but my business and user engagement metrics didn't change. WHY???"

"How do I know how fast my site should be?"

"How can I demonstrate the business value of page speed to people in my organization?"

The answers might lie with identifying and understanding the performance plateau for your site.

What is the "performance plateau"?

The performance plateau is the point at which changes to your website’s rendering metrics (such as Start Render and Largest Contentful Paint) cease to matter because you’ve bottomed out in terms of business and user engagement metrics.

In other words, if your page speed metrics are on the performance plateau, making them a couple of seconds faster probably won't help your business.

A correlation chart is an essential tool for identifying your performance plateau. This chart shows that, for this site, bounce rate dramatically worsens when LCP time slows from 0.1s to 0.4s. After that, bounce rate plateaus – it remains at around 75% for all sessions with LCP times slower than 0.4s.

The concept of the performance plateau isn't new. I first encountered it more than ten years ago, when I was looking at data for a number of sites. I noticed that not only was there a correlation between performance metrics and business/engagement metrics, there was also a noticeable plateau in almost every correlation chart I looked at.

A few months ago someone asked me if I've done any recent investigation into the performance plateau, to see if the concept still holds true. When I realized how much time has passed since my initial research, I thought it would be fun to take a fresh look.

In this post, I'll show how to use your own data to find the plateau for your site, and then what to do with your new insights.

Background

For this investigation, I selected four sites that experience a significant amount of user traffic. For each site, I used a month's worth of RUM (real user monitoring) data to generate correlation charts.

Correlation charts show the relationship between performance metrics – in these instances, Start Render and Largest Contentful Paint (LCP) – and user engagement (measured as bounce rate). They're a great tool for showing non-technical folks how performance affects the business.

(You can also create correlation charts that show the relationship between performance metrics and business metrics, such as conversion rate and cart size, but bounce rate is easier to measure right out of the box with most RUM tools.)

Results

The correlation charts below show the distribution of all visits, with each yellow bar representing a cohort of visits that experienced a given Start Render or LCP time. The blue bar represents the change in bounce rate across all cohorts.

In each of the correlation charts below, I've highlighted:

Optimal speed – The cohort of sessions that correlated with the lowest (aka best) bounce rate for that site
Beginning of the performance plateau – The cohort of sessions where the bounce rate begins to plateau
Median measurement for all visits represented in the chart

Keep reading for observations and takeaways.

Site A

Site B

Site C

Site D

Observations

1. A clear performance plateau emerged for each site

Each site experienced a plateau at which business metrics remained more or less the same as performance continued to degrade.

2. Plateaus emerged for both Start Render and Largest Contentful Paint

While it's great to see Largest Contenful Paint validated as a meaningful page speed metric, I'm even happier to see Start Render receive validation. That's because Start Render is widely available across browsers, while LCP still has limited browser availability.

3. The plateau emerges surprisingly quickly in some cases

For example, Site C's performance plateau starts at 400 milliseconds. That's early!

4. There's a lot of variability in the distance between the optimal bounce rate and the plateau

For some sites, you can see a much steeper incline in the curve from optimal to plateau. For some sites (such as Site C), the difference was as little as 300 milliseconds. For others (such as Site A), the gap was as long as 9 seconds.

5. The plateau sometimes started later when looking at LCP

Creating correlation charts in both Start Render and LCP generated interesting results. In two of the four sites I looked at, the charts were roughly comparable. For the other two sites, the plateau started later for LCP than it did for Start Render. This could be attributed to the fact that LCP measures when the largest visual element has completely finished rendering, so it can occur much later than Start Render.

6. For some sites the performance plateau starts well before the median

Predictably, the optimal bounce rate generally correlated to the cohort of sessions that is much faster than the median. A bit more surprisingly, for some sites the performance plateau started well before the median. This could come as a scary revelation for some site owners, because it means that the bulk of your user sessions are occurring on the plateau.

How to measure the performance plateau for your own site

I can't emphasize enough that the examples I've shared are illustrative, not prescriptive. The performance plateau for your site will be different from the plateau for another site. You need to look at your own real user data. (If you're new to performance, you might be interested in this synthetic and real user monitoring explainer.)

Fortunately, the process for identifying the low end of your site’s performance threshold is fairly straightforward. All you need is access to a statistically significant amount of your RUM data, plus whatever analytics tool you use for tracking business or user engagement metrics.

Step 1: Identify the metrics you want to measure

As mentioned above, bounce rate is a good metric to start with, because it's already gathered automatically by most real user monitoring tools.

If you have access to other data sources, then you can create a variety of correlation charts, If run an ecommerce site, then you can measure revenue, cart size, and conversion rate. If you work on a media site, then page views, session depth, and bounce rate matter.

Step 2: Gather lots of real user data

To ensure that you get statistically relevant results, the more data you can gather, the better. If your dataset is too small, you could get wonky results. When I conducted my investigation, I aggregated millions of transactions that took place over a single month. (If you're interested in trying real user monitoring, you can start a free RUM trial in SpeedCurve.)

Step 3: Create correlation charts

I've demonstrated how I like to show bounce rate (or whatever business/engagement metric you're plotting) across the distribution of sessions. (If you're a SpeedCurve user, here's how to create correlation charts.)

What to do with your findings

After you've finished your own investigation, you can do a few things with the results:

1. Share your findings within your organization

Correlation charts are a powerful tool for showing stakeholders the impact that site speed has on the business. Even if your results aren't what you hoped they would be, you can use this data to prove the value of continuing to invest in performance.

2. Understand why your business metrics are not improving despite your efforts

This might seem a bit demoralizing, but when you think about it, it's actually helpful to know. When you know where your performance pleateau begins, you can answer the question "Why don't my business or user engagement metrics improve when I make my site faster?" If you improve Start Render from 5 seconds to 3 seconds, but the performance plateau for your site starts at 2 seconds, you haven't yet made Start Render fast enough.

3. Change your performance goals

Set targets for moving more of your users into the cohorts that experience faster Start Render or LCP times. Ideally, improving key site speed metrics for more of your users should improve bounce rate (or whatever user engagement or business metric you're tracking) for more of your users. Ultimately, this is good for your business.

You can use your performance plateau to set goals. Continuing with the example in point 1, above, if you know that the plateau starts at 2 seconds, you can create a Start Render target of 1.5 seconds to work toward.

4. Or DO NOT change your performance goals

In the Site C example, the optimal bounce rate occurs for the 100-millisecond LCP cohort, and the plateau starts just 300 milliseconds later. With a huge amount of work, you might succeed in delivering faster LCP times to more sessions, but would the effort be worth it?

As the close-up view of the chart below shows, the bulk of sessions have speedy LCP times that are at the beginning of the performance plateau. In this case, the chart shows that perhaps you can be satisfied with your efforts, and your focus should be on fighting regressions and staying fast.

5. Create a baseline to measure against

Repeat this exercise periodically – perhaps monthly, or semi-annually, or after a deploy where you've made a number of performance improvements – and compare the correlation charts over time. Ideally, you'll see more of your sessions fall into the faster section of the distribution, before the performance plateau.

Questions? Feedback?

If you experiment with creating correlation charts and plotting the performance plateau for your site, I'd love to hear about your results!

Performance Hero: Alex Russell

Tue, 08 Apr 2025 00:00:00 +1200

Our newest performance hero is passionate, provocative, and unapologetically honest. While he's a true champion for web performance, his impact can be measured more broadly across the web. Join us in celebrating Alex Russell!

Alex Russell has been a strong voice in the web community for as long as I can remember. He's currently a Partner PM at Microsoft, working on Edge. Before that, he spent several years working at Google on Chrome, web standards, and much more.

Not only is Alex an accomplished engineer, he's also an amazing speaker and writer. I last saw Alex on stage at performance.now() in November, where he delivered this inspiring talk that got a lot of attendees talking.

After reaching out to Alex for this interview, I was pleased to see how thoughtful he was in his response. Not only did he provide great insights, he was quick to point out a handful of colleagues at Microsoft he felt more deserving of recognition, including Amiya Gupta, Ingrid Caldas, and Paul Roy.

Alex's passion for the web platform – and making it accessible for all – carries through in his writing, his talks, and fortunately for us, his email responses! Here's our email interview.

How did you begin your journey in web performance?

"My work in the past decade on performance has been an exercise in working backwards from strategy to tactics.

"The web has relatively few advantages versus its competitors (who are also, not coincidentally, also major browser vendors), but one of the most misunderstood advantages is perspective: we get to step back from the frothy churn of early capability introduction on native OSes and (if we're doing our job right) ride the 80/20 line to add capabilities that are important at about the same rate that they become commodities, but with the benefit of mistakes made by native competitors.

"That digestion procession often gets weaponised (or worse, fetishised, à la TC39 and CSSWG) as "thoughtful deliberation" by internal enemies of the web, but when it's working as intended, competition and urgency to ship creates a diversity of views about how to introduce a capability without having explain their fundamental value.

"But all of that value is contingent. If the web is a safer way, for example, to configure your brand-new IoT device versus downloading some app from a store – but the user experience sucks – no CEO or PM worth their salt will want to associate their brand with our platform.

"The same is true all the way down the capability spectrum: the web's potential to introduce safe, privacy-respecting ways of accessing the full potential of your devices is only as realistic as the willingness of decision makers to bet on the experience of the web. And if that experience is, in general, bollocks... why offer it on the menu?

"Make no mistake: Apple's work to kill the web is a two-front war. First, they are denying critical capabilities that they give every Tom, Dick, and Harry willing to pay $99 a year to put something in their store. Simultaneously, they are deeply committed to undermining the reliability of foundational experiences like tapping, swiping, and typing. If those feel like tosh on the web via the phones of CEOs and board members, would anyone invest in a web-based pitch? And why?

"The web is not what it promises. The web is what it does.

"And this strategy logic plays out in Android-land, where there are huge teams at Google that have no higher goal than to get folks that are happy making web apps to put something native in the Play Store instead. They haven't been quite as successful in keeping the Chromies down as Apple did the WebKittens, but the net effect of various management and political games should be read with not insignificant scepticism. Why, for example, is Google still withholding the ability for competing browsers to ship real PWAs on Android (a.k.a. WebAPKs)? This stuff matters, and if you only read public blogs, you might think it's just a random walk of technology futures explored and abandoned, but it's very much not that.

"Web developers need to wake up.

"Native ecosystems want to eat your lunch. They're doing so in an ongoing way, and to the extent that the web is a shitty, underpowered experience on most of the world's devices across most of the world's networks, we are handing our enemies a gift. I can't make you care about the web, but I can suggest that if you do, you should pay attention to the real and present dangers it faces; no matter how slow-moving they appear."

As a Partner PM at Microsoft, what are your primary responsibilities?

"MSFT is a... unique... place, and I learned pretty quickly after joining that my title is more like a partner in the law or audit firm sense. It's a description of generic seniority with a specialization attached, but at the level of Partner, the specialization is mostly about "How many reports do you have?" I have none (which is good for everyone involved).

"I do a weird job – roughly speaking, platform strategy on behalf of the web – and it's not one that anyone hires for. That means everyone who does this job hides out in their orgs doing something else on paper. For my 12+ years at Google, I passed as a co-TL for large-scale projects inside the web platform org, and at MSFT that's nominally a product management job. But what I care about, and what I work on regardless of which domain it's in, is in making the web a success versus its extremely potent and vicious competitors; adversaries that are threatening to extinguish it entirely on mobile.

"An incredibly small community of people do this work. In one way or another, we've all found ourselves working in and around Chromium. That's a little disconcerting, but it also makes sense: Blink is the only engine whose funders have made space to pursue an even moderately web-forward agenda in the era of entirely proprietary mobile OSes, and the Blink Launch Process has an explicit bias towards progress when sufficient need can be demonstrated. Nobody does this work at Apple or Mozilla; the folks who work in platform strategy at Apple are entirely on the other side (trying to extinguish the web, often weaponizing standards and standards-adjacent processes in the process) and Mozilla... well, the less said the better.

"So what the heck does that have to do with performance?

"First, I help lead an effort called Project Sidecar within the Edge team. We're a virtual team of volunteers that consult with anyone in the company that wants help with the web. That is a general-purpose offer, and our goal is to learn about problems that folks are experiencing all over the system, but today the effort mostly focuses on performance because of the dire place that many teams find themselves in. Large swaths of our org bought into the dogmas and prescriptions of the current JavaScript community, and that's just a recipe for pain whenever React is involved.

"Next, I keep the flame alive for a rebirth of the mobile web. Microsoft isn't heavily invested in that future today, but they let me work on it in ways that I think will matter.

"Lastly, a huge fraction of Edge's UI surfaces are web-based. Improving our own understanding of, and alignment with, the modern web is a surefire way to make Edge a faster, more competitive product offering for users on devices across the spectrum. And making things great for users at the margins is what I care most about."

You launched the 'Performance Inequality Gap' series in 2017 and have consistently provided updates since then. What is the outlook for 2025?

"Decidedly mixed. Apologies for the screenshots of SVG charts, but it helps to tell the story visually.

"We're starting to turn the corner on process nodes filtering down from the wealthy to the less-well-off, and that was basically frozen in amber until 2022:

"That nets out at improvements across the board in the past two years for perf per dollar, but not real-world performance:

"Average selling prices are also stagnant, which creates real tension. Premium buyers are still heavily segmented versus the rest of the market:

"And of course the one thing that hasn't changed – and the primary reason Apple still dominates in the metrics that matter most to web performance – is that every single Android SoC vendor continues to skimp on cache sizing:

What projects are you currently involved in, and what are you most enthusiastic about?

"Some I can talk about, lots I can't, sadly.

"I'm incredibly excited about the work my colleagues Nishita and Luis are doing to bring some of the ideas behind "Never-Slow Mode" to a contemporary context.

"We've experienced many teams being relatively ambivalent about performance... until they find their app embedded in the context of some other site that objects to their bulk. That interplay tends to deliver results, and the more the browser can serve as the mediator (and de-personalise the conversation) the better. So we're hoping to tier up from that work to a more expansive view of embedder and self-declared performance controls over time.

"A ton of work has been happening in our V8 and tooling teams to facilitate better memory attribution. That's exciting to me because as teams become more advanced in their understanding of their own performance, they start to care more about these aspects. Having better tools helps there, and Sulekha Kulkarni's V8 team within Edge is doing great work to make that more legible.

"Renewed energy around tools that will let us remove code from userland is always exciting, so I'm enthusiastic about customisable <select> (now that Apple has relented after a dozen years of blocking it) and energy around future-looking additions to Web Components.

"I also think it's finally time for us to create separate read and write phases in the DOM for style readback. I need to get those ideas on paper, but I hope for some progress there this year. Exciting times."

Looking ahead to 2025, what do you anticipate will be the main challenges and opportunities in the field of performance?

"Web performance faces two main challenges today:

The strength of the cult that has formed around React
The failure of browser vendors to push back forcefully

"Core Web Vitals are a shadow of what's possible. We need to imagine a world where browsers take the user's side much more aggressively (and always in an even-handed, privacy-preserving way). That's possible, and when browsers get there, it will do a lot to deflate the React bubble, which I think will be cathartic for businesses and developers trapped in a shockingly inefficient local minima."

Thank you, Alex! Your continued work on behalf of the web platform extends far beyond performance. Thank you for being such a strong voice in our community.

Do you have someone you'd like to recognize as a Performance Hero? Let us know at support@speedcurve.com!

Correlation charts: Connect the dots between site speed and business success

Wed, 02 Apr 2025 00:00:00 +1300

If you could measure the impact of site speed on your business, how valuable would that be for you? Say hello to correlation charts – your new best friend.

Here's the truth: The business folks in your organization probably don't care about page speed metrics. But that doesn't mean they don't care about page speed. It just means you need to talk with them using metrics they already care about – such as conversion rate, revenue, and bounce rate.

That's why correlation charts are your new best friend.

What is a correlation chart?

A correlation chart is a powerful data visualization that shows you the relationship between your page speed metrics and your business and user engagement metrics.

Correlation charts are generated using real user monitoring (RUM) data. They give you a histogram view of all your user traffic, broken out into cohorts based on performance metrics, such as Start Render, Largest Contentful Paint, Interaction to Next Paint, and more. Each cohort shows you the median time for whatever metric you're tracking for the session. (Those cohorts are represented in the yellow columns in the chart below.)

The next layer of the chart is where things get really interesting.

You also get an overlay (the blue line in the chart below) that shows you the business or user engagement metric – commonly conversion rate or bounce rate, but there are many more – that correlates to each of these cohorts. This lets you see at a glance how closely your business/engagement metric aligns with the speed of your site.

As pages get slower for this site, conversion rate (predictably) decreases. The cohort of users who experienced Largest Contentful Paint times of 1.1 second also had the highest conversion rate – more than 6 percent!

You can also see how quickly conversions drop off as LCP time degrades. At 2.5 seconds – which is Google's recommended threshold for LCP – the conversion rate is well under 3 percent. That's a huge drop!

Communicate to a broad audience

Correlation charts let even the most non-technical stakeholder easily see the connection between performance and the business KPIs they care about.

In my experience with talking about performance to a wide variety of audiences, correlation charts can be extremely effective in winning performance buy-in from key people in your organization. Not everyone understands the nuances of Core Web Vitals. But everyone understands revenue and bounce rate.

^{Image by pch.vector on Freepik}

Identify the performance plateau for your site

If you've ever made your pages faster but didn't see any changes in your business or user engagement metrics, you were probably frustrated – and understandably so. When setting page speed goals for your site, you need to understand your performance plateau. To do this, you first need to create a correlation chart.

The performance plateau is the point at which changes to your pages' rendering metrics (such as Start Render and Largest Contentful Paint) cease to matter because you’ve bottomed out in terms of business and user engagement metrics.

In other words, if your performance metrics are on the performance plateau, making them a couple of seconds faster probably won't help your business.

A correlation chart is an essential tool in identifying your performance plateau. For this site, the conversion rate plateaus at 2.8 seconds. To improve conversions, you would need to move more traffic to the higher-converting side of the chart – as close to 1.1 seconds as possible.

Validate your metrics

You don't want to waste time optimizing metrics that ultimately don't move the needle for your business or users. Correlation charts help you validate the performance metrics you're tracking and optimizing.

For example, when Google was in the process of evaluating Interaction to Next Paint (INP) as the new interactivity metric in Core Web Vitals, we conducted an independent analysis to validate that INP is a meaningful page speed metric. (By our definition, a meaningful metric is one that can be demonstrated to affect business or user engagement KPIs.)

In this correlation chart, the fastest INP time (48ms) correlates to a 9% conversion rate for this retail site. An INP degradation of just 50ms correlates to a 7.6% conversion rate – a significant drop!

My fellow SpeedCurver Cliff Crocker looked at RUM data for several sites – and specifically focused on correlation charts for each site. Cliff determined that, yes, having a faster Interaction to Next Paint Time typically does correlate to better conversion rates. Knowing this, most people should feel confident that optimizing INP is a smart move.

Spot performance-blocking trends

You can even use correlation charts to see the relationship between page-construction metrics – like blocking JavaScript, blocking CSS, and number of image requests – with your other metrics! This lets you spot trends on your pages that could be hurting performance and your business.

For example, in the chart above, you can see that while there are fewer blocking resources on the faster pages, this number takes a sharp upturn starting with the cohort of pages that have a start render time of 1.1 seconds.

If your goal is to deliver faster start render times to more users (and 1.1 seconds is a pretty good goal to shoot for), then this might trigger you to do an audit of your pages to analyze how your scripts and stylesheets are being executed.

Get started

We care about more than just showing you all your real user data. We want to show you the most important data. And we want to make it easy for you to share that data with people throughout your organization.

If you’re already a SpeedCurve RUM user: Simple correlation charts are available at the top of your RUM > Users dashboard. We capture bounce rate by default, so you'll see a correlation chart that shows you the relationship between Start Render and bounce rate.

You can easily create custom correlation charts in your Favorites dashboard. You can also add your own conversion rate data – as well as other data like cart size and revenue.

Questions? Send us a note at support@speedcurve.com.

If you're a SpeedCurve Synthetic user, but haven't tried RUM yet: Start your free trial any time! All you have to do is grab the RUM ID for your team – on the RUM page visible in the main navbar when you log in – and install the RUM JS snippet on your site. Email us at support@speedcurve.com if you have any questions!

If you’re not a SpeedCurve user: Sign up for your free trial and get these powerful charts for your own site.

Downtime vs slowtime: Which costs you more?

Tue, 18 Mar 2025 00:00:00 +1300

Comparing site outages to page slowdowns is like comparing a tire blowout to a slow leak. One is big and dramatic. The other is quiet and insidious. Either way, you end up stranded on the side of the road.

Downtime is horrifying for any company that uses the web as a vital part of its business (which is to say, most companies). Some of you may remember the Amazon outage of 2013, when the retail behemoth went down for 40 minutes. The incident made headlines, largely because those 40 minutes were estimated to have cost the company $5 million in lost sales.

Downtime makes headlines:

2015 – 12-hour Apple outage cost the company $25 million
2016 – 5-hour outage caused an estimated loss of $150 million for Delta Airlines
2019 – 14-hour outage cost Facebook an estimated $90 million

It's easy to see why these stories capture our attention. These are big numbers! No company wants to think about losing millions in revenue due to an outage.

Page slowdowns can cause as much damage as downtime

While Amazon and other big players take pains to avoid outages, these companies also go to great effort to manage the day-to-day performance – in terms of page speed and user experience – of their sites. That’s because these companies know that page slowdowns can cause at least as much damage as downtime.

There are three metrics that are hit hard by slow page load times:

Abandonment rate
Revenue
Brand health

Let’s take a deeper dive into the data behind each of these metrics.

Visitors may be more likely to permanently abandon slow sites than unavailable sites

If a website is temporarily down, there’s a reasonable chance you’ll try again later – assuming that you’re reasonably motivated to track down whatever it was you were interested in finding on that site.

But if a website or app is consistently laggy (read: many popular media sites), eventually, you just sort of drift away.

Anecdotally, this makes sense – and there’s research to back it up.

In one of the only studies (if not the only study) of the impact of outages versus slowdowns on abandonment rates, Akamai found that sites that went down experienced, on average, a permanent abandonment rate of 9 percent. Sites that suffered from slow performance experienced a 28% abandonment rate.

This isn’t to say that site outages are nothing to be concerned about. A 9% permanent abandonment rate is extremely bad for your business. But a 28% abandonment rate is even worse.

Slow pages could have up to 2X more impact on revenue than downtime

This finding comes from a study that, to the best of my knowledge, is the only study that compares revenue losses due to downtime with losses due to page slowness.

TRAC Research surveyed 300 companies and found that the average revenue loss for an hour of downtime was $21,000. For the same set of companies, average revenue loss due to an hour of performance slowdown (which was defined as response times exceeding 4.4 seconds) was much less – just $4,100.

Looking at just these two sets of numbers, outages seem like a bigger source of concern. But wait.

According to the same survey, website slowdowns occurred 10X more frequently than outages. This changes the numbers considerably.

In other words, according to this research, slow-loading pages could have twice the impact on revenue that site failures do.

Bear in mind, this is just one survey of 300 companies. The results cited here should definitely not be taken as a prediction of how your own site could fare. The most important takeaway from this study is that it forces us to ask ourselves:

How do I calculate losses due to slowness on my site?
How do these losses compare to downtime losses?
Am I at risk of prioritizing one performance issue (downtime) over another equally critical issue (slowness)?

Slow sites may suffer more damage to brand health

Unless your site experiences frequent and noticeable outages, occasional failures won’t undermine your brand. (In fact, remember back when Twitter made outages cute with the fail whale?)

Most users accept sporadic downtime as part of the reality of using the web. They’re less forgiving, however, if your site is routinely slow.

First impressions matter – and they happen faster than you might think. According to one study, we form our opinion of a website within the first 50 milliseconds. And once we’ve formed that opinion, it colours how we feel about a site’s credibility and usability, ultimately affecting whether or not we choose to make a purchase on that site.

A few years ago, I directed a neuroscientific research project in which participants were asked to complete transactions on an e-commerce site using mobile devices. Some participants experienced normal speeds, while others experienced load times that were artificially throttled with a 500-millisecond network delay. Participants believed they were participating in a standard usability/brand perception study, so they had no idea that speed was a factor in the tests.

After each set of tests, the research team conducted exit interviews with the subjects. Our subjects were asked to give their general impressions of each site and company. The results were revealing.

Some participants picked up on the slight deterioration in performance (calling the slower site “slow” and “sluggish”), but those who used the slower site also developed negative perceptions of areas unrelated to speed:

Content (“boring”)
Visual design (“tacky” and “confusing”)
Ease of navigation (“frustrating” and “hard to navigate”)

In other words, the slower pages affected people’s perception of three important aspects of the site that are closely aligned with brand perception.

Calculating the cost of "slowtime"

Calculating downtime loss is pretty straightforward. If your site averages $100,000 per hour in revenue, and you suffer a three-hour outage, you can estimate that you lost $300,000.

Calculating losses due to slowdowns is not as straightforward, but you can still get an idea of what those losses might be.

1. Create a correlation chart for your site

Using your real user monitoring (RUM) data, create a correlation chart for your site. A correlation chart gives you a histogram view (represented in the yellow bars in the chart below) of all your user traffic, broken out into cohorts based on performance metrics (such as Start Render and Largest Contentful Paint).

The chart includes an overlay (represented in the blue line) that shows you a user engagement metric or business metric – such the 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.

This correlation chart shows that the highest conversion rate – slightly more than 6% – correlates with a 1.1s LCP time. As the LCP time gets slower, conversion rate worsens.

2. Identify the performance plateau for your site

The performance plateau is the point at which changes to your website’s rendering metrics (such as Start Render and Largest Contentful Paint) cease to matter, because you’ve bottomed out in terms of business and user engagement metrics.

In other words, if your performance metrics are on the performance plateau, making them a couple of seconds faster probably won't help your business.

At 2.8 seconds, the conversion rate for this site plateaus. In other words, improving LCP times within the plateau zone – for example, from 4 seconds to 3 seconds – will probably not help conversion rate.

3. Identify your cohort of users who drop off the performance plateau

Using the above data, you can easily calculate the number of users who experience the performance plateau, just by adding up all sessions in the cohorts from 2.8 seconds to 4.5 seconds.

4. Identify average customer lifetime value for your business

Your repeat customers are arguably your most valuable customers. That's why it's helpful to know the average customer lifetime value (CLV) for your business.

CLV is a metric that projects the total average value of your customer based on past spending. Your accounting or finance teams will have this data. Calculating CLV can be complicated (and that complexity goes beyond the purposes of this post), but here's a simple way to approach it:

Segment your customers based on their purchase recency, frequency, and monetary value
Determine average order value
Figure out average purchase frequency
Calculate customer value
Multiply customer value by average lifetime value

For example, if you know that the median spend of a returning customer over the past three years is $1,000, then predicted future value for the next three years is $1,000. Total customer lifetime value is $2,000.

5. Calculate the lost CLV

Using the stat that 28% of the customers who fall off your performance plateau will permanently abandon a site that is consistently slow, identify the lost CLV.

Example CLV calculation

For example:

If the median value of a returning customer over the past three years is $1,000, then predicted future value for the next three years is $1,000.
Your current converting user base is 100,000 customers. They have a collective CLV of $200 million. Their projected collective spend over the next three years is $100 million.
10% of those customers (10,000) experience Largest Contentful Paint times at the poor end of the performance plateau.
28% of those customers (2,800) will not return.
Your projected lost CLV is $2.8 million.

As said, this is a simplistic calculation, but it's a good starting point to calculate your own formula that you can use for your site and your users.

Also note that this formula focuses only on lost CLV. It doesn't consider the immediate lost revenue from customers who abandon their transaction due to slowness.

Preventing outages is just one piece of the performance pie

If your business is reliant on your site, then you most definitely should care about preventing outages. You should, of course, conduct load testing and availability testing, and you should have effective load balancing and failover systems in place wherever possible.

But protecting your site from failure is just one piece of the performance pie. It’s a big piece, to be sure, but there are others. You also need to:

Track your site’s performance using synthetic monitoring (AKA lab testing) and real user monitoring (AKA field data)
Correlate performance metrics (such as Start Render, LCP, INP) with business and user engagement metrics (conversions, bounce rate, etc.) using your real user monitoring tool
Integrate synthetic testing with your CI/CD process to catch regressions in your staging environment
Create performance budgets to get real-time alerts when key pages slow down
Drill down into your synthetic/lab data to resolve performance issues as they occur
Look for opportunities to further optimize your pages (hint: images and third parties are a great place to start)

SpeedCurve lets you fight regressions from multiple angles of attack, so you can keep your site fast and your users happy – and your business successful. Give us a try!

NEW! Synthetic test agent updates: Chrome, Firefox and Lighthouse

Sun, 02 Mar 2025 00:00:00 +1300

This month, we've made some updates to our synthetic testing agents. In addition to upgrading the underlying operating system, we've added support for:

Lighthouse 12.3.0 (previously 10.4.0)
Chrome 133 (previously 126)
Firefox 135 (previously 128)

What has changed?

We understand the sensitivity related to changes in your performance data.

Synthetic updates are known to cause baseline changes due to hardware changes, browser optimization or in the case of Lighthouse, changes to the methodology.

Here is a rundown of what's changed in this update:

Chrome

Moving from Chrome 126 to 133 should not have a huge impact on your metrics.

As of Chrome 130, transparent text is no longer eligible to be considered for Largest Contentful Paint (LCP) but this change doesn't appear to affect a larger number of sites.

There were a number of updates to Chrome, which may affect Interaction to Next Paint (INP) introduced between 126 and 130, but as we don't measure INP with synthetic, there is no impact to your metrics (only your RUM data).

scheduler.yield was introduced in Chrome 129 and this may reduce Total Blocking Time (TBT) for some sites.

Firefox

There was no identified impact to metrics between versions 128-135.

See full release history here.

Lighthouse

There were no significant changes to the Performance category of Lighthouse.

However, there were several updates to the Accessibility and SEO categories that included new audits and improved weighting. Additionally, the PWA category has been removed entirely.

You can learn more about those changes from the resources below:

OS update

The operating system our agents use has been upgraded to Ubuntu 24.04. This upgrade was overdue and will allow us to rollout updates to our agent more quickly in the future.

The OS update has had an impact on some metrics, and during extensive testing, we've observed that Total Blocking Time (TBT) has improved due to this change.

Impact on metrics

To provide a baseline when upgrading browsers, Lighthouse, or other components of our agents, we regularly measure the speed of more than 200 sites in both our production and pre-production environments.

During this upgrade, we've found that most metrics have remained reasonably consistent between the new and existing versions of the agent, but that Total Blocking Time (TBT) has improved significantly.

Across the corpus of sites we're testing, we've observed that Total Blocking Time (TBT) has improved by approximately 16% at the 75th percentile.

After investigating, we've identified this improvement is due to the OS upgrade to Ubuntu 22.04

Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) have remained largely unchanged.

What should you do next?

Our observations on how the upgrade affects metrics are based on the sites in our test corpus, and every site is different.

While Total Blocking Time might be the only expected change, there is always a chance your metrics will change based on the optimizations discussed above.

Over the next few weeks, we recommend reviewing your performance budgets and checking that they are still appropriate for your site and then adjusting them if necessary.

This is a practice we recommend doing on a regular basis as part of a 'get fast, stay fast' methodology, which you can learn more about in our Web Performance Guide to Performance Budgets.

Private agents

For customers who host their own private SpeedCurve agents: We're planning to release an updated version of the Docker container in the next few weeks.

If you have any questions about the upgrade, its impact on your metrics, or any questions about SpeedCurve in general, you can reach us at support@speedcurve.com.