Fast Apps - Easy Perf Wins

Welcome to Syntax.

Today, we're gonna be talking all about performance wins. We're gonna 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 JS always is Wes. What's up, Wes?

Hey.

Not too much. Excited to talk about Perf Winds. We did a show, like, I don't know, five, six years ago on these. It's it surprised me it Wes so long ago, and there both is some a whole bunch of new additions to browsers and and tooling to make the stuff much easier JS well as what makes a fast website has has certainly changed as well. So we're gonna dig into easy things you can do and just sort of keep in mind as you're developing to to have the best performance.

Yeah. And speaking of best performance, you know what? Actually, Century 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 century.i0/syntax, sign up using the coupon code Sanity treat, you can get access to some really incredible features showing you all of the things that we're gonna be talking about. Performance tools are incredible.

You even get a Scott that tells you, just how miserable your users are. There's a lot of cool things that we're gonna 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 Century's performance tools. So this show is presented by Century.

So let's get into it. I figured we would start this off with the first part JS, like, why? What what makes apps slow in the first place? There's 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 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 or whatever, maybe, you're bringing in a whole bunch of stuff, if you Yarn sending too much stuff to them, that is a package that is too big for them to arrive, and it's gonna 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 in Mhmm. Various ways. He you know, it could be initial page load, but it it frankly, it could be every page load. It could be anytime they do anything.

So bringing too much stuff is certainly one reason that apps could be slow.

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 to something that is on the page, like images or video, if those are, larger than they should be, of course, that will slow you slow you down. Yep. Another one could be slow database work. You Node? 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 you're doing things in a nonperformant way where you could be doing everything in a single query, and instead, you're you're doing one query, taking that data, doing multiple queries, doing another query here. And, like, maybe you're going to the 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 is certainly one of them. There's also solutions with caching in here that we can talk about as well. Mhmm. Slow server. So your your actual website, the front end Sanity as fast as possible. But

if the server that you're making a request 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 gonna 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. Yeah. Yeah. Or maybe your server is under spec'd. You know? Yeah. Yeah. That's true. Maybe it's it's overrun. You Node, you've got too many people, or you're trying to do processing on your Vercel, and because of the the RAM or the the processor on that Yeah. Server is not fast enough, to do that. It can it 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 the 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.

A waterfall is when one request renders and realizes it needs something else, and then and then that thing renders and and realizes it needs something else. And 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 a 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 gotta go back to the server and then come back, and you go back and forth over the network.

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 realize it needs something else. And, usually, that's because you're 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 kinda keeps going down and down and down. And that's where you can get into a lot of kind of slow work.

Yeah. Totally. So let's talk about some terms here, some things that are gonna be important and and maybe potentially like, how do you know it's slow beyond the, like, hey. I'm using it, and it feels slow. So Yeah. The first one could be that, you don't understand web vitals. So the web vitals and and these are just kind of, like, standardized terms in the way to talk about these things. We have a a website here created actually by, Ben Vinegar on Century, 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 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, alright.

Who's the biggest, baddest thing, and how long is that specifically taking? There's also INP, which is interaction to next ESLint, and this measures the time from when a user interacts with the page, for when the 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, an accordion. It opens immediately. That's an extremely short INP. Right? But then we have this longer one, which is artificially delayed, and I click it. And you can see that interaction in Next Paint took, like, about a 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. Yeah. Or the 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 you can at least start interacting with the website

if you're before the JavaScript JS loaded and all the bindings are done. 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 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 Node 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. A big one for the layout shift is images where you don't hard Node their width and height. Yes. It's a Node it's super annoying to hard code width and height of an image unless it's automated because, 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 Node, 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. Yeah. And solution for that, if you haven't found the 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. Do you know that sorry. One more thing about that. Yeah. The browser now if you supply a width and height to

an image, the browser will now automatically give you an aspect ratio.

Cool. So you can say width 500, height 200, And then in your CSS, give it width a %.

And then because people also don't like hard coding width and height because, like, I don't know. I want the thing to be flexible. Yeah. 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.

