SpeedCurve Blog

Performance Hero: Harry Roberts

Mon, 30 Jun 2025 00:00:00 +1200

This month's performance hero is someone who's helped some of the biggest brands in the world speed up their sites – and who generously shares his wealth of experience with the performance community through articles, videos, and conference talks. Thank you for everything you do, Harry Roberts!

What we love about Harry is that he's both an idealist who believes in delivering great user experiences, and a pragmatist who knows how to measure the impact of site speed on businesses.

Harry and I recently had what we jokingly called a fireside chat. As a SpeedCurve power user with his clients, Harry had a lot of great feedback and insights into how he uses our tools. But our conversation was actually much broader, so I thought a lot of folks might be interested to hear Harry's thoughts about performance in general. I also thought it would be great to give him long-overdue kudos as this month's Performance Hero!

Keep scrolling to watch the video of our chat and hear why Harry had the following things to say:

Your e-commerce site should not be built with JavaScript. It should not be a SPA.
Sites that have gone all in on JavaScript are slower and more difficult and more expensive to make fast.
Nearly every website on the planet that is a SPA shouldn't be.
No one really wants the fastest website. They want the most effective website.
The number of product images on a page has a direct relationship to conversion rate. There's a sweet spot between too few and too many. You'll have to watch the video to learn what that sweet spot is. ;)
A/B testing is an essential tool in your performance toolkit.
Using RUM is probably the biggest predictor of the success of a site.
Headless commerce and headless content are great for the developer experience and terrible for the user experience.
Don't optimize Core Web Vitals for SEO. Optimize for user experience.
Too many people don't realize that Core Web Vitals and CrUX are completely different things.
Core Web Vitals are only one part of the much bigger performance picture.

Transcript

CLIFF CROCKER:

Hey everybody, this is Cliff from SpeedCurve. I'm really excited today to be chatting with a good friend that we know here at SpeedCurve and love: Harry Roberts.

Harry's an independent web performance consultant with over 17 years of experience, although I kind of find that hard to believe. The guy's young and attractive and... 17 years... come on. Lots of experience working with huge brands. Google, BBC, GE, the UN I think I saw on your site. Is that correct?

HARRY ROBERTS:

Correct, yes. Yeah.

CLIFF:

Awesome. Well-known speaker, internationally recognized leader in front-end performance and much, much more. He's also the co-chair of the best performance conference in the world, performance.now, which is held each fall in Amsterdam, which happens to be the last time that we saw each other. So it's been a while and it's good to see you again. How you doing?

HARRY:

Been a while. That was a phenomenal intro. I'm going to slice that out and I'll just give that out to conferences. That was wild. Thank you very much. The 17 years of experience is true. That's only because I was such a nerd that I registered my domain name when I was 17 years old, which was 17 years ago and I got my first job at that time. So as a consultant, I think I've got 11 years experience overall in tech... wait now, you're right, 17 years. Wow. But yeah, it's great to do.

It's been a few months, I guess it was sort of a fall-wintery sort of Amsterdam. We went for dinner together and I think that's when we had the first idea for this hangout, wasn't it?

CLIFF:

Yeah, absolutely. I mean what we wanted to do is... we thought it'd be great really for everybody, but also for people that are doing consulting or people that are focused on making performance better for clients, agencies, that sort of thing. But also just everybody to hear a little bit more about you and hear about our relationship because it's a pretty unique one.

So obviously we love you and I love when you're up on stage and you're presenting things and I always feel so flattered when you're throwing up a SpeedCurve chart or something like that to illustrate something, but you don't work for SpeedCurve and that's pretty clear, right? You're a friend and you use our tools, but I like to think that's by choice.

HARRY:

It's very much by choice, and in advance of this hangout now and in preparation for this, I was trying to remember how SpeedCurve got on my radar and I simply cannot remember. I dunno if it's worth pointing out for anyone who is watching. We don't have a commercial relationship. I'm not sponsored by you. I just have used SpeedCurve for so long that I think we have just become friends... normally it's me pestering for feature requests or asking for advice.

So I don't actually know where my journey with SpeedCurve started. I can go back into talks and I can go into slide decks many, many years and SpeedCurve dashboards show up, but I can't remember my first ever... that light bulb moment with the tool. It just seems fairly omnipresent now. It's just such a big part of my my day-to-day working life that I don't really remember the first time I used to speak of, which is crazy to me because it still feels shiny and new and fun.

CLIFF:

Yeah, well absolutely. I think while I'm not necessarily shiny new and fun, it does feel like I'm working on a product that is, and it's been certainly a fun ride here. So can you maybe tell us a little bit about how you're using SpeedCurve with your clients or in these engagements that you're doing?

HARRY:

Happily. So I think... context for anyone who doesn't either work in web performance or is new to it... normally what happens is I get an email from a client, a potential client, and they say our website is slow and we'd like to make it faster. And one of the first questions is how do you know it's slow? Is it just general sentiment? Can you just tell? Sometimes you can just tell you've got a slow website, right? There may be customer complaints and that's the serious one. If your customers are complaining that a site is slow, but if you want to make a website faster, you need to objectively know how, where and why is slow in the first place and certainly without a tool like SpeedCurve, or nowadays CrUX, is probably the lowest fidelity way to get there and without the data supporting, the argument of "the site is slow", you can't really make the case for "the site is now faster".

So where it fits... SpeedCurve bookends my projects where I can, if my client doesn't have SpeedCurve or similar install already, the first way that I would use SpeedCurve is when a client gets in touch, let's say the lead time to start that project is going to be two months, six weeks, whatever. I will try and encourage that client right now, "Go and install SpeedCurve, leave it running until I can join the project or the project starts," and then we've got at least a month of rich real data that spans various demographics, geographic locales, device types. I've got really rich data that helps me understand if the site is slow in the first place, where it's slow, why it's slow. That is a huge, huge part of my early work on a project.

If a client is feeling ambitious enough, especially if they've got a conversion-driven website, maybe they're a charity and they're looking for donations or an e-comm site, so they're just literally selling things or I've worked with streaming services and they just want people more engaged – do people watch more minutes of video if the site is faster. If my client is ambitious enough and that is relevant to them, when we install that initial SpeedCurve snippet, when we initially get SpeedCurve set up on the site, what I'll do is I'll then capture conversion rate data.

