SpeedCurve Blog

Performance Hero: Sergey Chernyshev

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

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

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

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

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

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

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

How did you get your start in web performance?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

^{Photo by Freepik}

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

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

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

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

Consider this scenario...

^{Photo by andreas on Freepik}

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

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

Is this fair? Not really.

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

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

1. End-user connection speed

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

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

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

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

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

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

2. Older hardware

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

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

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

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

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

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

3. Older desktop and mobile devices

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

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

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

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

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

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

4. Browser version

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

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

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

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

5. Browser use (and abuse)

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

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

^{Performance expert Tim Kadlec on Bluesky}

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

6. Other applications

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

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

Takeaways

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

1. Optimize your pages

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

2. Use a reliable content delivery network

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

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

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

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

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

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

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

Summary

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

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

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

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

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

In this post, we'll cover:

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

anymouse123456 via Hacker News

What do we mean when we talk about page size?

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

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

How does page bloat hurt Core Web Vitals?

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

Page bloat can have a huge impact on your Vitals:

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

How does page bloat hurt your business?

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

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

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

How does page bloat hurt your visitors?

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

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

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

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

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

HTTP Archive research: Background and caveats

Before we get into the analysis, some context:

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

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

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

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

Desktop: Median JavaScript weight increased by 10%

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

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

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

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

Desktop: Median image weight increased by 5%

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

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

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

Desktop: Median video weight increased by 17%

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

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

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

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

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

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

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

90th percentile sees a 24% increase

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

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

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

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

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

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

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

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

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

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

Can large pages ever deliver a good user experience?

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

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

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

How much content should you serve?

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

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

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

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

Takeaways

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

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

1. Understand the critical rendering path for each page

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

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

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

3. Use performance budgets to fight regression

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

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

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

5. Don't forget to monitor longtail performance

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

Questions or feedback?

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

Performance Hero: Annie Sullivan

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

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

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

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

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

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

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

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

How did you get your start in web performance?

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

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

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

What is the charter of the Chrome Speed Metrics team?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Our 10 most popular web performance articles of 2024

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

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

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

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

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

Cookie consent popups and banners are everywhere, and they're silently hurting the speed of your pages. Learn the most common problems – and their workarounds – with measuring performance with content manager platforms in place.

9. Best practices for optimizing images

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

8. Understanding and improving INP

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

7. Understanding and improving LCP

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

6. Best practices for optimizing JS

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

5. A complete guide to performance budgets

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

4. Get started with Core Web Vitals

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

3. The psychology of site speed

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

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

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

1. Averages, medians, and percentiles

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

Looking ahead...

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

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!

SpeedCurve Blog

Performance Hero: Sergey Chernyshev

How did you get your start in web performance?

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

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

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

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

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

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

Consider this scenario...

1. End-user connection speed

2. Older hardware

3. Older desktop and mobile devices

4. Browser version

5. Browser use (and abuse)

6. Other applications

Takeaways

1. Optimize your pages

2. Use a reliable content delivery network

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

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

Summary

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

What do we mean when we talk about page size?

How does page bloat hurt Core Web Vitals?

How does page bloat hurt your business?

How does page bloat hurt your visitors?

HTTP Archive research: Background and caveats

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

Desktop: Median JavaScript weight increased by 10%

Desktop: Median image weight increased by 5%

Desktop: Median video weight increased by 17%

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

90th percentile sees a 24% increase

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

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

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

Can large pages ever deliver a good user experience?

How much content *should* you serve?

Takeaways

1. Understand the critical rendering path for each page

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

3. Use performance budgets to fight regression

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

5. Don't forget to monitor longtail performance

Questions or feedback?

Performance Hero: Annie Sullivan

How did you get your start in web performance?

What is the charter of the Chrome Speed Metrics team?

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

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

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

Our 10 most popular web performance articles of 2024

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

9. Best practices for optimizing images

8. Understanding and improving INP

7. Understanding and improving LCP

6. Best practices for optimizing JS

5. A complete guide to performance budgets

4. Get started with Core Web Vitals

3. The psychology of site speed

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

1. Averages, medians, and percentiles

Looking ahead...

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

INP replaced FID

RUM attribution and subparts for INP and LCP

Re-vital-ized Vitals dashboard

New RUM filters

Delivery type

Navigation type

Page attribute

Geographic region

Improved how we collect RUM data

13 months of RUM

Unified dashboard filters

On-demand synthetic testing

Evergreen browser test profiles

We healed 30+ paper cuts!

Expanded our coaching services

How much content should you serve?