Nice. Yeah. I 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 in the website to use this because, like, 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 ESLint time, you know, can well, I mean, I guess the time it takes to complete loading is also extremely important, but you wanna 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 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 Yeah. I Wes I was talking about TTFB and how this JS, you know, the process it takes for your sir or 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 are you you Node, what exactly are you do you have caching turned on? Any of that stuff. So there's a lot of things that can inter affect these things. But, check this site out if you wanna learn more. It's webvitals.com.

It's a really useful resource.

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 you're server rendering. So what a lot of frameworks now will do is you can set in in React, it's called a suspense boundary, where as soon as React 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 wanna wait for, which JS, like, things like the title tag and ESLint of links for CSS and JavaScript, and you may want to wait on some crucial information. But other things, you may want to say, 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 a loader

if we're waiting too long. Yeah. Word. Alright. 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. Node for users is not going to be cached in the browser because, the browser needs to load the thing before it can cache it initially. Right? So if you wanna 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 dot 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 images, some SVG stuff that's taking a long time to Node, 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's important for seeing, you know, what it might be like on fast four g, slow four g, or three g, or even offline Australian.

Yes. There is an Australian. No. There's not. But, you can add custom ones in here too. So if you wanna simulate very specific things, I like the offline mode, especially if you're working with, PWAs. It's a a great way to test to make sure your PWAs are actually working without killing your network or something.

I mean, it's running locally. So you you you wanna be able to to test these things to make sure your service worker, etcetera, 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. Mhmm. 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 and the actual size of it. And if that number is large, which it actually looks like ours is a little bit large, six hundred and seventy four milliseconds, so maybe we can 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 the client, because that's the point where the server is just sending the first little bit of HTML that is that is necessary.

Yeah. I often find myself filtering by, the fetch XHR request too. Especially if you're hitting an API, you wanna check to make sure that that,

that time in which it's in the API is fast enough. One thing you should turn on in here is the waterfall. So if you right click on the 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, you're gonna 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. Yes. So 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 gonna see the first big one is going to be the HTML, and then Yeah. 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. Yeah. Ours is is fairly flat. I looked at ours before the show, and there's nothing concerning that I saw. 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 Node. This has undergone kind of a a change somewhat somewhat recently Wes it now shows you the local metrics like the LCP, the CLS, the INP. It shows you layout shifts, those types of things.

Yeah. The LOL, the AOL, the IRC.

RFLO.

Yep.

Alright. Wes.

L a l m a f o, rafflecopter, all that stuff. So, no. It it shows you all 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 ESLint called? Like, a fire graph? Is that what this is called? Flame graph? Flame graph. Yes. Yeah. And this is kinda 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, that 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 JS to save offline.

And then what why is save offline taking a longer time while 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 can it can find. Like, for instance, 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's it's end 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 Wes 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, etcetera. Or maybe this particular function is running really super long. I should figure out why that function is taking so long. This is where you do it inside of the performance tab.

It's it's it's a lot to get used to. In fact, the the interface is never my favorite. I 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 it's well worth your time to get acquainted with the performance tab.

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 four hundred millisecond limit to start up a worker.

Mhmm. And that includes any, like, instantiation of objects and and creating things. And and, usually, you're one, two, three milliseconds to run a script. But in this case, we the API for Blue Sky, they're, 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 I logged the issue on the GitHub, and somebody came in and sort of, like, dug into it with the flame graphs. Mhmm. I was like, oh, that was a really good look into how to actually read this. And he he pinned it out. He's like, wow. Like, three hundred and eighty 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.

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 these steps to fix some of this stuff. We 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. 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 Wes 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 gonna tell the browser Wes 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 gonna load them from the browser. That's ideal situation for most part. Yeah. There's also server side caching Wes you can cache things in memory or you can cache them in a 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 Valky. There's a lot of these. So, if you have your own that you like, I always end up just using Redis. I know that there's some controversy around, how they change their, license, but, you know, I I'm I'm still pretty much just on Redis. And and the way this works is is pretty much you're storing something data in the 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 gonna check that in memory cache first to say, hey. Does this podcast 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 Node, 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.

