How Fast Is Fast Enough?

The first speaker today, Tammy Everts, chief experience officer at SpeedCurve. I have told people before I've been doing performance work for a very long time and the entire reason I get to do it is because I have learned from people smarter than me who are so patient with asking, answering questions, with writing blog posts and things like that. And Tammy is definitely in that category.

I have been learning from Tammy since before I really dived full headed into performance. She's a prolific writer and one of the things that I love about all of her work throughout the years, whether it's been the research, whether it's been the work on the metrics, everything she's ever done, at the center of it is that human factor which is what I love so much about PERF anyway. But she's always thinking about what is the impact to people, what is the impact to the user, which is no surprise if you get a chance to meet Tammy. She's one of the kindest people you'll ever meet.

But I could not think of anybody better to start the event with than Tammy Everts. Ready?

Thank you.

So nice. You can't see I'm kind of blushing a little bit. Can everybody hear me in the back? Yes. Thank you. So I've been doing versions of answering these questions over the years, but I actually, when I started working on this talk, I kind of got back to some first principles and it was a really interesting talk for me to put together because I really actually thought about this question.

How fast is fast enough? And I try to avoid getting into kind of some rote patterns that I've acquired because I've been doing this for a long time. Before I do that though, it is Thanksgiving or not. Sorry, not Thanksgiving, that just happened in Canada. It is Halloween tomorrow and I did bring some, I can't give out candy at my house back in Canada, but I did bring some candy here. So I'm going to throw it. I'm going to try to not hit anybody in the head. I'm going to lob. There you go. This is Canadian chocolate.

Okay. My throes are very, very gentle. I've seen people almost get pegged at other conferences and I didn't want to hurt anyone.

I do have a bag of candy with me.

So if you would like to do trick or treating during this event, just come up to me and say trick or treat and I will give you candy and maybe ask you to do a trick.

So yeah. How fast is fast really?

Does anyone really know? It depends. There are so many Variables. So if you thought I was going to give you AN oh, it's 1.2 seconds, that's not what I'm going to say today.

But I kind of wanted to talk about what is fast? What does fast even mean? And I really like this piece that Catherine Jew, who's co founder at Kernel, wrote. She keeps a really excellent blog. It's beautiful, elegant, very fast.

It's literally just like serif text on a white background. So I tried to replicate that in the slides and she said fast is magical, and she caught me with that, so I read the entire post.

Fast eliminates cognitive friction. I don't want to kind of read all of this, but maybe for the benefit of the people in the back row who can't see this quote, I'll read the highlights. Basically, this idea that apps like Raycast or Superhuman, serving pages in under 100 milliseconds and giving you the content that you wanted before you even really expected that content to render just feels like. It feels magical.

And what's interesting, she points out, is that no one says, oh, I love these tools because they're fast. They're really great tools. They just feel magical. So I encourage you to check out this post.

It was kind of magical to read. And she wrote it really recently.

And that was kind of actually what sort of triggered my thinking about, like, what is fast? And have we kind of maybe settled a little bit in our thinking about what is fast enough?

On the flip side of that is fast is pragmatic. And what do we mean by pragmatic? We mean make your site fast enough to improve business metrics or user engagement metrics, like bounce rate or conversion rate, or time on site or revenue, or all of those other user experience and engagement and business metrics.

Or put another way, and I'm embarrassed to admit I've kind of said versions of this myself over recent years.

If there's no ROI beyond a certain point, is there even a point in making pages faster? Maybe that's fast enough. And that's fine, you should settle there.

But I don't really like this idea that we have to think that pragmatism versus magic. So I kind of thought, what if we could arrive at something that's pragmagical?

So if this term could go viral, that would make me so happy. Hashtag pragmagmagical. Hard to say, but it's fun to think about. And so what do I mean by pragmagical?

We're going to talk about that first. I'm Tammy Evers, you can find me in kind of all the usual places. I work for SpeedCurve, where we help a lot of companies monitor their pages and get fast, figure out what's wrong with their pages, how to make them faster, and then how to tie that back to those user engagement and business metrics that I just talked about so you can find me. These are some of the companies that I've been really lucky to talk with over the years.

And kind of getting back to that question and talking with all those companies about, well, what is kind of the space between pragmatism and magic. And ideally we want that space to be as small as possible.

And that's kind of what I want to talk about today.

So when we're thinking about how to define what's fast enough, I think it's really important to take a step back and think, well, who are you trying to please with the speed that you're trying to create on your site? Are you trying to make your boss happy? Are you trying to make Google happy? That's legit.

