Skip to content

A Complete Guide to Web Performance Budgets

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

In this post we'll cover how to:

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

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

Let's get started!

Continue reading...

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

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

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

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

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

Let's dive in!

 

Continue reading...

Debugging Interaction to Next Paint (INP)

Not surprisingly, most of the conversations I've had with SpeedCurve users over the last few months have focused on improving INP.

INP measures how responsive a page is to visitor interactions. It measures the elapsed time between a tap, a click, or a keypress and the browser next painting to the screen.

Definition of INP

INP breaks down into three sub-parts

  • Input Delay – How long the interaction handler has to wait before executing
  • Processing Time – How long the interaction handler takes to execute
  • Presentation Delay – How long it takes the browser to execute any work it needs to paint updates triggered by the interaction handler

Pages can have multiple interactions, so the INP time you'll see reported by RUM products and other tools, such as Google Search Console and Chrome's UX Report (CrUX), will generally be the worst/highest INP time at the 75th percentile.

Like all Core Web Vitals, INP has a set of thresholds:

INP thresholds for Good, Needs Improvement and Poor
INP thresholds for Good, Needs Improvement, and Poor


Many sites tend to be in the Needs Improvement or Poor categories. My experience over the last few months is that getting to Good is achievable, but it's not always easy.

In this post I'm going to walk through:

  • How I help people identify the causes of poor INP times
  • Examples of some of the most common issues
  • Approaches I've used to help sites improve their INP

Continue reading...

How to find (and fix!) INP interactions on your pages

Andy Davies – fellow SpeedCurver and web performance consultant extraordinaire – recently shared an impressive Interaction to Next Paint (INP) success:

Andy has promised us a more in-depth post on debugging Interaction to Next Paint. While he's working on that, I'll try not to steal his thunder while I share a tip that may help you identify element(s) causing INP issues for your pages.

Continue reading...

Mobile INP performance: The elephant in the room

Earlier this year, when Google announced that Interaction to Next Paint (INP) will replace First Input Delay (FID) as the responsiveness metric in Core Web Vitals in *gulp* March of 2024, we had a lot to say about it. (TLDR: FID doesn't correlate with real user behavior, so we don't endorse it as a meaningful metric.)

Our stance hasn't changed much since then. For the most part, everyone agrees the transition from FID to INP is a good thing. INP certainly seems to be capturing interaction issues that we see in the field.

However, after several months of discussing the impending change and getting a better look at INP issues in the wild, it's hard to ignore the fact that mobile stands out as the biggest INP offender by a wide margin. This doesn't get talked about as much as it should, so in this post we'll explore:

  • The gap between "good" INP for desktop vs mobile
  • Working theories as to why mobile INP is so much poorer than desktop INP
  • Correlating INP with user behavior and business metrics (like conversion rate)
  • How you can track and improve INP for your pages

Continue reading...

Does Interaction to Next Paint actually correlate to user behavior?

Earlier this year, Google announced that Interaction to Next Paint (INP) is no longer an experimental metric. INP will replace First Input Delay (FID) as a Core Web Vital in March of 2024.

Now that INP has arrived to dethrone FID as the responsiveness metric in Core Web Vitals, we've turned our eye to scrutinizing its effectiveness. In this post, we'll look at real-world data and attempt to answer: What correlation – if any – does INP have with actual user behavior and business metrics?

Continue reading...

