874: Fast Apps - Easy Perf Wins

Is your app feeling sluggish? Scott and Wes break down the biggest performance bottlenecks—like bloated assets, slow databases, and waterfall requests—and share easy wins to make your site feel lightning fast. From smarter caching to preloading tricks, these tips will have your app zipping along in no time! Show Notes 00:00 Welcome to Syntax! 00:58 Brought to you by Sentry.io. 02:01 What makes apps slow? 02:10 Loading too much. 03:26 Slow database work. 04:04 Slow server. 04:54 Waterfall requests. 06:34 How do I know what is slow? 06:45 Web vitals. 12:50 Streaming. 14:05 Network tab. 18:18 Performance tab. 22:53 Caching. 22:59 Client-side caching. 23:38 Server-side caching. Valkey.io. Redis.io. 25:40 Local data. 26:11 Gzip. 29:23 CDN. 30:57 Images. Cloudinary. Cloudflare Images. Imgix. Vercel Images. 31:08 Serving. 34:16 Compressing. 35:06 Ship fewer images. 35:50 Loading JS. Async vs Defer Attributes. 37:00 CSS. 38:28 Preloading & Prefetch. 39:40 Preloading on hover. 41:44 Ship less code. 43:49 Icons Nucleo App. 47:01 Fonts Tolin.ski. 51:13 Sick Picks + Shameless Plugs. Sick Picks Scott: Skywalkers on Netflix. Wes: Oxo Swivel Peeler. Shameless Plugs Scott: Syntax on YouTube. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. Today, we're going to be talking all about performance wins. We're going to be talking about the things that you need to know to make your applications work faster, just in general, smoother experience for users. Not only that weird look, what types of things to keep in mind, and just in general, some of the terms and ideas around making stuff extremely fast. My name is Scott Tolinski. I'm a developer from Denver. With me as always is Wes. What's up, Wes?

• 0:28Wes Bos?

  Hey, not too much. Excited to talk about perf wins. We did a show like, five, six years ago on these. It surprised me. It was so long ago and there both is some, a whole bunch of new additions to browsers and tooling to make the stuff much easier, as well as what makes a fast website has certainly changed as well. So we're going to dig into easy things you can do and just sort of keep in mind as you're developing to have the best performance.

• 0:58Scott Tolinski?

  Yeah. And speaking of best performance, you know, it actually Sentry has some of the most incredible tools for seeing performance in the real world over time. Because let's face it, you can run your lighthouse, you can run all of your stuff locally, you can run it on your own computer. But at the end of the day, you might be on like a fast internet connection with a fast computer and all kinds of stuff. And you might not know what's hidden in the real world. So if you head on over to sentry.io/syntax, sign up using the coupon code A TASTY TREAT, you can get access to some really incredible features showing you all of the things that we're going to be talking about. Performance tools are incredible. You even get a score that tells you just how miserable your users

• 1:41Scott Tolinski?

  are. There's a lot of cool things that we're going to be talking about in this episode that you're going to be able to take and make your stuff as fast as possible and see all that in action if you're checking out Sentry's performance tools. So this show is presented by Sentry.

• 2:01Scott Tolinski?

  So let's get into it. I figured we would start this off with the first part is like, why? What makes apps slow in the first place? There's a couple of reasons why apps could be slow. And the first one is just strictly, you're loading too much stuff. You're bringing too much stuff to the party. You're carrying all this stuff. You can't get through the door. And this could be too many images, too much JavaScript, just too much in general, because at the end of the day, we're sending information over the wire to somebody's computer, their phone, whatever. Their network speed dictates how much can actually be loaded. And if this is the first initial load or whatever, maybe you're bringing in a whole bunch of stuff. If you're sending too much stuff to them,

• 2:44Scott Tolinski?

  that is a package that is too big for them to arrive, and it's going to take a lot longer for it to load on anybody's application. And that goes for, you know, even if you don't have caching properly set up, which we'll talk about in various ways. It could be initial page load, but frankly, it could be every page. It could be anytime they do anything. So bringing too much stuff is certainly one reason that apps could be slow.

• 3:09Wes Bos?

  Too much stuff or too big of stuff as well, right? So if you are loading in things that are needed to render the page out, or just something that is on the page, like images or video, if those are larger than they should be, of course, that will slow you down.

• 3:26Scott Tolinski?

  Yep. Another one could be slow database work. You know, databases in particular can be slow if you're not using them correctly. You don't have indexes set up properly, or you're not doing performant queries. Maybe you're doing too many things, or maybe you're doing things in a non-performant way, where you could be doing everything in a single query, and instead you're doing one query, taking that data, doing multiple queries, doing another query here. And like, maybe you're going to the well too many times on the database, when you could be making a single trip to the database and back. So slow database work is certainly one of them. There's also solutions with caching in here that we can talk about as well.

• 4:04Wes Bos?

  Slow server. So your, your actual website, the front end can be as fast as possible. But if the server that you're making requests to are slow, they're slow to respond. So when someone visits a initial page, if that takes two or three seconds, it's, it's going to be, be kind of sluggish, right? Or it could simply just be slow to move through the tubes because your server may be not located close to where your actual user is.

• 4:33Scott Tolinski?

  Yeah, yeah. Or maybe your server is under spec, you know?

• 4:37Wes Bos?

  Yeah, yeah, that's true. Maybe it's, it's overrun. You know, you've got too many people or you're trying to do processing on your server and because of the, the RAM or the, the processor on that server is not fast enough to do that. It can, it's simply just slows things down. And then the last one we have here is just like waterfall requests or waterfall renders. So the idea of a waterfall is that you, you request a website that will return some HTML. And then that HTML is, is parsed out and then the browser knows what else it needs, you know? And it's often going to need things like CSS and images and JavaScript.

• 5:19Wes Bos?

  A waterfall is when one request renders and realizes it needs something else. And then, and then that thing renders and realizes it needs something else. And if you are waterfalling them, meaning that like one thing is hopping to another, sometimes you can be six or seven requests before you actually are able to display things on the page. So there are client server waterfalls that happen, meaning that you're, let's say you have like a server rendered component. You send the request to the server, it comes back, gives you the actual component. That component realizes it needs something else. It's got to go back to the server and then come back. And you go back and forth over the network.