Are you trying to make even your users happy? And sometimes this order is very intentional in terms of how I put this together.

Sometimes it feels like the users are a bit of an afterthought. We look at our business metrics and they get really focused on that. Or we look at our SEO related metrics and we get really focused on that and kind of forget, well, what about the users?

So let's talk about your boss first. Or your employer, your organization, that very important person who sent you here so that you could take away helpful insights to go back to your company and make your own site faster, your users happier, your business more successful.

Hopefully this isn't your boss.

I've heard versions of this over the years. This is a real thing that people say, not necessarily in these words. Our company, our products are so cool, people want them.

They don't mind if our pages are slow because they're there for the products. And this is a real thing that people believe.

Well, fortunately we can actually test that assumption. So there's a few ways we can do that. One way is doing a B testing or multivariate testing. So many years ago, kind of early on in my own performance journey, I was working at another company and we had a very cool brand. I won't name their name and they didn't quite buy the idea that making their pages faster would make that much of a difference, but they were willing to kind of put their money where their mouth is and do an 18 week multivariate test where we throttled some cohorts of users and we gave another cohort a fast experience.

And what was really interesting was, among other things, yes, conversion suffered for the slower cohort for the people who received that artificially throttled experience, despite the fact that they were still at the same very cool brand. And what was really interesting was that when the experiment ended at 12 weeks, the throttling experiment ended at 12 weeks, we continued monitoring those same cohorts over six more weeks. And we found that the people who suffered from the slower experience, and it wasn't painfully slow, it was just somewhat noticeably slower, failed to come back at the same rate that the other cohorts did.

So the takeaways there were, yes, predictably, as we knew as the performance folks that slower pages would equal fewer conversions. The surprising thing for all of us was that even when things returned to normal, those same people had a lower return rate.

If you are not able to convince your bosses to throttle the speed of your pages, there's something else you can do, which is if you are capturing rum data, real user monitoring data, where you're looking at real user behavior on your site and capturing all of those metrics, you can also capture other metrics like bounce rate or conversion rate. So this is just an example of a correlation chart that we create at Speed Curve for our customers. Our customers can create them for themselves. Where you can see that the orange bars, or I guess maybe it looks more like yellow on this screen. These yellow bars are a histogram that represent the distribution of LCP time across sessions for all the users. And you can see the blue line which measures the conversion rate as it kind of maps to those different cohorts. And what's really interesting, and we see this fairly consistently from site to site, is that there's usually a peak for conversion rate and it usually is over above where the fastest cohorts of user experience are.

So in this case with this particular site, this is one specific site where we captured a lot of data. We found that 6.2 second, sorry, 6.2% conversion rate correlated with about 1.1 second LCP time. Largest contentful paint. When meaningful content has rendered in the browser, you can also look at something that we call the performance plateau, which is what's that long tail of performance look like?

And see that basically if things don't really seem to get better or worse in terms of conversions along that long tail, and in this particular case, you can see the performance plateau starts at about 2.8 seconds. So what you can learn from that is that 1.1 second for this particular site, 1.1 second is kind of their goal. They want to push as much of their traffic as possible, kind of within that experience.

And 2.8 seconds is kind of their threshold. They don't really want to get slower than that. But also if they're going to try to get faster, they want to get much faster than 2.8 seconds. Going from 3 seconds to 2.9 seconds isn't going to make much of a difference.

So what we learned from that, from looking at a lot of correlation charts, is that there's actually no one size fits all correlation.

So don't take away from that previous chart the idea that 1.1 seconds is ideal. It's just ideal for this particular site.

And if your metrics stay on the performance plateau, your business metrics won't change. So those are two really important things to think about.

So that's kind of the business side of things. Let's talk about Google for a minute. We have a lot of folks from Google here and they will probably be more than happy to talk to you about Core Web Vitals. Core Web Vitals have been on the scene for a few years now and they were really important because they simplified performance in the sense that they helped us focus on three metrics that tie into three aspects of the user experience. So is the page responding? Are you able to see visual content that's largest contentful paint?

Does the page feel kind of janky? And are visual elements moving around a lot? We have cumulative layout shift for that. And is the page interacting and responding quickly Whenever you click or tap on things, then we have interaction in XPaint. So really, really helpful for us to coalesce around a set of metrics. And one of the things that Google has done with releasing Core Web Vitals is given us set of recommended good needs improvement and poor thresholds.