So not only can we work out is the site slow, then we can work out things like "every further 100 milliseconds of slowdown costs you X percent of revenue" that can then be used. I call that kind of "sprint zero" because that can then be used to actually price the project. So we could say, well, if your site was 250 milliseconds faster, you're going to make an extra $108,000 a year. Therefore the cost of the project probably shouldn't be more than 108K. It should be a percentage of that. And that can really help the business analysis, the business case of web performance. For me, that is the most useful way selfishly for me to use SpeedCurve is to be armed with the early data and it goes much, much deeper. But I don't want to give too long an answer, but that's the first way that I use SpeedCurve is just the richer the data that I have, the more effective the project can be.

Before using SpeedCurve, or without SpeedCurve, you would to an extent be shooting in the dark. You'd draw some synthetic tests, you'd use WebPageTest to say, well, in this laboratory environment, your site is only this fast or slow, but that doesn't really reflect what a real user might experience going into a project with real user data. It is the biggest game changer and it's probably the biggest predictor of a successful project. This has become a very long answer to a short question. Done, part two.

CLIFF:

It's very pertinent. I think it's absolutely something that we see and I've seen from my own personal experience way back in the day, so dating myself as well, when I was at Walmart Labs and I was running the performance team there, I had to really fight for performance. I really had to kind of make a case for it because it's not like developers were sitting around on their hands or twiddling their thumbs doing nothing. They've always got priorities, they've always got things they're focused on. These are things that are usually getting pushed top down less so maybe they're working on tactical debt, things like that.

But I think what you're talking about, what you're illustrating is what I found I had to do, which was tie performance back to business value, being able to say, "Hey, I know that we prioritized X, Y, Z and maybe an improved cart flow or optimized cart and checkout or whatever it might be. However, I can actually show you and demonstrate that improving our front end time at the time was what we were focused on at the 95th percentile by X seconds is potentially going to point the real gains in revenue." So I think that's pretty fantastic.

HARRY:

Yeah, it's huge. And as well, what I find really interesting is you're absolutely right, developers aren't just, they're not building slow websites for a thought. They're not doing things wrong, but there's always something that needs doing that is usually seen as more important. Performance is invisible. No one cares about security until after they've been hacked. So it's really hard to make a case of something that isn't a shiny new feature. I think intuitively, any CEO, any CTO, any head of e-commerce, anyone intuitively knows that faster is better. All things being equal, would you have the exact same site, fast version, or the exact same site, slow version? Everyone's going to pick the faster version, but to what end? Right. So I think that's one of the biggest things, and it's one of the things my clients, that sounds rude. Well, I'll take that back. It's one of the things that I really try and encourage my clients to do that they haven't necessarily thought about is, "what is this even worth to you?"

You could spend more hiring me than this is actually worth for you. And I don't want that for anyone because it's not good business sense, is it? Well, I mean for me, I suppose it is, but I don't want to be the guy who sells solutions to problems that don't exist. And using a tool like SpeedCurve where you can capture that custom data, whether it's a conversion or size of cart or average order value and being able to tie it back to specific customer events is really powerful. And the other thing as well is you can correlate interesting things. So yeah, we can say improved LCP increases the likelihood of purchase by 8%, but because of the amount of rich data that SpeedCurve gives me, and this is a true story, when you've got a product details page and you've got your main product image here, and then you've got all your thumbnails beneath it because SpeedCurve captures things like images above the fold, you can correlate the sweet spot.

And we found out, I think we didn't ever do any real customer research into this, but the more thumbnails, the more product thumbnails, the less likely someone was to purchase. And I just wonder if that's a case of just a bit of overload, a bit of too much information. And we found that the sweet spot is if you just have more images in your gallery carousel thing, your four thumbnails, statistically causation correlation, you can argue many different looks or takes on the data, but it's the silly things like that where, okay, yeah, you've hired me to look at site speed, but just out of interest, is there any correlation between the numbers, images above the fold and likelihood of conversion? And for one client, we found that yeah, that sweet spot was four. They would tend to sell more products if they only had four product images as opposed to seven or 11 and stuff like that. I just find fascinating.

CLIFF:

Yeah, totally. I've heard that. One of our customers also shared with me search results very much the same way. Okay, so we've got search results. You would think, okay, let's just throw as many results as we can on this page, and of course that's not going to do great things for performance. Even if you're lazy loading stuff below the fold,

Bigger, more complex DOM, whatever, it's not necessarily the best idea, but sort of in their mind it's more options, more chances that people are going to go and click and go that product details page. But they found when they actually cut it in half from 50 to 25, performance got better and engagement got a lot higher. However, then they cut it down even more like, Hey, okay, let's go the other direction. Performance really matters here. We need to actually look at minimizing this even more. And they cut it down to something like 10 or under 10 search results, which was kind of silly and they saw engagement drop off even though performance is better, it wasn't always context. So finding that sweet spot I do think is important.

This actually made me think about something about how you go about these engagements and one of the things that we love to do is look at experimentation or A/B testing performance changes. Do you find that your clients are typically up for that? Is it something where they're mature enough to actually say, "Okay, yeah, we're actually going to make this change and send it to X percentage our traffic and see what impact that has on conversion?"

HARRY:

I've got a couple of real good success stories with that. It's not as common as I would like it to be. I feel like experimentation, A/B testing, is always the smartest way to making LCP faster is always going to be the best idea, but making it faster is always better and there will be a point of diminishing returns. So certain things don't need A/B testing, right? Inlining your CSS, we don't need an A/B test for that. It'll just be faster. That is just better. But for certain things where there is a bit more of a trade off where, well, I'll just dive straight in with the example. I worked for the large US manufacturing firm, I guess you might call them, and they were using a particularly slow font provider and I've got a bit of, I'm a typography nerd and I like Type I nicely set sort of type and designs, but that's a point if it comes at a cost.

And this particular font provider was quite slow, so I just asked – and oh, they were licensing a custom font. It wasn't just Google Fonts, it wasn't free. They were licensing a font for just over a hundred thousand dollars a year and it was just really tanking base feed off site speed. So I just asked them, look, can we just run an A/B test and for just 1% of your users, and it was really easy to set this A/B test up directly in SpeedCurve because all we had to do was there isn't quite a traditional stack, which is music to my ears because it's easy to make old stacks fastest. They had a PHP sort of e-comm site and we just literally wrote a bit of PHP that said, but 1% of requests to this site don't give the custom font and set a cookie saying they haven't been given the custom font and then tell SpeedCurve, we've done that.