Or, another example is I'm on my website, I'm working on, fetching Twitter stats and or social media stats for all of my content. You know? So I I wanna go off to to Twitter and LinkedIn and Blue Sky and everything, single one, and pull back, like, likes and and whatnot.

But, a, you can't do that too often because there's there's rate limits on these APIs, and 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 a expires on it, and you set it, like I don't know. You set however long you want to expire. I'll put a week on it or something like that. And then as part of your fetching logic, you first check if the cache already has that piece of data, and you just send it back immediately.

Yeah. Totally.

There's also local data. We've talked about that a little bit more on this this show recently than in the past, but you can store data in your IndexedDB.

You can store data in local storage or even in cookies. You can put stuff in those places so that way it's gonna 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 or IndexedDB, either way. That information already exists within the client, and therefore, it is it takes no amount of time to load that data.

Next one we have here is just turning on GZIP. This is almost not something you ever have to worry about because At least any one. Yeah. Have this type of thing on already.

Basically, the way that it works is your server will send your 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 Wes 32, which is a little microcontroller, and it only has a couple megs of memory on it. Mhmm. And the 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 as gzip, and it went down from 1.9 megs down to, I think, like, 70 k or something like that. And it's very good because if you have strings of text that are similar every single time so you if you have the word Wes Bos a million times, it's only gonna 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. 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?

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, b r, which JS, I think, Brotli Brotli. Yeah. Brotli or Zed Wes.

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 ZedSTD, which is not one I've heard about. Looks like it's from Facebook.

It's a lossless compression algorithm developed by Yarn Collett at Facebook.

Okay. Beautiful. But for most of you, your

server is gonna have it turned on. Or if you put throw, like, a CloudFlare or something in front of your website, it's gonna figure out all that stuff for you. Largely don't have to worry about it, for sure. But that said, there's also a concept of a CDN. A CDN is a content delivery network. Make 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 Wes or US East or who knows where. So a CDN is definitely something worth having. It's easy to and 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. Yeah. There's all sorts of stuff. Yeah.

A a CDN, you can either, like, explicitly upload your assets to a CDN. Like like, for example, you would usually do that with something, 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 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 1 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 kinda neat. Like, I was trying to go to some, like, Chinese supplier websites the other day. 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's no CDN. Right? It was loading from a server in China.

Yeah. Yeah. Totally.

Let's talk about images because images, one of the biggest sources of, you know, size in general JS media.

Images being one of them. And, the 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 posts where it shows you how to do it with s three. The long and short of these services are you upload your images. It puts them into a bucket.

The then you you give a URL that has potentially some transformation stuff or whatever going on. And when the user loads that user URL, a number of things happen, especially with Cloudinary. The browser tells it, you know, what formats it can accept or Node 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 put saving that cached version into a folder as well as caching it into your your ESLint. 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 going off and fetching the thousand pixel wide image and then squishing it down. It's gonna fetch the one that is appropriately sized for what you need. So Wes. Like, on the flip side, you can provide a really nice experience for people who who can handle it. You know? Like, I have Yeah.

Freaking three gigabit symmetrical now. Yep. Four k beautiful monitor.

Yeah. 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. If you got the pipe, you might as well use it. That's for sure. Exactly. Yeah. If you got it, use it. 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 his 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.

Yeah. I know. I I when I first used Cloudinary, I was like, this is this is what everything I want. Cloudinary Wes do, like,

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? Yep. Who who cares? I don't know. JPEG Pnpm, all that stuff. Exactly. I don't care. You figure it out for me. And the thing I really like with Cloudinary is some of their AI tools are really nice Wes 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. What else? Oh, compressing.

A big thing you can do is go on if you have a lot of images in your Git Deno, like, your your images are not part of, like, a separate CDN, but they're part of your your Git repo, install the ImageBot 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 Vercel. Mhmm. But it does it lossly or lossy? Loss no. Lossless. Lossless. 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? So it will just do lossless compression, meaning that, like, why the hell Scott, especially if it's in a git Deno? Yeah. Totally.

Yeah.