And they're different for each metric and you can kind of see them up here.

And as I said, you can talk to the Google folks about that if you're curious. But the thing to keep in mind about these thresholds is they are based on aggregate data and other factors that are kind of pulled in. They're not one size fits all metrics.

They are important. You can read on the Google Developer blog that basically they highly recommend that you achieve good Core Web vitals for success with Google search and also for your users, because that's kind of the whole point of what this is. But as Tim said On this stage last year, it's important to think of core web vitals as a starting point, not a finish line. So it's great to get familiar with the vitals and start familiarizing yourself with them and how they apply to your own site.

But that's just where you begin.

Google's thresholds are not your thresholds.

I can't stress this enough. If you are aiming for an LCP time of 2.5 seconds, because you see that as a generic recommendation, you could be doing your site a real disservice. And you're doing your users and your business a disservice.

This is a really interesting recent study by Content Square where they looked at data for 997 of their retail customers. And it keeps bothering me that it's not 1,000, but that's fine, we'll let that go. And what they found is, and you might think this is kind of trivial, was that the customers who had a good IMP experience an average conversion rate of 2.5% and the customers with a poor INP experienced an average conversion rate of 2%. And you think 2% to 2.5%. Is that really a big. That's a 25% difference. That is very, very significant. But you have to bear in mind again that this is based on aggregated data and then averages across that data.

So as an example, 200 milliseconds is considered good INP for Google based on segregated data.

My colleague Cliff, who is going to be with me doing a demo later on today, and you can chat more about this with him if you're interest. When INP was first announced at SpeedCurve, we like to validate business metrics.

So when INP first came out we were like, well, does it actually correlate with user behavior in any meaningful way? Because if it doesn't, it's hard to recommend it as a metric that people should really, really care about. And so he looked at four different sites, captured conversion data for them, fairly significant amount of data, and created four different correlation charts which you can see here. And if you're interested in more about what he did, you can also follow link to learn more about this research.

And what he found was actually that the peak conversion rate for these four sites vary depending on imp. So IMP had a strong correlation in three out of four of the sites. In one of them we were eh, we don't know. But for three out of four of them there was a correlation and it varied from 50 milliseconds to 150 milliseconds, but you can see that all well within 200 milliseconds. So if you thought 200 milliseconds is good enough for your pages, but you were one of these three site owners, you would be doing, as I said, your site and your users and your business a Disservice by thinking 200 milliseconds is good enough. I think the important thing to keep in mind is that aiming for someone else's metrics is always a bad idea. Aiming for somebody else's target is not right for you. Find your own target and aim at it.

So let's talk about your users, these people that we sort of forget or they sort of become this sort of aggregate lump of humanity. So let's think about them for a little bit.

Over the years, if I had a dollar for everything I read that was based on a poll of folks asking them how fast they expected web pages to be, I would have a lot of dollars. It's like 8 seconds, 3 seconds, 5 seconds, 2 seconds. People have no shortage of opinions. And again, this is based on we surveyed 3,000 people, or we surveyed two people, and we average their numbers and that sort of thing. It doesn't mean anything. And I hate to say, and I have actually, like, I have happily shared data like this in the past, and now I'm retrenching on that. Like, it's interesting to hear what people say they think they want, but does it actually correlate with what they really need and what's helpful for them? And, you know, again, moving down the line, helpful to your business? Not much.

That's because metrics do not equal feelings.

We try really, really hard. And I think everyone in this room, if you're here, you care about users and you care about user experience, and you're trying to find a way to map metrics to feelings, but that will never, ever, ever, ever, ever be the case.

It's impossible. We can do our best, but we should always keep in our back pocket the idea that we're not getting it quite right.

And that's because if we just focus on metrics and happily think that our metrics are mapping to something real that our users are feeling, we're not actually thinking through the broad range of contexts with which users are experiencing our sites or our apps.

I really like this quote from Kara Pernise, who is president and CEO of Nielsen Norman Group, where I won't read it all, but basically, people are spending a long time on your site and the site's pretty quick and they're clicking a lot and they're visiting a lot of pages. Sure. That can mean that they're really engaged and they're having a good time using their site or it can mean they're totally lost, they don't know what they're doing, they can't find what they want, they're really frustrated.

This is where usability testing can be really, really handy and it doesn't get done enough in conjunction with site analytics. But her recommendation is usability tests when possible, especially if you're doing something new, building a new site, building a new property you've done some big sprint is actually do usability testing and map that research or results with your site analytics so that you understand are the users who are using your page engaged or lost?