Bounce rate went from 88% down to 61%, I think roughly those are the numbers. So an over 25 percentage point improvement in bounce rate just from removing a custom font. Now what that meant was we proved a business case for saving them over a hundred thousand dollars a year because, obviously, get rid of the font, get the designer – worked with a really great designer who actually went on to build a really, really nice website about modern font stacks like removing custom fonts that's formed off its own side project, but it's like win on top of win. We could prove that bounce rate was measurably better to about 25 percentage point increase of improvement. And we saved them licensing costs of over a hundred thousand dollars a year. And that one A/B test provided that data.

Another one, I've got a client where they've just got this mega Google Tag Manager instance and the one Google Tag Manager contains four different containers and it's this just beast, this Frankenstein monster of a tag manager that's been touched by a hundred people over the last 10 years. And I'm convinced that's the biggest problem about INP issues, but I can't prove it until we whip it out. But the data that is coming out of there is so critical to the business that we can't just remove it. A very, very brave soul, and I'm very grateful to them, allowed us to run an A/B test whereby 5% of users to one particular part of the site, it's a very highly trafficked site, just weren't given a tag manager at all. Now I'm not comfortable sharing the results of that just yet. It's still actually technically an inflight project, but again, we can tell SpeedCurve this session didn't have Tag Manager.

We can go to the local storage as well, which is nice. We don't actually need to use cookies. So it's all GDPR compliant. We can use local storage to record that. So we don't need to worry about consent and compliance and we can just run an A/B test and we can tell SpeedCurve "I want to plot all of the non-tag manager sessions against the with tag manager and just sort of quantify the impact." And then we can correlate that with... is the data we're getting more valuable than the engagement we're losing. Because okay, I'm a performance engineer. No one cares about performance more than me. But if the business could say, right, we can see that tag manager is harming INP, but the data we're getting from tag manager is worth more than what the bad INP is losing us, then just have bad INP, right?

CLIFF:

Yeah.

HARRY:

No one really wants the fastest website. If someone wanted the fastest website, they'd let me delete all of their CSS, delete all of their JavaScript, use Times New Roman. It's a balancing act and ultimately what we want is the most effective website. And even if that means slower but more profitable, then we just stick with slower. Ideally, we'd have both, but realistically my clients just want more effective websites.

CLIFF:

I think it comes down to revenue. I mean it does mean most of the sites that we're working with, they are there for a purpose. They're there for whether it's generating revenue or in case of nonprofits just generating that user engagement. There's always, that's the ultimate measure, right?

HARRY:

Yeah, of course.

CLIFF:

The ultimate outcome is not better performance. It's whatever that is that you're striving towards.

HARRY:

Yeah, exactly.

CLIFF:

So you mentioned a lot of examples there, which I really appreciate. Are there any common themes or issues that you're finding across your clients? Are they all, "Hey, I always go in and I do this because I know it's some low hanging fruit and I'm going to get a great win for this?" Or are they all unique? Is it more taste specific? And obviously without giving away too many of the goods, obviously you are for hire, we're not trying to get free consulting here, but what are some of those patterns you're seeing?

HARRY:

So I'll be completely honest with you, there are only two big patterns that I tend to see.

Sites that have gone all in on JavaScript are slower and more difficult and more expensive to make fast. That's the first pattern I will see.

Any site that is an SPA is going to have two problems. One, it's going to be hard to capture decent metrics because SPAs sidestep the web platform, it's not SpeedCurve's fault. That data can't be captured. It's not Core Web Vitals or CrUX's fault. That data can't be captured if you're going to sidestep the web platform. You don't get web platform features that makes analysis incredibly difficult, even the best tooling in the world at present and bridge that gap... that if you using an SPA, you're going to struggle to make that site faster. It's harder to know where it's slow.

Common patterns that evolve are the more JavaScript you have, the slower that site is going to be. And the worst thing is that sites tend towards more JavaScript over time, not less. You release a site on Next.js, now it's already got too much JavaScript. In six months time, you can guarantee it won't have less. It's always going up. So those kind of sites always tend towards worse performance, which means that guardrails, tracking bundle sizes, regression tests, deploy tests, they're vital. That's one common pattern. As soon as I see an inquiry from a client and they've got a single page application, and also don't even get me started on single page applications, if you've got a homepage, a search results page, a product page, a product listing page, that's not a single page application, I've just named four pages. Nearly every website on the planet that is an SPA shouldn't be. Photoshop in the browser, that's a single page app.

Your e-commerce site should not be built with JavaScript. It should not be a single page app. That's me ranting now. So that's the most common pattern is if you've got a single page app, if you're using a lot of JavaScript, it's going to be a lot harder to find the problems and remedy them. Not impossible, just more expensive. And usually the tragedy there is that's a problem of team of course for themselves. The flip side is, again, I'm reluctant to name any names even though this is like a victory. I worked with a firm here in the UK, they're a worldwide brand, but they're a very British firm and their site was built on Laravel, but it was a lamps stack, which I mean, and everything's having a bit of a spring or a bit of a resurgence at the moment, which I'm very happy to see.

But we got this project to 99.8% passing Core Web Vitals over 335 million page views. So getting to 99.8%, passing over 335 million page views, that was trivial. That was easy when building on a traditional boring stack, I wouldn't fancy my chances doing that with a React application, Nuxt view, whatever. So that's the only real pattern I ever tend to see.

Another emerging pattern I'm seeing people are really digging the ergonomics and the developer experience of headless commerce and headless content. And again, not going to name any names, but there are certain providers who all they do is headless content. You've got your digital asset management, you've got all of your CMSes in one provider, all of your SKUs for your web shopper in another provider. And these are clients where they've built single page apps on top of this headless architecture and they're suffering horrendously with time to first byte issues because that one request that would traditionally go into a Magento store and it would just say, right here's Magento, let's go and look in your database. Here are the products, here's how many they've got in stock. Here's the price, send that back one HTTP request one sort of there and back life cycle.

Now what happens is a request comes in for a server rendered page or SSR, and all of a sudden you've got an API endpoint that lives in a totally different place and it might even live on a different continent, depending on who your provider is. So that one request that comes in for a page that traditionally would've just been one request, one response, it now fans out to, right, we need to go over here to get the CMS content for this product. We need to go to this provider to get the SKU information, the stock price information, all of that kind of stuff. So now I see these really trendy modern stacks that are like, yeah, it's convenient. Yeah, it's nice. It kind of feels a bit edgy to be using all these new tools to build what is really a solved problem. I'm just seeing Time to First Byte skyrocket and I've got two clients with very, very similar stacks, very similar objectives, suffering the exact same fate. So those are the two most emergent patterns I'm seeing in the last couple of years, maybe a bit longer.

