518: WebPageTest Improvements, Shopify Hydrogen, and is .CSS a Bad Idea?
WebPageTest adds Opportunities and Experiments, but is it worth it? Shopify announces Hydrogen, a framework for dynamic commerce, is .CSS a bad idea? And using the new INP metric.
Guests
Chris Coyier and Dave Rupert
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert. With me is Chris Coyier. Hey, Chris. How are you doing today?
Chris Coyier: Hey! I'm doing pretty good.
Dave: Boy, it has been. We are catapulting our way into summer 2022 here. It's good. It's heating up in Austin, Texas. I'm sure Bend is just perfect weather, so there you go.
Chris: Yeah, it's been cold but doable.
Dave: Cold.
Chris: It's coming. It's coming. It's coming. It's all good. I feel pretty good for the most part.
Did you see this? You know we have friends at--
Dave: I have. I mean--
Chris: I mean, yeah. Let's call them acquaintances. We have a bunch of people that we know who ended up over at -- I don't know what you call the parent -- Catchpoint is the parent company who make, who bought, I think, WebPageTest from kind of a solo-entrepreneur guy. I forgot his name.
Dave: Mm-hmm.
Chris: But it was like, "This is such an important tool in the world of performance testing," but it didn't have a business model, I don't think. It was just like, "Here's this expensive thing."
I think there were some fables, like, "He ran the thing out of his basement," or whatever. [Laughter]
Dave: Yeah. Patrick Meenan, I think, was the guy. And you had to email him for an API key. I do remember that. [Laughter] I have emailed him before.
Chris: Right.
Dave: But it was like, yeah, he was running -- he has phones in his mom's basement -- you know -- [laughter] in North Carolina that you could connect to - or something. But he kind of built these device labs. I think they were actual device labs that you would then queue up to run your tests on. But that didn't really scale, so I think they joined forces with Catchpoint here. They've been--
Chris: like a long time later. You know?
Dave: Yeah.
Chris: Like a decade later or something. Yeah, I think Catchpoint saw, "Hey, this is--" and acquisitions happen all the time. I'm aware of it.
Sometimes you do it just for goodwill or capturing some customers. Who knows how many email addresses WebPageTest had. Maybe you can convert some of them to some other kind of paid product or something. I don't know what the details of the acquisition were, but they saw something and bought it.
Then you're like, okay, interesting. Now, what's going to happen? What's WebPageTest plus money? [Laughter] You know?
Dave: Mm-hmm. Yeah. Yeah.
Chris: It turns out they were able to redesign it, which is kind of like a dream redesign project, I remember. Kind of like Google Fonts. You know? It's like this incredibly important product that just sucked to use. [Laughter]
Dave: Right.
Chris: Somebody got to redesign it and came out. The same kind of thing here. WebPageTest used to just be very bad, let's say, from a visual design perspective.
Dave: Well, yeah.
Chris: Yeah.
Dave: Well, a few Web1 flavors in there. It was -- you know -- it hurt, but it did its job. I think that's the testament to it is you click the "Test My Website" button and it gave you a good test, like very thorough results.
Chris: Yeah, exactly. I wouldn't say that the design was bad because design is allowing people to get done the task they need to get done, and it did that, right?
Dave: Right. Right.
Chris: Just from an esthetic thing, probably some UX fails in there. I don't know. But it got the redesign, so congratulations to the team over there. Got the redesign out looking a lot better. You know?
Dave: Mm-hmm. Mm-hmm.
Chris: Now there's momentum. You know? Once you've shipped it, now you can continue shipping and iterating and stuff. I'm sure that feels really good.
But I just wanted to shout out to them because they had a big release just yesterday. As we record, it'll be maybe a week old as you're hearing this. They released this thing called Opportunities and Experiments. It looked like you were pretty excited about it too. I know, internally, they were just over the moon about this kind of thing. But it really does change the ballgame of performance testing a little bit in that you can run a test and then it will, first of all, give you actual advice. It won't just say, like, point at something and be like, "That's bad." It gives you this opportunity to be like, "Well, but what would it be like if you fixed it?"
Dave: Yeah.
Chris: And so, that's kind of huge, I think.
Dave: Yeah. It starts off, I think, with three questions: Is it quick: yes, no, needs improvement? Is it usable: yes, no, needs improvement? And is it resilient? If something goes down, would it still stay up?
Yeah, and so now you can go in. This is under their Pro plan, so it costs money a month.
Chris: Well, there you go.
Dave: I think it's $180, which sounds -- if I'm candid, it sounds like a lot. But then if I'm thinking about or I know how much performance can mean in actual dollars in sales, it does not sound like a lot for the company to have a really good monitoring on that. You know?
But the cool thing is it'll tell you your problems and it'll say, "Do you want to just try to fix this problem?" I asked Scott how it worked, Scott Jehl, a performance--
What would you call him, a performance guru, Scott Jehl?
Chris: He certainly cares a lot about performance, but he cares a lot about the Web, period. You know?
Dave: Yeah. But I was like, "Is this just running edge workers and it's reformatting your page? It's yonking your style tags up to the head, and is that solving it?"
He was like, "Basically, yeah. That's what it's doing." It goes and it grabs all your stuff.
Chris: It makes the transformations and then tests it with the transformations in place, right?
Dave: Makes the transformations and then tests that after the worker has processed it. And I'm just like, that's so cool because, right now, to test a performance fix, you have to run some baseline tests. You have to make the fix. You have to redo your build Webpack to shimmy the service worker in the right place, and you have the right workbox blah-blah-blah. Then you go through.
You do all this build stuff, and then you deploy it, and then you need to get it on preview branch. And then you need to make sure that preview branch is running the same dang hardware as the production branch. Then--
Chris: Yeah.
Dave: Then you can run the performance test and see if it made a difference. That's hard to do. But I think seeing this happen on the edge, no code, you just click a button, boom, you're building differently. [Laughter] That's great.
Chris: Yeah, it's a lot of work just to run a thing that, although, usually, it's like if you're going to do performance work, it's not total guesswork. Chances are that's going to land in master because you're doing something that obviously makes your website faster.
Dave: Right. Right. You've figured out or you have the right recommendations to do it, but it's like how fast would this run. I don't know if this is one that they have, but how fast would this run if I was actually using AVIF, if I had an AVIF WebP JPEG PNG image process.
Chris: Right.
Dave: How fast would it be? Maybe they can just show you.
Chris: It'll just tell you. Yeah. That's pretty cool. You know if the work is worth it or not.
For example, I was looking at the results of a thing, and it was like there are 15 render blocking scripts. Wow! You know?
Dave: Yeah.
Chris: That's a good amount. It seems so bad. It's not great. But then it runs the test and is like, okay, first render on slow 3G mobile. It was 4.5 seconds or 5 seconds - or something. Then let's say all 15 scripts you made not render blocking. Then it was like 4.2 seconds - or something.
Dave: Mm-hmm.
Chris: It's just like, meh. You know? [Laughter]
Dave: Right.
Chris: It wasn't that bad, so it can teach you both ways. It can show you, "Okay, this is really worth the work." In this case, it probably was because I think the way that it was making them non-render blocking was to put the defer attribute on it, so that's what you're talking about is a worker. Right? It grabs the HTML, finds those 15 scripts, chucks the defer attribute on it, then runs the test on that HTML.
Dave: Yeah.
Chris: It made a difference but, to me, it wasn't like, "Eh, I'm going to run some different tests, actually, to see if I can find something a little juicier than that."
Dave: Yeah, but you know there is sometimes you put defer on the wrong one and, suddenly, your app doesn't load until way super late.
Chris: Yeah.
Dave: You have to--
Chris: Test that too. Make sure it comes up and the features are still there.
Dave: I think of critical CSS. Critical CSS is one of the biggest bangs for your buck. Right? The first payload, you get a paint. Right?
Chris: Yeah.
Dave: It says, "I have CSS. I can paint the page." It's a very huge improvement in page speed and performance. But it's a lot of effort to do, get up and running per template, per page, per everything. It's a lot of work to get up and do. But if I could click a button and see I'm going to shave ten seconds off my page load if I just do critical CSS, well, boy howdy, I'm like, that's cool.
And even just like, let's click all the buttons. Let's just yeet it. Click all the buttons. What if we did all this performance work? How fast would the page be?
Chris: Right.
Dave: Then from there, you have your milliseconds. I think it's -- wasn't there an Amazon quote? Every 100 milliseconds is 1% of revenue. You know?
Chris: Yeah. You sell enough widgets, it's worth money.
Dave: So, let's say I shaved one second off. That's 10% more money. If I shave 10 seconds off, that's 100% more money. You know? Maybe that's where you should put your money credits, your development credits. Maybe that's the biggest way. You don't have to actually build a new feature. You just have to fix how you load your website.
Chris: Hmm. Juicy. I like that we can test it way faster because it changes your brain a little bit because if you're in the mood to do some performance work and you need, for some reason, you're like, "Oh, I'm going to use that," because then I can just test a bunch of stuff and just see what's worth it and what's not and stuff. A really clever product.
It may be the first of its kind in some respects, but I do think of dev tools allows you to persist changes between loads to some degree, right?
Dave: Mm-hmm.
Chris: You can do little baby versions of this right within dev tools, but it's probably not giving you the full, massive output. Nor could you probably run Lighthouse on your persisted changes, so you don't even get that.
Dave: Mm-hmm. Yeah.
Chris: But you can get stuff like - I don't know - how many resources are being loaded and what's the total size of stuff.
Dave: Lighthouse gives you recommendation that I think this kind of gets, but it can perform those recommendations, which is just cool. It's like, "Hey, you have a lot of -- you have 15 CSS tags and that's really bad." [Laughter] Link rel blocks the page from loading, so please don't. Or add the preload. What's the new lazy loading syntax? Maybe you could add some of those.
Chris: Oh, there is one, isn't it? I mean there's loading lazy, but isn't there some new one, too?
Dave: It's link rel preload as style - or something like that. And so, it'll preload it and then convert it into a style tag when it works. I don't know what the browser support is for that, but I'm into it. I like it, but I don't know.
I think I tried to use it and I just ended up doing the on error this dot rel equals, or on success or whatever - on load. Then you'd flip it. The old Scott Jehl trick. Yeah.
Chris: Speaking of Scott Jehl, huh.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by another podcast, another podcast that just so happens to be even a little bit older than ShopTalk Show, and we've been here for ten years.
For over a dozen years, the Stack Overflow podcast has been exploring what it means to be a developer and how the art and practice of software programming is changing our world. From COBOL to containers, from Rails to React, the Stack Overflow podcast is the best place to learn what's happening in the world of software development.
Each week, you'll hear from working developers and leaders from top technology companies hosted by Ben Popper, Cassidy Williams, Matt Kiernander, and Ceora Ford. The Stack Overflow podcast is your home for all things code. New episodes twice a week wherever you get your podcasts.
Thanks for the support.
[Banjo music stops]
Chris: Um... You mention critical CSS being a bang for your buck, which is literally true.
Dave: It's a lot of bucks though. [Laughter] A lot of bang, a lot of bucks.
Chris: Yeah, I mean it kind of depends, right? Do you have some really clear tooling that allows it? Maybe.
Dave: Mm-hmm.
Chris: If you're on a WordPress site, you can try Jetpack Boost. You click a button, and it does a bunch of analysis, and it does critical CSS for you. The bucks there are not very many bucks. There are some caveats, but whatever.
If you're just doing it absolutely from scratch on who knows what stack, it's probably going to be a little bit hard. But I was watching a video. This came out March 3rd. It's Ada from Samsung Internet. Jake from Google.
Dave: Oh, yeah. Yeah.
Chris: They did one of those HTTP 203 YouTube shows.
Dave: Mm-hmm.
Chris: That we're all jealous of. Man, they've got a budget, huh? Gees.
Dave: They've got a budget, and they're really funny. [Laughter] Spoiler. Surma is not on this season, so the very first video where they confront the fact that Surma is no longer on the season is the best cinematic -- no, maybe the second best. Netlify just had a good video. But it's one of the best cinematic moments in WebDev history. [Laughter]
Chris: I think I missed that one, but in this video they have a little picture of him on the shelf.
Dave: Oh...
Chris: It looks like--
Dave: There's a -- Jake's real doll with Surma's face clearly on it.
[laughter]
Dave: It's a big statement. It makes an appearance.
Chris: Yeah. Where did Surma go? Just to some startup or something, right?
Dave: I think, yeah.
Chris: Shopify or something? Not that that's a startup anymore.
Dave: Oh, yeah. Maybe he's at Shopify. A lot of Googlers just left for Shopify, so.
Chris: Why?
Dave: Shopify must be doing something big.
Chris: Some bucks, or is it some secret thing? I don't know.
Dave: Dion Almaer went there, and then I think a lot of people followed him.
Chris: Hmm. Mm-hmm. They are going to do that thing, like pay with Shopify, even if you're not buying anything from a Shopify store. Isn't that part of their new world a little bit? Kind of like - I don't know - Apple Pay, but Shopify Pay or something. Maybe they already have that.
Dave: Yeah, they do have. I think it's -- is it Shopify Pay or Shop--
Chris: ShopPay?
Dave: But they have something like that. They just released a new React thing called Hydrogen. Did you hear about that?
Chris: No.
Dave: It's like a whole UI library for integrating into a Shopify site. It's almost CreateReactApp, but it's CreateShopifyApp, is what I'd call it. But it has all the components you need like product grids and stuff like that.
Chris: Oh...
Dave: You can style them and whatever, but it kind of takes all the headache away from building a custom Shopify app. I think they're even doing server components now too. I just read that this morning.
Chris: Whoa!
Dave: They'll do server-rendered components in the Hydrogen app. This is all kind of hearsay, but I think it's just really cool because right now the way to make a Shopify theme or a Shopify site is to hack in and use the liquid stuff.
Chris: We could probably have a Shopify person on because they're so big that it's probably worth understanding a little bit more. But I do think you have that right. Your average person, "Oh, I want to sell something online. What's the way to do it?" And you'll for sure get advice to check out Shopify. I don't think that's incorrect advice. They make great software for selling stuff online, right?
You sign up. You probably get a subdomain or something.
Dave: Mm-hmm.
Chris: You can probably hook it up to a domain pretty easily. Then there's a CMS, right? You say, "Oh, here's my mug. I sell mugs that say 'Butts' on it." You just pop those up for sale, and then it does everything for you. It gives you the URLs, the cart, the checkout process, and whatever else. I don't even think you really need Stripe, right? They're their own internal Stripe or something.
Dave: It does a payment processing, yeah, so they do it for you.
Chris: That's a lot. I don't know if they're keeping inventory for you and shipping for you, but they probably have solutions for that. If not, they are doing it too. Wow, what a lot.
But then on the flip side of that coin, they're like, "Oh, but if you just want to throw up a Hugo site, go ahead. Still use our APIs and stuff."
Dave: Mm-hmm.
Chris: They're happy to be like the APIs that power your store that doesn't use any of the other stuff Shopify offers, right? You can build a website however the hell you want to.
Dave: You can build it. Yeah, you can build a totally custom deal, but the first party thing is use the--
Chris: Their templates and whatnot.
Dave: Their templates, like old WordPress style. You're in editing.
Chris: For sure.
Dave: You may add some tools for ferry up. You work locally and shoot them up. You know?
Chris: Yeah. Another layer behind just use a template is to FTP in - or whatever - and dink around with templates and customize the store, right?
Dave: Mm-hmm.
Chris: I'm sure there are tons of developers who do that. But another layer even deeper than that is not to use their liquid templates at all right?
Dave: No.
Chris: If you're using this Hydrogen thing, you're not in liquid land. You're doing something totally--
Dave: No, you've basically ejected. But you're using their library to build your stuff.
Chris: Yeah, and you don't even have to use this if you don't want. I'm sure you could just use other APIs too. There are so many entry points.
Dave: I think it solves a lot of problems. We have a client on Shopify right now, and we actually brought in Brenda Storer to kind of help out with it just because she's making Shopify themes and stuff like that. She knows what she's doing. And so, we were like, "We want somebody that knows what they're doing."
Chris: [Laughter] Sure.
Dave: One thing the client has requested, and they really want, is connecting to Facebook marketplace and Instagram.
Chris: Hmm.
Dave: There's a Facebook agreement between Shopify and stuff, so you can't sell products on Instagram, right? I can't sell my new book or my new Front-End Masters course. Hey, it's out!
Chris: Why? What?
Dave: You can't.
Chris: You could post a thing that says, "Go buy it."
Dave: I could post about it that says, "Go click the link in my bio to go then click a link to go to--" I can do that. But you don't get a pay button like a checkout now button.
Chris: Yeah, the real buy button things, yeah.
Dave: But Shopify has an integration that allows that, so you can--
Chris: Oh, juicy.
Dave: Shopify will let you, like, click "Buy" from Facebook or from Instagram.
Chris: Which is a reason to use it just right there. If that's what you want, you do it. It's kind of like back in the day, you'd use CD Baby because it got your CD on Spotify, and then Apple Music and stuff. You've got to just the third party that gets it where you want to get it.
Dave: Right. If somebody can become a distribution channel, let's do it. But now you've sold a piece of your company to them (in a way) because you're paying them a percentage and a transaction fee.
Chris: Yeah.
Dave: You're paying them a percentage of every transaction, but you have to look at your sales. Are you selling enough through Facebook that you don't want to stop doing that?
Chris: Hmm.
Dave: Are you making enough that all the transaction fees are way too much and you could actually hire a development team to build Magento or something like that?
Chris: Mm-hmm.
Dave: Then definitely do that, or product customization.
I have a friend. My friend John runs Uplift Desk, and a desk is maybe something that has just enough customization that you don't want to do Shopify.
Chris: Oh, interesting.
Dave: You know what I mean?
Chris: Yeah.
Dave: Because you can add whatever, cupholders and attachments.
Chris: Do you know what they use?
Dave: I think they use a homegrown thing.
Chris: Hmm.
Dave: Maybe it's based on some kind of e-comm platform, but with a customer builder.
Chris: It's funny that you almost pay the most technical debt the less power you have as a seller. If you really did sell coffee mugs that you were really, really proud of, it's such a silly little thing that you probably have a Shopify store.
Dave: You mean this space coffee mug from Laser Wolf Attack? Yeah.
Chris: [Laughter]
Dave: That's a good coffee mug.
Chris: But you're like, "I want to sell these mugs. My goal in life is to sell as many space mugs as I possibly can." Maybe you're on Etsy too.
Dave: Mm-hmm.
Chris: And maybe you're trying to sell them on Instagram. Maybe you find some way to do that. Maybe Shopify lets you, but maybe you can't figure it out, so you're just doing the link in bio thing. And maybe you have a WordPress site with WooCommerce on it, or something, too. All you want to do is be in every channel you can be in.
Dave: Right. Right.
Chris: You're trying to get SEO, but you're trying to be on different platforms and stuff, which is, technical debt-wise, nuts. But that's that. But then once you're big enough, you have your one channel and people just come to you. You're not even losing sales because you're not on one channel because people want your thing so bad. They're just going to buy it wherever they buy it.
Dave: Right. It depends on what product. Do you sell one coffee mug, or do you only sell them in pallets of 3,000?
Chris: [Laughter]
Dave: For the corporate office or whatever. Probably how the quantities in which you sell depends on how you either market or your e-commerce channel too. I think if you're direct to consumer, it's different than direct to -- or B2B or whatever, B2E.
Chris: Somebody should write that blog post, though. Probably Spotify themselves. How many different ways can you build a Shopify store and what are the tradeoffs? I'm sure that already exists somewhere, but I would like to understand that a little better.
Dave: How to build a Shopify, like a big flow chart. [Laughter] Use this. No, yes. No, use this.
Chris: Yeah, like what are the steps up the ladder of complexity and why would you take that step up if you want to. But here's the thing. I've got to circle back to fricken' Jake and HTTP 203.
Dave: Okay. We're going. Yeah.
Chris: Jake and Ada did a show called "Is CSS a Bad Idea?" which is obviously the most click-bait thing ever that's required watching. If anybody else did it, I would just roll my eyes and not watch it, but because it's a fricken' HTTP 203, of course, you watch it, and it's super well done.
Of course, it's not -- in the first two minutes of the video, he's like, "Read that title again." It's "Is .css a bad idea?" meaning are style sheets that are dots. Can you inline all of your styles?
He's talking about inline like a style block, not like Tailwind. That's a different consideration - or whatever.
Dave: Mm-hmm.
Chris: Because even Tailwind ultimately produces a .css file, usually. He's even questioning that. The idea is then, fine, do that, but then take that and put it in a style tag in the head of the document so that the first packet, the first request of the website has the styling information it needs.
Sort of what confuses this is do you trim it to be critical or not? They didn't super get into that.
Dave: Mm-hmm.
Chris: But I think the assumption was that, yes, you do.
Dave: Yeah.
Chris: And you not only do that, but you serve the styles that that particular page needs. Pretty interesting. And it's so good that it beats everything. It beats lots of individual CSS files.
It turns out the worst thing that you can do that you measured is put all your CSS into one file and serve that, which used to be very definitely the way to go. You know?
Dave: Wow. That's brutal. [Laughter] Putting CSS on blast.
Chris: Yeah, it's a great video.
Dave: Interesting. You know what I always come down to is your post from a million years ago about global and page level and then I forget what. You had a third-level like one-offs.
Chris: Yeah, something like that. I remember that.
Dave: But it was like there's global CSS. That's what every page is going to use. That's your critical CSS. You can be pedantic and be like, "No, critical CSS is only for the styles that are on that page."
But I'm just like, "You know what? Global stuff should be critical stuff." If it's everywhere, if it's truly everywhere, it'll be on this page. Then the page level CSS--
Chris: Mm-hmm.
Dave: Literally just writing script tags at the top of the page you're authoring. [Laughter] Just do that.
Chris: Yeah.
Dave: Or if you're authoring in component islands, boom. Write CSS in your island. You know? That's it. You have page or global page component.
Chris: And one-off. Yeah. Or, yeah, component.
Dave: And whatever. Just kind of weird junk drawers. [Laughter] I still stand by the junk.css.
Chris: Yeah. I found it. I called the article "One, Two, or Three," and I wrote it ten years ago.
Dave: "One, Two, or Three," ten years ago, and I still think that's maybe the best strategy there is.
Chris: Yeah. Maybe a caveat maybe in line the one. [Laughter] Or maybe inline all of it. I don't know.
Dave: Well, some of it, too, is like ten years ago, when you wrote that, to do a grid system like 960 or some responsive version of that, I had to code all that there, all the breakpoints, blah-blah-blah. All that crap is coming down. It's 100 megs of CSS, or something. Now it's two lines of CSS Grid.
Chris: Yeah, that's changed the game a bit, too, right?
Dave: You know what I mean? The penalty is like nothing.
Chris: Yeah, and you used to sprinkle font sizing all over the thing, and now we have -- I don't know -- just use these three or four font styles that I have pre-setup and stuff. The amount of CSS that we could ship is lower. I think if you tested that across all the Internet's data, you'd probably find that we're probably shipping more CSS or at least a similar amount.
Dave: Yeah. Oh, doesn't the http archive have that data? I feel like they do.
Chris: Yeah.
Dave: Yeah.
Chris: The thing that's gone up in size is JavaScript and images. HTML has stayed remarkably stable over time. CSS has gone up, but just a little bit.
Dave: Mm-hmm.
Chris: The last time I looked at that data, which was a week ago, so not very long.
Dave: Oh, there you go. If you looked at it recently, yeah. Hmm. Hmm. Hmm.
Chris: Yeah, and the article was good, too. It was on the Speed Curve Blog. It was a super good article.
Dave: They used to put CSS in the top, but now we're demoted, man.
Chris: Yeah, Tammy Everts, "Ten years of page bloat: What have we learned?" Oh, that's just the perfect article to go with what we're talking about.
Dave: Oh, yeah.
Chris: Because everybody talks about the total page size. That's gone up.
Dave: Right.
Chris: We know that. Right? It's like tripled in ten years.
Dave: Always. Yeah, always tripled.
Chris: But why? What tripled? It's not the HTML. It's the JavaScript and the images.
Dave: Mm-hmm.
Chris: There are more of them and they're bigger. And so, images are always in a little bit of a weird category because they're not really render blocking. You know?
Dave: Mm-hmm.
Chris: These days, it has to do with stuff like largest contentful paint and stuff, so it does kind of matter. But for some reason, images don't. It's a solvable problem and they don't bother me as much. They're not ruining the experience of using websites so much. But JavaScript definitely is. You know?
Dave: Yeah. Yeah. I'm looking at the charts. JavaScript is still going up. [Laughter] Yeah. Then images has kind of plateaued, actually, like image bytes. Partly because image requests are going down.
Chris: Yeah, since about 2019. Yeah.
Dave: But I wonder if that's just SVG and different stuff is now a little bit easier or whatever.
Chris: Picture stuff.
Dave: Like SVG style sheets and stuff.
Chris: Perhaps, yeah. But if you took the images and you just sliced them off here because you're like, "I don't know. Whatever. They're not particularly damaging to Web experience."
Dave: Mm-hmm.
Chris: Then what's left? It's definitely JavaScript.
Dave: Yeah.
Chris: Even CSS, even though it's essentially tripled in ten years, it tripled from a pretty thin slice to still a pretty thin slice.
Dave: Like 20 to 60 bytes, kilobytes, 20 to 70, yeah.
Chris: Eh... and it's so fast to parse and blah-blah. It's fine. [Laughter]
Dave: Yeah. What is it? All bytes are not created equal. Fonts are a big deal.
Chris: No, and CSS -- I shouldn't say that because CSS are some of the most important bytes because they're way up in the head. They tend to be in a link tag, and the link is render blocking.
Dave: Right.
Chris: Does it matter? Yeah, it totally does matter.
Dave: Yeah.
Chris: And so, not having to make an http request at all because you're in-lining it is pretty cool. And then trimming it is pretty cool too. Yeah, I mean it matters. I'm not saying it doesn't matter.
Dave: But we've gone from like 54 kilobytes of JavaScript to 450 kilobytes of JavaScript. And that factors in Brotli compression, like new forms of compression showing up. You know what I mean?
Chris: Yeah, right.
Dave: It's still 6x, 9x.
Chris: The oddest thing about JavaScript is the size of it matters. But its execution time is super variable and the slowest, generally, and it has the power to do all kinds of other gnarly crap. You know?
CSS generally, it just does what it does. It's going to style the page. There are not certain bits of CSS that are going to do unknown, weird damage to your website, whereas JavaScript can have one little for loop in it that runs a freakin' ton and slows the hell down of your website. What happens in JavaScript is wholly unknown.
Dave: Mm-hmm.
Chris: That 500K of JavaScript, who knows what it's all doing?
Dave: Somebody on YouTube is going to call me old for saying this, but do you remember when we used to make PNG spreadsheets? Doesn't that seem like forever ago?
Chris: Spreadsheets? Yeah, yeah. We were solving--
Dave: PNG spreadsheets. We would sit down, and we'd try to squeeze every bit of white out of the PNGs and get things as close as possible and laser cut these basically big PNGs to build the website. Do you remember that?
Chris: Of course, I do.
Dave: That is so far away.
Chris: What was the best one? There was one that just did it on one-off, and it was kind of--
Dave: You dropped all the things in a folder, and then it'd spit out your--
Chris: Yeah, it was kind of fun to use. I can't--
Dave: Oh, man.
Chris: I can't remember anymore.
Dave: I remember it viscerally because it was like, "Whoa, it gives you this--" You put a bucket of images in.
Chris: Mm-hmm.
Dave: It gives you the spreadsheet and it gives you all the CSS to do that.
Chris: Right. It lasted, as a concept in our brains, so long that it -- it was Sprite Cow. That was--
Dave: Sprite Cow.
Chris: So good.
Dave: That's the one.
Chris: That we'd call them SVG Sprites, which conceptually made sense, right? You're trying to smash a bunch of SVGs into one file. But there are probably symbols or have IDs on groups or something, and then you can reference pieces out of it. Conceptually, it accomplished the same thing as a Sprite did, but it just didn't hang on because even Sprite (back in these days) was co-opted. I'm not sure it was the absolutely perfect word. You know? I don't know.
The idea came from video games, didn't it? Like, "That's how Super Mario runs is because there's a Sprite of all of his little running things."
Dave: Yeah.
Chris: It shifts the position of the thing. I guess it is--
Dave: And the Cloud Sprite and the Hill Sprite are the same one. They just color shifted the cloud and the hill.
Chris: Yeah, pretty cool. It was just the save HTTP requests (when it came to the Web).
Dave: Mm-hmm.
Chris: It was sort of performance-based, and it really did because we were so obsessed with tracking the number of HTTP requests. And it mattered, but the way that we talk about performance has just changed. People are a little bit less obsessed about the number of requests. Part of that is because we have HTTP2 now, and it literally just matters less.
But we've also just evolved our thinking. It never was about the number of requests. What matters in Web performance is how does it feel. How long is it until people can use your website? Stuff that has an actual impact on the usage of the website.
When we were like, "I bet I could get 17 down to 9," it was just a game. You weren't actually measuring the usage. Yeah.
Dave: The funnest game, but yes, it was a game, but the funnest game.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Notion. Learn more and get started for free at notion.com/codepen. That's notion.com/codepen to help you take the first step towards an organized, happier team today.
That again is notion.com/codepen. I know this is ShopTalk Show and not CodePen Radio, but that's the URL we got just to keep all them clicks all consolidated for this overall sponsorship.
Notion is best. As you know, I've done videos about how we use Notion. We've talked about Notion a ton on CodePen Radio and ShopTalk Show. It's a phenomenal software product. In my opinion, it really changed the game and kind of invented a new category of knowledge management app, which is kind of how I think of it.
It's an app that's really at the core of running any kind of business, but probably mostly software technology businesses because that's where my brain is at. It helps you plan projects and have shared calendars and have shared meeting notes. What you can do with it is really open-ended in the best possible way. Everything you make is like a database or documents, and it's all nested and has good permissions levels and stuff.
I know I'm speaking very abstractly here, but once you get into using it, you're going to find it very natural and comfortable to use, especially in a team setting. It just really brings people together. I have no doubt that it's made us a better place to work (at the places, the businesses I've incorporated Notion into there). It's like Notion is where the work happens (a lot of times), and I really love that.
I also want to say one thing about how I appreciate how they get the details right at Notion, as a company. For example, for a long time, anybody asks us, "Where is the API? Where is the API?" for years and years and years. Finally, they're like, "Here's the API," and it's super well done. It's well documented. It has good default integrations. It's just a super well-done API to the point where people were just like, "Um, thanks. That's perfect, actually. Great." [Laughter] You know?
Then they took a bunch of time to get even a little detail about how text is selected across blocks in the document editor. It just underwent this great improvement of how you can select text across them, and it feel just like you're selecting text in a natural way that you'd expect in any text editor, which was different before because of the block nature of editing.
A little hard to describe, but if you don't notice it, well, that's what they wanted. They didn't want you to be like, "Eh, why is text selection weird in here?" which it kind of used to be a little bit. Now it's just better. I appreciate that we're going to spend time on that detail. Not on necessarily some big, flashy thing, but just on getting the experience of using the app good.
Thanks for the support, Notion.
[Banjo music stops]
Dave: Yeah. It's evolved quite a bit. Even in Lighthouse land. Have you heard of the new property of the new Lighthouse? What is it? It's called -- I'm going to get it for you because it's got a weird name. Oh, man. I'm going to the Web.dev blog to find this.
Okay, I found it. Over on the Web.dev blog there's a new metric called INP (interaction to--).
Chris: Oh, I have not heard of this. This is a new one of the new Web core vitals?
Dave: This is a new Web core vital hot off the pressure.
Chris: Hmm.
Dave: Let me pop it into the show notes here for us. Yeah, it's basically the new time to interactive or first input delay. It's the replacement for that because those ended up being kind of like metrics you could cheat or metrics that kind of weren't exactly true.
Chris: Oh, are they going to deprecate some too? This is huge news. How did I not hear this?
Dave: Yeah, so first input delay basically was like, "How long are we waiting?" but it didn't--
Chris: It was always good, right?
Dave: Yeah. Well, yeah, it was spoofable, I guess, would be the right thing. Right?
Chris: Okay.
Dave: But interaction to next paint, which if I'm--
It measures the time it takes the webpage to respond to user interactions from when the user starts to interact until the moment the next frame is painted on the screen. It's really down to painting.
If I click the search toggle, how long does it take for the search to show up? When does the browser have a frame to paint that search? How heavy is it?
Maybe scroll is the interaction they're looking at there, or something like that too, like time to scroll - or something like that. But it basically says how long have you blocked the main thread. How bad have you jammed up the main thread?
Chris: Hmm.
Dave: It's really pretty cool, so it's kind of replacing first input delay.
Chris: Okay.
Dave: And so, it's going to be kind of a -- I think it's turning it--
From when I -- I talked to Paul Irish recently, but I think it's going to end up being kind of maybe one of the good ones, one of the ones you want to pay attention to - if you had to pick.
Chris: They're really dunking on first input delay here, huh?
Dave: Well, I love--
Chris: You guys invented it, so gees.
Dave: Yeah. [Laughter] Yeah. It's Spiderman pointing at Spiderman.
Chris: [Laughter] Yeah.
Dave: [Laughter] It's like, "That guy did that! You're that guy!"
But no, I think first input delay just had some problems. But I found it very useful. No one else, like no other performance people were like, "Yeah, let's use that." But I always found it useful because--
The question you're asking is, when can the user use it?
Chris: Yeah. Who cares if you can see a form if you can't even click into the thing.
Dave: Right. That's what matters. But this is a good point, like, this maybe gets more exact, like, "Okay, you can see it, but when can you -- when does the browser have a paint cycle? When can the browser actually use it?" I think it's subtle, but it's not just measuring the render blocking. It's measuring render-blocking in the context of input, like somebody has input. How choked up is the browser?
Chris: Okay. That's good news. I want to read that in more detail.
Dave: Yeah, so that's new core Web vitals dropping.
Chris: [Laughter] Nice.
Dave: I think that actually touches on a question -- didn't we have -- a while ago. Somebody was like, "Is core Web vitals going to go away?" I think SWIX wrote that in. Is core Web vitals going away? I think as long as it keeps iterating and coming up with new or trying to be a good reflection.
Chris: Yeah.
Dave: I think it's great.
Chris: The nuance is people are a little weirded out by it because guess where this new metric comes from. Google.
Guess who has the search product that everyone is really worried about doing well on. Google.
Guess who says these metrics are related to how well you're going to do on that search engine. Google.
Google has a lot of control over all this. You know? Why were people pissed off about Amp? Because Google controlled it. It was one of those things that there are too many--
Dave: Those people turned out to be correct - just FYI.
[Laughter]
Chris: And there was, remember, some kind of Amp steering committee, which ended up just being a joke. I mean I hate to say it, but they didn't have any influence. It just existed, and then people talked. Then nothing happened. It was useless.
There is no steering committee or whatever, as far as I know, for Web core vitals. There's no governance.
Dave: Mm-hmm.
Chris: It's not open-source. You know it's none of those things. So, the fact that it's so tied to also SEO, we're just hearing less uproar about it because it's kind of a good idea. It's like measuring actual good performance concepts that everybody can agree on, and it's not mandating any particular framework or anything.
Dave: Mm-hmm.
Chris: It's like, "Do whatever you want on the Web, but we're going to measure it in this way, and it is going to affect your SEO," at least to some minor degree.
Dave: I had a post a long time ago, like a standard system of measurements, you know. It's one thing to be like, "Oh, my website is fast. It got a 99 on Lighthouse," but it's like, "Which lighthouse? The mobile one with 4x slowdown or the desktop one on your Google Fiber?"
What speed did you get a 99 on? On your Mac? I'm finding out now, when I run tests on my Mac Book versus my Digital Ocean server--
Chris: Yeah?
Dave: --are very different because the Digital Ocean server is like a mobile phone from 2010, and my Mac Book is like a Mac Book from 2022. You know. This thing is a screen machine and it's like 2x delta between the two. I doubt Googlebot is running everything on an M1 Mac Book. You know what I mean? [Laughter] Googlebot is probably on some pretty thin hardware measuring your websites.
Chris: Yeah.
Dave: It's very interesting to see or even just kind of try to evaluate how much this stuff--
I don't know. I think we just need a standard measurement system, and then we all kind of corporately agree this is going to be imperfect, but it is something we can kind of look at and get an idea of what's going on. That's what I like about Lighthouse scores is they try to point you to problems, potential loading problems.
Chris: Right.
Dave: It's not like -- if it was 100% SEO-based or something, I might be like, "This is not good." But it's very much like, "Hey, you have a render-blocking script. We can tell you that."
Chris: Yeah.
Dave: Fix it or not, but it'll be faster if you fix it.
Chris: Right. That's starting to come down a little. In the early days of these tools, I feel like, used to suggest stuff that was like, "How am I going to fix that?" You know?
Dave: Yeah.
Chris: Even critical CSS feels like that a little bit. It was always dinging you for that, and you're like, "This is not--"
Dave: Right. It got invented last week, and so--
Chris: Yeah. [Laughter]
Dave: Could it not be something I have to do today to get in Google? Yeah. I read the blog post two weeks ago. It's not there yet.
Chris: Heck, yeah. All right, well, we've got some-- I was hoping to have some--
Well, the point is, we've sent out a bunch of invites for interesting shows that Dave and I have planned, so that's not this week. It won't be next week either, but then we'll start a little series of that.
Dave: Yeah.
Chris: At least no promises because it's summer now, but we're trying, and we have some ideas. Yeah.
Dave: We've got some folks. Got some irons in the fire. Yeah, it should be good.
Chris: The doodles are out. [Laughter]
Dave: The doodles are out, so thank you. But yeah, we do have to cut this off. Yeah, thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter for 16 tweets a month. Join us over in the D-d-d-d-discord, patreon.com/shoptalkshow. And some YouTubes, if you haven't watched them yet, over at youtube.com/shoptalkshow. Be sure to like and subscribe. Smash that bell notification to get notified when we have loaded more videos. Chris, do you got anything else you'd like to say?
Chris: [Laughter] Oh, I hope this recording works. I'm at 0% uploaded. ShopTalkShow.com.
Dave: [Barking]
Chris: [Laughter]