And another one here, which seems like an obvious strategy, but JS 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 a a number of things. Or maybe you could just straight up do it in 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, Node, yeah, it's JS 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. Yeah.

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. Mean 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.

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 and doesn't include it. So it saved me, like, quite a bit. Nice. Nice.

There's also CSS stuff. Right? Inlining, critical CSS is is good for the most part. There it's funny because that pendulum has kinda swung back and forth between, like, oh, inlining everything, ESLint 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 I don't ever really use inline CSS. Do you inline critical CSS often, Wes?

I do on my current website because you but you really have to have a 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 I would thought SvelteKit did critical CSS.

Yeah. For sure, but it 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 Node, 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 the Syntax website at all. Maybe if we were to throttle it, it simply just uses a whole bunch of link tags in the head. Yeah.

It's actually interesting.

I'm wondering about that myself. 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 gonna need to download this font CSS JavaScript images.

I mean, I know I'm gonna need them. Mhmm. 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, kinda like calling ahead, ESLint in ordering the pizza so that by the time I do get there, by the time I am hungry, I'll need it. So a a reload 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 and you can preload entire pages.

That will kick off the network overhead, the IP lookup, and JS well as the the downloading and possible parsing of JavaScript CSS for you before it's actually needed.

Yes. And there there's also something that is funny. This was, turned on by default in some frameworks. Like, I 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 ESLint, and it starts loading that page behind the scenes. That way, when you click it because there is inherently gonna 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 ESLint, so, therefore, I'm gonna start loading everything just to, you know, kick off that process ahead of time.

But, if you gotta 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. 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 expensive for you or

or the user as well if Yeah. They're on, like, a limited bandwidth plan. So Right. Exactly. Yes. Either way, it could be generating a lot of unnecessary

large Wes, so just make sure, you know, you know what you're doing there.

Yeah. Like, you can you can easily inflate, the cost of a website. Your database calls go up five, six x. You had to kinda figure out if it's worth it or not, and and people will try to figure out different rules. Sometimes people just preload all links that are in the the browser.

I think Node even with the with AI, you will probably start seeing things where you can get a whole bunch of data as to, like, alright. This is a hundred thousand 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. Yeah. At the very least, if you could imagine that people are gonna 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 JS, like, a problem with AI specifically now. AI is just, like, give you all the libraries. Oh, you who cares? You you know? Yeah. 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, you know, hey. There are a lot of great new browser APIs for whether that is CSS or JavaScript or any of that thing. 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, big monolithic libraries. A lot of these things are, like, older. Like, is it under is underscore actually tree shaken now? I don't even know. I'm pretty sure you can.

The build tools have gotten really good at being able to tree shake even, like, older common JS packages.

As well, some things are bundled, though, like, bundled together. Yeah. Yeah. Like like Node is explicitly

shipped and bundled in a way where it can be easily tree shaken.

Yeah. But even then, like, do you 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 Next.js, and I was trying to figure out, like, 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. JS it just text? Text is large. But one of them was the HLS video streaming, library, and it was, like like, 300 k or 400 k, something huge like that. 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.

Yeah. No kidding. Right? We also have icons. 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 Wes I took a I was a senior dev at an agency, and I'd gotten really deep into, at the time, whether that was icon fonts or any of these ways of doing icons in a vectorized way.

I got I got all these designs with rasterized Photoshop icons, and I was just like, you 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 Scott. 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. We're we're using something, 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 Scott, is an SVG sprite sheet using symbols.

I use an app called nucleoapp.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, Sanity sheet idea Wes 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. 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 It, like, dumps it on the page. Right? Like, you you have to somewhere on the page, you need to have a massive dump Yep. 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 your HTML. 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 of SVG, which is being able to color them and and possibly modify them. Or even we're shipping them as a React component.

You know? Yes. Yeah. Well, like, that's that's the thing JS, like, the Syntax website, we have SVGs, and those are shipped as part of our JavaScript bundle. Right? Yeah. We and and we we have to. There's there's Wes don't we don't have to, but there's we wanna change the colors of the SVGs, so I don't think we have a a better alternative to that. Well, we could do a symbol we could do a symbol sheet. We'll we'll figure it out, and we'll But if it's a symbol sheet, it's still part of your JavaScript bundle, though, isn't it? Yes. Because the whole website is part of the JavaScript bundle.