CLIFF:

It's kind of crazy. I'm seeing it a lot too, literally it was just looking at it before this call with a customer where their time to first byte just jumped up horrendously and it wasn't necessarily due to super side rendering. It wasn't due to any real architectural changes that they made and we're still trying to get to the bottom of it. They're going to start capturing server timing so they can get a little bit more detail into like, "Hey, is this the CDN? Are we seeing requests that are going back to origin?" But then there's also this emergence of looking more at some of those subparts, I would call them I guess without a better term for what's in time first byte, the redirect time, server time, connection time, the TLS handshake, all that stuff. So it still feels like... it's funny, we always talked about 90% of the time spent on the front end, and I think that that's absolutely true. I wouldn't go back against that, but we can't ignore this other part that is so critical to start render and FCP, LCP, all those things that are more sort of a user experience metric.

HARRY:

Right. So this is actually, I had exactly what you just said, had a major breakthrough on a client project with SpeedCurve, and this is going to seem like a setup, but if you want, I can show you it now. If we just just take a pause now while I go and get a dashboard up and we'll get back and I'll show you the bit you mentioned about subpart on Time to First Byte... SpeedCurve got me to the bottom of a really complex problem recently. Well let me just go and grab some dashboards and I'll show you what I mean because the kind of information that is vital.

CLIFF:

Okay, so I swear I'm not throwing Harry a softball here, but I think he's got a good use case to sort of illustrate some of the getting behind Time to First Byte a little bit from a client.

HARRY:

Yeah, yeah. So exactly as you were just saying, the subpart of Time to First Byte and the historical not belief because it is true most slowdowns happen on the front end, but if you've got bad Time to First Byte, you're really going to struggle to hit your front end targets. So I think as most people watching probably are already aware, Google make this incredible amount of data freely available to have this for free is truly remarkable. It's not without its downsides. This is data specific only to Chrome and that's Chrome not on iOS. But having this for free I think is a remarkable see change for the industry. But what you'll see this client around this Time to First Byte last year suffered Time to First Byte regressions, but this is very opaque. What's going on there? Is it increased server load? Is it API calls? Is it database reads?

What is going on here? This data, and remember it is free so we can't criticize it, but this data is very opaque. So I told this client, Hey look, we can get to the bottom of this and many other things. This client is actually a huge, huge SpeedCurve fan now. They adore SpeedCurve. We installed SpeedCurve and I got some great insights because what we can see, and this covers the last I think one month of data is we break down the subpart or SpeedCurve allows us to break down the subparts that everyone else has called Time to First Byte, right? What you'll see is that DNS, your initial connection and your TLS are basically effectively zero now. They're so quick, they don't even really register other network. Again, zero server response 800 milliseconds. But the real concern for me is this 600 millisecond redirect.

So I was like, immediately, not problem solved as such, but this is like an immediate right. Well there's your problem. Redirect, this site is suffering with redirect. One thing I really adore about SpeedCurve, and you do need to be a little bit of a graph nerd or know a little bit about interrogating data because I think SpeedCurve is the performance engineer's tool. I think it's very, very well suited to the power user. It's a bit like a Swiss Army knife. It's got loads of different tools on it. You just need to know when to use which one. I was fascinated by this data. Obviously it seems that about 600 milliseconds of our delay are attributable to redirects. That seems quite extreme, and I didn't really notice many redirects as I used the application. So one thing, and this is the simplest way to look at it, is just the number of incidents of these things.

So if we look at server response on the 4th of March at 1:00 PM we've got 32,000, nearly 33,000 page views that logged a server response metric or a timing for server response the same day or the same snapshot, we logged just 561 redirects. So what we can see here is that redirects are actually, though very long and very slow and very problematic, they are in the vast minority of use cases. So looking at this data, I can go deeper rather than just saying we've got a problem with redirect. What I can say is "We appear to have a very, very localized problem with redirects and wherever these are happening, it's in the minority, but they are very extreme."

So this is just the time series graph and I guess most people using SpeedCurve, this will be the most common type of graph they would interface with. But I'm really fond of being able to plot histograms. So what I did is I just created a quick chart to where I plot the number of incidences of backend times overall time verse bite, the number of redirects and the number of server responses, again over the same one month period. And what we'll see is that if we're actually try and look at redirects, I dunno if you can even see that, if you look around this sort of 0.2 and 0.4 on the X axis, the number of redirects we actually incur on this site is minuscule. And what this allowed me to do is pinpoint the fact that yes, redirects do take a lot longer than I would like, but they're not really the problem affecting this site at scale. Most of the time we're not incurring redirects. When we do, they're very, very expensive, right? 600 milliseconds. But it allowed me to not go down the wrong path. It allowed me to not waste time assuming that redirects were happening everywhere.

And being able to just manipulate raw data like this in many different chart types is... to me it's phenomenal because yes, you have to know what you're doing, but even if you've got a slight intuition for graphs or looking at data, you can save so much time. So if you look at the process... this, we've got backend time, it's very opaque, don't really know why. And we look at this, you might draw the conclusion, "Oh, backend time is slow because we've got redirects." Then we look at this, we say "We have slow redirects, but that's not why we have slow backend times." And it turns out for this particular client, this particular project, this particular site, the time really is just majority spent on server responses, expensive API calls, and things like that rather than this almost misleading red herring of redirect.

This for me is a bit of a rollercoaster journey and I actually, I dunno if she ever told you, but I actually, when Tammy [Everts] and I were organizing one of the PerfNow events, we were on a call about the conference. I asked her to stay on the call for a bit afterwards just so I could tell her about this. I just felt so proud of myself by digging through this data and getting to the bottom of it. You can't do that with tools that don't let you manipulate your own data. But for me that was a really fun, fun. Don't ever invite me to a dinner party. My idea of fun.

I thought this was a really case I have and I'll use, I thought this was a really cool use case for the tool. Just really enlightening. So the subparts thing you're talking about just that stepping through each of these three tabs and just seeing the progression of just digging deeper, I just found that really, really valuable. And yeah, it's just funny you should mention sub parts of Time to First Byte because that was one of the biggest breakthroughs I had. The most fun breakthroughs I had recently with SpeedCurve.

CLIFF:

Nice.

HARRY:

I'm going to stop sharing now.