10 things I love about SpeedCurve (that I think you'll love, too)

This month, SpeedCurve enters double digits with our tenth birthday. We're officially in our tweens! (Cue the mood swings?)

I joined the team in early 2017, and I'm blown away at how quickly the years have flown by. Every day, I marvel at my great luck in getting to work alongside an amazing team to build amazing tools to help amazing people like you!

In the spirit of celebration, I thought it would be fun to round up my ten favourite things to do in SpeedCurve (that I think you'll like, too). Keep scrolling to learn how to:

  1. Fight regressions and stay fast
  2. See the impact of performance on your business
  3. Benchmark your site against your competitors
  4. Track third parties to make sure they're not quietly hurting performance
  5. Make sure you're tracking the best metrics for your pages
  6. Get a prioritized list of performance recommendations
  7. Bookmark and compare synthetic tests and RUM sessions so you can quickly find and fix performance issues
  8. Run A/B tests so you see how code changes affect your performance and user engagement metrics
  9. Get customized weekly reports
  10. Motivate your team with a wall-mounted monitor showing your favourite charts 

Continue reading...

Demystifying Cumulative Layout Shift with CLS Windows

As we all know, naming things is hard.

Google's Core Web Vitals are an attempt to help folks new to web performance focus on three key metrics. Not all of these metrics are easy to understand based on their names alone:

  • Largest Contentful Paint (LCP) – When the largest visual element on the page renders
  • First Input Delay (FID) – How quickly a page responds to a user interaction (FID will be replaced by Interaction to Next Paint in March 2024)
  • Cumulative Layout Shift (CLS) – How visually stable a page is

Any time a new metric is introduced, it puts the burden on the rest of us to first unpack all the acronyms, and then explore and digest what concepts the words might refer to. This gets even trickier if the acronym stays the same, but the logic and algorithm behind the acronym changes.

In this post, we will dive deeper into Cumulative Layout Shift (CLS) and how it has quietly evolved over the years. Because CLS has been around for a while, you may already have some idea of what it represents. Before we go any further, I have a simple question for you:

How do you think Cumulative Layout Shift is measured? 

Hold your answer in your head as we explore the depths of CLS. I'm interested if your assumptions were correct, and there's a poll at the bottom of this post I'd love you to answer.

 

Continue reading...

Exploring performance and conversion rates just got easier

Demonstrating the impact of performance on your users – and on your business – is one of the best ways to get your company to care about the speed of your site.

Tracking goal-based metrics like conversion rate alongside performance data can give you richer and more compelling insights into how the performance of your site affects your users. This concept is not new by any means. In 2010, the Performance and Reliability team I was fortunate enough to lead at Walmartlabs shared our findings around the impact of front-end times on conversion rates. (This study and a number of other case studies tracked over the years can be found at WPOstats.)

Setting up conversion tracking in SpeedCurve RUM is fairly simple and definitely worthwhile. This post covers:

  • What is a conversion?
  • How to track conversions in SpeedCurve
  • Using conversion data with performance data for maximum benefit
  • Conversion tracking and user privacy

Continue reading...

What is page bloat? And how is it hurting your business, your search rank, and your users?

For more than ten 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 that this topic would be played out 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

Continue reading...

Farewell FID... and hello Interaction to Next Paint!

Today at Google I/O 2023, it was announced that Interaction to Next Paint (INP) is no longer an experimental metric. INP will replace First Input Delay (FID) as a Core Web Vital in March of 2024. 

It's been three years since the Core Web Vitals initiative was kicked off in May 2020. In that time, we've seen people's interest in performance dramatically increase, especially in the world of SEO. It's been hugely helpful to have a simple set of three metrics – focused on loading, interactivity, and responsiveness – that everyone can understand and focus on.

During this time, SpeedCurve has stayed objective when looking at the CWV metrics. When it comes to new performance metrics, it's easy to jump on hype-fuelled bandwagons. While we definitely get excited about emerging metrics, we also approach each new metric with an analytical eye. For example, back in November 2020, we took a closer look at one of the Core Web Vitals, First Input Delay, and found that it was sort of 'meh' overall when it came to meaningfully correlating with actual user behavior.

Now that INP has arrived to dethrone FID as the responsiveness metric for Core Web Vitals, we've turned our eye to scrutinizing its effectiveness.

In this post, we'll take a closer look and attempt to answer:

  • What is Interaction to next Paint?
  • How does INP compare to FID?
  • What is a 'good' INP result?
  • Will there be differences between INP collected in RUM vs. Chrome User Experience Report (CrUX)?
  • What correlation does INP have with real user behavior?
  • When should you start caring about INP?
  • How can you see INP for your own site in SpeedCurve?

Onward!

Continue reading...

NEW! Lighthouse 10, Core Web Vitals updates, and Interaction to Next Paint

There is a lot of excitement in the world of web performance these days, and April has been no exception! At SpeedCurve, we've been focused on staying on top of the items that affect you the most.

Here is a look at what's new in SpeedCurve:

  • Support for Lighthouse 10, including metric scoring changes as well as audits
  • Updated RUM Core Web Vitals, including the much-anticipated addition of Interaction to Next Paint (INP)

All of this work driven by the community is having a big impact in our collective goal to make performance accessible for everyone.

Read on to learn more about these exciting changes! 

Continue reading...

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

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

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

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

If you've ever asked yourself any of these questions, then you could find the answers in 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 performance metrics are on the performance plateau, making them a couple of seconds faster probably won't help your business.

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 and 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.

Continue reading...

Element Timing: One true metric to rule them all?

One of the great things about Google's Core Web Vitals is that they provide a standard way to measure our visitors’ experience. Core Web Vitals can answer questions like:

  • When was the largest element displayed? Largest Contentful Paint (LCP) measures when the largest visual element (image or video) finishes rendering.
  • How much did the content move around as it loads? Cumulative Layout Shift (CLS) measures the visual stability of a page.
  • How responsive was the page to visitors' actions? First Input Delay (FID) measures how quickly a page responds to a user interaction, such as a click/tap or keypress.

Sensible defaults, such as Core Web Vitals, are a good start, but one pitfall of standard measures is that they can miss what’s actually most important.

The (potential) problems with Largest Contentful Paint

Largest Contentful Paint (LCP) makes the assumption that the largest visible element is the most important content from the visitors’ perspective; however, we don’t have a choice about which element it measures. LCP may not be measuring the most appropriate – or even the same – element for each page view.

The LCP element can vary for first-time vs repeat visitors

In the case of a first-time visitor, the largest element might be a consent banner. On subsequent visits to the same page, the largest element might be an image for a product or a photo that illustrates a news story.

The screenshots from What Hifi (a UK audio-visual magazine) illustrate this problem. When the consent banner is shown, then one of its paragraphs is the LCP element. When the consent banner is not shown, an article title becomes the LCP element. In other words,  the LCP timestamp varies depending on which of these two experiences the visitor had!

https://www.whathifi.com with and without the consent banner visibleWhat Hi Fi with and without the consent banner visible

Continue reading...

July 2022 product update: Web Vitals support, more synthetic test agents & performance heat maps

It's been another busy month here at SpeedCurve! Check out our latest product updates below.

Continue reading...

June 2022 product update: Performance recommendations on Vitals dashboard, RUM path filters & more

We've been busy here at SpeedCurve HQ! Here's a roundup of our recent product updates.

Continue reading...

Understanding the performance impact of anti-flicker snippets

Experimentation tools that use asynchronous scripts – such as Google Optimize, Adobe Target, and Visual Web Optimizer –  recommend using an anti-flicker snippet to hide the page until they've finished executing. But this practice comes with some performance measurement pitfalls:

  • Hiding the contents of the page can have a dramatic effect on the Web Vitals that measure visual experience, such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)
  • Anti-flicker snippets can also affect Cumulative Layout Shift (CLS) and the synthetic equivalent of First Input Delay (FID), Total Blocking Time (TBT).

In this post we'll look at how anti-flicker snippets work, their impact on Web Vitals, and how to measure the delay they add to visitors' experience.

Continue reading...

Industry page speed benchmarks (March 2022)

Page Speed Benchmarks is an interactive dashboard that lets you explore and compare web performance data for leading websites across several industries – from retail to media – over the past year. This dashboard is publicly available (meaning you don't need a SpeedCurve account to explore it) and is a treasure trove of meaningful data that you can use for your own research.

The dashboard allows you to easily filter by region, industry, mobile/desktop, fast/slow, and key web performance metrics, including Google's Core Web Vitals. (Scroll down to the bottom of this post for more testing details.)

At the time of writing this post, these were the home pages with the fastest Start Render times in key industries:

As you can see, I've included Largest Contentful Paint alongside Start Render in this chart, for reasons I explain below.

Continue reading...

Ten years of page bloat: What have we learned?

(See our more recent page growth post: What is page bloat? And how is it hurting your business, search rank, and users?)

I've been writing about page size and complexity for years. If you've been working in the performance space for a while and you hear me start to talk about page growth, I'd forgive you if you started running away. ;)

But pages keep getting bigger and more complex year over year – and this increasing 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. 

In this post, we'll cover:

  • How big are pages today versus ten years ago?
  • How does page bloat hurt your business?
  • How does page bloat affect other metrics, such as Google's Core Web Vitals?
  • Is it possible to have large pages that deliver a good user experience?
  • What can we do to manage our pages and fight regression?

Continue reading...

SEO and web performance: What to measure and how to optimize

Chances are, you're here because of Google's update to its search algorithm, which affects both desktop and mobile, and which includes Core Web Vitals as a ranking factor. You may also be here because you've heard about the most recent potential candidates for addition to Core Web Vitals, which were just announced at Chrome Dev Summit. 

A few things are clear:

  • Core Web Vitals, as a premise, are here to stay for a while.
  • The metrics that comprise Web Vitals are still evolving.
  • These metrics will (I think) always be in a state of evolution. That's a good thing. We need to do our best to stay up to date – not just with which metrics to track, but also with what they measure and why they're important.

If you're new to Core Web Vitals, this is a Google initiative that was launched in early 2020. Web Vitals is (currently) a set of three metrics – Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift – that are intended to measure the loading, interactivity, and visual stability of a page. 

When Google talks, people listen. I talk with a lot of companies and I can attest that, since Web Vitals were announced, they've shot to the top of many people's list of things to care about. But Google's prioritization of page speed in search ranking isn't new, even for mobile. As far back as 2013, Google announced that pages that load slowly on mobile devices would be penalized in mobile search. 

Keep reading to find out:

  • How much does web performance matter when it comes to SEO?
  • Which performance metrics should you focus on for SEO?
  • What can you do to make your pages faster for SEO purposes?
  • What are some of the common issues that can hurt your Web Vitals?
  • How can you track performance for SEO?

Continue reading...

RSS