• 6:02Wes Bos?

  And then there's also just like server waterfalls for, for rendering, meaning that you render, server render a component and then you realize that component realized it needs something else. And usually that's because your server rendering something, you're fetching some data. Based on the response of that data being fetched, you realize you need to render something else. And then based on rendering that thing, maybe you realize you need to render something else. And it just kind of keeps going down and down and down. And that's where you can get into a lot of kind of slow work.

• 6:33Scott Tolinski?

  Yeah, totally. So let's talk about some terms here, some things that are going to be important and maybe potentially, like, how do you know it's slow beyond like, hey, I'm using it and it feels slow. So the first one could be that you don't understand web vitals. So the web vitals, and these are just kind of like standardized terms in the way to talk about these things. We have a website here created actually by Ben Vinegar on Sentry, which is webvitals.com. There's a number of different things that you'll see in the browser's dev tools, but also in performance tools and all kinds of things. But it's also something that takes into account for SEO purposes as well. So LCP or largest contentful paint, largest contentful paint is basically the

• 7:17Scott Tolinski?

  time it takes for the largest one to load, the largest asset, text or image or anything to render on the page. That gives you kind of an idea of like, all right, who's the biggest, baddest thing? And how long is that specifically taking? There's also IMP, which is interaction to next paint. And this measures the time from when a user interacts with the page for when the browser renders a visual response. So you could think of this as latency when somebody clicks something. So in this example on the site, I click an accordion, it opens immediately. That's an extremely short IMP, right? But then we have this longer one, which is artificially delayed. And I click it. And you can see that interaction and next paint took like about a

• 8:01Scott Tolinski?

  second here. And so because of that, that's a bad user experience, obviously. So that can happen totally if you're maybe you're doing something and you're waiting for a database response and it's slow, or maybe you're running way too much JavaScript and some things are happening that don't need to be happening.

• 8:19Wes Bos?

  Yeah, or the worst is when you need to wait for the JavaScript to load before you can even use it. Like I was on eBay the other day, and I couldn't even focus the search box until all the JavaScript had been loaded on the page for, I don't know, for whatever reason, but like, that's why it's so nice to use HTML features when possible, because you can at least start interacting with the website if you're before the JavaScript was loaded and all the bindings are done.

• 8:53Scott Tolinski?

  Totally. There's also CLS or cumulative layout shift. We all know this is maybe the most frustrating one for me in the entire world. I think the worst thing that I can interact with on a website is when you open it, half a second later, an ad pops in and the thing you went to click on moved and now all of a sudden you're clicking on an ad. This will make me want to throw your application in the trash so quickly. So this basically measures the total amount of layout shift that's happening. And if things are coming in late or popping in late, that's going to disrupt how your users are using it. And that's also going to be exacerbated by like the way that things are loading into your page, whether that is through JavaScript, like you had mentioned, perhaps like you're waiting on JavaScript to execute before things pop in there that could happen.

• 9:37Wes Bos?

  A big one for the layout shift is images where you don't hard code their width and height.

• 9:43Scott Tolinski?

  Yes.

• 9:43Wes Bos?

  It's a no, it's super annoying to hard code width and height of an image unless it's automated. Cause like, I don't know. So what people do is they just throw the image tag in there and then you have text and then as soon as the image loads, it pushes the text down or often you'll throw a banner up at the top if there's a sale. And then that pushes the whole website down a little bit. That's really annoying because you have to wait for the JavaScript to load for it to figure out if it should be loading it. There's a whole bunch of annoying things around that.

• 10:13Scott Tolinski?

  Yeah. And solution for that, if you haven't found a solution, aspect ratio is pretty well supported now. You turn aspect ratio on that, that will apply the correct height regardless of whatever the width is and vice versa.

• 10:25Wes Bos?

  Do you know that, sorry, one more thing about that.

• 10:27Scott Tolinski?

  Yeah.

• 10:28Wes Bos?

  The browser now, if you supply a width and height to an image, the browser will now automatically give you an aspect ratio.

• 10:37Scott Tolinski?

  Cool.

• 10:37Wes Bos?

  So you can say with 500, height 200, and then in your CSS, give it with 100% and then, because people also don't like hard coding width and height. Cause like, I don't know, I want the thing to be flexible.

• 10:50Scott Tolinski?

  Yeah.

• 10:50Wes Bos?

  But now aspect ratio will kick in without you even having to set it. And it will, it will determine the aspect ratio from the width and height of the image's attributes.

• 11:01Scott Tolinski?

  Nice. Yeah, I think aspect ratio is one of those things that was very exciting when it was added for this specific reason. Now, we just need to get everybody who drops an ad, a banner ad, or anything on your website to use this because get that stuff out of here. There's also FCP, first contentful paint. This measures the time at which a page starts loading to when any part of the page's content is first displayed. So basically, your page starts loading, something shows up, that is your FCP. This is important to know because that slow time, you know, can, well, I mean, I guess the time it takes to complete loading is also extremely important,

• 11:41Scott Tolinski?

  but you want to make sure that things are showing up quickly as well that can, you know, give your users the sense of something loading fast. And maybe perhaps you're showing skeleton screens or something like that to make it feel faster. There's also TTFB. This is something a lot of us are, have seen before, which is time to first byte. This measures the duration from when the page starts loading to when the first byte of content is received from the server. If you have a long TTFB, it probably means that something is slow on your server. When I had initially had like a performance tutorials on Level Up tutorials a long time ago on YouTube.

• 12:18Wes Bos?

  Yeah.

• 12:18Scott Tolinski?

  I was, I was talking about TTFB and how this is, you know, the process it takes for your server, how long it takes your server. And I had a lot of people leaving comments being like, mine is really slow. How do I fix it? Mine is really slow. How do I fix it? Well, it's like, well, you gotta give me more information, you know, like what kind of server are you working with? What are you doing on your server? Are you, you know, what exactly are you, do you have caching turned on, any of that stuff? So there's a lot of things that can affect these things, but check this site out if you want to learn more. It's webvitals.com. It's a really useful resource.