Unless, you are only rendering server side and and returning HTML straight to the browser.

Yes. Yeah.

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 Node, and you don't have the The cached HTML. Load it. Yeah. Yeah.

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 a variable font, which can get bolder or wider or taller, or

it can change in any number of different ways. 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 not and it was just much easier. So I moved it all to a variable font, and then 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 side, 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. And you can you can bundle,

like, a version with or without that depending on on what you want.

Yes. Is that right? Why don't I'm 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 they're so much bigger. Yeah. And in fact, on my website, tolin.ski, I even I 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. That's cool.

One kinda 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 Yes. Or, like, if you if you just have, like you wanna, 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.

Should I try it? Okay. So in console in consoleata in consoleata font, the one weight of normal with all the letters is six k k b, and one font with just the letter okay is one k b. So six times smaller, if you only need a couple letters. So maybe figure out. Parse your parse your your text. Figure out what what letters are needed on the page, and maybe don't load the letters you don't need.

Yeah. Right. Yeah. That's so fun. I mean, again, that makes sense if you if you're using something as a display for the title of the site or something like that. That's the only thing you're gonna be using if you're just loading syntax.

Yeah. You would only need those letters. Correct. Yeah.

Man. Yeah. Nice and cool stuff. So there's a lot you can do. And and, honestly, if you don't need custom fonts like, I love custom fonts. You know, I I like getting 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 just need to download a thing. So, yeah, it depends on what you need. But, if you're just building something like basic informational site that you don't need to have a lot of character to it, just go to the system font, or or who who cares? There's papyrus on there or something.

Beautiful.

Alright. Let's move into the next section, which is sick picks.

Do you have a sick pick today? I do. This is a really fun documentary called Skywalkers, a love story.

And I thought this was, like, really, fascinating. We you know, we were we just put it on when we were, like, looking for literally anything because we're just like Yep. We've already blown through every, available episode of, our our our Korean dating show. We we have nothing to watch. So it's like, alright. What do we put on? We put on Skywalker's a love story, and it's about these two these two people who climb buildings.

They climb all kinds of stuff. Yeah. That's really nuts.

And then they pose for artistic photos.

So, like, she'll be, like, laying back in a 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, crazy shots of people climbing insanely high up things in the Node, 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, highly recommend. It was a it was a cool cool story and visually very impressive.

I'm going to sick pick the OXO Swivel Peeler.

And I freaking love OXO stuff. Yeah. And my wife got me the Swivel Vegetable Peeler for Christmas. And I I've never in my life thought, I wonder if there's a good vegetable peeler. You know? Like, they're all just okay. Yeah. And she got me this one. Holy crap. This thing is amazing. Like, it's so sharp. It just takes the the thinnest, like, top off of it. I've been doing mangoes, been doing carrots, doing potatoes.

It's it's, like, like, $10, and I I I'm thinking, like, man, kinda wish I bought this ten years ago. I didn't realize that there's a good version. The little vertical one with just the little Yeah. Yeah. Okay. I got this. I have this exact one. Yeah. So good. This is, like, part of the, 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.

That's great. Yeah. Highly recommend it. Check it out. Yeah. I use this for everything. Anytime I Scott peel anything. Shameless plugs. Head on over to youtube. Youtube Com forward slash @ syntax f m. We're putting out all kinds of stuff, whether it's deep dives into the things that we're talking about on the show or really interesting unique video stuff. We even have a really super fun new series here where, we're doing way back trivia on Friday. It's going to be really super fun. Yeah. Producer Sanity 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. And if you were around for any of this stuff, it's gonna be a blast from the past. So check out all of the things that we're we're checking out. It's gonna be on Friday, three devs react to wayback trivia. So check it out.

Awesome. Alright. Well, thanks, everybody, for tuning in, and we will catch you later.