R3ACT: A Frightening Look At Performance Figures

Good morning, everyone. Or should I say, good morning, Dom. For the five of you who follow me on Twitter, yes, I'm still on Twitter! I'm still on Twitter! It's just like a twitter. I'm still on Twitter! I follow you all on Twitter. You follow me on Twitter? Yes, I'm still on Twitter. Imagine that! I do this every morning. I greet the Dom and I've been doing this probably about like six, seven years, like literally every day.

And I want to thank well, I'm here for React Summit US. I want to thank you nations for having me. Merci beaucoup. And I want to say hello to New Jersey. New Jersey is what I used to call U.S. east 1 NYC 1A. Because that's how we work, right? But we're here in New Jersey, home of what used to be the New Jersey Nets. Any ball fans here? New Jersey, birthplace of Whitney Houston. In the US, the New York Times. They're the best employers in the history of work. The Sopranos. I hear they're good to work for. New Jersey, birthplace of Greg, okay, someone knows. And for those who don't know who Greg is, you might know Craigslist? Oh. There you go. You know.

Speaking of horror and tragedy, today we're actually going to talk about web performance. I mean, web performance, come on, now. It's not that bad. But, you know, I know Halloween was a few weeks ago. I personally like Halloween. It's a little fun. But, essentially, we are going to have fun with today's talk.

And, essentially, I'm sort of, you know, entitling this Monday the 13th. Because we are going to look at some pretty interesting and potentially sad data. So, with all that being said, welcome to my presentation, which I'm calling React. And, specifically, it's a frightening look at performance figures.

I mean, I don't want to make it sound like it's really bad. I'm not saying that it's really going to be that bad. But we are going to look at some data. And that's not always favorable. But that's how the web is sometimes when we talk about performance.

So, let me introduce myself. My name is Henry. I can be found on all socials at Henry Helvetica. Yes, that is not my real name. It's a known plume. I have a situation I'm starting up called Command H. It's sort of a web development company. I'm going to do web performance stuff. I'm from the greatest city on the planet called Toronto in Canada. Oh, we have Canadians here. Oh, thank you. Thanks for coming to see me. And I'm a bit of a distance runner. Yes, I did a Nike campaign a few years ago. I'd be happy to talk about that. The running, that is. But I started this campaign online called the hashtag devs campaign, and, yes, if you do run any runners here, yeah. I wanted to go out this morning. I didn't have my gloves. It was zero degrees Celsius, and I chose not to. That being said, let's go.

So we're here to talk about react. Now, some of you probably remember react turned 10 years old this year, which is actually pretty cool, and if you look back and you think about what was happening ten years ago, the iPhone 5S was the new thing. When did iPhone 5S come out? Okay. And, if you're of the other flavor, the Moto X was brand new, but that was ten years ago. But something really important happened a few years after that, specifically three years after. In November, 2016, I try to remind people all the time, this was a significant date in history for the web for developers too. It was even more accessible in the fall than it was on desktop. And that happened in fall of 2016, and I want you to keep in mind that this is never, ever, ever, ever, ever, ever, going back. All right? Now, that also indicates that we're basically in modern times. And, you know, we once had the web kind of look like this. Speaking of Craigslist, speaking of South Jersey, all right, real talk about technology. There's a lot going on on the web right now. We have a little, not too many, you know, technologies on the hood here. But, you know, today's web kind of looks like this, you know, for the NBA fans. There's a lot going on here. You know, it may not look like it, but we're talking about just under, like, 50 technologies working under the hood, you know? Live updates, you know? Like, there's so much going on here. There's so much going on, you know? And it's the web and what it's capable of and looks like today.

When we talk about the modern Web, we also want to talk about modern performance. Because if you're going to talk and work with the modern Web on your devices, when you do some tracking of performance, we're talking about modern performance. And, you know, whenever performance comes to mind, we have to discuss the idea of metrics. And, you know, it felt like, you know, we kind of can click, click, okay, 8. 5 seconds, we're good, but modern metrics or modern performance also require modern metrics. And we are here today.