• 12:50Wes Bos?

  With the time to first byte thing, you're gonna hear a lot of frameworks now supporting streaming. And the benefit of frameworks supporting streaming is that if you have one little piece of your website that is slow, like for example, if you have a, a Twitter widget that your server rendering in your footer and that for some reason takes. Four seconds to actually load your whole website shouldn't have to wait just for that that one component if you're if your server rendering. So what a lot of frameworks now will do is you can set in React, it's called a suspense boundary, where as soon as React

• 13:30Wes Bos?

  hits a suspense boundary, it realizes, okay, well, I can send what I have so far, sort of the skeleton of the whole website. There's certain things you do want to wait for, which is like things like the title tag and a list of links for CSS and JavaScript. And you may want to wait on some crucial information. But other things you may want to say, ah, you know what, it's fine. Start streaming this part of the website to the browser, and then I'll I'll stream the rest when I have it. And you can throw up a loader if we're waiting too long.

• 14:04Scott Tolinski?

  Yeah, word. All right. Well, let's get into more stuff about how we know it's slow. There's some tools within your browser, which is the network tab. First and foremost is going to show you a lot of these things in terms of how fast or how slow or just how large your resources are. So anytime you refresh, if you have your network tab open, as long as the little recording guy is pressed, which it usually is, it's going to show you the loading time of everything. Now, it's also going to show you if things are being cached, because this is super important to know that if you are loading things and everything is cached and it's all fast, then that's how it's going to be on every subsequent load. But the initial load for users is not going to be cached in the browser,

• 14:45Scott Tolinski?

  because the browser needs to load the thing before it can cache it initially, right? So if you want to make sure that your things are somewhat fast on the initial load, there's a disable cache button in here. You can click disable cache. And then every time you load it, it's going to be as if it's loaded for the first time. From here, there's, you can sort by the size of resources and how long or how large things are. So obviously, we have a large content.json file that's for our search. We have a font that's a variable font. It's pretty darn big. And we have, you know, assets, JavaScript, that kind of stuff. And then furthermore, you can even sort by time, which things are taking the most amount of time to load. So we have some

• 15:30Scott Tolinski?

  images, some SVG stuff that's taking a long time to load. And then you can remove that disable caching to then see what the every subsequent load would take. You can also throttle the internet. And throttling is important for seeing, you know, what it might be like on fast 4G, slow 4G, or 3G.

• 15:47Wes Bos?

  Australian.

• 15:48Scott Tolinski?

  Offline Australian. Yes, there is an Australian. No, there's not. But you can add custom ones in here, too. So if you want to simulate very specific things, I like the offline mode, especially if you're working with PWAs. That's a great way to test to make sure your PWAs are actually working without killing your network or something. And I mean, it's running locally. So you want to be able to test these things and make sure your service worker, etc., are working, or local data. Offline mode is great. Those can be all super duper helpful for determining, you know, if your application is actually performing well.

• 16:22Wes Bos?

  Mm hmm. One little tip I have is if you filter for doc, that's going to show you the initial HTML page request. So if you load that, then that shows you how many milliseconds and the actual size of it. And if that number is large, which it actually looks like ours is a little bit large, 674 milliseconds, so maybe we can dip into that. But that's how you know if there's a problem on your server, or if there's a problem on the client. Because that's the point where the server is just sending the first little bit of HTML that is necessary.

• 16:59Scott Tolinski?

  Yeah, I often find myself filtering by the fetch XHR request, too, especially if you're hitting an API. You want to check to make sure that that time in which it's in the API is fast enough.

• 17:12Wes Bos?

  One thing you should turn on here is the waterfall. So if you right click on the columns in your network tab, there's the ability to add additional columns. And one of them is called waterfall. So click on one of your titles. So if you scroll all the way top.

• 17:28Wes Bos?

  You're going to see if anything is being held off by another request. So you probably have to make it much larger than what Scott has it right now.

• 17:36Scott Tolinski?

  Yeah.

• 17:37Wes Bos?

  But that will give you a good visual for what things are are being delayed by what. And if if you see a fairly large one come in after. So for example, you're going to see the first big one is going to be the HTML. And then hopefully, everything else is fairly flat out from there. But then you'll you'll see some that are like a waterfall. And that will show that will very quickly show you where things could be improved. Because something is requesting something and that's requesting another thing. And that's requesting another thing.

• 18:11Scott Tolinski?

  Yeah.

• 18:11Wes Bos?

  Ours is is fairly flat. I looked at ours before the show and there's nothing concerning that I saw.

• 18:16Scott Tolinski?

  Yeah, word. There's also the performance tab, which is super handy. This is harder to read. This is maybe a little bit more work to to understand than the network tab. But this does give you the metrics now. This has undergone kind of a change somewhat somewhat recently, where it now shows you the local metrics like the LCP, the CLS, the IMP. It shows you layout shifts, those types of things.

• 18:38Wes Bos?

  The LOL.

• 18:38Scott Tolinski?

  Yeah, the LOL, the AOL, the IRC.

• 18:42Wes Bos?

  RFLO.

• 18:43Scott Tolinski?

  Yeah.

• 18:45Scott Tolinski?

  LMAFO, Ruffelcopter, all that stuff. So no, it shows you all this. And what's cool about this is that if you record and let's say I click around the site, it profiles the site and you can stop and it gives you a, what's it called? Like a fire graph? Is that what this called? Flame graph?

• 19:05Wes Bos?

  Flame graph, yes.

• 19:06Scott Tolinski?

  Yeah. And this is kind of hard to read. But the way that this thing works is that if you scroll up, you get essentially your JavaScript that's running and doing different things. So this is like a function call. And then this calls this, that's calls this, this calls this. And you can see each of these things are all kind of large until you get to this one. And this is the one that you can tell is taking up the most amount of time is to save offline. And then what, why is save offline taking a longer time? Well, there's these longer ones that create a fragment from HTML that's Taking some time and you can dive into exactly what's happening in your application. This is really handy if you have JavaScript that is slow. Here's some things that it can find, like for instance,