CLIFF:

Yeah. Awesome. Thanks for sharing that. I think it's always fun to see people using the tool and seeing how they're using it in a lot of similarities I think that we run into. So yeah, I think that that's going to be helpful for a lot of people. We haven't really gone here yet, but you've mentioned a couple metrics that I can use to jump to this topic, which is Core Web Vitals on top of having a great data set in CrUX. I do think Core Web Vitals have been a pretty great move for our industry, certainly in terms of visibility and getting more of a conversation going around performance. But do you find that your customers, the people that you're working with, do you feel like they're focusing too much on Core Web Vitals? Do you feel like they're maybe focusing enough? Where's that line and what are your thoughts on that?

HARRY:

Not conflicting views... different. It's a difficult one. I'm with you. I think Core Web Vitals are great as a metric, but I think there are two sides to Core Web Vitals. I think the move to standardize performance metrics is really valuable. And I genuinely LCP, INP, CLS. I think are great metrics and I like how well researched they are, how well defended they are. I'm a fan of Core Web Vitals as a metric, but we have to remember is there's a different side to Core Web Vitals and that different side to Core Web Vitals is you've got to pass these to get up high on Google and that's like the cult of Core Web Vitals. And the biggest problem there is that, well, not the biggest, there are multiple problems. One is are you prioritizing performance for the wrong reasons? Given that it's now an incentive, there's a slew of people gaming the system. I don't care if they're doing that. It doesn't really affect me. I don't work with those kind of people so it doesn't really affect me. But the ethicist or the person who cares inside of me, there is one somewhere that cares, I just think it's doing it for the wrong reasons.

But then the other problem of course is that even if you cared for the right reasons and you think Core Web Vitals are great and we know that better LCP leads to better user experience, better customer satisfaction... it's Chrome-only for now. That's not Chrome's fault. I mean we've got the Interop thing – shout out to Ryan Townsend, a good friend of ours who actually put forward Vitals for Interop 2025. He did a very simple but very important thing he did to get it on the radar and Safari are now considering implementing it.

But if you're going to go all in on Core Web Vitals, and again, it's not your fault as a site owner or as a business, but if you are over-indexing on Core Web Vitals, you're leaving a lot of opportunity on the table for your entire iOS audience. For a start, I've worked with clients in the past who one very high-end fashion retailer, they were over 80% iOS traffic. Optimizing Core Web Vitals for them was not a wasted endeavor, but not a measurable one. I've got a current client, they're 51% iOS traffic and their entire project is based on improving Core Web Vitals. Here's an interesting bit of research you could do. You could take all the data, you've got your anonymous customer data in SpeedCurve, you could run the numbers. You know what would be really interesting... be really interesting to see if do Core Web Vitals data gathered from Chrome visits in any way predict faster iOS experiences?

Obviously because there is no LCP in Safari, you can't do it for, but could you proxy it? FCP is in Safari and Chrome. So what I'd love to see is, maybe, I'm sorry I'm giving you a job now, but given the data SpeedCurve has, anonymizing that and saying, well, do you know what? If you do improve Core Web Vitals, it looks like that will have a positive impact on Safari or iOS by this percentage because... do you know what I'm trying to say? Sure. Could we still use Core Web Vitals as a predictor for better experiences in Safari? My instinct is of course, yes, but we don't know. So yeah, Core Web Vitals, I'm a fan of the metrics. I'm a fan of the rigorous definitions of the metrics. I'm less of a fan of the kind of cult of Core Web Vitals, optimizing Core Web Vitals for the sake of it rather than understanding the business impact.

And of course Google haven't helped, they haven't actually published any expected increase in ranking. If they said, "Oh yeah, it's about 5% of your ranking," that would give people a lot more confidence in whether they should embark on it or not. So everyone's just been shooting in the dark and I'm starting to see what I think I would call the post Core Web Vitals world. I'm getting inquiries now where people might be using Core Web Vitals as the metrics to optimize, but they're not doing it for SEO. They're doing it because they know that INP will affect engagement and LCP might affect conversions.

CLIFF:

Right.

HARRY:

So it's a bit of a double-edged sword. I think the cult of Core Web Vitals is sort of in the rear-view mirror now. The whole hype train around search rankings. Any studies are just anecdotal, no one knows for definite if it's worth doing. So I feel like people are leaving that behind. I'm seeing in my own inquiries in the work I'm doing, people are less bothered about SEO and they're going back to olden days... the kind of web performance you and I came up on.

CLIFF:

Sure, sure. Well you heard it here first, the title for your next conference talk, the cult of Core Web Vitals. I love it. I agree with you. And again, it's kind of hard because on one hand it's like I really hold the team up. Annie Sullivan and her team have just done such a fantastic, phenomenal job.

HARRY:

Incredible work.

CLIFF:

Like moving the needle in a very big way, in a very big way. And honestly, I can tell you just by talking with them and meeting with her team, they're doing it because they love performance and they really want to make the user experience better. And being able to maybe leverage some of the impact on our search ranking or whatever to move the dial... kudos to them. That's awesome. However, they have no control over what WebKit does. They have no control over Apple, essentially. And that is just such a huge gap. We do hope to see at least LCP and potentially event timing, INP, in this year with WebKit. But still no CLS. But then that begs even a bigger question like this data that people are starting from and going off of is the Chrome User Experience Report, is Crux data. I would put money on this to say there is no way in hell that Chrome is going to say, yeah, let's include Safari data.

HARRY:

Well, I mean you cannot get, because Edge has Core Web Vitals as a first class citizen, it's Chromium, but you can't get Edge data into CrUX. And again, that's to the expected because it's CrUX. Which begs the question, would Apple have to call theirs SUX? Yeah, Safari, right? Sorry, that wasn't very good.

CLIFF:

That would work. That would work. I don't know. That might be a branding issue a little bit. I think the folks from RUM Vision have quoted that term already, so I'll give props to them for it.

HARRY:

Really? Yeah, I, but you're absolutely right. So even if Safari do start supporting the metrics, surfacing that data, because of course – and this confuses a lot of my clients, understandably – So Core Web Vitals and CrUX are different things. Core Web Vitals are the metrics that could be available everywhere. CrUX is just the data captured by Chrome visits that cover those metrics. So even looking at basically just that subtle distinction that CrUX and Core Web Vitals are different things, and I think a lot of people don't understand the impact that has. And a lot of my clients, a lot of developers, a lot of developers don't even realize that Chrome on iOS, certainly at the time of recording, is just Safari. It's not Chrome at all. Yeah, it syncs your bookmarks across different devices. That's about it. It's not Chrome at all and it's a huge blind spot.