Now, modern metrics look something like this. This is just a few of them, but here we have a septet of metrics, time to first bite, largest contentful paint, total time, cumulative layout shift, speed index, which is one of my favorite, by the way, first input delay and interaction to next paint. These are seven metrics that we pay attention to today. Who has heard of the majority of these? I can't even see, by the way, so whatever. But I'm going to concentrate on a few, and specifically this quartet of metrics, LCPCLS, FID, and interaction to next paint.

So, first off, let me start with my first point, which is web page testing. I used to work at this company called Cashpoint where we had this tool called web page test. Who has heard of web page test? Please say yes. No. Okay. Just a few of you. All good. Because now more of you can take my course next year. But we look at what the web looks like under the hood, all right, like the shiny car looks great, but maybe it's blowing blue smoke. You know, we can pick that up. But what I'm going to present to you is a bit of a snapshot of the web. This is what we see as performance people when we look under the hood. And specifically, okay. I thought that was a heckler. And specifically, I'm going to talk about the tools that we use, well, tools. I'm going to pull data from this place called the HP archive. Which is sort of like lab data of how the web is being built. And that's the main kind of data we have. I'm also going to pull from the CWV tech dot report.

So it's essentially a core of vitals report. And it's RUM data. And I'm going to pull some of that as well. And I'm also going to pull data from the RUM archive. Which is a RUM version of the HP archive. Courtesy of the good people at Akamai. And this is also super useful for anyone who is trying to do web performance.

And since we're talking about modern web performance and, you know, I want to speak in a language that people at least had heard of. Who's familiar with core vitals here? Hands up if you've heard of it. Okay. Awesome. Thank you. So we're going to talk about that today. And core vitals is made up of three metrics. And our core vital is the time, the user experience, and the loading process.

So we start with things like visual completeness, you know, the user experience of visual completeness. When you're holding your handheld device, likely a smartphone. What does it look like when the page is loading? When that happens, we talk about the LCP, the largest content for paint. And that means, like, the hero image or the hero or the largest content, when it's good, it loads in 2,500 milliseconds, or more. In between, it's kind of like, meh. But we're going to talk about that. But we also got to talk about page stability.

Who's here loaded a site, and it's like, you waited for the page to calm down before we started reading? All right? We talk about that all the time, and that comes down also to a bit of a user experience. And when it comes to the page stability, we talk about the CLS, which is the cumulative layout shift. And, you know, here it's not a timing index, it's more like just a metric, and 0.1 or below, awesome. 0.25 or higher, not that good. And in between it's like, whatever. It needs work. The ultimate score here is zero. All right? And, of course, we have to talk about interactivity.

What happens when you click that buy button on your React Summit US ticket? You want that to work or not? All right? But, we talk about the FID, first input delay. 100 milliseconds or lower, awesome. 300 or higher, not that good. And in between, needs work. All right. So, now the data. Let's start to look at this. What I'm going to do now, I'm going to sort of compare what the web looks like and what we see React sites look like. All right? So, what the web looks like right now when we poll the web, 43. 1% have good CLS, good LCP, and good FID. So, sort of like three green checks. When it comes to React sites, 37. 7% have good across the board. All right. That really means that just over 60% of the web users, either with good LCP or good FID, are either mediocre or poor Core Web Vitals. And these are just data points I want you to keep in mind. Let's look at these vitals now individually. Let's start with the LCP. Now, the web has good LCP at a rate of about 59%, which is pretty good. So, again, that means that the hero or the largest content on the web is better than your Google Play Store, and with around 60 to 70% of the web users who are media-intensive, that means they're faster at a 60 or 59% rate. React, 47.4%. Okay, not a huge deal, but, you know, again, just a reminder of what's going on. The web, when it comes to CLS, when it comes to page stability, is doing well at a rate of about 75%. When it comes to mobile, you know, either way, it's all pretty good. Again, these are points I want you to remember. Now, the FID, the first input delay, the interactivity metric, the web is passing at a rate of 96%, which is amazing. React is passing at a rate of just about the same, 96.5, which is also amazing. But for those of you who track performance, this is a metric that we've had some challenges with, and as we look at this example, we've looked at the data. Any teachers, former teachers here, anything like that? Yeah? You know when you write that exam, and everyone in class gets like A plus? And you're like, hmm. Either this was the wrong exam, or everyone was cheating.