• 19:48Scott Tolinski?

  you're working in a component based workflow like React or something like that and you have a loop. And maybe you have a function that you're expecting to run once, but that function is somehow being caught in the loop cycle of the rendering. And it ends up getting run every single time a component is created or maybe updated or something like that. You could see that that function is being called repeatedly or perhaps it's taking a long amount of time. Where if you could potentially move that up into a place in your application or memoize it or something like that. It gives you the opportunity to say, hey, why is this thing actually running so much? It should only be running once, et cetera. Or maybe this particular function is running really super long. I should figure out why that function is taking so long.

• 20:31Scott Tolinski?

  And this is where you do it inside of the performance tab. It's a lot to get used to. In fact, the the interface is never my favorite. I find myself getting really annoyed at the interface sometimes, but it gives you so much information in terms of when things are loaded, how they're loaded, frame drops and all that kind of stuff. So it's well worth your time to get acquainted with the performance tab.

• 20:52Wes Bos?

  This is also really handy if you're trying to debug serverless functions. Because serverless functions you pay based on usually wall time or CPU time. And you can dip into it and say, oh, this thing is running a little bit longer. We had one once about a year ago, the Blue Sky API was not loading on CloudFlare workers. Because CloudFlare workers has a 400 millisecond limit to start up a worker. And that includes any like instantiation of objects and creating things. And usually you're one, two, three milliseconds to run a script.

• 21:32Wes Bos?

  But in this case, we, the API for Blue Sky, their like TypeScript package, was doing something weird with ZOD under the hood where it was doing way too much validation and creating a whole bunch of new objects. And I logged the issue on the GitHub and somebody came in and sort of like dug into it with the flame graphs.

• 21:54Scott Tolinski?

  Hmm.

• 21:54Wes Bos?

  I was like, oh, that was a really good look into how to actually read this. And he pinned it out and he's like, wow, like 380 seconds of this is is actually just creating a new instantiated object. So it's, it's pretty rare that that actually happens, but you do run into some oddities.

• 22:12Scott Tolinski?

  Yeah, totally. And, and I found myself getting some really good information from here occasionally where it's just, why is this thing, why specifically is this thing taking so long to load? If the network shows that all of the stuff is coming in, clearly the issue is JavaScript and JavaScript can be slow for a number of reasons, whether you're doing too much, or maybe you have some promises that you're waiting that you don't need to, or all kinds of stuff. So yeah, definitely worth your time to get into it. Let's talk about the steps to fix some of this stuff. We have our diagnostic tools. We kind of understand what some of the potential issues are. How do we fix this stuff? And you know, one of the biggest things that you can do is cache your stuff.

• 22:57Scott Tolinski?

  So there's a number of ways you can implement caching, client side caching. What it does is it caches it in your browser. And you set client side caching by giving it caching headers on your, your, your requests or your responses. So when you return a response from a request, you can, depending on the framework that you're in and how you're working, you can tell it how long to cache for, what to cache like, and that's going to tell the browser when that comes in, hey, save these files or save these images into my local cache. Next time I hit refresh, it's not going to load them from your server. It's going to load them from the browser. That's ideal situation for most part. Yeah. There's also server side caching where you can cache things in memory

• 23:43Scott Tolinski?

  or you can cache them in a key store, all kinds of ways. Redis is one of the most popular ways people do this. There's also an open source version. That's a fork of Redis called Valki. There's a lot of these. So if you have your own that you like, I always end up just using. Using Redis, I know that there's some controversy around how they change their license, but you know, I'm still pretty much just on Redis. And the way this works is pretty much you're storing something, data in a key value, and you can set all kinds of things on there like when to refetch this cache or whatever. That way, if I say I'm requesting all of the podcasts, and if it has been, you know, an hour or two hours or whatever, the website is first going to check that in-memory cache first to say,

• 24:28Scott Tolinski?

  "Hey, does this podcast and information exist? If yes, pull that information instead of making a trip to the database to do it." And that can be something that you, you know, it's like not something that every site needs, but if you notice yourself having slow database queries or large database queries or potentially just slow information coming from your server, a Redis cache can certainly help.

• 24:48Wes Bos?

  Or another example is I'm on my website and working on fetching Twitter stats and/or social media stats for all of my content, you know? So I want to go off to Twitter and LinkedIn and Blue Sky and everything, single one, and pull back like likes and whatnot. But A, you can't do that too often because there's rate limits on these APIs. And B, that's very slow to do on every single page. So what I'll do is when I get the data back, I'll throw it into, I'm using Cloudflare Key Value, and then you, but it's the same thing as Redis, where you just put expires on it and you set it like, I don't know, you set however long you want it to expire. I'll put a week on it or something like that. And then as part of your fetching logic,

• 25:33Wes Bos?

  you first check if the cache already has that piece of data and you just send it back immediately.

• 25:39Scott Tolinski?

  Yeah, totally. There's also local data. We've talked about that a little bit more on this show recently than in the past, but you can store data in your index DB. You can store data in local storage or even in cookies. You can put stuff in those places so that way it's going to check first. And maybe perhaps you have some sort of a syncing system or perhaps that data only lives in local storage or cookies or index DB. Either way, that information already exists within the client and therefore it takes no amount of time to load that data.

• 26:11Wes Bos?

  Uh, next one you have here is just turning on Gzip. This is almost not something you ever have to worry about because

• 26:17Scott Tolinski?

  At least anymore.

• 26:18Wes Bos?

  All servers have this type of thing on already. And basically, the way that it works is your server will send your app, your data, HTML, CSS, JavaScript, anything back as a compressed stream. And then the browser knows how to uncompress that. And Gzip is very good because like I have, I had a React application the other day, and I was trying to put it on a ESP32, which is a little microcontroller, and it only has a couple of megs of memory on it. And then the application itself was 1.5 megs once it was compiled. And then I ran it through Gzip because I needed to store it on the device as part of SGzip.

• 27:01Wes Bos?

  And it went down from 1.9 megs down to, I think, like 70K or something like that. And it's very good because if you have strings of text that are similar every single time, so if you have the word "Wes Boss" a million times, it's only going to send that once over the wire. So you don't have to worry about things being very, very long. So if you have long selector class names, you have very long, like an SVG that you use 20 times that is embedded into the HTML, that's okay because the Gzip saves you from that.