Not to sort of big you up too much on this fireside chat, but one of the biggest draws for my clients is that if we put SpeedCurve on their site, they get full visibility of their Safari and iOS traffic and their three Firefox users. But yeah, so that plugs a huge gap. And my biggest current client, when we looked at that Google Analytics data, they saw they were about 51% iOS traffic. And I had to tell 'em, well, you do understand that all of the Core Web Vitals data we've got and all the CrUX data we're benchmarking ourselves against only takes into account 49% of our users. And that sent a bit of a, I was in the senior leadership and that sent a bit of a ripple through the room because people hadn't realized, and that made SpeedCurve an even easier sell because I was like, oh, we can remedy that easily, but we can't do it with CrUX.

CLIFF:

Right. Makes sense. Makes sense. So I know that we're kind of coming up on the end of our time here and we've covered a lot and certainly I could go on, we should just do this monthly or something, but without trying to sound too pitchy, without trying to sound too much of a paid shill myself, you use a lot of tools and I'll be the first to say that there's some fantastic tools out there. I've never been more proud to be in a group of competitors that have such a high caliber of focus around performance. So I don't want to knock those tools at all because credit where credit's due. And I've worked at some of those companies before and worked on those products. So I'm not going to be a hypocrite. But what would you say is different about SpeedCurve? Why would you use SpeedCurve? You've given some examples already, so I apologize for making you restate them, but from your view, what's the real differentiator there?

HARRY:

Well, let's take one step back and sort of agree with what you just said is there are some great alternatives to SpeedCurve out there. I've got a personal account with Request Metrics to check out what they're getting up to and it's really good. I was working on an e-com site recently and RUM Vision was already installed on there. And it's like if you've got a project that is a Core Web Vitals project, then those tools are very, very honed in on that and they're very predisposed to, if you're fixing Core Web Vitals, here's your Core Web Vitals data.

One thing I really, really do love about SpeedCurve... and actually other competitors, other tools exist other than the ones I've just mentioned. One thing I find with a lot of other companies that are a bit older is their RUM solution seems like a bit of an afterthought in a lot of cases. I've used tools, and I'm not going to name any names, because this is critical. It is a bit of a diss, I found that tools that companies that traditionally sell APM, like backend application performance monitoring tools, I tend to find that their RUM tools are not a core business unit and therefore don't get the same resources, the same look-in. I've seen companies changing that. I've seen companies improving their RUM offering.

So two things that I like about SpeedCurve is that you've been around long enough that you aren't just a Core Web Vitals parrot. You were designed before Core Web Vitals even existed, which means that there's a key focus on a holistic look at user experience. You've got User Happiness Score, you've got ability to track Safari, Firefox, other browsers. It means that if you aren't just doing a pure Core Web Vitals project, which a lot of mine aren't, a lot of mine are revenue based and conversion based. Having a tool that was built before Core Web Vitals means that they've got a very, very mature and solid baseline for doing API oriented performance improvements rather than just keeping Google happy. And the other thing is you weren't spun off from an APM product. SpeedCurve was built from the outset to be, I think, I mean I've never even asked Mark [Zeman] what his motive was, but I think it just, I imagine Mark was just like, "We need to build the RUM tool that's missing" and build it from scratch and build it to be a first class citizen. It's not an add-on to your APM, it's a whole product in its own right and I think that's strong and it's stood the test of time.

HARRY:

I adore Treo. Treo is just as big a part of my toolkit as SpeedCurve is. They solve incredibly different problems for me. They are entirely complementary. There's no overlap other than sheer quality of product. So SpeedCurve. I think my three main tools that I could not live without: SpeedCurve, Treo, WebPageTest. Those are the three main things. They're all very complementary. I've worked on, like I say, pure Core Web Vitals projects that I've had RUM Vision installed already. And do you know what? If you want to know everything about your Core Web Vitals, that's a really good place to start.

The biggest problem with a lot of other tools is you don't really get to manipulate that data very well. So the example I just showed with the Time to First Byte subparts, if you're using a tool that is very Core Web Vitals orientated, until Chrome surfaces those subparts to us, they'll always be opaque because using proper RUM natural in browser stuff and not using just CrUX and stuff like that... sorry, I'm going to reword that because RUM Vision does use proper RUM. They're not using CrUX.

CLIFF:

Yeah, yeah, absolutely.

HARRY:

What I meant to say there was probably the, because you can sort of manipulate your own data very intricately in SpeedCurve, you just can build up a far more forensic picture of what's going on. And that's probably why it's my favorite. I think it's probably, like I said before, it's the performance engineer's tool. It's the one I like because it's very forensic. It allows me to get really deep in the weeds, but that's because I've been doing this for, as you say, 17 years. In the weeds is where I belong. So yeah, for me it's just a really, really useful tool for getting sleeves up and hands dirty.

CLIFF:

Yeah. Yeah, I feel like that's sort of where I was always drawn to SpeedCurve as well as a practitioner and working at a competitor prior to SpeedCurve. And I think Mark's initial take on it was also just about how he wanted to present the data in a way. He's a designer, he's a designer by trade, and when Steve [Souders] joined him, it was sort of the design and performance element between the two of "How do we display this data in a meaningful way that makes sense?"

But further to that, you're right, they were filling a hole that wasn't there. Or sorry, a RUM product that hadn't been built yet. And I would say for our peers as well in this group, I would include them in this idea that this observability focus that everyone has, and for good reason, there's APM and now it's observability and monitoring... all these different services and machines essentially I think missed the mark. Again, where's the user experience in all that? Where's the front end observability? Because I do believe, and I will say that some of those larger observability providers have kind of created RUM in that vein and a bit more as a checkbox where you're not necessarily getting that deep understanding and ability to share it across people who aren't necessarily DevOps or front-end engineers or others that are going to be key to making business decisions and funding performance initiatives.

HARRY :

Yeah. Well that leads me on to an interesting point actually because one thing I've neglected to mention is I've been talking about SpeedCurve through my eyes as a performance engineer, but the reason this is a great story arc because remember I told you my SpeedCurve bookends my projects and I'll start with installing it for my benefits so I know what's going on.