Well, it was figured out that this was the wrong metric. And this was something that was sort of hidden, and they figured out that, you know, they weren't tracking this interactivity metric properly, so it is going to be scratched officially by next year, but what they did do is replace it with this one metric called Interaction to Next Pink. I forgot the two part. It was experimental until this year, where it was basically staged to go full-on March of next year, all right? So when you start to look at interact, INP for short, you start to look at the data. It looks like this. The web is passing at a rate of 78%, and again, this is an interactivity metric. This is how, you know, we get things bought online, JavaScript, but React is not doing the best. So, again, the INP average is 80%. This is how we get things bought online. JavaScript is not doing the best. So, again, when it comes to the INP, React at a rate of 50% is mediocre or poor. So, just to bring you up to speed of what the INP is going to signify in terms of metrics, moving forward, at 200 something. So, in between it's good. Not good. And in between it's meh. Pardon me. But, again, these are important parts because we're talking about the interactivity that is necessary for really the web to operate these days, okay?

Super fun. Now, we are about JavaScript, aren't we? And just a reminder that a kilobyte of JS is not equal to a kilobyte of, say, images. Image data. JavaScript has this level of toxicity that we just need to keep in mind. You know, again, we're not hating on JS. At least I'm not. Someone else in my deck will. But this is important to know.

So let's look at some data here from the HTTP archive. So at the 50th percentile, the web is shipping about 560 kilobytes of JS. Cool. Now, if we compare that to what React sites are doing, everyone's happy apparently. Almost 1200 kilobytes. All right? And this has been going increasing year over year. 12% year over year increase from last year.

Now, if we look at the top 100,000 React sites, they're shipping 436 kilobytes at the 50th percentile, which is basically double what the web is doing in the top 100,000 sites. Now, another metric that I struggled to bring up but I didn't want to because it almost deserves its own talk is total blocking time. For those who say follow, I don't know, lighthouse scores, this is worth a lot of your score, all right? The problem is that JavaScript, the abundance of it tends to influence total blocking time, increase it, and probably start to, you know, hammer your user experience. I'm going to get to that in a hot minute, but I want to bring it up here.

Now let's look at some more data. This is super fun. Just a reminder that, again, what I talked about earlier, we have more mobile users than desktop users, just generally. And desktop metrics tend to do better than mobile metrics, kind of makes sense. You know, we don't have M3 laptops and mobile phones yet. But generally, you just want to keep that in mind. So for example, this is Akamai rum data. The Internet traffic looks like this. Again, more mobile devices online than desktop. At a rate of 80% more. Okay.

Okay. 61.4 versus almost 34. Now, this is a really interesting screen shot and I want to share it. Now, you're going to see that part where I kind of stop on July 1st, and you see mobile at a rate of almost 70%. This is the kind of data point that happens quite often. Why? We have holiday weekends. Why? We have weekends in general. Mobile use jumps on weekends versus the rest of the week. So, even more data proving to you that we are in a mobile device society.