• 27:36Scott Tolinski?

  Yeah, totally. And this is something that, like you mentioned, we used to have to do this ourselves. We used to have to set this up in our own servers and configure Gzip. But mostly now, if you're hosting on any major platform or even like Coolify or any of that stuff, you don't have to worry about Gzip. It's just done for you. How do, how do you actually know if Gzip is turned on on your server?

• 28:00Wes Bos?

  So what you'll do is you'll go to Dev Tools and you go to the Network tab, click on any one of your responses. So for example, the first document one, and you look at the headers. There's going to be Response headers and request headers. And the request headers will often have a accepts encoding or accept encoding header. Basically, that is the browser saying, hey, I can use the following encodings. So send me any of these. So in the case of Syntax FM using Microsoft Edge, it says I can use GZIP, deflate, BR, which is, I think, Brothly.

• 28:42Scott Tolinski?

  Brothly, yeah.

• 28:43Wes Bos?

  Brothly, or ZSDT. So I can, I can have any of those, Z standard. And then the, if you look at the response, there's going to be a header called content encoding. And that will tell you what the, the actual encoding is, which is, in this case, it's ZSTD, which is not one I've heard about. Looks like it's from Facebook. It's a lossless compression algorithm developed by Yan Callit at Facebook.

• 29:09Scott Tolinski?

  Okay.

• 29:10Wes Bos?

  Beautiful. But for most of you, your server is going to have it turned on. Or if you put, throw like a CloudFlare or something in front of your website, it's going to figure out all that stuff.

• 29:21Scott Tolinski?

  Yeah, you largely don't have to worry about it, for sure. But that said, there's also the concept of a CDN. A CDN is a content delivery network. It makes sure your content is distributed globally so that way people aren't loading things directly from your server, which might be loaded or located in US West or US East or who knows where. So a CDN is definitely something worth having. It's easy, trivial, honestly, to just throw CloudFlare on top of anything. So for me, these days, I'm pretty much just using CloudFlare as a CDN for, you know, everything. But yeah, there's, there's other options. There's CloudFront.

• 29:55Wes Bos?

  Yeah.

• 29:55Scott Tolinski?

  There's all sorts of stuff. Yeah.

• 29:57Wes Bos?

  A CDN, you can either like explicitly upload your assets to a CDN. Like, like, for example, you would usually do that with something.

• 30:10Wes Bos?

  Like your images or your video, or you throw a CDN in front of your, your website, or in front of like a bucket of data. And what will happen is it will sort of slurp up data that it has to live somewhere by default, right? Usually it'll, it'll live somewhere. US East One is probably the most popular one. And then a CDN will suck it up and then put a copy around the world, give one, flip one upside down, give it to the Australians so that it's relatively fast for them. And it's kind of neat. Like I was trying to go to some like Chinese supplier websites the other day. And I was like, oh, wow. Like, this is very slow to load this website. Like extremely slow to load this website. And it's because there, there was no CDN, right? It was loading from a server in China.

• 30:56Scott Tolinski?

  Yeah, yeah, totally. Let's talk about images because images, one of the biggest sources of, you know, size in general is media, images being one of them. And for me, the, the easiest way to have images be fast is to use a service like Cloudinary. There are a number of these. There's Cloudflare Image CDN. If you Google Build My Own Cloudinary, there's a lot of posters that shows you how to do it with S3. The long and short of these services are you upload your images, it puts them into a bucket. Then you, you give a URL that has potentially some transformation stuff or whatever going on. And when the user

• 31:38Scott Tolinski?

  loads that URL, a number of things happen, especially with Cloudinary. The browser tells it, you know, what formats it can accept, or it knows what browser is requesting this image. So that will, it will serve the smallest possible image. It will create that image, serve the smallest possible version of it to the user, and then it will cache it both by putting, saving that cached version into a folder, as well as caching it into your, your client. So that way, obviously, next time you load, it's loading from your cache. But the next user that requests it, it doesn't have to create that image. It goes and fetches that one that's been created. That's the smallest possible version. That way, again, if somebody's on a phone, the image that it needs is only 300 pixels wide. It's not

• 32:22Scott Tolinski?

  going off and fetching the 1000 pixel wide image and then squishing it down. It's going to fetch the one that is appropriately sized for what you need. So, yes.

• 32:32Wes Bos?

  Like on the flip side, you can provide a really nice experience for people who, who can handle it, you know, like I have. Frigging three gigabits symmetrical now.

• 32:42Scott Tolinski?

  Yep.

• 32:42Wes Bos?

  4K beautiful monitor.

• 32:45Scott Tolinski?

  Yeah.

• 32:46Wes Bos?

  And even like, like, we have a nice TV and it's amazing. I'll still stop and be like, wow, this looks really good. And it's because they they're realizing, oh yeah, they got the the pipes for it. Like, might as well send send it as as large as possible.

• 33:02Scott Tolinski?

  If you got the pipe, you might as well use it. That's for sure.

• 33:04Wes Bos?

  Exactly. Yeah. If you got it, use it. Uh, I'm a big fan of that, like transform on demand. Just so that you don't really have to to fuss with it. I I we talked about on a previous episode where my own personal website using Gatsby was doing it all like on build. And it just got to a point where it it's like a half an hour if I'm doing it without a cache. And it's it's too much. It's way too much. So now I have to, I'm switching it all to doing it on demand.

• 33:32Scott Tolinski?

  Yeah, I know. I, when I first used Cloudera, I was like, this is, this is what everything I want.

• 33:38Wes Bos?

  Cloudera will do like, um, like format, like I might the, they have this like format of auto, which is basically you figure it out. Is this better as a JPEG or a PNG? Or as a, what are, what's the WebM, you know?

• 33:53Scott Tolinski?

  Yep.

• 33:54Wes Bos?

  Who who cares? I don't know.

• 33:55Scott Tolinski?

  JPEG, XL, all that stuff.

• 33:56Wes Bos?

  Exactly.

• 33:57Scott Tolinski?

  I don't care. You figure it out for me. And the thing I really like with Cloudera is some of their AI tools are really nice where you can say, not like the generative stuff, but you can say, hey, crop in on the face of this person. That's really nice for avatars. People upload a photo of themselves. You can automatically crop it to their face. You don't have to make the user do all that stuff.