Once a project reaches sufficient maturity, I need to hand that over to a client. I need to know that the business understands how to use SpeedCurve. One thing I love about SpeedCurve is just how cheap and free and easy it is to spin up dashboards on a whim. I also really respect that you don't do pricing based on the number of seats because that really helps democratize performance.

Any new client project, whenever they install SpeedCurve and I get my login details for their SpeedCurve account, I'll create a private dashboard that I just call "Scratchpad" or "Playground". That's where I'll just throw things at the wall to see what sticks. No one else needs to see this. This is my messy inner workings of my brain, but it's so cheap and easy for me to do that. LCP went up, right? What metrics correlate with that? I'll throw all those at the wall. It'll be a messy just having a messy desk, but it's mine and no one ever needs to see that. And then when I've distilled an idea, I can then go to the shared dashboards and sort of have an overview dashboard and I can high dip my thoughts there. And generally what I tend to do with clients is I'll say, "Look, SpeedCurve is a fantastic tool. You can't really break anything, just go and play around. But the day-to-day observability and day-to-day practical use, go and look at your live dashboard. Go and look at your custom dashboard that we've made."

I might make a dashboard for marketing, one for finance, one for DevOps or whoever it might be. And that's one thing that customers, I'm a user of SpeedCurve, but the customers, my clients who end up signing up to SpeedCurve, they get a very different thing out of it, which is just distilled useful information, never information overload. It's like, "Look, go create your own dashboards privately, play around, just see what sticks. It's fun. It really is fun. But ultimately we've got one or two places that you're going to go to and that's your pulse check. Is a site humming nicely? Is it just ticking along? Have we had a regression?"

So yeah, that brings me back. That's my second half of my, how I use SpeedCurve is setting up those regressions, making sure clients are comfortable, not over faced with it. And I love that it can do both. It's a power tool for power users, but equally you can just put it in TV mode, stick it on a screen in the office, and everyone just knows what they're looking at. It's incredible.

CLIFF:

That's awesome. Well, this has been long, so I know I'm going to have to do a lot of post editing here. But again, could go on and on. Thank you so much, Harry. You're a great friend. You're a great champion in our industry, true performance guru that we've all looked up to for a while and we absolutely love working with you. I'm going to include some links to how you can get in touch with Harry. Harry is for hire and obviously does an amazing job. If you work with him, your site will get faster. So definitely want to promote him and hold him up as a strong partner for SpeedCurve. So thanks again, Harry. Really appreciate the time.

HARRY:

That's incredibly kind of you. Yeah, no, it's just nice to hang out, man. We always have a nice time when we hang out, so I've really enjoyed this. And yeah, I dunno. Thanks for your support. People don't see the back channel but times I'll ping you or Andy [Davies], "Can we add this feature? Can we do this?" And the fact that you've stayed such a driven and focused and small team just means that, I dunno, it's just really nice. It's nice working with you. I dunno. Appreciate it. Emotional now. But no, really, really enjoyed this. It's been so much fun.

CLIFF:

All right. Well hopefully I don't have to wait until November, but if it is, or I guess October. It is October. Well, we'll see you at PerfNow in the fall.

HARRY:

See you in Amsterdam. But yeah, until then, we'll catch up soon.

CLIFF:

All right. See you, buddy.

HARRY:

Take care, dude. Thank you.

A better way to manage performance budgets in SpeedCurve

Mon, 23 Jun 2025 00:00:00 +1200

We've made a major update to how you create, manage, and monitor performance budgets in SpeedCurve – and we think you're going to love it.

Until now, performance budgets lived inside your Favorites dashboards. That worked well for surfacing budget charts in context with the rest of your performance data, but it made managing budgets frustrating because they were spread all over your Favorites dashboards.

To fix this issue, we've moved performance budget management into its own dedicated Budgets dashboard. This change unlocks powerful new capabilities and makes tracking your performance thresholds and goals easier and more intuitive than ever.

Centralized budget management

Performance budgets now live in their own dedicated dashboard. This gives you a single, central place to view, manage, and monitor your budgets without having to navigate through multiple Favorites dashboards.

Easier navigation and filtering

We’ve introduced both a list view and the familiar card view, so you can choose the layout that best suits your workflow. Powerful new filters also help you quickly find specific budgets, even across large teams with multiple sites.

More context in one place

Each budget now includes a detailed view with its current status and recent performance, so you can instantly understand how your metrics are trending relative to their thresholds.

Budgets have names and descriptions

Budgets can now have a name and description, giving you more context and clarity, especially when collaborating with team members.

Improved budget types

We've separated absolute and rate of change budgets. You're no longer required to create an absolute budget in order to set a rate of change budget – making performance budgeting more flexible and tailored to your needs.

Visualize rate of change budgets

Rate of change budgets now include proper visualizations, so you can clearly see when and where your metrics cross thresholds. This makes it much easier to catch regressions as they happen.

Alert history

Ever wonder when a performance budget alert was triggered and why? With our new alert history, you can track exactly when alerts were sent and what the budget's status was at the time.

Alerts that work around you

Of course, we've kept the alerting options you already rely on. Whether via email or webhook, you'll still get notified when budgets are exceeded – because we know you're not logged into SpeedCurve 24/7.

Audit trail for every budget

Transparency matters. Now you can see a full audit history for every performance budget, including who made changes and what was edited. It's a simple way to stay accountable and collaborative across your teams.

Favorites still matter

Even with all these improvements, you can still add budget charts to your Favorites dashboards. If you've created performance budgets in your Favorites dashboards, don't worry – they'll stay right where you left them. Budget charts from those dashboards remain intact, but you'll now manage them from your Budgets dashboard.

Get started with performance budgets!

This update is all about giving performance budgets the focus they deserve. With all your budgets and budget management tools in one central place, it's easier than ever to keep your site fast, efficient, and on target.

If you're a SpeedCurve user – Log in today and check out your new Budgets dashboard. We think it's a big step forward in how teams manage web performance, fight regressions, and stay fast.

If you're not yet a SpeedCurve user – Sign up for a free trial and create performance budgets for key metrics (like Start Render and Largest Contentful Paint). Contact us at support@speedcurve.com if you have any questions or feedback.

NEW! SpeedCurve RUM for your Magento projects

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

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

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

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

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

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

With this module, you can:

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

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

How to enable SpeedCurve in your Shopify store

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

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

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

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

How to install and use SpeedCurve RUM

1. Create your SpeedCurve account

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

2. Install the SpeedCurve RUM Shopify app

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

3. Connect the Shopify app to your SpeedCurve account

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

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

