SpeedCurve Blog

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.

Performance Hero: Sergey Chernyshev

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

We often hear how special, generous, and supportive the web performance community is. This didn't happen overnight. This month, we're excited to recognize someone who has been a huge part of creating the community culture we enjoy today: Sergey Chernyshev.

Whether answering questions on social media, helping someone with a proposal for a conference talk, or simply being welcoming and kind to newcomers, webperf folks are some of the most generous people you could ever hope to find. There are so many folks out there who are organizing, educating, evangelizing, and building great tooling in an effort to improve user experience on the web. Sergey has been doing all of those things earlier and longer than almost everyone!

Sergey is a well-known early champion of web performance and user experience. Among other things...

Back in 2009, he started the first web performance meetup group in New York City, which is still running strong today.
He lit the match for many conversations about how to improve speed through his Meet for Speed events (also still going strong), where brave souls ask for critique of websites while a panel of experts perform forensic analysis of front-end code.
He has brought in countless speakers, in addition to his own talks, to give different perspectives on front-end performance.
He has helped people organize their own web performance meetup groups in cities around the world.
He has built an assortment of free and open-source tools – from ShowSlow (a circa-2009 synthetic monitoring tool) to Speed Patterns (a collection of design patterns for fast user experiences on the web that is a current work in progress). You can check out his many other tools and projects on his personal site.

On top of everything, he is kind, funny, and always up for a hallway conversation.

Sergey currently works as a Speed Manager at Cloudflare. He took some time out of his personal schedule to give us a little more insight into the path he's taken.

How did you get your start in web performance?

"I was always curious about making web pages faster and configured compression and optimized my databases, architecting things to do less work when a user loads the page.

Then I attended a first talk by Steve Souders [a fellow SpeedCurver!] at one of the Web 2.0 conferences that O'Reilly organized, where he introduced the topic of web (or front-end) performance and immediately converted me on the spot, as I realized that we were mostly looking in the wrong place."

What prompted you to start the first web performance meetup group?

"I was already interested in meetups and attended quite a few in NYC, so after another Web 2.0 conference and chatting with Steve, I thought that I cannot really wait another year to talk to people about this important topic and decided to step up as an organizer and created a topic of Web Performance on Meetup.com and started the group with monthly events."

When was the first NY WebPerf meetup, and do you recall who spoke?

"The first event was in May 2009 with my own presentation about the Tools of the Trade, I still have the deck for it here – it's fun to reminisce about it. Then I was able to find more folks in the NYC scene and we had a PHP/MySQL/front-end trio talk at Etsy's office, and then it kept rolling. ;)"

ShowSlow was one of my favorite tools early in my career. What drove you to build it and are there any plans to revisit it or any of your other open-source projects?

"I built ShowSlow, which was the first open-source synthetic tracker, I believe. It started with my reading an obscure post by Stoyan Stefanov about YSlow beacon setting, which I ended up reverse-engineering and basically creating an endpoint to collect that data.

I built it because I wanted to track those synthetic scores and to keep the conversation going without decision makers manually running YSlow on their machines. Then, later, I convinced the Google team to add similar beacon functionality to the Page Speed Insights plugin they built, and then convinced Patrick Meenan to add it to WPT [WebPageTest] as well.

It was a great collaboration of open sorcerers and I loved it.

I don't think I'd be resurrecting it, because sitespeed.io basically replaced it and they did a much better job maintaining it, plus RUM replaced synthetic monitoring anyway, and there are plenty of affordable commercial tools like SpeedCurve that can spend time maintaining these ever-more-complex solutions.

I am revisiting a few projects here and there, such as UX Speed Calculator. I hope to give it a few more features and potentially create a talk to show progression of understanding of speed data. And maybe the UX Capture library and methodology will get a facelift now that soft navigations might come back, we have much better APIs for collecting metrics, and container timing might get standardized.

Or maybe my idea of Borderless Computation can be the next big hit, but I fear that it is just too crazy and unrealistic. ;)

If only we had more hours in a day..."

What are you most excited about in 2025, related to performance, and what keeps you up at night?

"In general I want to get into more 'design and build fast experiences'. I hope to one day write more articles for Speed Patterns and build a speed museum that I've been thinking of for a while now.

In terms of technologies, we do have a few innovations like Speculation Rules and a few related things like View Transitions, that finally break the old paradigms of the existing web and can potentially bring big changes. But as with any big and shiny feature, there is still a long way to go before they become mainstream.

One day I hope we can find a working and cool alternative to the SPA pandemic and make it possible and fun to make things useful and fast at the same time.

