SpeedCurve Blog

ICYMI: Some of our most exciting product updates of 2024!

Tue, 17 Dec 2024 00:00:00 +1300

Every year feels like a big year here at SpeedCurve, and 2024 was no exception. Here's a recap of product highlights designed to make your performance monitoring even better and easier!

Our biggest achievements this year have centred on making it easier for you to:

Gather more meaningful real user monitoring (RUM) data
Get actionable insights from Core Web Vitals
Simplify your synthetic testing
Get expert performance coaching when and how you need it

Keep reading to learn more...

INP replaced FID

In the spring, Google made it official: Interaction to Next Paint replaced First Input Delay as the responsiveness metric in Core Web Vitals (the trifecta of performance metrics that are a key ingredient in Google's search ranking algorithm).

^{Correlation chart demonstrating that as INP gets worse, so does conversion rate for mobile users}

We've been tracking INP since well before Google made the announcement, so SpeedCurve users didn't have to scramble to switch over to a new metric. Because we've been tracking INP for a while, we were able to share some insights that our users found helpful, such as:

While INP changes typically correlate to changes in metrics like bounce rate and conversion rate, the results vary from site to site
Mobile INP has an even stronger correlation to bounce rate and conversions than desktop INP (see chart above)
There's no consistent correlation with Google's thresholds for 'Good' and 'Poor'

The main takeaway: While Google's recommended thresholds for 'Good' INP are a helpful starting point, you need to look at your own data, filter desktop and mobile traffic separately, and see how your INP results correlate to your own business and user engagement metrics. That's the most reliable way to ensure that you're creating meaningful performance goals for your pages.

RUM attribution and subparts for INP and LCP

Last May, we introduced more diagnostic detail for INP, to match the diagnostic depth we offer for Largest Contentful Paint (LCP). We made it easier to identify which user interactions are responsible for INP issues. We also started collecting performance data for INP subparts (which we also collect for LCP subparts), so you can understand exactly where interaction time is being spent.

This detailed walkthrough shows you how to make more meaningful and intuitive attributions for your RUM metrics (like INP and LCP) – which makes it much easier for you to zero in on your performance issues.

Re-vital-ized Vitals dashboard

Since we first launched the Vitals dashboard back in December of 2020, we've heard from many of you who want to expand the scope of the dashboard to include other meaningful metrics that are not technically considered Core Web Vitals.

Back in September, we gave the Vitals dashboard a complete refresh. We made it easier to filter metrics across page groups and to easily see LCP and INP subparts. We also added Backend Time and First Contentful Paint (FCP) to the Vitals dashboard, and we continue to show Total Blocking Time (TBT).

These three metrics tell us a lot about potential causes of a poor user experience:

Backend Time isn't always a black box. RUM can tell you where that time is being spent, whether its network related or due to CDN or origin issues.
First Contentful Paint tells us when the page begins to render and effectively become consumable by an end user.
Total Blocking Time gives us clues around CPU-intensive tasks that block rendering and interactivity with the page.

Focusing on Largest Contentful Paint (LCP), here's a walkthrough of how to leverage your Vitals dashboard to find and fix issues with your Vitals.

New RUM filters

We delivered a plethora of new RUM filters this year...

Delivery type

The delivery type of a page indicates how it was delivered to the browser. There are now three possible values:

Cache – Page was delivered from the browser's cache, which means the browser did not make a network request for that page
Navigational prefetch – Page came from the in-memory cache, via the Speculation Rules API
Other – This delivery type is when none of the other delivery types applies

Note that delivery type is only supported in Chromium-based browsers.

Navigation type

Not all navigations are created equal. We released a filter in RUM that allows you to explore navigation types. You can find navigation types in the filters of your RUM and Favorites dashboards.

These filters allow you to track:

Navigation – Full-page navigation
Reload – Page is reloaded from the browser history
Back-forward navigation – Page navigation using back/forward navigation (also known as bfcache navigation) controls
Other – All other navigations

Page attribute

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

Page attributes are extremely useful when looking at pages that have unique performance characteristics, such as:

Page was a soft navigation – When implementing RUM for a SPA, you can use this attribute to compare initial page loads/hard navigations to SPA/soft navigations.
Page visibility was hidden – For pages that are loaded in a hidden state, such as when you open a link in a background tab for viewing later, the performance can vary greatly given the browsers ability to mitigate resource consumption in an effort to preserve the user experience.
Page was prerendered – Prerendering can happen automagically in the browser or by using the Speculation Rules API . When this occurs, pages that are activated appear to load instantaneously and have unique characteristics compared to other types of navigations. For example, in SpeedCurve, prerendered pages will have a value of '0' for most metrics.
Page was restored from back-forward cache – The bfcache essentially stores the full page in memory when navigating away from the page. This browser optimization has the effect of instantaneous page loads when a user is navigating back (or forward) to a previously viewed page.

These filters are super helpful for diagnosing all kinds of pain points. For example, here's how to use these filters to diagnose rendering issues with the bfcache.

Geographic region

We now record users' geographic region, also known as country subdivision. This enables you to dive deeper into how your users are spread around the world. For example, you can filter Core Web Vitals by region, or find regions with the most traffic.

Improved how we collect RUM data

Last summer, while we were adding more diagnostics for Core Web Vitals, we re-implemented our RUM pipeline using Fastly's edge compute. Now performance metrics are captured for longer and beacons are sent at the earliest of 60 seconds after page load starts, or when the visitor leaves the page (if that happens sooner).

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

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

That sounds like a win for everyone!

13 months of RUM

Not only have we improved the quality of our RUM data, we've also increased the quantity. Previously, your Synthetic data was retained for 13 months and your RUM data was retained for 3 months. We've expanded RUM data retention to match Synthetic.

What does this longer retention period let you do? Among other things:

See year-over-year changes in your metrics, including Core Web Vitals
Bookmark and compare RUM sessions over longer time periods
Trend metrics and compare time periods

Unified dashboard filters

SpeedCurve is now eleven years old. One of the things we love about our product is how it's evolved over time. However, in some cases, parts of our UI didn't come along for the ride. This was the case with our dashboard filters. This has been a nagging 'to-do' that we've finally checked off our list, courtesy of our awesome dev team.

You'll find that filters now work the same way across ALL of your dashboards. As an extra bonus, you'll find more options available on most dashboards, including Favorites.

On-demand synthetic testing

By popular demand, we've made some important changes to on-demand testing:

Updated 'Test Now' options – These include site testing and custom URL (adhoc) testing.
View your tests – You can find your test(s) in the Synthetic Tests dashboard, where you'll be routed after starting them (unless tests are grouped as a deployment). Clicking on any of the tests will take you to the Test Details dashboard.
Group on-demand tests as a deploy – When you select 'Group tests as a Deploy', you have the option to add a name and description for the deploy. The deploy will be marked on your charts and the test(s) will be found in the Deployments dashboard, where you'll be routed after they are submitted.

See an in-depth walkthrough: How to test a site on demand

Evergreen browser test profiles

We've introduced "evergreen" browsers to your Synthetic test settings. These browser profiles don't reference specific emulated hardware or a particular browser. They're intended to be a great place to start your web performance testing and provide long-lived profiles with names that don't age. We will periodically update these profiles as web performance trends change.

If you haven't already done this, we encourage you to switch your existing testing to these new browsers. You can also recreate any of the old browser profiles if you need them by creating a custom browser profile and referencing the old emulated devices.

We healed 30+ paper cuts!

We all love big showy features, and this year we've released our share of those. But sometimes it's the small stuff that can make a big difference.

A few months ago, we looked at our backlog of smaller requests from our customers – which we labelled "paper cuts" – and decided to dedicate time to tackle them.

These include:

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

We hope these updates have made your performance and UX monitoring easier!

Expanded our coaching services

Since we ramped up our coaching services, these are the most common goals and concerns we've heard when we talk to people:

Staying compliant with Google's thresholds for Core Web Vitals
Minimizing and fighting regressions
Improving search rank, conversions, and bounce rate

We're super proud of our recent coaching successes, including:

Decreased Largest Contentful Paint on product images from over 3 seconds to under 2 seconds for a major US retailer
Reduced Interaction to Next Paint from over 500ms to under 200ms for a national French news site
Improved Cumulative Layout Shift so 97% of visitors had a good experience for a global hardware and IT services company

How can we help you? Our team includes some of the most experienced people in web performance – Steve Souders, Tammy Everts, me, Andy Davies, and Mark Zeman (from left to right below). We've started global conferences, written books, taught courses, run design agencies, and improved user engagement and conversion rates for all the big brands.

We care about making the web faster, and we want to help you. Contact us at support@speedcurve.com to learn how we can help you meet your performance goals in 2025.

Looking ahead to 2025

We love our industry's current trajectory. Talking to customers, browser vendors, and other monitoring providers, it feels like we're all aligned on some of the same goals:

Get even more nuanced, actionable data from RUM
Think outside the Core Web Vitals box
Make our tools easy for a broader audience to use (We see you, marketing, SEO, and product management folks!)
Continue the quest for iOS support of modern metrics

As always, we love your thoughts and feedback. What do you need in the year ahead? What are your biggest performance challenges? What are you most excited about? Send us a note at support@speedcurve.com!

Performance Hero: Pat Meenan

Mon, 16 Dec 2024 00:00:00 +1300

This month, we celebrate everything that OG performance hero Pat Meenan has done – and continues to do – for the web performance community.

When we started the Performance Hero series earlier this year, we had an idea of the types of folks in our community we wanted to acknowledge:

People who are making a difference in web performance
People who are humble
People who give without expectation
People who don't necessarily crave the spotlight

When looking at these attributes – for a lot of us who have been around this space for more years than we care to mention – it's hard not to think about everyone's favorite web performance OG: Pat Meenan. This month, we celebrate all that Pat has done and continues to do for web performance.

Pat, who is currently a software engineer at Google, is the definition of humble. When we reached out to him about this post, he was quick to point out others who he felt had made a bigger impact in 2024. We look forward to celebrating them as we continue recognizing performance heroes in 2025, but he doesn't get a pass on recognition this time around!

Pat has contributed so much to the web, and to web performance specifically.

Most notably, way back in 2008, Pat built a little open-source tooI called WebPageTest (now owned by Catchpoint) that has served as the biggest arrow in our collective web performance quiver for years. Some people might not know that Pat ran the infrastructure out of his house for more than a decade. When I learned this, I remember being amazed that someone would create something so helpful and so powerful, just to give it away to users for free.

WebPageTest been foundational for many of us in understanding performance. It was the catalyst for SpeedCurve when our founder Mark Zeman built the first version of our synthetic tool way back in 2012, and it served as our backbone during our early years.

However, Pat's contributions didn't stop with WebPageTest. He's a fan favorite on the web performance speaker circuit, a frequent contributor to Chrome (and the web as a whole), and after all of these years he remains one of the biggest cheerleaders for a faster web.

I caught up with Pat over email to fire a few questions at him. His responses didn't disappoint.

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

"I'm working on bringing compression dictionaries to the web. [Watch Pat's 2023 talk at performance.now for background.] I think it will radically change how we serve content and look at MPA versus SPA, bringing a lot of the benefits of SPAs (delivering just the changed content) to document navigations and reducing the performance cost of sending code updates."

Pat is not kidding. You can see the potential benefits of using compression dictionaries on some very popular resources here.

What do you see as the biggest performance challenges we are up against in 2025?

"Losing focus. We got a decent boost from the Core Web Vitals efforts, but performance is a never-ending grind. If you take your eye off the ball, it tends to regress pretty badly. Performance still isn't part of the core DNA for most product teams, and even some of the ones where it was have shifted focus."

(Amen, brother. Getting fast is hard, staying fast is harder.)

What do you see as your biggest performance win?

"Of all time, it was probably indirect by getting people to actually look at web performance waterfalls and videos and understand how browsers and their code interact."

Getting stakeholders engaged in web performance remains one of our biggest challenges. It's been a challenge since I can remember. Pat's gift to the web performance community – WebPageTest – has taught us how to read a waterfall, how to visualize performance through the use of filmstrips, and how to show your boss how much slower or faster you are than your competitors using video.

"More recently and directly, getting fetchpriority adopted. I often refer to it as an 'easy' button for some quick performance gains."

If you are looking to optimize LCP or other important resources, using fetchpriority is one of Pat's cheat codes for web performance.

If you could wave a magic wand, what is the one performance best practice you'd apply that would have the most impact on user experience?

"Eliminating JavaScript from the critical path (rendering and interaction). If you can give a browser everything it needs in the HTML, and if the HTML is served quickly, things will usually default to being fast. When logic needs to run on the client before the browser can take action, it is usually slow."

So true. As Ilya Grigorik pointed out in Building Faster Websites, optimizing the critical path is key to improving the user experience. JavaScript remains the biggest obstacle for loading performance and responsiveness.

Thank you, Pat! The impact you've had and continue to have has meant a great deal to this community. You truly are the textbook definition of a performance hero.

A Holiday Wish: Core Web Vitals in Safari

Tue, 26 Nov 2024 00:00:00 +1300

Did you know that key performance metrics – like Core Web Vitals – aren't supported in Safari? If that's news to you, you're not alone! Here's why that is... and what we and the rest of the web performance community are doing to fix it.

Somebody pinch me. Seeing this post and the resulting thread gives me great hope.

Nicole Sullivan (aka Stubbornella, WebKit Engineering Manager at Apple, and OG web performance evangelist) isn't making promises or dangling a carrot. Nonetheless, it's evidence of the willingness for some public discussion on a topic that's been exhaustively discussed in our community for years. Nicole's post has gotten some great responses from many leaders in our community, hopefully shaping a strong use case for future WebKit support for Core Web Vitals.

(If you're new to performance, Core Web Vitals is a set of three metrics – Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint – that are intended to measure the rendering speed, interactivity, and visual stability of web pages.)

In this post, I'm going to highlight some of the discussion around the topic of Core Web Vitals and Safari, which was a major theme coming out of the recent web performance marathon in Amsterdam that included WebPerf Days, performance.sync(), and the main event, performance.now().

The problem

We've made significant headway with Core Web Vitals, no question about it. Unfortunately, when it comes to measuring real users, the playing field is not equal and we are dealing with an ENORMOUS blind spot. With no WebKit support for Core Web Vitals, we have a serious lack of information for Safari and Mobile Safari.

In the opening keynote for performance.now(), Tammy Everts (AKA the Britney Spears of Nelson, BC, World's Best Performance Mom, and Chief Experience Officer of SpeedCurve) summarized the performance landscape, helping to set the stage for the conference and many hallway discussions.

As Tammy pointed out after sharing a wealth of stats about global internet usage, there are major gaps between who we're building our sites and apps for and how we monitor those sites and apps:

As Alex Russell highlighted in his talk later that same day, performance inequality continues to grow between iPhone users (the haves) and Android users (the have-nots). If you haven't read it yet, make sure to check out his series on the Performance Inequality Gap.

The premise of Alex's talk continued with the theme that we need to do more if we want to save the web, especially on mobile. As a platform, mobile is getting killed by native apps. The inability to measure performance consistently across browsers perpetuates this issue.

Interlude: What we see in our data

iPhones are responsible for the majority of traffic for US-based sites, which means they're the primary source of revenue for many online retailers. This is not the case in other countries, such as India, where usage is completely the opposite.

SpeedCurve RUM data from November 2024 - Top 5 browsers by Country

So, what's the problem? If we are optimizing based on Core Web Vitals, aren't we optimizing for the lower-end experience? Shouldn't that translate to better performance on premium devices?

Not exactly.

But let's be honest. We don't know. And we can't pretend to.

On one hand, it's fair to think that a phone with more processing power is going to be faster. But when you've been building JavaScript-heavy applications for high-end devices, you might expect that there is a great deal of uncertainty.

Chrome and Safari use different rendering engines and different (or non-overlapping) APIs for optimization. And as Katie Sylor-Miller recently pointed out, in-app browsers (such as Facebook and Instagram) are notorious for adding performance overhead to the user experience.

Core Web Vitals aren't the only things missing from WebKit

Tim Kadlec and Annie Sullivan both called this out in their opening and closing keynotes on day two of performance.now().

As Tim pointed out in his talk, we can't expect that these three metrics are the end game of performance. We have to look at them as a starting point.

And as Annie mentioned at the end of the day, we need wider support for Element Timing and Container Timing.

There is hope!

This community is amazing, and together we're capable of making a difference. While it's often tempting in today's climate to throw up your hands and complain, those who really want to make a difference, can. Here are some (very) recent examples.

Interop project

Ryan Townsend recently posted a proposal to get Core Web Vitals into Interop 2025. While this may not make it (yet), it's creating good visibility. Learn more and upvote.

WebPerfDays

The WebPerfDays un-conference is back with a vengeance. It was awesome getting in a room to discuss a broad number of agenda items the day before performance.now(). Our first breakout session was around "GSD in WebKit". We spent the time brainstorming alternative means of getting the features we want (such as Core Web Vitals, Element Timing, Container Timing, etc.) implemented in WebKit.

The first action, to be tackled by the W3C RUM Community Group (discussed below), was to put together a list of position statements for Core Web Vitals, Event Timing, and Element Timing for ALL browser vendors. Just having a decisive list of where everyone stands should go a long way and help us understand where to focus.

Is responsiveness even an issue in WebKit? The group's hypothesis was: yes, it is. This was based on work that has been done to correlate user behavior with a polyfill for First Input Delay (FID), as well as indications that 'rage clicks' appear to be more frequent on iOS (among other indicators).

The second part of the discussion focused more on how we get this done. We explored three main areas:

Funding – Should we pass the hat and convince our bosses to chip in and pay Igalia to implement features? On the positive side, there is real interest in a sponsored initiative to fund WebKit development. While the collection plate was empty at the end of the conference, we have some actions for the group to follow up on.
Coercion – Can we make a strong case to Apple support our efforts? Your ears must have been burning, Nicole. Your name was raised as a potential point of contact who we know cares deeply about performance. :)
Shim it – Can we polyfill for event timing? While not our favorite option due to the complexity, maintenance, and potential overhead, it really can't be overlooked if options 1 and 2 don't work out or if we need an early prototype before being implemented in WebKit.

W3C RUM Community Group

To tackle issues like Core Web Vitals support in Safari, it was announced on stage at performance.now() that a new community group has been formed within the W3C, called the RUM Community Group. I'm so excited and humbled to be co-chairing this group with Nic Jansma (Akamai) and Karlijn Löwik (RUMvision). It says a lot to the positive energy of our community that folks from different RUM providers are coming together in this effort!

We had a terrific response and have hit the ground running. If you are a RUM provider, RUM maintainer, RUM user, browser vendor, or just curious, we'd love to have you! Learn more here.

Performance is everyone's business

Our goal at SpeedCurve is to help you understand how ALL of your users experience your site – not just users on specific devices and browsers. With hope and effort, we'll get there!

2024 Holiday Readiness Checklist (Page Speed Edition!)

Wed, 30 Oct 2024 00:00:00 +1300

Delivering a great user experience throughout the holiday season is a marathon, not a sprint. Here are ten things you can do to make sure your site is fast and available every day, not just Black Friday.

Your design and development teams are working hard to attract users and turn browsers into buyers, with strategies like:

High-resolution images and videos
Geo-targeted campaigns and content
Third-party tags for audience analytics and retargeting

However, all those strategies can take a toll on the speed and user experience of your pages – and each introduces the risk of introducing single points of failure (SPoFs).

Below we've curated ten steps for making your users happy throughout the holidays (and beyond). If you're scrambling to optimize your site before Black Friday, you still have time to implement some or all of these best practices. And if you're already close to being ready for your holiday code freeze, you can use this as a checklist to validate that you've ticked all the boxes on your performance to-do list.

Optimize your monitoring

By now, you're most likely getting ready to head into a holiday code freeze/thaw/chill – which means you may not have a lot of opportunities to make big changes or optimizations. Here are a few things you can tackle right now that don't necessarily require higher-level approval or extra costs.

1. Use both synthetic and RUM

Explore free tools. Hopefully this item is easy to check off. If you don't have a monitoring solution in place for the holidays, there are a lot of free trials out there you can use – including ours! (Not sure if you need synthetic or real user monitoring? You probably need both.)

Work around RUM deployment challenges. Real user monitoring (RUM) can sometimes be harder to implement on short notice compared to synthetic tools. Use a tag manager (e.g., Google Tag Manager) or A/B testing tool if you need to circumvent code changes.

Use CrUX in a pinch. If you're still out of luck in the RUM department, you can always look at field data from Google CrUX (Chrome User Experience Report). Caveat: CrUX data isn't true RUM. It's collected from Chrome sessions only, and only for certain types of Chrome users. It also filters out origins and pages that don't meet specific eligibility requirements. But CrUX data is better than no RUM data.

2. Make sure you’re tracking the right metrics

Think beyond Core Web Vitals. While Core Web Vitals are typically a big focus for retailers because they have a direct impact on search rank, they are not the only indicators of a good user experience. In fact, for a lot of customers, iOS traffic – which Vitals can't track – is the most popular and has higher conversion rates. With so much of your revenue at stake, relying only on Core Web Vitals creates a huge blind spot.

Consider adding custom metrics. If you need to track iOS traffic and other clients, custom metrics let you measure what is most important to your business.

Don't forget about backend time. Time to First Byte (TTFB) can be a page speed killer, especially during peak traffic.

Track your CDN. If you use a content delivery network (CDN), then you need to know that CDN performance is critical during the holiday season. Did you know that you can track the health of your CDN in RUM using server-timing headers? Capture cache hits/misses, time spent at the edge, origin, and even round-trip time (RTT) for most major CDN providers.

3. Manage third-party scripts

The average web page has 35+ third-party scripts. The average blocking time for the 10 most popular third parties is 1.4 seconds. Third parties can hurt important metrics, like Core Web Vitals. More important, slow or blocking third parties can hurt how users experience your site, which in turn can hurt your user engagement and business metrics.

Audit the third-party scripts on your pages. I'm always amazed at how many sites have third-party tags that are no longer needed or in use. Remove unwanted scripts.

Defer or load asynchronously. Avoid single points of failure by deferring non-essential scripts or loading them asynchronously.

Set up tracking and performance budgets. Focus on third parties that are business critical or, more important, critical for the user experience. (More on performance budgets and alerts in section 6, below.)

Know your SLAs with third-party vendors. If possible, ask vendors about their release schedule during the holidays to avoid unpleasant surprises.

Put together a playbook for third-party failures. This is a simple guide that includes a point of contact for each script, kill switches, or procedures to remove scripts using a tag manager.

Dig deeper into these tips and more with this guide to monitoring and optimizing third parties.

4. Make sure you’re tracking the right pages

For both RUM and synthetic monitoring, it's important that you are both measuring and classifying pages correctly. This is especially true as you get closer to holidays, when the performance of a product page can make or break a user's purchase decision.

Segment your pages in RUM. Add RUM page labels that segment your pages in a way that makes sense for your business and prevents confusion where you have too many unique values when trying to dissect performance issues.

Label your pages in synthetic. Make sure your labels make sense, but more important, ensure that the URLs you are monitoring are still valid. For example, last year's product link may no longer be relevant for a PDP page.

Don't forget to test your campaign landing pages... ideally before the promotion begins. Campaign landing pages are often outsourced to agencies that cannot (or do not) test with performance in mind. As a result, campaign pages can be the slowest pages on your site. Ensure you're monitoring current campaign landing pages early, before the promotion starts, in order to identify any performance gotchas during the main event.

5. Establish a connection between metrics and business outcomes

Set a baseline for understanding the impact of performance on your customers (and your business metrics). Using the metrics you’ve already identified, create correlation charts (like the one below) that show you the relationship between your performance metrics and business metrics, such as conversion rate. This will help you understand what your performance budgets should be as you move into peak.

Benchmark your site against your competitors. Setting up a competitive benchmarking dashboard – which is easy to do with synthetic monitoring – is an effective way to see who's delivering a good UX and who isn't.

Check out these industry benchmarks for a current snapshot of how leading sites perform across a number of industries, including retail, travel, media, and more.

6. Set up reporting early

Set up reports. Be proactive in reporting to stakeholders. Consider setting up automated weekly reports for different stakeholder groups. Make sure people have visibility into the metrics they care about.

Set up reporting ahead of time so key stakeholders know what to expect. Reach out to them proactively to make sure they don't have any questions about the data they are receiving and what the metrics mean. (Need help explaining what the difference page speed metrics mean and why they matter? Check out this glossary of common web performance metrics.)

7. Create performance budgets and set up just-right alerting

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

This guide goes into much more detail about how performance budgets work and how to set them up, but here are the key points:

Establish budgets for your key metrics
Create budgets for render-blocking third parties and third parties that are known to have Long Tasks
Set up alerting, but be wary of creating alert fatigue
Again, make sure that alerts go to the right people

Holiday post-mortem

It's common for people to put more effort into preparation. It's also common for the holiday season to take it's toll. We highly encourage taking some well-deserved time to yourself after the holiday crunch is over – but before you do, here are a few things that will help you unload after the holidays, and put you in a great position to hit the ground running in the new year.

8. Look at your historical data

Identify each anomaly and drill down into your data to understand why it happened. Post-mortems shouldn't be about finger pointing. Identifying issues that could have been prevented ensures you are ready next time.

Report issues to third-party vendors. If you experienced issues with any of your third parties, share your data with the provider and work with them to improve.

9. Improve your monitoring and testing

Identify changes in user behavior. Use your RUM data to identify how user behavior may have changed during the holiday period. Make note of heavily trafficked pages that you were not monitoring synthetically. Your users should help dictate what you are monitoring. Were you prepared for changes to traffic patterns? Can what you observed potentially help with scalability testing?

Use the data you're gathered above to refine your synthetic testing. Update URLs, browsers, devices, geolocations, etc. to align with what you've learned about your users via your RUM data.

10. Celebrate wins!

Acknowledge the great work that got you through the holidays. The long hours. The attention to detail. The collaborative cross-functional team spirit that all went into creating a great user experience. We see you!

Send out a fun post-holiday card across your org, using your data to celebrate wins such as:

Uptime – Was your site available 99% of the time or more? That's a win!
Key performance metrics – Did you stay within your regression thresholds for important metrics like backend time, start render, and Core Web Vitals? That's fantastic and definitely worth sharing.
Third parties – Were your third-party scripts performant throughout the holidays? Shout it from the rooftops!
Business metrics – Do your correlation charts show that you delivered a speedy experience to a significant amount of your converted traffic? Huge win!

It's not too late!

If you're like me and this season has crept up on you, fear not! There's still a lot you can do to keep your site fast – and your users happy – through the holidays and beyond.

If you're already a SpeedCurve user and you have questions about any of these strategies, send us a note at support@speedcurve.com and we'll be happy to help!

If you're not using SpeedCurve yet, start your free trial and send us your questions at support@speedcurve.com.

NEW: Vitals dashboard updates and filter improvements

Tue, 15 Oct 2024 00:00:00 +1300

Our development team recently emerged from an offsite with two wonderful improvements to SpeedCurve. The team tackled a project to unify our filtering, and then they over-delivered with a re-Vital-ized dashboard that I'm finding to be one of the most useful views in the product.

Take a look at the recent updates – and a big thank you to our amazing team for putting so much love into SpeedCurve!

Start simple, go deep...

Performance is hard, complex, and riddled with nuance. There is a sea of data collected by SpeedCurve and endless ways to interpret that data.

New users of the product crave good design and simplicity in an effort to make sense of this firehose of performance information.

Power users desire diagnostic capabilities that require extensive use of the latest and greatest browser APIs.

Sometimes it's hard to do both and still provide meaningful information to both audiences. We embrace this challenge and, wherever possible, adopt the principle of starting with a simplistic overview and progressing into meaningful, actionable data.

Vitals dashboard improvements

When we first launched the Vitals dashboard back in December of 2020, we focused on keeping it simple. Core Web Vitals were still a new concept, and educating folks was the primary goal.

In the last four years, a lot has changed:

First Input Delay (FID) was given the boot in favor of Interaction to Next Paint (INP).
Chrome exposed browser APIs providing attribution of element selectors and timing subparts for LCP and INP.
Finally, we heard from many of you who wanted to expand the scope of the dashboard to include other meaningful metrics that were not technically considered Core Web Vitals.

More metrics: Backend Time and First Contentful Paint

We've added Backend Time and First Contentful Paint (FCP) to the Vitals dashboard. We also continue to show Total Blocking Time (TBT).

Those three metrics tell us a lot about potential causes of a poor user experience:

Backend Time isn't always a black box. RUM can tell you where that time is being spent, whether its network related or due to CDN or origin issues.
First Contentful Paint tells us when the page begins to render and effectively become consumable by an end user.
Total Blocking Time gives us clues around CPU-intensive tasks that block rendering and interactivity with the page.

Vitals Dashboard walkthrough

The following assumes you are leveraging both Synthetic and RUM. If you aren't using our RUM, you'll still get a look at your synthetic data. (If you'd like to add RUM to your monitoring, contact us at support@speedcurve.com and we'll set you up with a free trial!)

Focusing on Largest Contentful Paint (LCP), let's walk through an example of how to leverage your Vitals dashboard to find and fix issues with your Vitals.

1. Review the color-coded tabs to see which metric needs attention

Beginning with the overview at the top of the dashboard, you can look at the tab for each metric to see what needs attention. Each tab is color-coded so you can see if it's Good (green), Needs Improvement (orange), or Poor (red). These thresholds are aligned with Google's recommended thresholds.

2. Select a tab to drill down into a metric

Selecting the LCP tab lets us know just where we sit for the population we are investigating. We've also included badges to make it clear which browsers support each metric. (That's right – Safari doesn't support LCP, so you can't track performance for your iPhone users.)

3. View historical performance

Further down the dashboard, a time series chart provides a historical look at the metric, with added context around volume (for RUM customers only). If your LCP is poor in the middle of the night, should you care? Maybe!

4. Get a high-level view of historical performance for Good, Needs Improvement, and Poor cohorts

For added context, the distribution charts show a historical view of the experience of a population – and, of course, a histogram representing the entire population of experiences for LCP.

Clearly there's room to improve LCP. Now what?

5. Identify problem pages

Seeing tabular data for LCP (below) allows us to identity problematic pages that need attention.

In this case, Home seems to be the only page getting a 'poor' rating for LCP. It's also the most popular page by volume, as indicated by the % of page views.

6. Identify the most problematic elements on the page

After re-filtering the dashboard to the home page, the updated heat map (below) shows the most problematic LCP elements on the page. Surprise, there are many!

The LCP element is not necessarily going to be consistent across experiences, even for the same page. As shown, the text element for the cookie consent dialog is the biggest offender, but this might not always be the case (when users are already opted-in, for example).

7. View data for subparts

The subparts data isn't necessarily relevant for the text element identified above, but for other elements, such as images, we can see how each subpart is trending over time to identify any regressions that may have been introduced by a recent change.

8. See visualizations of problem areas on the page

Our synthetic data gives us even more diagnostic detail, including visual identification of the LCP element, framed in red below.

9. Get detailed diagnostics, so you know HOW to fix issues

Finally, the improvements specific to LCP for this page are shown. Maybe there is some low-hanging fruit here. (I'm looking at you, lazy-loaded LCP image!) This list of optimization suggestions – each of which can be expanded to get more information – is a good jumping-off point for making improvements.

Unified filtering

“Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to worry about what will happen.” - Jakob Nielson

SpeedCurve is now eleven years old. One of the things we love so much about our product is how it's evolved over time. However, in some cases, parts of the UI didn't come along for the ride. This was the case with our dashboard filters. This has been a nagging 'to-do' that we've finally checked off our list, courtesy of our awesome dev team.

You'll find that our filters now work the same way across ALL of your dashboards.

As a VERY big bonus, you'll find more options available on most dashboards, including Favorites.

There have been many user requests for filter option updates to specific dashboards. We think we've hit them all, but if we missed anything, let us know!

We hope you enjoy the latest updates. Keep the feedback coming – and go hug a developer today!

Performance Hero: Sia Karamalegos

Tue, 01 Oct 2024 00:00:00 +1300

Sia Karamalegos is a web performance diva we've come to know through her many articles, workshops, conference talks, and her stint as an MC at performance.now() last year – not to mention her role in speeding up a pretty big slice of the internet!

Sia is kind, funny, smart as heck, and always down to talk web performance (especially if you have a Shopify site). For those reasons and many more, we are excited to share that Sia is this month's Performance Hero!

Sia currently works as a freelance web performance engineer. She was previously at Shopify, helping their merchants make their sites faster. She is a Google Developer Expert in web technologies, an active member of the W3C Web Performance Working Group, co-organizer of the Eleventy Meetup and... well, you can read the rest here.

Recent performance win at Shopify

While Sia's impressive bio speaks for itself, her commitment to improving performance cannot be overstated. She shared a recent performance win with us from her time at Shopify, which I'll paraphrase here (and look forward to learning more about in a future post or conference talk).

Sia and her team at Shopify noticed a troubling pattern where a large number of merchant sites were lazy loading LCP elements. She mined the HTTPArchive and discovered that close to 70% of Shopify sites were guilty of using this antipattern.

After finding the issue and failing to convince engineering of its importance, Sia developed a new Liquid feature on her own (Liquid is Shopify's templating language) that made it possible to fine tune lazy loading while not losing the benefit of default lazy loading of images below the fold. The results were pretty staggering!

Green = good!

While the uptake isn't immediate for the fix (due to the need for a Shopify theme developer to implement the new features), it's anticipated that adoption will continue to grow over time. You can read more about this on the Shopify performance blog.

Free new resource: Shopify Theme Vitals!

The timing of this post couldn't be better. Sia very recently launched a new free resource, Shopify Theme Vitals.

Shopify Theme Vitals leverages the HTTPArchive and Chrome User Experience report (CrUX) to provide Shopify devs and merchants with an aggregated data set of Core Web Vitals (CWV) performance by theme.

Where you can find Sia...

You can follow and learn more about – and hire! – Sia here:

We are thrilled to add Sia to our growing list of performance heroes! Past heroes include: Michelle Vu, Estela Franco, and Paul Calvano.

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

How to provide better attribution for your RUM metrics

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

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

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

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

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

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

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

How the browser handles attribution

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

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

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

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

Consider the following three links:

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

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

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

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

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

For example, consider the following markup:

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

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

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

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

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

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

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

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

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

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

Making attribution meaningful

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

With SpeedCurve, there are two ways of accomplishing this:

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

Using a relevant `id` attribute

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

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

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

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

Using the `data-sctrack` attribute

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

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

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

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

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

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

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

NEW: Paper cuts update!

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

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

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

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

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

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

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

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

Keep scrolling for an overview of some of the highlights.

On-demand testing updates

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

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

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

UI updates

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

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

Regional performance

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

A whole lot more...

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

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

NEW: Improving how we collect RUM data

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

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

This post covers:

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

What's changing?

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

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

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

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

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

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

How your Core Web Vitals may change

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

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

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

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

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

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

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

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

Largest Contentful Paint (LCP)

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

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

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

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

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

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

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

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

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

Cumulative Layout Shift (CLS)

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

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

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

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

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

Interaction to Next Paint (INP)

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

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

Why we changed our approach

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

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

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

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

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

That sounds like a win for everyone.

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

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

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

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

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

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

Slow pages hurt your business

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

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

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

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

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

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

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

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

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

US Retail Benchmarks leaderboard

Background: Looking at 20 leading sites

For this investigation:

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

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

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

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

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

Serve static assets with an efficient cache policy

Metric(s) affected: Rendering metrics for repeat views

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

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

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

Reduce unused JavaScript

Metric(s) affected: Largest Contentful Paint

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

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

Page prevented back-forward cache restoration

Metric(s) affected: Rendering metrics for repeat views

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

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

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

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

Metric(s) affected: Cumulative Layout Shift

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

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

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

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

Minimize main-thread work

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

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

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

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

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

Reduce JavaScript execution time

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

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

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

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

Avoid enormous network payloads (AKA page size)

Metric(s) affected: Largest Contentful Paint

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

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

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

Serve images in next-gen formats

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

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

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

Ensure text remains visible during webfont load

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

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

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

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

Reduce the impact of third-party code

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

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

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

Reduce unused CSS

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

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

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

Avoid 'document.write()'

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

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

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

Eliminate render-blocking resources

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

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

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

Use HTTP/2

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

Fix: Learn how to set up HTTP/2.

Do NOT lazy load the LCP image

Metric(s) affected: Largest Contentful Paint

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

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

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

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

Why are so many recommendations neglected?

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

Some optimizations may not affect the critical rendering path

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

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

Some optimizations may be harder (or impossible) to implement

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

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

People just don't know

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

But still...

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

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

How to prioritize page speed optimizations

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

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

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

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

3. Grab the easy fixes first

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

Some easy(ish) recommendations:

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

Start somewhere and keep moving

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