So let's talk a little bit about that. So it's helpful to think about tasks as being kind of falling into two rough camps.

We have engagement tasks and we have productivity tasks and we all do all of these things all the time. So an engagement task is something that is very open ended, it's very absorbing.

You can spend a lot of time doing an engagement task and a good example of this is, oh, and then you have a high tolerance for waiting because you're engaged and you're absorbed and you haven't really given yourself, you haven't time boxed what you're trying to do. So an example of this is you're researching a trip. So you just kind of want to like as many of you might have done if you were coming to Amsterdam and wanted to maybe tack on a little bit of pleasure travel with you as well. You just kind of like fall down rabbit holes of reading about your destination and looking at pretty pictures and things like that. This is you, you're researching a trip, you're dreaming time doesn't matter anymore.

As opposed to productivity tasks where you want to quickly complete a very specific output. And so that can mean, and that means you generally have a lower tolerance for waiting.

And an example of that would be administering your trip.

So this is you, you're on the trip that you planned in the previous slide. You were having a great time at the resort you were staying at and then you got pinged and found out that your flight got cancelled and you tried to contact the resort that you're staying at to find out if you could extend your stay, but the resort is all booked up and they can't keep you for another night. So now you have to look for another place to stay for a night and you have to move your family over there. Suddenly you're not so happy you're on the trip. And maybe you're using the exact same website that you used to plan the trip, but your frame of mind is absolutely the polar opposite of what it was when you were in that engagement. Focused stage.

Same person, same metrics, same number of clicks, same time on site, but completely different user experience.

And Sandra, I don't know if Sander's here yet. There he is.

I really like this graphic that you shared on LinkedIn a while ago. So I pulled it in here and you can. Sandra's that guy right there. You can talk with him during the break if you want to learn more about this. He's a performance consultant and what he pointed out in this is something that I've known.

But I like how elegantly it's expressed in this particular graphic where just one slow step in a journey can make the entire experience feel really slow. So how do we create flow?

So what is flow? Let's talk about that. So flow state is a state in which people are so involved in an activity that nothing else seems to matter. It's kind of what I talked about before. And I'm quite obsessed with the idea of flow state because I feel like it's actually so missing from so much of our lives. And I'm constantly looking for flow state activities to do in my spare time to make up for the fits and starts of human computer interaction that kind of muddle up my day.

The experiences should be so enjoyable that people will continue to do it, even at great cost, just for the sheer sake of doing it.

So how do we. What does that mean? How do we create flow on time or online? You really can't.

It's very, very hard to create an absolutely instantaneous experience. So what we're really trying to do is we're trying to fake flow. How can we make experiences that feel like flow experiences online? And this is a quote from 2012.

And I feel like that was a bit of the North Star for a lot of folks back then. It was like, yeah, 100 milliseconds feels instantaneous. It's basically that the human eye can't perceive 100 milliseconds. Most of us can't.

Basically, we're aiming for something really, really high.

So 100 milliseconds was kind of the dream.

And I feel like we've lost that dream.

So think about this is basically, we're going for that zoetrope experience of persistence of vision. That's what we're really trying to do online.

So pragmatism, magic, pragmatic is unique to your site. It's all those business metrics that I talked about before. You're looking at your rum Data magical is 100 milliseconds. How do we get those two things closer together? Well, I don't have the answer right now, but that's what this conference is for. But let's aim for pragmagical. I feel like this focus on business metrics is maybe a little cynical and maybe doing all of us a bit of a disservice. Why not try to give your users the best possible experience? So the takeaways that I hope you get from this are know who you're trying to please.

Know why people are on your site. Are they. Is it an engagement task?

Is it a productivity task? Identify your metrics and thresholds.

That's obviously important. That's what the tools are for. Meet your targets, mitigate regressions. Do all those things that you're supposed to do as soon as possible. Never stop monitoring. Of course, if you're going to be fighting regressions, do usability testing to avoid making false assumptions about about how your users feel when they're on your site.

And the most important, always err on the side of creating an experience that isn't just tolerable, that's not just good enough, but ideally it's delightful.

Isn't that a great idea to actually give your users a sense of ease and joy in a day that might not feel easeful and joyful? Thank you very much. I'm going to be at the Google help desk at 1:10 if you want to chat and I'm going to be doing a demo there with Cliff at 2 2025, 1425. But yeah, thank you very much for listening.