The performance inequality gap is growing at an alarming pace and I feel that we all need to find better solutions for this problem. It is possible that one does not exist, though. Inequality is, unfortunately, a norm of our life and the web performance aspect is just a reflection of it."

What advice do you have for someone who is interested in learning more about web performance?

"Read the docs, but also learn to triage the issues using the tools. Learn what makes things slow and how browsers and networks work and how they talk to the servers.

And more generically, don't take anything at face value. All the rules that were written so far were written by people like you. Understand why things are the way they are, and that will give you a good direction for your exploration and decision making.

Last but not least, remember that we are not solving problems for computers. We are solving them for people, as we try to make them less frustrated with computers."

Thank you Sergey! Lucky for us, you show no signs of slowing down (pun intended). The world is a faster, better place with you in it!

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

Six things that slow down your site's UX (and why you have no control over them)

Tue, 11 Feb 2025 00:00:00 +1300

Have you ever looked at the page speed metrics – such as Start Render and Largest Contentful Paint – for your site in both your synthetic and real user monitoring tools and wondered "Why are these numbers so different?"

^{Photo by Freepik}

Part of the answer is this: You have a lot of control over the design and code for the pages on your site, plus a decent amount of control over the first and middle mile of the network your pages travel over. But when it comes to the last mile – or more specifically, the last few feet – matters are no longer in your hands.

Your synthetic testing tool shows you how your pages perform in a clean lab environment, using variables – such as browser, connection type, even CPU power – that you've selected.

Your real user monitoring (RUM) tool shows you how your pages perform out in the real world, where they're affected by a myriad of variables that are completely outside your control.

In this post we'll review a handful of those performance-leaching culprits that are outside your control – and that can add precious seconds to the amount of time it takes for your pages to render for your users. Then we'll talk about how to use your monitoring tools to understand how your real people experience your site.

Consider this scenario...

^{Photo by andreas on Freepik}

Someone visits your site on their family computer, which is shared by four people.
The computer is a MacBook Pro they bought in 2018, so it still feels newish to them. (They have no plans to replace it any time soon. Kids can be rough on laptops!)
The primary browser is Chrome 108 (circa 2022) with a half-dozen nifty toolbar add-ons, including social widgets and a parental control plugin.
Each family member has their own browser window with anywhere between 10-20 tabs open at any given time. They keep the same browser window open for days or weeks (sometimes even months) on end.
They tend to leave all their other applications open, for easy access. This includes MS Word and Excel, PS Elements, Zoom, and Stop Motion Studio (for the kids!). They're concerned about internet security, so they'e also running antivirus software.
They think they have high-speed internet because they're paying their service provider for it, but they're using an eight-year-old modem.
They only restart their machine when it's running so slowly that it becomes intolerable — or when it crashes.

If a crash happens when they're on your site, your user doesn't blame any of the factors listed above. Chances are they blame your site. This holds true for slowdowns as well.

Is this fair? Not really.

It's also not fair that those lost seconds and lost visitors could result in lost revenue for your company, but this is the world we live in.

Let's go into more detail about end-user performance culprits.

1. End-user connection speed

If you live in an urban centre, you may enjoy connection speeds of 150 Mbps or more. You may find it hard to believe that there are still many rural communities where internet users typically experience connection speeds of just 6-10 Mbps. And as the graph below shows, even some urban centres can suffer download speeds as low as 20 Mbps.

Here are some minimum download speed requirements for common online activities:

Check email and basic web browsing: 0.5-1 Mbps
Music streaming: 1-2 Mbps
SD video streaming: 2-3 Mbps
Video calls and gaming: 3-5 Mbps
HD video streaming: 5-25 Mbps
Stream 4K content and play competitive online games: 25-50 Mbps

Keep in mind that the numbers above are bare minimums. Meeting these thresholds does not guarantee an optimal experience.

The number of internet users in your house could increase your download speed needs by 2X or more. If multiple people are using the connection at the same time – which is more common than not – then your requirements could be double, or even triple, the numbers listed above.

Smart devices also affect connection speeds. The connected devices in your home – such as smart thermostats, lighting, and security systems – are all quietly consuming more bandwidth in the background.

2. Older hardware

If you subscribe to faster service through your ISP, but you're using an older modem and/or an older router, you may not be getting the service you're paying for. For a myriad of reasons, older hardware can't always accommodate faster speeds.

Most people use the same hardware for between five to ten years. It's recommended that you replace your modem and router at least every five years – or even as often as two or three years, depending on the quality of the hardware and how it's treated during its lifespan. (Despite this, I’ve yet to encounter an ISP that proactively reminds customers to upgrade their hardware.)

^{If your modem looks like this, replace it immediately.}