• 34:16Wes Bos?

  What else? Oh, compressing. A big thing you can do is go on, if you have a lot of images in your Git repo, like your, your images are not part of like a separate CDN, but they're part of your your Git repo. Install the Image Bot extension. And what it will do is every time you add an image to your Git repo, it'll just crawl for any images and then it'll submit a pull request of the compressed versions. But it does it lossy or lo- lossy? Loss? No, lossless. It doesn't lossless, meaning that like some images can be compressed without actually giving up anything. And then other images, you can compress even further by losing a bit of the quality, right?

• 34:57Wes Bos?

  So it will just do lossless compression, meaning that like, why the hell not? Especially if it's in a Git repo.

• 35:04Scott Tolinski?

  Yeah, totally. Yeah. And another one here, which seems like an obvious strategy, but is to just do less. So ship less, less images, right? And this could be, maybe you're shipping an image when you, something could be SVG that loads just fine. Or it could be all a number of things. Or maybe you could just straight up do it in CSS. That was actually such a huge thing in the past. People don't realize this, but man, we had to, used to have to ship images to do anything. Like rounded borders, or box shadows, or gradients, or any of that stuff. And it's crazy because the internet at that time was so much slower. So like now, yeah, it's, we can do so much more with CSS. And I don't think anybody's out there doing button background images anymore still. But if you are, don't. So stop it.

• 35:50Wes Bos?

  Yeah. Next one we have here is loading JS. This is not a thing you really have to worry about with modern build systems because they do it all for you. But often they will minify your JavaScript. Or probably more important than minifying JavaScript is tree shaking your JavaScript. Meaning that removing parts of the JavaScript that are unused. So modern tools are able to crawl through your entire library, crawl through every little piece that is needed. And it will not include it. So I was working on a CloudFlare worker. And I was including puppeteer, which is 300 megs or something with the browser. And I didn't need that for production.

• 36:35Wes Bos?

  So I just ran like a little if statement and did a dynamic import inside of that if statement. And the bundler is smart enough to realize that that if statement turns into an if false statement, which then it will know to just simply remove that whole if statement from the bundle. And doesn't include it. So it saved me like quite a bit.

• 36:58Scott Tolinski?

  Nice, nice. There's also CSS stuff, right? Inlining, critical CSS is good for the most part. There, it's funny because that pendulum has kind of swung back and forth between like, oh, inlining everything, inline nothing. Inline just critical CSS. But the CSS that is critical, if it's on your HTML elements from the load, it doesn't have to go off and load, you know, a CSS file or anything like that. It, I don't ever really use inline CSS. Do you inline critical CSS often, Wes?

• 37:33Wes Bos?

  I do on my current website because you but you really have to have a tool that is able to understand what is loaded on this page and what CSS is attached to it. So you have to have very tight coupling. I'm surprised. I thought SvelteKit did critical CSS for sure, but it doesn't, which the if you do not critical your CSS, if you do not inline your critical CSS, what happens is your page loads and you can see a flash of unstyled content while the CSS is is trying to be loaded. But I I don't see that on the syntax website at all. Maybe if we were to throttle it, it simply just uses a whole bunch of

• 38:17Wes Bos?

  link tags in the head.

• 38:19Scott Tolinski?

  Yeah, it's actually interesting. I'm wondering about that myself.

• 38:24Wes Bos?

  Maybe it's it's maybe it's good enough. One other thing you can do with your CSS is you can put preload and prefetch tags either in the head of your document. So for example, if you're loading some fonts or you're loading a bunch of JavaScript, but you know those tags come later in the HTML, what you can do is you can put preload tags in the head and say, hey, I know later I'm going to need to download this font, CSS, JavaScript, images. I mean, I know I'm going to need them. So can you start working on on that now? So by the time I actually do ask for them, they'll be ready. You know, it's like kind of like

• 39:07Wes Bos?

  calling ahead and ordering the pizza so that by the time I do get there, by the time I am hungry, I'll need it. So a reload a preload tag or now there's a new speculation API in the browser, which will allow you to to do it a little bit more flexible and you can preload entire pages. That will kick off the network overhead, the IP lookup and as well as the the downloading and possible parsing of JavaScript CSS for you before it's actually needed.

• 39:39Scott Tolinski?

  Yes. And there's also something that is funny. This is turned on by default in some frameworks. Like I believe Gatsby was one of the first people to really have this turned on by default. But preloading on hover, so like you hover over a link and it starts loading that page behind the scenes. That way, when you click it, because there is inherently going to be latency between the time that you hover over and when you click. It's like, hey, I know you're about to click this link. So therefore I'm going to start loading everything just to, you know, kick off that process ahead of time. But if you got to account for the fact that users don't always click the links they hover over. A lot of people use like their mouse to kind of like look at a page and they might be hovering over several different things.

• 40:20Scott Tolinski?

  And it's just hitting your server repeatedly in different areas to load different things. So especially if the, the content that it's loading could be heavy, just be aware that it could be expensive for you. If you're preloading expensive things, because it might be-

• 40:34Wes Bos?

  It could be expensive for you or, or the user as well. If they're on like a limited band with plan, so-

• 40:40Scott Tolinski?

  Right, exactly. Yes. Either way, it could be generating a lot of unnecessary large requests. So just make sure, you know, you know what you're doing there.

• 40:48Wes Bos?

  Yeah, like you can, you can easily inflate the cost of a website. Your database calls go up 5, 6x. You have to just kind of figure out if it's worth it or not. And, and people will try to figure out different rules. Sometimes people will just preload all links that are in the, the browser. I think now even with the, with AI, you will probably start seeing things where you can get a whole bunch of data. As to like, all right, this is 100,000 people visited my website and these are the paths that they took. And then you could take that data and then figure out what is the most likely link that somebody will click after visiting this page.

