(00:09) Henri: Welcome, welcome everyone. This is the first, webpage test live of the year of 2022. It’s been a little while, but I'm glad that everyone here could join us. So once again, sorry that, we're a few minutes late. I was still, I guess, figuring out the back end of, this whole enterprise that is, Streamyard. It's my first time using it. So, thank you for your patience, but once again, welcome to webpage tests live. This is not an episode of guess who is coming to dinner, and I am not Tim Cadillac. My name's Henri I'll be host with the most today. Shout out to Tim, he wasn't feeling, amazing. So he picked me and asked me if I could, fill in for him. And I absolutely could. So this is why I'm here.
You're gonna see me, a few more times a bit more often, at, this amazing channel that is the web page test Twitch channel. So, like I mentioned, this is our first, WPT live of the year. We’re happy to be back. we ended the year, we were a little busy obviously, and we, unfortunately, did not have as many streams as we wanted, but we are going to get going again and, we're gonna stay busy, and, I'm actually gonna talk about that.
In fact, webpage test live is going to be a lot of different things. We're going to do the classic sort of like auditing that we all love, that you guys all came for. But we're also going to have some really interesting stories. Like we're going to ask developers to join us and just talk about the or journeys, in, performance, what they do, little things like that, but we're also gonna do things like, have like like-minded content, for example, we're gonna start a series, soon with the good people at the web Almanac and, more on that little later today. For sure we are going to essentially sort of, handle all things, performance, all things, user experience, which is what we know and know very well. That being said, oh, okay, I see the comments coming in. Yes, that was the Sydney reference thank you very much.
Beyond what you, just heard, which is, again, the fact that we are going to, do a lot more content on this channel. We're also gonna do things like, work with meetups, work with the community, for example, shout-offs to Sege. I don't know if he's in the chat at all, but, if he isn't someone pick him cuz he's late. We’re gonna work with the New York, meetup meet for speed. We're gonna work with the Toronto performance meetup. Hello, that's what I do. And certain events perf-now, hopefully happening later on this year, we're gonna talk about maybe perf-matters if that comes around. And obviously, we are gonna talk about lazy load. That's gonna be later on this year, probably I think mid to late May more details about that soon enough.
Either way. Let’s get back to the crux of the matter. And, today is webpage says live and we're going to have a special guest, but first I wanna get to how we sort of came about to today's episode. So yesterday we had a fantastic blog post. In fact, I'm going to bring that up right now. We had a fantastic blog, post covering sort of, performance and the planet, essentially talking about performance and emissions. And you could actually, if you've not seen it, you could actually go to this link right here and go check it out. An amazing guest blog post from, Fershad. I think I pronounced that correctly. And, it just got me thinking because we had CS a couple weeks ago and Sony had announced, an EV an electric vehicle. Sony, ye of AV who sold TVs are now doing EVs, which I thought was super interesting. But then I sat back and I was like, man, I'm a big fan of automobiles and, I know pat mean in the chat somewhere. He's a fan of automobiles too fast ones, surprise, surprise.
I thought it might interesting to maybe profile some of the, better-known EVs around, so I was like, okay, this would be kind of interesting. And I thought to myself, like, who should I bring along to have this, EV profiling conversation? And I just kind of poked around and I thought to myself, why not reach out to a good friend of mine? And I'm actually going to bring him on stage right now. Bingo. Hey, and here's our surprise guest today, Mr. Paul Calvano, do you know that your mic is off?
(05:19) Paul: I know it's off now.
(05:22) Henri: Okay, there we go I mean. I have to save you there because, I'm the one who had the hot mic for a hot minute and that was, kinda embarrassing, but anyhow, Mr. Paul Calvano thank you. First of all, for, making some time to join us. And, I have to let people know. I reached out to Paul because, I know at the we're in 2022, I guess a couple years ago, I remember you had organized this sort of, kind of like a weekly kind of a meetup where we were, or you were profiling, a lot of sites in and around, the COVID situation. And, I thought that was super interesting. And, I think what that went on for about like four or five weeks we did that, is that correct?
(06:05) Paul: Yeah, It was a lot of fun. I remember one of the weeks we had, a large team from the NHS join and, we got to go through a bunch of their websites and it was a really good time.
(06:18) Henri: Yeah, it was really good. So, I just thought it'd be right for me to ping you and to see if you're available and, I'm super happy that you were so, we're actually going to sit back and, go through some sites with Paul and, in particular, I'll let him name them, in a hot minute, but Paul an amazing engineer, him and, I think met a few years ago at a conference, I wanna say, was it like,
(06:45) Paul: It was the last [Inaudible06:46 ] conference? I think
(06:48) Henri: Which one?
(06:49) Paul: I think it was the last fluent conference.
(06:51) Henri: You are absolutely correct. It was the last fluid conference. It was my first and last fluent, conference, which was, fortunate, but I used to follow it online. But yeah, Paul is a fantastic, engineer. He was also, I mean, I don't say was, but he is also part of the guys of the, web almanac project as well. We'll get into that, a little later but yeah, Paul, did you wanna add anything, that I forgot?
(07:18) Paul: No, I'm just, I'm really happy to be here and, thanks for having me on
(07:23) Henri: Oh, all by means. And by the way, a little shout out, can we get some, clapping emojis, Paul just celebrated 10 years at Akamai. Yay. I mean, that's Big.
(07:35) Paul: Yeah, no, it's, it is. It's a really, really awesome, awesome place to be and I'm having a lot of fun there.
(07:42) Henri: Awesome. Awesome. Awesome. Well, what we'll do is, I believe you should have, I think sharing privileges at this point and, we'll probably just get started.
(07:56) Paul: Cool. Let me go ahead and share my screen. So yeah, when, Andre, reached out to me last night, one of the things that he wanted to do is take a look at, some of the vehicles that were, you can see webpage testing on my screen, right? He wanted to take a look at some of the electric vehicles that were being, announced at CES. And I'm not as much of a car enthusiast as much as Andre so, I know very, very little about it, but, Andre had given me a couple of, a couple of websites that we can look at, Teslas model 3, BMW's IX and, the Rivian.
(08:37) Henri: So, let me, jump in real quick. And, first of all, Paul I know Patrick is hugely disappointed right now that you're not an automobile fan,
(08:48) Paul: You can, you can kick me off if you want
(08:50) Henri: I won't, but I'm sure, Patrick May have some words for you afterward. As, Paul just mentioned, I was like, what are the, the big hot topics in EV and the hot companies? And, I remember again, CES this year, BMW is buzzing for a hot minute as they had this car that was changing color. It was going from black to white. And back again, I thought that was kind of interesting. So I was like, oh, let me look at the BMW, offerings for EV and they have an M series EV, which was kind of surprising. and then, mentioned Rivian simply because, and I think I'm pronouncing this right Rivian, simply because that they'd been buzzing and, they're worth 70 billion and they sold 11 cars last year.
So I was like, Hey, they must be like pretty big. So I threw them into the hat and, I threw in Tesla for obvious reasons. But, what I didn't realize is Tesla 3, the model 3 is one of the best-selling cars on the planet right now, which I had no idea about. And, which I think is pretty impressive. So I was like, let's throw Tesla 3, I mean, model three into the mix. So that was the reasoning behind, those 3 picks. So that said, Mr. Calvano, I'll, I'll let you sort of proceed with your magic.
(10:20) Paul: Sure. So I was actually chatting with a couple of my colleagues about this, this morning. And, Michael Gooding had mentioned to me, wouldn't it be amazing if these, vehicle websites could load in the time that the vehicles can speed up. You know how easy it is to nerds snip me because you do it quite often. and, so I wound up, while we were getting ready for this, I wound up writing query in HDP archive to pull out some of the core web vitals and a few other stats, from the, Chrome user experience report. And so this, SQL query just, extracts a couple of metrics from this, materialized, table that Rick [Inaudible11:03 ] created. And, yeah, what you can see here is that, the Tesla, the P75 or LCP is faster than, going zero to 60, which is pretty incredible.
(11:15) Henri: I mean, we don't want to give Elon another reason to brag now, because that would be crazy on Twitter. ,
(11:24) Paul: All of these sites, the P 75s are really great, the, and, and so forth. It was also interesting to me to see kind of the, let me zoom in on this, because I'm sure it's hard to see. but, so what, was, like really interesting to me is, is seeing kind of the difference in, the percentage of traffic, like BMW, has 52% traffic on desktop, whereas, Rivian is only 35%, and 42% for Tesla. So there's definitely big differences in terms of the mobile density. Rivian seems to be the one that has more mobile traffic than, any of them, but the scores and the, performance numbers, definitely, look, pretty good.
(12:14) Henri: Interesting.
(12:19) Paul: Then, since we're here to talk about webpage tests, what I wanted to do is, pull some of those sites, and just run a webpage test measurement. So I use the default settings, and webpage tests. We’ll look at Tesla first, and do much analysis on this. I just kind of ran the tests, so this is more or less, a live audit. So this particular measurement was run with the default settings. So it's five megabit connection. I ran it from Virginia and EC two on a Chrome desktop browser. You can see the real, user data from crux.
By the way. I'm, almost embarrassed to say that when I wrote that query, I did not realize that the P 75 numbers were actually in this. So like when I came back and I looked at web page test, after I wrote the query, I was just like, really. And that's, one of the things I love about webpage test is that like every once in a while I find a feature that I had no idea existed and it's been there forever. Sometimes I'll ask Tim like, Hey, when was this like, added? And he'll be like two years ago. And I just love how, it's so on top of things and how much of the UIs improved over the years.
so let's take a look at, the Tesla 3 one, and you can see the, first of all, the waterfall, like the number of resources on this waterfall is, really, really small compared to, what you might see on a lot of, a lot of websites. I mean, there's, there's definitely some heavier resources in terms of, large, large images and, large, video files. If we look at the connection view. I often look at the connection view to see like, kinda where we're spending most time. And I think that a lot of websites you'll either find that they're, bound either by CPU like JavaScript third parties, or they're bound by bandwidth. And it looks like, just looking at the sheer amount of media content on this page, that it's, very much, bound by bandwidth. You can also see that in the bandwidth graph here where like, we're, constantly at the five megabit connection that we've defined for this test. So the test is really limited by the bandwidth that we're using to measure it. If I ran this with FIOS it would probably be a lot faster. And, but I ran into sort of five megabit connection, and this is kind of what it looked like.
(14:47) Henri: Very kinda like pedal to the metal the whole time. Oh man. Pardon that pun.
(14:52) Paul: That was good.
(14:52) Henri: How do you even think of it?
(14:58) Paul: Now the green vertical bar here shows the largest contentful paint. So on this particular page load, the largest contentful paint happened in around, four and a half seconds. And the largest content paint happened before the video is loaded, which is nice. One of the things I often do when I'm looking at the site is I'll kind of look at like, what's happening before the page starts to render and what's happening after the page starts to render. Cause these are two, like really, key areas where you can kind of focus on, like if I can optimize what's happening before the page starts to render, then I might actually be able to influence the entire page load. And then the rest of it all comes down to user experience and so forth.
Just kinda looking at some of the, things in the waterfall I can see. So this, the HTML is 374 kilobytes it's compressed. If I look at my response headers, I can see that it's using Gzip compression. Looks like there are some headers here that, provide some indication of what's going on at the origin. So it looks like they have some cashing at the origin and they're cashing their HTML for 10 seconds as well, which is nice. So they're doing they're caching the HTML in the browser, but it's like a very quick revalidation if user is refreshing. They're, most likely gonna do a revalidate and not download the full 374 kilobytes,
(16:21) Henri: Which site is this, by the way?
(16:23) Paul: This is Tesla.
(16:24) Henri: This is Tesla. Now, did I just see that Tesla's on Droople am I dreaming?
(16:30) Paul: That's what the headers say?
(16:33) Amazing okay tesla, modern cars.
(16:38) Paul: Yep. Okay. So looking so I can see that, three critical CSS resources, and then it just starts downloading images right away. Right. And the first image that gets loaded this, hero image here, so model 3, hero a desktop. If we take a look at the response headers for this, I can see that, it's a JPEG image, its 352 kilobytes. If you look at a couple of the other images, I can see, for some of the images, they're using ABIF as well, which is really, really nice. So, you could see that they're using, they're using modern image formats.
the one thing that I was a little bit concerned about with this particular image, the very first image that was loaded is that if we look at the actual image, it's the, it's not the first image that's on the page. So it looks like the, and we can kind of dig it to dev tools to figure out where this image is being loaded., but it looks like they might be preloading the image or, or, maybe doing a hint to load the image earlier. But the first image that actually loads on that page is this one here.
(17:50) Henri: Yeah. Interesting where
(17:52) Paul: The first image that should load is, that hero image in my opinion, and that's, that's actually over here. So it loads, pretty late.
(18:03) Absolutely By the way, for everyone watching. And, if you feel like sharing some of these findings on Twitter, let me just gimme a quick second here. Let me go back here, banners, by all means, tag us in a tweet at the real webpage test or end, use hashtag WPT live. So I could, potentially, keep track of it, afterwards, but, there's some very interesting stuff here. So I just love that it's a Droople site using AVIF like talk about the extremes there, like not modern and cutting edge at the same time. NASA is also on Droople. Okay. Well, maybe someone will wanna fly with NASA now.
(18:57) Paul: I noticed that Mike Michael Gooding wrote in the chat that too many of these car puns are gonna get exhausting.
(19:03) Henri: Michael, whoops, wrong one. Where is he here? Michael. Michael, I saw you somewhere. There we go. Yes. That might be the case, so, thanks for joining Michael been a minute. But, again, but getting back to what Paul just mentioned there, like, I talk about the investigative nature of, performance profiling and, you start to see these, I don't say it's bizarre behavior, but they're loading a, image that is not being used, as a hero image. And, the hero image is, way down the chain in terms of loading orders. So again, these are the things, these are the discoveries that you'll make once you start to dig through the- In webpage test and understand like, Hey, this might need to be bumped a little, a few notches, to hopefully improve the user experience and, load times, et cetera, et cetera.
(20:10) Paul: So one of the things I wanna do is I wanna try to fit figure out where that image is being loaded. So I, I copied just the URL for that image, just the file name for the image. And I loaded the page in Chrome and I'm, now filtering by dev tools. So I can see the image loading over here. I can see, so I can see all the details on the image, and I can also see the, initiator, so I can see exactly where that image was loaded from. I’m gonna go ahead and click on the initiator to see where that image is. And so we can maybe get an idea of why that image could have loaded so early.
So this, this image was loaded, in a, picture element. From the looks of it, it looks like it should have loaded, much later than some of the other images, because, if we take a look at the, headers, I wonder if it's, pre-loaded. we can also take a look in the, chat Adam during the, we can also take a look, to see if there's, pre-loads in HTML and there aren't, let's actually go back to the response headers and see if, they have any pre-loads or pre-fetches in here. And I don't see one, so it's really interesting that like, that image might, and if anybody sees it on the chat and can figure out why that image happens to be loading first when it's like so late in the HTML, that would be interesting to me, but, yeah, , I definitely see there, there being some benefit to lazy loading, on this site, like, it's not doing lazy loading, but if it was this image probably wouldn't have been loaded so earlier, and, this one may have popped first.
(22:00) Henri: And, a quick mention, my man Mr. Hersel, I'm not badmouthing Droople, I'm just having a little bit of fun, but, maybe I'll reach out and we could do some, Droople profiling. So, we could talk about that offline didn’t wanna interrupt, but proceeds, please.
(22:24) Paul: Looks like pat wrote in the comments that the separate origins, so it doesn't get prioritized against, the images on the main origin. I'm still not sure why that cuz both of these images are on that, separate origin. They're both on Teslacdm.dot com. So I'm just still not sure why, one will be fetched much later.
(22:45) Henri: So Mr. Meaning chimed in the main hero image is a background image that doesn't get discovered until layout, which is why it loads so late preload could help it loads sooner.
(22:56) Paul: Cool. Thank you.
(22:57) Henri: Merci, Mr. Meaning, vroom, vroom.
(23:01) Paul: Vroom, vroom Alrighty. Another thing I noticed here is the fonts that are loading. So the fonts are loaded on a separate domain. So it's CDN-design.tesla.com they're using WAF2 which is good or WAF2 is, I think if you're, probably one of the better font formats to use, because it's Brotli compressed, and they only have three fonts or actually four fonts. Some of these, we can take a look at some of the sizes of these. We got 59 Kilobytes, some 58 kilobytes, seven kilobytes, and so forth. I always get a little bit concerned when I see the fonts loading before the page starts to render because it makes me think that the fonts might be blocking. I think the best way to determine that is to look and see how the font is actually, how the font is actually loading. So if we go back into dev tools, I'm gonna just find the fonts, and look at the initiator for those. And we'll take a look at the CSS where the font is defined
And sometimes that works okay. Let's go and search for the font file made. There you go. So it looks like they are using a font-display swap. So it's, good. So it may just be a coincidence that the largest content will paint and, pop and select these fonts were loaded because, the fonts are not required for rendering the page. Let's see, what else do we have here? We do have a couple of large videos. The, videos are loaded later in the page, which is nice. In some sites where I see the video loading, a lot earlier, you wind up being in a situation where the video bites could sometimes compete with, the rest of the resources for bandwidth. So it looks like they're, they're doing a good job of, not doing that. And still a lot of these images. I think the images are really what's pushing out the low tide here. So lazy loading would probably be a great improvement for them in terms of, performance.
(25:30) Henri: Yeah. And, I've always felt like some of these sites were very, great examples of sort of, resource management just because of the nature of their business, like you have to see how amazing the interior on the Tesla is, X, Y, and Z. And I'm always kind of curious to see how individual companies go about this business of, of making sure, hopefully, of looking after a good user experience and performance, right?
(25:59) Paul: Yep. Looking at the three large JavaScript files I see here they're loaded or, so line number 11, this script, is 230 kilobytes compressed. And if we take a look at the response headers, we can see how it was compressed. So this was Gzip compressed.
(26:28) Henri: Hmm, Interesting.
(26:29) Paul: One of the things I like to do with, especially the largest, text resource on a page is try to get an idea of how much Brotli compression would help out. There's a tool that I wrote a while ago that, will take a URL and it just runs a curl request, [inaudible26:54 ] and then it, runs broad and Gzip compression against the uncompressed resource to just see how much smaller it can be. And so what I can see here is that this resource was served with Brotli compression level nine. So they, set up the compression level as high as it will go., which is nice. that's where they got, from 800 kilobyte file, 236 kilobyte, response payload they went to [inaudible27:18 ] compression level 11 on this. They could actually shave off in that 25%, more so that, 236 kilobyte resource could go down to 177. Between that and the lazy loading, I think would probably be, some of the biggest, things Tesla could do
(27:39) Henri: Yes. and it was funny because, the few times you did sort of, bring out, compression and, I hadn't seen anything Brotli related and I was like, okay, I mean, there's not wrong with Gzip but it is 2022. I thought I'd see, Brotli being, mentioned a tad more. Is it possible that you share that, tool, URL in the chat
(28:04) Paul: Sure I'm going to do that right now?
(28:06) Henri: That'd be awesome. So we can just kind of flash that out. And for those I'm, I’m, sure we are surrounded by, some amazing and well learned, performance folks in here, but, for those who may, watch the video afterwards, you may ask yourself, well, why is it not on 11? Well, there's always a bit of a trade-off. For those who don't know, you can go with the heavy compression and, the music as loud as possible, but at some point you do want some, some like speed in its processing of the files. So like, yeah you could have it on 11, but the compression might take a little longer and these things tend to sort of, oh, there we go.
(28:55) Paul: I created this tool back in 2018, I had, done some research using, squash. So squash has a bunch of, compression benchmarks that you can download. And, so I just visualized some of the data that they were presenting. And one of the things that you can see here is that with Gzip compression, the compression speed go goes down with every compression level, the decompression speed remains pretty constant. And Gzip compression level six is pretty much the default on most servers, with the exception of, engine X, that the default is one. Yeah. So if you use engine X check your Gzip compression levels, because you might be doing yourself a disservice, if you have the default, but Gzip compression level six is the default for Apache and, a few of the others. I think it's the default for IOS that could be wrong.
If you look at the compression ratio between Gzip level six and Gzip level nine, there's not a whole lot of, reduction so really using anything between six and nine is probably fine. Six if, you are using dynamic content. Nine, if you're pre-compressing, I think is probably appropriate. When you look at Brotli, you can see kind of the same, the same, the same distribution once compression speeds. And so Brotli compression level one generates a much larger payload than, than even Gzip level nine, but it's a lot faster. And, with every compression level, it gets, slower and slower, and slower compression ratio gets higher. Yeah.
Now, if you look at what you could do with Gzip compression level six at 3.15. Your compression ratio is gonna be higher at almost any of the Brotli compression ones. Because, 35, megabit per second compression speed is gonna be more comparable to Brotli compression level five. So if you're serving HTML Brotli compressed, I would do it with Brotli compression level five. If you're serving pre static resources like JavaScript and CSS, and, and like the compression time is not gonna impact the user. Then I would go to Brotli compression level 11, which is 50 times slower than Gzip40 times slower than Gzip. So it's considerably slower to pre compress the these, but if it's not impacting the user, then it's, just time spent elsewhere
(31:27) Henri: Insights. Amazing. I think I remember this blog post as well, actually, because the minute you, brought it, back up, I was like, oh, I totally remember this. And that's probably where I remember this sort of, trade-off, conversation I just had. So thank you very much for that. Did you wanna, drop that link to that, blog post?
(31:46) Paul: No, I think there's actually more recent, research in the Almanac. So the Almanac has a compression chapter. so I'll drop that link in there as well, because, the, so this was, pretty good deep dive into how sites are compressing text-based resources, and it also goes into some of those recommendations for, compression levels that are recommended for dynamic versus static.
(32:22) Henri: Awesome. That's awesome. And we're definitely gonna get, as, I mentioned at the start of the, program, I guess we're gonna further some conversations with the good people at the H E B archive, Web Almanac. And, I'll get into the details at the end of the show. I keep saying this at the end of the show at the end of the stream. And, but yeah, I mean, that's awesome, documentation right there that, I'll make a note of and maybe, bring in the author.
(32:58) Paul: Cool. Awesome. One of the things that I was very impressed with here is just the limited number of third parties. There's seven third parties here, Google analytics, double click, it's, really, really impressive that, it's just this small of a list
(33:22) Henri: That is very unusual. Who was talking about this just recently. I forget who, but they're just talking about third parties and, it's kinda like you just have to manage them. That's pretty much it, shout out to Zach Toman who, sort of used to talk about that, back in the day when he had done, some talks, with Conde Nast and just saying like, he wasn't going to be able to pull them out. His conversation was more about managing their effect.
(33:56) Paul: Yeah. Yeah, so that's, why don't we move on to one of the other sites? So who do you wanna do? BMW or Rivian?
(34:06) Henri: Let's go BMW. I was actually very shocked that they have an M series EV like, what is going on there.
(34:15) Paul: I don't know what any of that means, but,
(34:19) Henri: It's all good.
(34:21) Paul: So in this case, you can see that the, the real user data from crux is showing that the P75 for LCP is, a bit slower. for 1, I think that this view, is based on the URL, not, not based on the overall domain, if someone can correct me if I'm wrong on that, I think Barry wrote a blog post about it, so he probably will correct me if I'm wrong.,
(34:51) Henri: I'll wait for tune the web to chime in.
(34:56) Paul: So with BMW, I can see, a ton of small CSS resources. And if we take a look at some of these resources, you, you can see like 0.8 kilobytes, actually 2 kilobytes, 0.13 kilobytes, like really, really small. So it looks like they're not doing bundling of these resources. And one of the things that you might say, Hey, 0.3 kilobytes is nothing why are we even like, worrying about this? The browser spent 2.2 kilobytes of data to request 0.3 kilobytes of response. There's definitely a bit of, waste going on here.
(35:42) Henri: Do the math folks do the math.
(35:46 Paul: Now, the other thing is like, when you think of the way that, compression, algorithms work by like building dictionaries and then using those dictionaries to compress resources, and it's probably very primitive explanation of how a compression algorithm works, but the more bites you have to compress the better your compression ratio is gonna be. And that's, that's why, like, you sometimes you'll see that like HTML compresses better than JavaScript and CSS compresses better than JavaScript. And it's really because of the repetition, when you have a small resource like this, right, this unimpressed size of 0.8 was compressed to 0.3. And so it was maybe a 60% compression ratio. Where with like some of the larger files, you might see 80 or 90% reduction in, in file aisle size.
Now the 0.5 kilobytes means nothing. But if you sum all of this up and compare the amount of bytes received for all of the resources, on this, like all of the CSS resources and compare that to bundling it all together and then compressing it, you might find that there's some bite savings to be made by doing that. And there's definitely, probably , some, bite savings along the wire for the request, payloads as well.
(37:13) Henri: Yeah. cause at first I was like, man, why all these little requests, and I realized they're on H2, but, as Mr. Meaning would, probably remind me, and I'm not sure, but, they may not be on a tuned server, and, who knows what's taking place there after, but Wow.
(37:36) Paul: There's often this almost kind of see it like a tug of war between like people saying compress these resources, and I'm sorry, like bundle of these resources together because you have a smaller payload and less to transfer, and then unbundle this because you're creating such a large payload that it's wasteful right. It’s kind of hard to get that balance bundling is beneficial, but if you bundle everything and you've got like an e-commerce website, that's got all your checkout, JavaScript being loaded on your homepage, you're probably doing a disservice to that first view. It might be better later on, but you gotta hope they get there.
So there's definitely a balance. I think that like, sometimes a lot of times I'll see like this in both, extremes, right. You've either got a lot of really, really small resources and no bundling, or you've got large payload and bundling, I don't think there's really any great tools out there. It's, really just kinda doing the work to figure out, the proper bundles and like what's being used. Dev tools have, like a really great feature that, gives you, some insight into your code coverage. So you can see like what resources are being used. Yeah. That could help a developer, that.
(38:53) Henri: Has some insights and, know what's, quote-unquote wasteful and what not as being sort of parsed for no reason.
(39:02) Paul: Yeah. And we can actually do that over here. So I'm gonna pull up the BMW web page and just, click the record button on this, code coverage feature. And we can see how much of the, bytes are used on this page. And it seems like it's quite a bit like the JavaScript, WDTM is mostly unused, but then, Brightcove is mostly unused probably cause I didn't scroll that into view and then a lot of these CSS files are, pretty small. It’s, how much of them are unused? I think a lot of the CSS is not, not being utilized so bundling it would probably, make that even more evident in a tool like this because you might see that, but there's, I think that there's some, some cleanup work that could probably be done.
(39:48) Henri: Yep, yep, yep. Yep. And again, some testing essentially, to see what comes of it and, and what the doesn't. Yep. It's quite the waterfall.
(40:02) Paul: It is quite the waterfall. One of the features I really like about webpage test, is the ability to customize the waterfall cause I mentioned that like one of the first things I always do is try to figure out what's going on, during that critical rendering path and like what's happening before the page starts to render, and in this case that's like 10% of this waterfall. So it's really, really hard to kind of make sense of like, what's, slowing things down here other than things we've already mentioned. And there may not be anything other than that, that we see here, but I love this little feature that this is probably one of those things that you can use web page test every day and not know what's there. So, definitely take note of this.
You can set a maximum time, so I'm gonna set a maximum time for one second and now I can see the waterfall graph, updated and I can see actually what's going on here. And what's, interesting here is that you see a bunch of these resources, loading before the first byte HTML. And I believe this is, either preloaded server push. We can, go and take a look in the waterfall to see what's going on here, but they're, they're definitely loading some of the critical CSS and JavaScript early. So let's actually go up here and take a look at the response header for the base HTML.
So what I can see here is they've got, pre-loading for fonts, so they're, pre-loading their fonts. And then they've got, pre connect headers for, this doesn't look like they're, pre-loading, at least in the, response header, some of those CSS files, maybe you might see that elsewhere. It's interesting that these are, it does say that this JavaScript is server pushed though. There we go. So hat would explain it. So H2 server push is pushing these resources early, and then they're also using preload to preload the fonts, which is why these, resources are the first ones that get loaded on the page.
(41:53) Henri: Let me just mention something here. If you go to the LCP view, it will trim the waterfall to the LCP.
(42:04) Paul: Can you say that again?
(42:07) Henri: Yeah, just mention, I don't know if you can see it on your screen at all, but if you go to the LCP view, it will trim the waterfall to the LCP.
(42:15) Paul: How do you do that?
(42:19) Henri: And, hold on. Oh, here, I'm thinking I'm controlling the screen LCP view. I don't see it right away.
(42:31) Paul: if you go to the LCP, so are, are you saying, going in to the web vitals dashboard,
(42:38) Henri: Main results page, click LCP. There we go.
(42:44) Paul: There we go. Well actually, which one was, click LCP
(42:49) Henri: There it is.
(42:53) Paul: The LCP is still, about eight seconds here.
(42:59) Henri: Wow. This waterfall is amazing.
(43:02) Paul: There's definitely a lot going on here. Now you can see the, pre-connected action over here. So it looks like SP curve, and, and, Adobe DTM reconnect was setting up that connection early so that when the browser needed to make those requests, it just fires off the HTTP Request.
(43:27) Henri: Yeah. Just sat there on its own. You're like, Hey, what's going on here?
(43:32) Paul: Yeah.
(43:35) Henri: Hmm. are sort of, unusual, well, interesting, I shouldn't say unusual but interesting findings, from, the great German company.
(43:46) Paul: I don't know. I'm looking, let me get back to.
(43:50) Henri: Well, look at that LCP image. Amazing.
(43:56) Paul: And so they definitely, if we look at the connection view, you can see, well, first of all, there's a lot more third parties here. We can also see, there's definitely ‘ots of images, but also, some of these third parties are loading before that unload event fires. The LCP event happens over here. Now that LCP image was loaded before it became visible, on the page. So, that may be something for them to investigate as well is. Potentially what JavaScript or, third party resources could be blocking the rendering of that resource, maybe they're fetching a resource with JavaScript, or maybe they've fetched the resource and they're holding it back. And so the other JS modes executes, hard to say for sure, but, but yeah, there's definitely some work to do here.
(44:57) Henri: Nice, nice, nice. Again, the investigative nature of the work, and you start to find little unusual, bits of behavior from, your resources.
(45:10) Paul: Yep.
(45:12) Henri: Cool. So that's BMW. We looked at Tesla who's last, I think. Oh,
(45:20) Paul: Rivian is last I also had the CES web page second look at Rivian. Now you notice that on all these websites, there's, large videos. And the load times are very, very heavily impacted by these videos as well. So the metric that you're using to measure, becomes very important here because if you're looking at largest contentful paints. I've got a one-second page load time. Right. But if I'm looking at the unload time it's around 25 seconds. So this is a huge discrepancy here.
What's actually, meaningful here is, the largest contentful paint, really indicative of what that user experienced to do that, I would, would typically go and look in the film strip and try to get an idea of, what's actually going on during, each of these milestones. So once we hit that 1.5 seconds. so this was the largest contentful paint, and it looks like the largest contentful paint wasn't even-- let me actually change this to 0.1 seconds, just so that we can see, but the largest contentful paint was actually this background. Wow. And not the actual,
(46:35) Henri: Not the actual Image,
(46:38) Paul: And then, yeah, that's really, really interesting I mean, it was a second later that the, actual largest contentful paint was displayed, but, yeah that's, that's interesting. I don't know what might have caused that to pop earlier.
(46:56) Henri: And that actually might even be a carousel. I remember poking around yesterday and I was like, man, I think this is a carousel, but either way.
(47:02) Paul: I hope this isn't the first image in the carousel
(47:06) Henri: Like in my head, I'm just kind of like thinking, thinking, because I remember I was like really poking around the page yesterday. I was like, what is going on here now? But interesting finding again, numbers don't lie.
(47:19) Paul: They've got some really large JavaScript over here. And it looks like with the H2 prioritization the images are still kind of getting priority over the JavaScript, which is really, really interesting. And I think, maybe because it's on separate domains, as Pat mentioned before, we've got media.eivian.net and Rivian.com. So it's two separate domain names that had their own priorities. But because of that, you wind up having, the images in the JavaScript competing. It might make sense to collapse these into a single domain name or at least coalesce them onto a single connection.
(47:56) Henri: Wow. Okay Rivian if they spend as much time on the website, as they did go ahead,
(48:08) Paul: 2.3 kilobytes, 2.3 megabytes of uncompressed JavaScript is nasty.
(48:17) Henri: Don't get Alex Russell in here., this whole stream will explode, shout outs, Mr. Russell, Microsoft's finest.
(48:30) Paul: All righty. Curious to see how much, so what, Brotli level they're using or what Gzip level they're using, as well. This is Gzip compressed. Let's actually run that through the tool as well and see what happens.
(48:50) Henri: Two megs of JavaScript. That's stunning.
(48:56) Paul: Yeah.
(49:06) Henri: Again, I just thought it'd be an interesting look because they're getting so much buzz and attention.
(49:13) Paul: So this one is interesting. They, they are Brotli compressing the resource to Brotli level five. So they've Gzip compressed it to Gzip level seven, probably it's either Gzip six or seven it's really close. But Brotli compression level looks like it's around five. If they went to Brotli compression level, 11, it could shave off like another 70 kilobytes. What it was interesting to me is that when we loaded this image in webpage test, it didn't actually return the Brotli compressed resource. Maybe it just wasn't compressed in time or, maybe it was, was it a cache hit? Yeah, it looks like it was a cache hit, so, yeah, it's interesting. I'm not sure why that wasn't served Brotli compressed, but it looks like the server at least is capable of sending it Brotli compressed and, it's Brotli compressing it to Brotli level five. I'm guessing it's doing a real-time compression as a result of that, to try and it's probably using Brotli level five in order to, avoid impacting the user with the higher level.
(50:21) Henri: Yeah. And slower times. Wow. Okay,
(50:27) Paul: Cool. I know we're almost at time. Did you have any direction you wanted me to focus on or did you wanna,
(50:33) Henri: like I said, I think this was mostly sort of like an exercise and sort of like poking around, see what, is actually in there that we can, sort of pick up investigate and, and see what looks, potentially unusual. But, yeah, I mean, that was like, there were some for sure, interesting findings here without a doubt. And mean, I think you'd mentioned there was something else that you may have wanted to take a quick Gander at, or was I sort of dreaming?
(51:07) Paul: No, I don't think there was.
(51:12) Henri: Yeah. Yeah. Awesome. Well, again, I get back to, comments I've made on Twitter before, and, I've said it live tonight today, pardon me a couple times is that, what we love, in this space is that, we can actually look at requests, individually and see exactly what's going on and, what resources are, coming in early, coming in too late, aren't compressed, properly, potentially, little mistakes that are made along the way, that are, pushed up right to production. And these aren't big deals, but we're just here to sort of like find out, and that's really it. And that's what we do at webpage test let's go.
That being said, Mr. Calvano, first of all, thank you very much for your time. I do realize that this was a bit of a last-second request, for you to come in and fill in some shoes. But I'm one who's, always appreciated your acumen in this space. So I do wanna thank you for coming in, and filling in that spot. Now for everyone out there, if you're not following Paul, I think you absolutely should be, you're not living right. So his, Twitter handle is there, @PaulCalvano. He has amazing, content on his blog. He’s also written some fantastic pieces over at the HP archive, in the, discussion page, which actually brings me back to, the point I want to make.
Now, I spoke about, working with the good people at HA shout out, Rick, and, where is he here? I know he is around here somewhere, shout out to, Barry who's somewhere in the chat. We're going to be doing a series of conversations with them as well. Talking about the web almanac, some of the data that we pulled out today in the conversation around compression and, subsequently throughout, the next two, three months, we're gonna have like these sort of AMAs with, some of their contributors. speaking of AMA, I also wanted to mention that, we are going to have believe it or not a webpage test AMA with, members of the webpage test team, and that's gonna be taking place sometime early February. So look out for that. we're gonna be announcing it through our Twitter handle Twitter page @realwebpagetest. I'll be mentioning it as, mentioning it as well at, my Twitter handle, which is @HenriHelvitica.
And that's going to be, a super event because we're able to talk about, everything webpage test, you'll be able to meet some of the members of the team. And, we'll sort of like fill you in, on some of our plans as well. What else did I wanna talk about? Oh, first of all. Our next live is going to be January 14th, 27th. So make sure to come back for that, maybe some more prizes, speaking of surprises, if you ever wanna be on, let us know, ping us on Twitter, ping me on Twitter. we're definitely going to have more guests, talk about more things, Mr. Hershel, maybe we'll, talk, Droople how to make performant Droople and we'll also about your 49 inch, ultra-wide monitor. I mean, I wanna make sure that you're still good with that.
Oh, shout out to my man, Jason, in the building, let's go Netlify and, what else did I wanna talk about, oh, please give us a follow @realwebpagetest. We’re gonna be your best Twitter neighbor rest assured. If you are into the performance space, we are going to have a lot of, content for you in the months coming. And I think that's all I want to talk about. Yeah, I think that's it. So once again, everyone, thank you very much for joining us today. That was a lot of fun. I hope you caught most of it, if not all, beyond that, we're actually going to get the recording edited and we'll get it back up, hopefully, maybe next week. And, you'll be able to sort of go back and parse some of this, information that, Paul Calvano was so nice to, bless us with.
And with that, I think there's like another 40 seconds, Paul, did you have anything to share?
(55:41) Paul: Nope.
(55:43) Henri: Oh, come on, man. Ye back mile, let's go. You, you must have some gems. You must have some gems to share.
(55:52) Paul: in 40 seconds right, No pressure. Well, thank you. So thank you so much for having me on this was a lot of fun. Oh, thank you very much.
(55:57) Henri: And, last thing I am gonna mention, if you have never used, webpage test in your life, there's no better time than the present. Let me go back and get into my banners, cuz this is amazing right here. Bingo. Go check it out, get yourself an account. We’ll be talking about, some of these details as well at the webpage test AMA it's gonna be a lot of fun, and yeah, just give us a follow. And that being said merci beaucoup thank you very much for joining us and we'll catch you in a few weeks. Cheers.