Specifications and standards are in flux. Back around 2011, most cable companies made the switch from DOCSIS 2.0 to DOCSIS 3.0. (DOCSIS stands for "data over cable service interface specifications".) If you're not using a DOCSIS 3.0 or 3.1 modem, then you haven't been fully leveraging your high-speed plan.

We don't know how many users are still using DOCSIS 2.0. While it's to be hoped that most internet users are using DOCSIS 3.0 at minimum, there's definitely no guarantee. I searched for numbers on how many people might still be using DOCSIS 2.0, but couldn't find anything. But given that a non-trivial number of people hold on to their modems for 10-15 years, it feels safe to assume that some folks are still using hardware that undermines performance.

(Note that the specs for DOCSIS 4.0 have been released, but DOCSIS 4.0 modems aren't available for retail purchase yet. After DOCSIS 4.0 starts being broadly released – possibly later this year – we should be ready for the same scenario to play out all over again.)

3. Older desktop and mobile devices

While the current "industry standard" sets the lifecycle of a desktop computer at four to five years, data shows that the average person keeps their computer for longer than that.

In the US, the average person replaces their desktop computer every 5.6 years. In those 5.6 years, performance can seriously degrade — sometimes due to viruses or, more commonly, due to simply running low on memory.

5.6 years is just an average. Many people hold on to their computers for much longer. In other words, more than half of the people coming to our sites could be using significantly older devices.

The desktop replacement lifecycle is increasing, not decreasing, over time. According to Statista, the average lifecycle could increase to 6.5 years by 2027.

This holds true for smartphones, as well. The smartphone replacement cycle is a fair bit shorter, but the lengthening trend also appears here. In the US, the average expected lifecycle of smartphones is currently around 2.8 years (again according to Statista). In a couple of years, that lifecycle is expected to grow to about three years.

(Personal disclosure: In September 2024, I reluctantly retired my seven-year-old iPhone 7. I mention this for anyone who might not believe that many people choose not to upgrade their phones every couple of years.)

4. Browser version

You upgrade your browser religiously. Many people do not or cannot, so it's unwise to assume that your users are running the latest and greatest version of their chosen browser.

To illustrate, let's look at the latest Chrome stats from Statcounter. Some interesting things to note:

A small number of users are still using Chrome 39, which was released in 2014.
Versions 122 to 132 were released over the past 12 months. These are used by 88.32% of Chrome users.
11.15% of Chrome users use versions (77 to 120) that were released between 2019 to 2023. In other words, they're using versions that are up to five years old.
0.52% of Chrome users are currently using versions that are between 5-10 years old. Does that not sound like much? There are an estimated 3.5 billion Chrome users worldwide, so 0.52% of that is more than 18 million people.

Why does the age of the browser version matter? Outdated browsers may not support new web technologies and standards, resulting in compatibility issues and slower loading times (not to mention security issues, but that's a whole other problem).

5. Browser use (and abuse)

Browser age is just one issue. There are a number of other variables that can affect browser performance, such as:

Cache and cookie overload – Most people don't clear their cache and cookies regularly (if at all). Over time, these files pile up and slow down the browser.
Multiple windows and tabs – Having too many windows and tabs open at once requires more system resources, which leads to slower performance.
Malware and adware – These can cause a number of problems, including redirects, unwanted popups, and other slowdowns.
Browser extensions – Not all plugins affect performance, but some definitely do, particularly security plugins. The more plugins, the greater the risk of page slowdowns.

^{Performance expert Tim Kadlec on Bluesky}

Related: Some productivity experts say too many open tabs can lead to cognitive overload and reduced focus for users. According to some experts, you should never have more than 3-5 tabs open at a time. Raise your hand if you have more than five tabs open right now. *RAISES HAND*

6. Other applications

Running too many non-web applications at the same time affects web performance. But many non-techie internet users don’t know this. Some other things that aren't common knowledge outside our tech silo:

Automatic software updates – Consumes CPU and memory, potentially leading to slower browsing.
Antivirus software – Scans incoming files to identify and eliminate viruses and other malware such as adware, spyware, trojan horses, etc. It does this by analyzing all files coming through your browser in realtime, meaning that files are paused for inspection before being permitted to download. Because of this inspection, a performance penalty is inevitable and unavoidable. The extent of the penalty depends on the software and on the composition of the page/resource being rendered in the browser.

Takeaways

As I said at the top of this post, you have no control over potential problems at the very front end of the user experience. But that doesn’t mean you shouldn’t arm yourself with the knowledge that problems are occurring.

1. Optimize your pages

While you can’t control the end-user environment, you have tons of control over your pages. Optimizing your images and JavaScript (including third parties), smarter browser caching, creating performance budgets to catch regressions — these are just a few of the techniques you can leverage to mitigate the damage done by things like poor connection speeds and older hardware.

2. Use a reliable content delivery network

In addition to optimizing the heck out of your pages, you should also consider using a reliable content delivery network (CDN).

3. Use real user monitoring to understand real-world performance

Don't rely on your own experience using your site. You also shouldn't rely on synthetic tests to give you a true sense of how your pages perform. Your synthetic testing tools show you how your pages perform in a clean lab environment. Synthetic monitoring is essential for establishing a baseline and showing you the impact of code and design changes. That's only one half of what you need to know. You need to combine synthetic and real user monitoring.

Real user monitoring (RUM) tools show you how your pages perform out in the real world, where they're affected by variables outside your control. You need real user monitoring that gives you full visibility into how actual people are experiencing your site.

4. Look at performance at the 75th and 95th percentile, not just the median

Too many people focus on what performance and user experience look like at the median, and they neglect the large number of users at the 75th and 95th percentiles. Here's when and why you should focus on median, 75th percentile, and 95th percentile results:

Median – This is typically a stable measurement, so it's good for seeing long-term trends; however, the median will typically not show short-term trends or anomalies. Importantly, it also doesn't give you any visibility into the user experience being tracked in the worst-performing half of your data.
75th percentile – This is a good balance of representing the vast majority of measurements, while not being affected by outliers. While not as stable as the median, the 75th percentile is a good choice for seeing medium- to long-term trends. The 75th percentile is the best value to use when setting performance budgets. It's the percentile that Google recommends using when monitoring Core Web Vitals.
95th percentile – This encompasses the experience of almost all of your users, with only the most severe outliers excluded. This makes it perfect for spotting short-term trends and anomalies. If your metrics look good at the 95th percentile, you can feel assured that the majority of your visitors are having a fast user experience.

Summary

You have a lot of control over the design and code for the pages on your site, plus a decent amount of control over the first and middle mile of the network your pages travel over. But when it comes to the last mile – or more specifically, the last few feet – matters are no longer in your hands. This is why you need to combine synthetic and real user monitoring for visibility into the full breadth of your users' experiences.

Page bloat update: How does ever-increasing page size affect your business and your users?

Tue, 28 Jan 2025 00:00:00 +1300

The median web page is 8% bigger than it was just one year ago. How does this affect your page speed, your Core Web Vitals, your search rank, your business, and most important – your users? Keep scrolling for the latest trends and analysis.

For almost fifteen years, I've been writing about page bloat, its impact on site speed, and ultimately how it affects your users and your business. You might think this topic would be exhausted by now, but every year I learn new things – beyond the overarching fact that pages keep getting bigger and more complex, as you can see in this chart, using data from the HTTP Archive:

In this post, we'll cover:

How much pages have grown over the past year
How page bloat hurts your business and – at the heart of everything – your users
How page bloat affects Google's Core Web Vitals (and therefore SEO)
If it's possible to have large pages that still deliver a good user experience
Page size targets
How to track page size and complexity
How to fight regressions

anymouse123456 via Hacker News

What do we mean when we talk about page size?

When we talk about page size, we're referring to overall page weight and complexity. This includes:

Size – Total page weight in bytes. Size matters, especially to mobile users who have limited and/or metered data.
Resources – Total number of resources (HTML, images, fonts, etc.) on the page. The more resources, the greater the complexity of the page – and the increased likelihood of rendering delays, and even blockages.
HTML – Typically the smallest resource on the page, HTML's performance risk is usually negligible. (Having said that, a while back I dug into a page where the total HTML size jumped dramatically because of a bunch of inline JavaScript, which led to rendering delays, so keeping an eye on HTML size is still a good idea.)
Images – Often the greatest contributor to page bloat. Looking at the 90th percentile of the distribution of page weight, images account for a whopping 6.6 MB of a roughly 11.1 MB page. In other words, images comprised almost 60% of the total page weight. And if that already wasn’t enough, the number of images on a page has been linked to lower conversion rates on retail sites. Learn how to optimize images.
Video – Over the past couple of years, video has proliferated hugely. This is a potential cause for concern for anyone who cares about metrics like Largest Contentful Paint, which measures the largest visual element on a page – including videos. (More on that below.)
JavaScript – A page can have a relatively low JS weight but still suffer from JS-inflicted performance problems. Even a single 100 KB third-party script can wreak havoc with your page. The more scripts on your page, the greater the risk. It’s not enough to focus solely on blocking scripts. It’s possible for your pages to contain zero blocking scripts and still have less-than-optimal performance because of how your JavaScript is rendered. That’s why it’s so important to understand CPU usage on your pages, because JavaScript consumes more CPU than all other browser activities combined. When JavaScript blocks the CPU, the browser can’t respond to user input. This creates what’s commonly called "jank" – that annoying feeling of jittery, unstable page rendering. Learn more about optimizing JS.
CSS – Like JavaScript, CSS doesn’t have to be bulky to cause problems. Poorly executed stylesheets can create a host of performance problems, ranging from stylesheets taking too long to download and parse, to improperly placed stylesheets that block the rest of the page from rendering. And, similar to JavaScript, more CSS files equals more potential trouble. Review some CSS optimization tips and best practices.

How does page bloat hurt Core Web Vitals?

Core Web Vitals are a Google search ranking factor. Given that Google continues to dominate search usage, you should care about Vitals alongside the other metrics you should be tracking.

Page bloat can have a huge impact on your Vitals:

Cumulative Layout Shift – Excessive resources can contribute to a poorer CLS score, as more elements shift on the page.
Largest Contentful Paint – LCP measures when the largest visual element (image or video) in the viewport finishes rendering. Heavier visual elements can take much longer to render, especially videos. If you're serving huge videos that take several seconds to fully render, that could hurt your LCP times.
Interaction to Next Paint & Total Blocking Time – Excessive and/or non-performant JavaScript can hurt interactivity metrics, like INP and TBT. The more scripts on your pages, the greater the risk.

How does page bloat hurt your business?

A Google machine-learning study I helped with a few years ago found a few strong predictors of whether or not a page resulted in a conversion, ranked in the following order:

The total number of page elements was the single greatest predictor of conversions.
The number of images on the page was the second greatest predictor.
The more scripts there were in a series of pages in a session, the less likely that session was to convert.

Image size is another issue, as excessive image weight hurts your SEO ranking in Google Image Search. Given that image search comprises upwards of 26% of Google searches, this is something you should care about. (You can dive deeper into best practices for image optimization.)

How does page bloat hurt your visitors?

In his excellent ongoing series of blog posts, The Performance Inequality Gap, Alex Russell makes a compelling case that serving huge pages is an "ethical crisis for front end" as more and more users rely solely on low-powered mobile devices to deliver essential information and services:

The "i" in iPhone stands for "inequality".

Premium devices are largely absent in markets with billions of users thanks to the chasm of global wealth inequality....

As smartphone ownership and use grow, the frontends we deliver remain mediated by the properties of those devices. The inequality between the high-end and low-end is only growing, even in wealthy countries. What we choose to do in response defines what it means to practice UX engineering ethically.

Developers are clearly out of touch with market ground-truth. Building an understanding of the differences in the experiences of the wealthy vs. working-class users can make the privilege bubble's one-way mirror perceptible from the inside.

HTTP Archive research: Background and caveats

Before we get into the analysis, some context:

The numbers cited below all come from the HTTP Archive. I looked at the top 1M sites, focusing on median and 90th percentile numbers. This is to try to understand how a "typical" page might perform, as well as pages in the longtail.
These numbers should NOT be taken as a benchmark for your own site. You haven't necessarily achieved anything great if your pages are smaller than this, nor have you failed by default if your pages are bigger. I'll go into this more below.

Desktop: The median page has grown by 8% in one year

If you look at the year-over-year increase from 2467.5 KB to 2675.2 KB, you're forgiven if your initial reaction is "that's not too bad". But 8% growth is significant. At that rate, the median page could be 3 MB by the end of this year. That's not trivial.

Even if you consider this growth not too worrisome, it's important to keep in mind that it's just an aggregated number, which masks the more dramatic increases in specific resource types, such as images, JavaScript, and video.

Desktop: Median JavaScript weight increased by 10%

A 10% year-over-year increase in JS size is something to take note of. All in, JS weight has increased by 28% since 2022.

Each script on your page represents a potential single point of failure, especially if the script is render-blocking or has an excessive Long Tasks time. The more scripts on your page, the greater the performance risk.

Even if the script doesn't block the page from rendering, excessive and unoptimized JavaScript can hurt interactivity metrics like Interaction to Next Paint and Total Blocking Time. Remember: The single best thing you can do with JavaScript is to avoid using it when you don't need to.

It's interesting to note that the number of scripts on the median page has more or less remained the same, as shown above. This suggests that the increase in JS weight is coming because individual scripts are becoming heavier.

Desktop: Median image weight increased by 5%

This finding came as a somewhat pleasant surprise. While the upward trend is still present, it's not quite as alarming as it has been in previous years.

Still, it's important to keep in mind that 1058 KB of image weight represents roughly 40% of the total weight of the median page. Improving image optimization and rendering best practices could have a noticeable impact on page speed.

Similar to the observation about JS size and resources above, it's interesting to see that while the number of image requests has been more or less stable over the past couple of years, the total size has increased. This suggests that the size of individual images is trending upward.

Desktop: Median video weight increased by 17%

As mentioned earlier, video is one of the main growth areas. (If you're adding up the numbers and wondering how the video weight makes sense given the median page weight cited earlier, keep in mind that these medians are calculated based on pages that contain these resources. Of the one million URLs tracked by the HTTP Archive, not all contain video.)

As mentioned earlier in this post, Largest Contentful Paint (one of Google's Core Web Vitals) measures when the largest visual element (image or video) in the viewport finishes rendering. Heavier visual elements can take much longer to render, especially videos.

In other words, if you serve huge videos to your users, it could be hurting your LCP times, which could then be hurting your Google search ranking.

While not all pages serve video, those that do are serving larger and larger video files. The median page that contains video serves just 2 files, but the total weight has increased by 28% in just two years.

Mobile: Median page has grown by 7.5% in one year

A few years ago, it seemed like mobile page growth had slowed down, but it once again appears to be on the upswing. The median page served to mobile is well over 2 MB – and keep in mind that this is being served to low-powered and/or connectivity-impaired mobile devices.

While the median mobile page is still a bit smaller than the desktop page, when we look at the breakdown across resource types, we can see growth in images, JavaScript, and video, just as we did with desktop:

90th percentile sees a 24% increase

Things get really interesting when we compare numbers at the 90th percentile. This is where we can see explosive growth over the past year.

The 90p page currently weighs in at over 11 MB. At this rate of growth, the 90p page could reach 14 MB by the end of this year.

90p mobile page is 4X larger than median mobile page

The 90th percentile page served to mobile is almost 10 MB, making it four times larger than the median page. As before, consider the range of mobile devices that might be struggling to render this massive page.

90p page contains 2.5X more requests than the median page

The median page served to desktop contained a total of 76 resources (HTML, JS, images, videos, etc.) compared to the 90th percentile with a total of 189 resources. In other words, the 90p page contains almost three times the number of requests.

While it wasn't surprising to see the large number of image, JavaScript, and video requests at the 90th percentile, it was a surprise to see that the 90p page contained 12 HTML requests and 30 CSS requests.

Most 90p page weight comes from video, images, and JavaScript

As mentioned earlier, not all pages contain video, but those that do at the 90th percentile contain a LOT – almost 20 MB!

Image weight comes next, weighing in at 6.6 MB. JavaScript runs third at almost 2 MB.

Can large pages ever deliver a good user experience?

Yes. While page size can be a red flag for performance issues, you need to take a closer look at how your pages are built to see if the size and complexity of your pages actually affect how fast your site feels to your users.

It's not enough to look at crude metrics like total requests and size. You need to know:

How many of your requests are blocking requests?
If your page contains blocking requests, how many of them occur in the critical rendering path? That is, how many blocking requests are there before key page metrics like Start Render and Largest Contentful Paint?
How many of your potentially problematic requests come from third parties, and how do you maintain visibility into how they're performing?
Are the most important images on your page the first images to render? How quickly do they show up?

How much content should you serve?

Making your pages as small as possible is in the best interest of your users who don't have access to fast networks and devices. Alex Russell suggests these per-page content targets for first-load under 3 seconds on 75th percentile devices:

For JS-centric pages – No more than 365 KB of JS and 365 KB of markup, for a total of 730 KB
For markup-centric pages – No more than 75 KB of JavaScript and 1.3 MB of markup, for a total of 1.4 MB

This is how those recommended thresholds stack up against the current reality:

Are these targets aggressive? Yes. Will you be able to meet them? Possibly not. But as the saying goes, don't let perfect be the enemy of good.

Takeaways

I meet with so many people who build and optimize websites. When we investigate how their pages are built, I routinely witness surprise at spotting things like ghost scripts, huge unoptimized images, and blocking resources they weren't aware of. These are smart people. The problem isn't them – it's the scale of their sites, the speed of their release cycles, and the number of people who touch each page.

We might never get our lean, pre-1999, under-1MB web pages back. But we can regain control over the pages we have today.

1. Understand the critical rendering path for each page

Your pages probably have a some dead weight on them, and some of that weight is unoptimized. Too much stuff means you can't see the forest for the trees. The key to a good user experience is quickly delivering the most important content first. Here are some great resources for analyzing and optimizing the critical rendering path.

2. Make sure everyone who touches a page understands the performance impact of what they do

All the fancy performance monitoring tools in the world can't help you if you don't have a strong performance culture at your organization. Here are some tips and best practices to help on that journey.

3. Use performance budgets to fight regression

Page bloat happens when people stop paying attention. Pages need to be monitored consistently over time. Integrating performance testing into your CI/CD process is a great way to fight regression, especially if you combine this with creating performance budgets. By creating performance budgets for key metrics – such as Start Render, Largest Contentful Paint, Interaction to Next Paint, and various page size and weight metrics – you can get alerted when they go out of bounds.

4. Don't assume hardware and networks will mitigate page bloat

Increased page size and complexity is not fully mitigated by faster devices and networks, or by our hard-working browsers. Clearly we need to keep talking about it. We need to understand how ever-growing pages work against us. And we need to have strategies in place to understand and manage our pages.

5. Don't forget to monitor longtail performance

While some of your users may have newer devices and speedy networks, not all are this lucky. If you're using a real user monitoring tool, keep an eye on your performance metrics at the 75th and 95th percentiles so you have an understanding of your site's less-than-optimal performance.

Questions or feedback?

I'd love to hear your thoughts and insights. If you're interested in tracking page size and complexity for your own site, we'd love to have you try SpeedCurve for free!

Performance Hero: Annie Sullivan

Mon, 20 Jan 2025 00:00:00 +1300

Let's kick off the new year by celebrating someone who has not just had a huge impact on web performance over the past few years, but who has even more exciting stuff in the works for the future: Annie Sullivan!

Annie leads the Chrome Speed Metrics team at Google, which has arguably had the most significant impact on web performance of the past decade. We've gotten to know Annie through frequent discussions, feedback sessions, and hallway talks at various events. Most recently we caught her closing keynote at performance.now() in November.

Speaking from experience, driving change at scale from within a large organization can be very challenging. Annie and her team navigate this arduous task with true passion for web performance and for improving the user experience. Read on for a great recap of a recent discussion with Annie and just a few of the highlights that make her a true performance hero.

In her recent performance.now() talk, which is a must-watch, Annie took us through key learnings she has had while working in performance for the last couple of decades.

In her preamble, she celebrated some of the successes our community has had over the past year. This slide really stuck out to me as an example of how we collectively have a huge impact on the user experience:

You know when you are measuring success in 'years of time saved' that you've had a meaningful impact. Nice job, everyone!

It's really important to acknowledge that none of this would have been possible without the great work from Annie and her small-but-mighty Speed Metrics team at Google. Here is a little more we learned about Annie and her team.

How did you get your start in web performance?

"The very first web performance project I did was back in the late nineties! I was running a message board for the local punk rock scene in Detroit. I started with WWWboard, but it had a race condition that led to overwriting posts. So I decided to write my own message board in PHP and MySQL, which better managed transactions. But my original version was slow, because I queried the database for every page load. Of course writes were much less common than reads, so I added a caching layer for reads, and that did the trick.

"After I finished college, I did performance work here and there while developing games for Playstation 2, and later at Google. Then in 2008, Google issued a code yellow for application speed, and I was the code yellow lead for Google Docs. A critical part of the code yellow was ensuring Google's sites would be fast for users across the globe, even if they had slow networks and low end devices. Leadership wanted to know the real page load times end users were experiencing. So in addition to all the optimization work we did for Google Docs, I got to spend a lot of time and energy working on the measurement problem: how can we get end-to-end latency numbers? How do we slice and dice them to find problem areas? What should we tell browser vendors is missing? That got me started on a long journey I'm still on today."

(We always knew you were punk rock, Annie, but we had no idea you'd been at performance since the nineties!)

What is the charter of the Chrome Speed Metrics team?

"The Chrome Speed Metrics team aims to quantify users' experience of the web to provide Chrome engineers and web developers the metrics, insights, and incentives they need to improve it.

(At SpeedCurve, we've worked closely with this team over the years, and can tell you that everyone is invested in this mission. The Speed Metrics team is a great example of how to build a performance first culture within your organization, whether that's a ginormous company like Google or a small shop like SpeedCurve, passionate people truly can make a difference.)

2024 seemed like it was full of big wins. What was the one you were most proud of?

"With the introduction of the Long Animation Frames API [LoAF], sites have better insight into the causes of slow JavaScript than ever before. With the additional data, we've been able to reach out to several third parties who've then made improvements, and I've heard positive stories from several other members of the web perf community who've done the same. There were two case studies highlighting third party wins published on web.dev (1, 2), and Google Publisher Tag launched a new yielding strategy. All the feedback from third parties we got from this process helped us prioritize the scheduler.yield() API so that it's easier for third parties to work well with the rest of the content on the page.

"I know third parties have long been a point of frustration for web performance enthusiasts, but it's been amazing to see the optimizations here, which can make thousands or even millions of sites faster overnight."

(We agree the visibility that LoAF attribution brings is exciting! Everyone loves to hate third parties, but with the exception of synthetic testing, we haven't had a lot to work from. SpeedCurve is hard at work looking at how to leverage the LoAF API to improve our RUM data. We hope that third parties embrace this data and continue to look at improving. However, we are also hearing that a fair number of LoAFs responsible for poor Interaction to Next Paint (INP) are surprisingly coming from first-party JavaScript!)

What are you working on now and/or what are you most excited about?

"I'm currently working with Michal Mocny [on the Google Speed Metrics team] on integrating soft navigations into Core Web Vitals. I'm really excited about getting a deeper understanding of single page applications and their performance. From my perspective, it's the biggest blind spot in web performance and every day I learn something new."

(We've been following this work closely and are thrilled to see it getting so much attention. SPAs continue to be a challenge for performance, starting with measuring the true user experience. Looking forward to seeing this evolve!)

As we roll into 2025, what do you see as the single biggest challenge in front of us?

"I always get excited about challenges, and I think the biggest one is working together! There are so many wonderful developments in the world of standards--increased engagement from other vendors, the RUM CG, the Container Timing work. I'm excited for the challenge of collaborating effectively with people around the world. There's so much potential to bring many more viewpoints to the table."

(Well put, Annie. We couldn't agree more. And here's a shameless plug for the W3C RUM Community Group, which has generated a lot of interest and had its first meeting on January 17. Learn more about the RUM Community Group.)

We are soooooo excited for 2025, especially with awesome leaders like Annie at the helm.

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

Our 10 most popular web performance articles of 2024

Thu, 19 Dec 2024 00:00:00 +1300

We love writing articles and blog posts that help folks solve real web performance and UX problems. Here are the ones you loved most in 2024. (The number one item may surprise you!)

Some of these articles come from our recently published Web Performance Guide – a collection of evergreen how-to resources (written by actual humans!) that will help you master website monitoring, analytics, and diagnostics. The rest come from this blog, where we tend to publish industry news and analysis.

Regardless of the source, we hope you find these pieces useful!

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

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.

9. Best practices for optimizing images

They say a picture is worth a thousand words. Unfortunately that picture can also cost you 1,000 kilobytes. Images are an important part of providing a rich, user-friendly experience online. It’s critical to optimize how they’re loaded and how much they weigh. Here's a detailed checklist of best practices and how-tos to make sure your beautiful images aren't hurting your page speed.

8. Understanding and improving INP

Interaction to Next Paint (INP) is the Core Web Vital that measures how responsive a page is to visitor interactions. According to Google, a 'good' INP time is faster that 200 milliseconds. Learn how to identify and debug slow interactions – and most important, how to make them faster, improve your INP time, and potentially improve your Google search rank!

7. Understanding and improving LCP

Largest Contentful Paint (LCP) is the Core Web Vital that measures when the largest visual element on the page renders. To make Google happy, aim for an LCP time under 2.5 seconds. Here's everything you need to know to start measuring, debugging, and optimizing LCP.

6. Best practices for optimizing JS

Byte for byte, no resource affects page speed more than JavaScript. JavaScript affects network performance, CPU processing time, memory usage, and overall user experience. Inefficient scripts can slow down your website, making it less responsive and more frustrating for your users. This guide walks you through essential techniques for reducing the negative impact of JS on your pages by focusing on reducing the impact on the initial load, as well as reducing the impact of the actual JS interaction itself.

5. A complete guide to performance budgets

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

4. Get started with Core Web Vitals

This is it, your one-stop shop. Everything you need to know about Core Web Vitals – from SEO and business impact to how to continuously monitor, catch regressions, and fix issues with each Vital.

3. The psychology of site speed

If you don't consider time a crucial usability factor, you're missing a fundamental aspect of the user experience. Before getting into the technical side of web performance, it's important to first understand the roots of our craving for lightning-fast online experiences.

2. Fifteen page speed optimizations that sites ignore (at their own risk)

Last summer, I analyzed the home pages of twenty leading websites and found that many sites are not taking advantage of a surprising number of optimization best practices – to the detriment of their performance metrics, and more importantly, to the detriment of their users and ultimately their business. Which of these neglected page speed optimizations could you be missing out on?

1. Averages, medians, and percentiles

This remains the most-read article in our entire library. It goes to show that there are a lot of people out there trying to understand their data. There are many ways to view aggregate web performance data, including 50th percentile, 75th percentile, 95th percentile, and average. What do they each mean, and which should you use? Find out here.

Looking ahead...

We love feedback! Did you find these articles helpful? Is there a topic or set of best practices you'd like us to write about? Let us know at support@speedcurve.com.