• 41:34Scott Tolinski?

  Yeah, at the very least, if you could imagine that people are going to be mostly all over your site, it's loading that stuff into your cache too. So that could be good for you. There's also the idea of shipping less code. I mean, and I know this is like a problem with AI specifically now. AI is just like, give you all the libraries. Oh, you, who cares? You know? So you have, you have to be aware that there are browser APIs that do many of the things that you might be shipping a library for. So if, if you bring in a whole, a big library into your application when you don't need to, that is making your, your site slower for unnecessary reasons. And, um, you know, hey, uh, there are a lot of great new browser APIs for whether that is CSS or JavaScript or any of that thing.

• 42:18Scott Tolinski?

  So opt for using browser APIs wherever possible before bringing in a big old library. Also opt for smaller or tree shaken packages over large bundled, uh, big monolithic libraries. A lot of these things are like older, like is it, is underscore actually tree shaken now? I don't even know.

• 42:36Wes Bos?

  I'm pretty sure you can, um, the build tools have gotten really good at being able to tree shake even like older common JS packages.

• 42:45Scott Tolinski?

  As long, some things are bundled though, like bundled together. Yeah.

• 42:49Wes Bos?

  Yeah, like, like loadash is explicitly shipped and bundled in a way where it can be easily tree shaken.

• 42:55Scott Tolinski?

  Yeah.

• 42:56Wes Bos?

  But even then, like, do you even need that entire thing? Or like, like one of them I'm just looking for is, I was looking at the bundle analyzer for my, my new website on NextJS. And I was trying to figure out like, hmm, what is using up all of this space? You know, like what it's, it was seven megs for the entire server side framework. And I was like, like, is there anything that's massively taking up space? And, and a lot of that was just my content is, is just text. Text is large. But one of them was the HLS video streaming, uh, library. And it was like, like 300K or 400K, something huge like that.

• 43:37Wes Bos?

  And I was like, man, imagine we get HLS video APIs in the browser. That would be huge for being able to drop that massive dependency.

• 43:48Scott Tolinski?

  Yeah, no kidding, right? We also have icons. Um, this is something that has like changed and evolved over the years, many different times. We had icon fonts at one point. We did icons with images way back in. I'll never forget was I took a, I, I was a senior dev at an agency and I'd gotten really deep into at the time, uh, whether that was icon fonts or any of these ways of doing icons in a vectorized way. And I got, I got all these designs with rasterized Photoshop icons. And I was just like, oh, man, losers. What, what did I do? I, I, I, so I quit my job and I took a new job and it was a nice, high paying job. And the very first comp I get had these like ugly raster icons. And I was, I had to go to the designer and I'm like, no, we're not doing that. I'm not doing that.

• 44:33Scott Tolinski?

  We're, we're using something, uh, vectorized. Either way, the new way to do icons in a way that is typically faster, smaller, whatever is SVG sprite sheets. If anybody has any more up to date information and I'm wrong, please correct me, but I believe that the fastest, smallest way to do this, if you have an icons is an SVG sprite sheet using symbols. I use an app called nucleo app.com. Lots of different SVG sprite sheets or symbol sprite sheets will do this for you. Just Google it. You'll find some utilities online. But the concept is really similar to the old, uh, sprite sheet idea where you have a whole bunch of images on one image. It only has to load that one image and then you crop it to give you the right one.

• 45:16Scott Tolinski?

  However, with SVG symbols, it puts kind of all your SVGs into a single file with symbols. And then the individual SVGs reference those symbols and then you use a class. It uses that symbol.

• 45:29Wes Bos?

  Like dumps it on the page, right? Like you, you have to somewhere on the page, you need to have a massive dump of every single SVG that you could ever possibly use. And then you reference, some people don't, don't like that approach because it adds the SVG code to the, to the JavaScript bundle or to your HTML. But the alternative to that is, is to ship them as images and then you lose out on. All the benefits of SVG, which is being able to color them and possibly modify them.

• 46:01Scott Tolinski?

  Or even we're shipping them as a React component, you know?

• 46:05Wes Bos?

  Yes. Well, like, that's, that's the thing is like, the syntax website, we have SVGs and those are shipped as part of our JavaScript bundle.

• 46:13Scott Tolinski?

  Totally. Yeah.

• 46:14Wes Bos?

  We, and we have to, there's, there's, well, we don't have to, but there's, we want to change the colors of the SVGs. So I don't think we have a better alternative to that.

• 46:27Scott Tolinski?

  Well, we could do a symbol. We could do a symbol sheet. We'll figure it out.

• 46:30Wes Bos?

  But if it's a symbol sheet, it's still part of your JavaScript bundle, though, isn't it?

• 46:35Scott Tolinski?

  Yes.

• 46:35Wes Bos?

  Because the whole website is part of the JavaScript bundle, unless you are only rendering server side and returning HTML straight to the browser.

• 46:46Scott Tolinski?

  Yes. Yeah.

• 46:48Wes Bos?

  So tricky, but I think Svelte will have a solution for that. Server components gets around, around that as well because you're simply just returning the HTML that is needed and you don't have to.

• 46:58Scott Tolinski?

  Right. The cached HTML.

• 46:59Wes Bos?

  Yeah.

• 46:59Scott Tolinski?

  Yeah.

• 47:01Wes Bos?

  Last one we have here is fonts. I just put a card on the list of shows because there's so much in terms of fonts. In terms of like, if you're using a custom font, does it take a long time to load? If so, should you render a fallback font? What's better, changing the font on somebody one second in, like loading like Times New Roman and then loading something else? Or loading nothing, you know? And there's a whole bunch of new stuff in the browser for like font fallbacks and how to best approach them. We also now have variable fonts, which if you used to load like six or seven weights, it might be better just to load a variable font,

• 47:41Wes Bos?

  which can get bolder or wider or taller, or it can change in any number of different ways.

• 47:47Scott Tolinski?

  Yeah, variable fonts are incredible, but you do need to know specifically if you need one variation of that font, like let's just say you're just using, you know, regular, non-bold, whatever, non-italicized body font, then loading a variable for that font is going to be a much larger font load than just the static font for that. So if you, if you are using a font in various different ways, for instance, we were using, I think, like six or seven different versions of MDIO on the syntax site. And so we had the bold italic, we had 900 italic, we had regular body, we had light italic, we had all these things, bolded and it was just much easier. So I moved it all to a variable font and then