67% of sites have more mobile traffic than desktop. Again, natural. And, you know, I just want to remind people there are two mobile users that we know, okay? iPhone users and clowns. There are apparently a few clowns in here. But real talk though. Serious talk. This is important and here's why. A few nerds may have picked this up, seen the talks, but Facebook engineering had done some fabulous work and there was this library they had called Device Year Class. Anyone familiar with that? It's totally cool because I'm here to tell you about it. Android devices made this play for volume, meaning you were able to buy inexpensive Android devices. What happened was they gave you shiny new phones with antiquated or old guts. Old CPUs, old GPUs, but they worked. That's all that mattered. But what they discovered is the fact that this kind of information was super important in terms of what you were sending down the wire. Generally, Android devices are just not as powerful. We ended up with a new phone with basically older parts. Now, why does this matter? The reminder that we're mostly on mobile. The reminder that the total blocking time that I talked about is 2.5 to 3 times worse on a mobile device. So that interactivity that you're trying to achieve, people are having a harder time on mobile phones. This is a thing called rage-clicking. It sounds funny, but it's actually being tracked by RUM providers out there.

Dinotrace, actually the good people at Sentry outside, they actually have their own metric they're calling user misery or something like that. But this is actually being tracked. It's like how many times you're hitting this button, because it's not working. What happens is that the JavaScript is hammering the main thread, rather than hammering your user experience. More JavaScript, worse TBT, total blocking time and worse becomes your INP. Harry Roberts has the quote of all quotes, a performance engineer out of the UK, JavaScript is the fastest way to build yourself a slow website, which I thought was kind of interesting.

We always talk about measuring. You absolutely have to measure. You want to see what is going on, the app looks great, the site looks amazing, but what is happening under the hood? You cannot improve what you don't measure. Shoutouts to the runners out there who are trying to get Pbs. Thank you. You use tools like WebPagetest, where I used to work, but you also have tools like Lighthouse, Debugbear, Trio. Another quote I like here, be conservative what you send. Don't send JavaScript that is not going to be consumed. There is a lot of that happening. I could have given another talk about that. Send resources to machines that conform completely to the specifications. Kind of like an interpretation of the robustness principle. Again, be aware of your users. We have the technology to figure that out. Page performance is now perception in all user experience. That is a fantastic quote. Because it is mine.

You remember that NBA landing page? It is a React site by the way. Failed at the largest content for paint metric. Cumulative LRG, a shift. FID. INP, mediocre. And total blocking time not the greatest. That being said, in closing out, I want to say we have three or four performance discussions or two or three presentations happening at this conference.

Three of them are taking place with these gentlemen right here, Ivan Ken, Medhat who's going to be streaming. That being said, you can find me on all socials, Instagram, what's the other one? Not Facebook. Instagram, Twitter, Bastodon, Blue Sky, whatever comes up tomorrow.

We're going to take two questions for Henry. Henry, the first one is, why does React web pages have a larger JS code generally? I mean, I think just for the most part, okay, so I don't like to play this blame game because I don't believe it's about that. I really do believe it's about testing. It's about making sure that you see actually what is going on. I think I was talking to someone about this yesterday, it's like, you know, we are very delighted with the work that we do. Probably React people Yeah, you can have mine. One, two, okay. Yes. I mean, I think it just comes down to testing really, because I think that that's being overlooked, even though performance is becoming a bit of a bigger conversation, but at the end of the day I think, if we test and see what actually is going on, we'll be like, oh, I can't go with this right now. And so, there is a pinch of discipline discussion to be had. Shaking my head, testing.

Okay, so the next question is, what are some low-hanging fruit that are commonly missed when trying to improve web page performance? I mean, there is... oh yeah. You know, low-hanging fruit. I think one of the easier ones is, I think, page weight. Because if you see a heavy page, you have to at least ask yourself, what is going on that I've missed? That's like the first indication. And the next step is really just to do a trace, or really, just go look at your dev tools and a waterfall chart. And I know a lot of people do not look at waterfall charts. I've heard it from the horse's mouth, in fact. That will indicate to you that something is off and then thereafter you can start to really dig in and find out exactly what is going on. So I think that's the lowest hanging fruit.

Well, we could keep talking, Henry, but we are out of time. Henry is going to be in the speaker Q&A room. All of the amazing questions, I see them. I'm sorry we didn't get time to ask them.