4. Enable SpeedCurve in your theme

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

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

Optional automatic page labels

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

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

Troubleshooting

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

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

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

Next steps

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

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

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

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

NEW! SpeedCurve RUM for your Shopify store

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

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

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

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

> How to enable SpeedCurve RUM in your Shopify store

Site speed is critical in ecommerce

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

Poor performance increases bounce rate

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

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

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

Poor performance decreases conversions

Performance improvements directly correlate with sales. For example:

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

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

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

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

Slowdowns can cost more than downtime

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

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

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

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

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

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

Easy setup, no developer required

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

No developer required

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

Get useful data immediately

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

Friendly support when you need it

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

Add RUM to your Shopify store – for free

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

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

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

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

The Definitive Guide to Long Animation Frames (LoAF)

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

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

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

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

Keep reading to learn:

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

Where we've come from

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

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

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

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

Why does animation frame rate matter?

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

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

Anatomy of a LoAF

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

Long Animation Frame (LoAF)

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

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

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

More things to note:

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

Script Timing

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

Long Task

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

What does a LoAF entry look like?

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

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

Key LoAF milestones

There are several key milestones within a Long Animation Frame:

startTime
Start of the frame.

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

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

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

Key milestones during a Long Animation Frame

What can we do with this milestone data?

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

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

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

LoAF milestones vs main thread activity

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

paintTime
When the browser starts paint operations for the frame.

presentationTime
When the frame is actually displayed to the visitor.

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

Timestamps added by the PaintTimingMixin

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

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

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

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

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

Summarising LoAFs

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

Some examples of summary metrics I've experimented with:

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

Script attribution

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

Relationship between LoAF and Script Timing entries

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

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

A typical Script Timing entry might look like this:

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

Timing

startTime
When the script was invoked.

duration
How long the script execution took.

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

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

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

Invoker

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

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

Script details

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

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

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

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

Why script details might be unavailable

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

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

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

Summarising script data

There are multiple ways to summarise the Script Timing data.

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

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

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

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

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

Matching script data to INP

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

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

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

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

LoAFs overlapping with INP

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

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

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

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

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

Breakdown of script execution by INP phase

There are at least two ways to calculate INP phases

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

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

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

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

How to capture LoAF entries

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

Indirectly, using PerformanceObserver

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

Directly, by querying the Performance Timeline

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

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

Exploring LoAF in DevTools

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

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

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

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

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

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

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

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

Getting started with LoAF

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

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

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

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

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

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

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

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

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

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

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

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

What's new in your SpeedCurve dashboards?

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

In short, we've:

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

New metrics

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

Total Blocking Duration (TBD)

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

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

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

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

Other new metrics

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

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

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

Vitals dashboard updates

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

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

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

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

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

RUM JavaScript dashboard updates

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

Home dashboard updates

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

Drilling into your RUM waterfall

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

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

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

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

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

More resources

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

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

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

Get started!

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

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

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

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

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

Have you ever asked yourself these questions?

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

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

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

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

What is the "performance plateau"?

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

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

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

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

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

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

Background

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

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

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

Results

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

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

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

Keep reading for observations and takeaways.

Site A

Site B

Site C

Site D

Observations

1. A clear performance plateau emerged for each site

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

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

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

3. The plateau emerges surprisingly quickly in some cases

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

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

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

5. The plateau sometimes started later when looking at LCP

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

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

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

How to measure the performance plateau for your own site

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

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

Step 1: Identify the metrics you want to measure

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

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

Step 2: Gather lots of real user data

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

Step 3: Create correlation charts

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

What to do with your findings

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

1. Share your findings within your organization

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

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

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

3. Change your performance goals

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

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

4. Or DO NOT change your performance goals

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

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

5. Create a baseline to measure against

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

Questions? Feedback?

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

Performance Hero: Alex Russell

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

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

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

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

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

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

How did you begin your journey in web performance?

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

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

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

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

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

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

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

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

"Web developers need to wake up.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Web performance faces two main challenges today:

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

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

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

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

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

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

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

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

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

What is a correlation chart?

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

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

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

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

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

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

Communicate to a broad audience

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

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

^{Image by pch.vector on Freepik}

Identify the performance plateau for your site

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

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

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

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

Validate your metrics

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

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

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

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

Spot performance-blocking trends

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

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

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

Get started

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

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

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

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

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

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

SpeedCurve Blog

Performance Hero: Harry Roberts

Links

Transcript

A better way to manage performance budgets in SpeedCurve

Centralized budget management

Easier navigation and filtering

More context in one place

Budgets have names and descriptions

Improved budget types

Visualize rate of change budgets

Alert history

Alerts that work around you

Audit trail for every budget

Favorites still matter

Get started with performance budgets!

NEW! SpeedCurve RUM for your Magento projects

How to enable SpeedCurve in your Shopify store

How to install and use SpeedCurve RUM

1. Create your SpeedCurve account

2. Install the SpeedCurve RUM Shopify app

3. Connect the Shopify app to your SpeedCurve account

4. Enable SpeedCurve in your theme

Optional automatic page labels

Troubleshooting

Next steps

NEW! SpeedCurve RUM for your Shopify store

Site speed is critical in ecommerce

Poor performance increases bounce rate

Poor performance decreases conversions

Slowdowns can cost more than downtime

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

Easy setup, no developer required

No developer required

Get useful data immediately

Friendly support when you need it

Add RUM to your Shopify store – for free

The Definitive Guide to Long Animation Frames (LoAF)

Where we've come from

Why does animation frame rate matter?

Anatomy of a LoAF

Long Animation Frame (LoAF)

Script Timing

Long Task

What does a LoAF entry look like?

Key LoAF milestones

What can we do with this milestone data?

Summarising LoAFs

Script attribution

Why script details might be unavailable

Summarising script data

Matching script data to INP

There are at least two ways to calculate INP phases

How to capture LoAF entries

Exploring LoAF in DevTools

Getting started with LoAF

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

What's new in your SpeedCurve dashboards?

New metrics

Total Blocking Duration (TBD)

Other new metrics

Vitals dashboard updates

RUM JavaScript dashboard updates

Home dashboard updates

Drilling into your RUM waterfall

More resources

Get started!

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

What is the "performance plateau"?

Background

Site A

Site B

Site C

Site D

Observations

1. A clear performance plateau emerged for each site

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

3. The plateau emerges surprisingly quickly in some cases

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

5. The plateau sometimes started later when looking at LCP