• 48:31Scott Tolinski?

  you can change how the font loads with the, the correct variable font tags. You can even swap out specific glyphs if like, let's say on the syntax site, the zero has a little dot in the center. If we wanted to remove that dot from the center, there's an alternate version of the zero without that, that we could pass in that, that parameter and it would change that.

• 48:53Wes Bos?

  And you can, you can bundle like a version with or without that, depending on, on what you want?

• 48:59Scott Tolinski?

  Yes.

• 48:59Wes Bos?

  Is that right?

• 49:00Scott Tolinski?

  Uh, well, I don't know about bundling that. I don't know. I've never, no, I think the variable font just has all that included, which is why they're so much bigger. Yeah. And in fact, on my website, tolin.ski, I even, I think I'm using MDIO as well. I, I liked the variable I, so I changed the way that the I, so my I looks like, kind of like funny compared to how it looks straight out of the box, just because I thought it had a little bit more pizzazz to it.

• 49:25Wes Bos?

  That's cool. Uh, one kind of interesting thing about Google fonts is you can load a font and only tell it which letters you want. So if you're only using like the R, or like if you, if you just have like, you want to like have a cool okay somewhere, you could literally just load a Google font with the letters O and K and it will, it will just ship those two. How curious how much smaller it is.

• 49:54Wes Bos?

  Should I try it? Okay, so in Consolata, in Consolata font, the one weight of normal with all the letters is 6k KB, and one font with just the letter "OK" is 1KB. So, six times smaller, if you only need a couple of letters. So, maybe figure out, parse your text, figure out what letters are needed on the page, and maybe don't load the letters you don't need.

• 50:25Scott Tolinski?

  Yeah, right. Yeah, that's so fun. I mean, again, that makes sense if you're using something as a display for the title of the site or something like that, and that's the only time you're gonna be using it.

• 50:34Wes Bos?

  If you're just loading syntax, you would only need those letters.

• 50:38Scott Tolinski?

  Correct. Yeah. Yeah, nice and cool stuff. So, there's a lot you can do. And honestly, if you don't need custom fonts, like, I love custom fonts. You know, I like getting fonty with it. But if you don't need custom fonts, just load up the system fonts, the system font stack, all that stuff, and it's gonna be the fastest experience, because those are already gonna be on the computer. You don't have to download a thing. So, yeah, it depends on what you need. But if you're just building something like a basic informational site that you don't need to have a lot of character to it, just go with the system font, or who cares? Throw Papyrus on there or something.

• 51:11Wes Bos?

  Beautiful. All right, let's move into the next section, which is Sick Picks. Do you have a sick pick today?

• 51:20Scott Tolinski?

  I do. This is a really fun documentary called Skywalker's A Love Story. And I thought this was like, really fascinating. You know, we just put it on when we were like, looking for literally anything, because we were just like, we've already blown through every available episode of our Korean dating show. We have nothing to watch. So, it's like, all right, what do we put on? We put on Skywalker's A Love Story, and it's about these two people who climb...

• 51:51Scott Tolinski?

  Buildings, they climb all kinds of stuff.

• 51:53Wes Bos?

  Yeah.

• 51:54Scott Tolinski?

  Up on the roofs.

• 51:55Wes Bos?

  Nuts.

• 51:55Scott Tolinski?

  Um, and then they pose for artistic photos. So like, she'll be like laying back in a dress and he's got like a drone that's taking this like very artistic photo of her or they're kissing or anything. And it's just this duo of these two people who are just kind of like adrenaline junkies and it's like their, their whole story. But man, is there some, uh, crazy shots of people climbing insanely high up things in the snow. Uh, uh, just mind boggling feats. And the whole time you're just like, no, they're not doing this. There's not, there's no way. And it's crazy. So, um, I highly recommend it. It was a cool, cool story and visually very impressive.

• 52:40Wes Bos?

  I'm going to sick pick the OXO Swivel peeler. Um, and I fricking love OXO stuff.

• 52:47Scott Tolinski?

  Yeah.

• 52:47Wes Bos?

  And my wife got me the Swivel vegetable peeler for Christmas and I, I've never in my life thought, hmm, I wonder if there's a good vegetable peeler, you know, like they're all just okay.

• 53:00Scott Tolinski?

  Yeah.

• 53:00Wes Bos?

  And she got me this one. Holy crap. This thing is amazing. Like it's so sharp. It just takes the, the thinnest li- like top off of it. I've been doing mangoes, been doing carrots, doing potatoes. It's, it's like a 10 bucks and I, I, I'm thinking like, man, kind of wish I bought this 10 years ago. I didn't realize that there's a good version.

• 53:20Scott Tolinski?

  The little vertical one with just the little.

• 53:22Wes Bos?

  Yeah.

• 53:22Scott Tolinski?

  Yeah. Okay. I got this. I have this exact one. Yeah.

• 53:25Wes Bos?

  So good.

• 53:26Scott Tolinski?

  This is like part of the, uh, in, in the, in the States, you get married and you get a bunch of OXO stuff. So this definitely came in that, that bundle.

• 53:34Wes Bos?

  That's great. Yeah. Highly recommend it. Check it out.

• 53:37Scott Tolinski?

  Yeah. I use this for everything. Uh, anytime I gotta peel anything. Shameless plugs. Head on over to YouTube, youtube.com forward slash at syntax FM. We're putting out all kinds of stuff, whether it's deep dives into things that we're talking about on the show or really interesting, unique video stuff. We even have a really super fun news series here where, uh, we're doing way back trivia on Friday. It's going to be really super fun. Yeah, Producer Randy has put together several screenshots from old websites. And Wes CJ and I have to guess what year the screenshot is from using the clues of the interface stuff, maybe browser technology that exists. It was a ton of fun. I had a great time with it. And yeah, I think you'll have a lot of fun too.

• 54:22Scott Tolinski?

  And if you were around for any of this stuff, it's going to be a blast from the past. So check out all of the things that we're checking out. It's going to be on Friday, Three Devs React to Wayback Trivia. So check it out.

• 54:33Wes Bos?

  Awesome. All right. Well, thanks, Eddie, for tuning in and we will catch you later.

• 54:38Scott Tolinski?

  Peace.