Hasty Treat - 5 Things That Make Your Site Slow

Welcome to Syntax. On this Monday, hasty treat. We are going to be talking about 5 things that could be potentially making your site slow, and this is gonna be a series. We have a whole bunch of these things, so we'll hit them in in different hasties along the way here. My name is Scott Tolinski. I'm a developer from Denver, Colorado. And with me JS always is Wes Bos.

Hey, everybody. I'm coming at you live from a shed out my cottage, which is very cold in here right now, but it's the quietest place. We couldn't be any different right now. You have a toon

and a giant puffy jacket, and I'm wearing shorts and a T shirt.

So, apologize that I'm feeling very comfy here. Didn't you just have, like, snow, like, a week ago? Yeah. But we also had, like, 75 degree weather

the day before and, like, probably the day after. You Node, Colorado weird like that, so that's it's how we do it. I think that we anytime we say any sort of temperature, we need to convert it to the other one. So 75, American

Okay. Is

23.8 Celsius.

Oh, I thought you were just gonna guess because I thought that would have been fun. I think that's about I think that's about 10 degrees. Like, I don't know Celsius at all, so that would be fun. Alright. Let's next time that comes up, we'll guess. Wes. Right? This episode is sponsored by LogRocket.

Now LogRocket is the perfect place to stop guessing why your bugs happen. And by this, I mean that it's not like other bug tools because what it gives you is a pixel perfect session replay, which is a scrubbable video with network requests, console logs and errors, network activity, Redux store, just about everything, and including even mouse events for where your user is clicking so that you can see exactly where and why these bugs and errors happened. It logs all of this stuff so that you can just pop on here, watch a little video, and it's amazing because you can solve these issues without them having to contact you, without them having to say, alright. I was on this browser. I clicked on this. I did this and then then this.

And and, you know, nobody wants to do that if they just had an issue on their website. So head on over to log rocket.comforward/syntax and sign up today. You will get 14 days for free.

And, honestly, it's more than enough. Drop it in your site to check it out, and then be amazed when you can solve these bugs visually, which is really the dream.

So let's get into it. We're gonna be talking about 5 things that can be making your site slow, And, I think the very first one we wanted to talk about was slow t t f b.

T t f b's.

Time to first banana.

That's great. Yeah. It it stands for time to first bite, and this is definitely one of those things that make your site feel really slow because, usually, what happens is when you visit a website, it's just white, while you're waiting for it to Node, or you Yarn on the previous page. You click the link, and you're waiting for that next page to show up. And that time to first byte is basically what it means is that when you request something from the server, the server gets that request. It gets the stuff that you need. It it makes templates into HTML, all that good stuff, and then it sends it back to the browser. So the time from clicking the link to the browser getting, like, its first line of HTML is called the time to first byte, and that's pretty important. So, like, what makes a time to first byte slow? So there's kind of 3 steps here. The first is that when you click it, your browser will do a DNS lookup, which translates the domain name into an IP address.

Generally, there's not a whole lot you can do on that end, if you're using any sort of, like, popular service or server or something like that because, these things are pretty well tuned. But I think where a lot of the the slowness comes from is, a, you have a server that is too far away from the actual user. So one of your customers is in Australia.

Your server lives in New York. It has to get on a boat and ship across the entire ocean in order to get there. That's why people put servers all over the world so that, your Australian and your Chinese users get faster response times.

A lower latency is is often what you'll hear. The other thing you can get here is, like, slow server processing. So what needs to happen on your server? Well, let let's take WordPress for an example because a lot of the web is WordPress.

When the request happens, WordPress gets it. It needs to figure out, okay. This is the URL they wanted. What does that translate onto my end? And then maybe it needs to make 6 or 7 database calls to get posts and information about the website and information about the currently logged in user. And then once the database is done, it gets all that data back. And then, it says, okay. Now I've got the data. Now let me template it out, and it's in PHP.

PHP scripts Node to run, and it needs to be converted into HTML. That's your sort of templating step. And then finally, you ship that out of the server back to the browser.

So that processing on the server, the faster that can happen, obviously, the the faster your website will load.

And then once you've sent that response back, it's out of your server's hands, and it's onto the network speed of the actual user. So there are some things you can control there, like the server processing and where your server is, and there's some things you can't control, which is how fast is your user's Internet connection.

Yeah. Totally. And it's funny because TTFB can often be, like, a really slow thing in your your when you check your network Wes, you check your app building, and you see, oh, TTFB.

And then how do I how do I work on that? It's almost like a black Bos, but I think this was a really good explanation of everything that's happening there and maybe where you can to look to start to, speed up some of those processes.

So the next step is going to be you have either too many requests or too large of requests or, potentially, you're waterfalling your requests. What do I mean by any of this? Well, what happens after that TTFB is the server or the browser starts to request items such as your scripts, right, or your images. It says, hey. Give me that image from from this URL or give me that script from this other URL.

And these things are just like any other file on your computer. They take kilobytes, KBs, and sometimes, unfortunately, even megabytes, which shouldn't really happen, right, unless it's, like, like, a video, I guess.

So we have these requests for various assets, and they need to come in. And just like your computer, when you share files, it takes a file from 1 place and moves it to the next. You have to be very cognizant about the size, and overall quality of these images or or various, scripts. For instance, we'll talk later on about some of these assets being too large, a little bit more in-depth in the next step. But right now, if you have too many requests, that's a big deal. Let's say you are not bundling up your JavaScript or not bundling up your CSS, as in you're not taking all of your files and squishing them into 1 file, They could be potentially loading, you know, 5 or 6 different JavaScript files. Node of the, JS I do a lot of WordPress consultancy for friends. Just like friends will be like, hey. I have this WordPress site. It's very slow. I can't figure it out. And then I went to their site. The The first thing I always do is check the network group the network panel because sometimes these people, like, they're they're just adding things left and right. And I saw that this guy's site was loading 4, count them, 4 different versions of jQuery, and they were all being loaded in as a a unique request. So it's like I came in there. I cleaned up some of his plug ins, cleaned up some of the Wes. But just how many things you are requesting is such a big, big deal.

So just to make sure that you are smooshing with a build process down into everything, if you have WordPress or Drupal or anything, there's often different plug ins or extensions that just add that stuff for you. But a lot of the stuff we're working on nowadays is built with Webpack or Gulp or one of these things that just smush everything down into 1 file of its various type.

Yeah. One one more point on the waterfall is that the the network tab in your Firefox or Chrome dev tools are going to be super helpful to visualize what waterfalling is because Essential. Yeah. Sometimes what happens is that, like like, let's say you load some CSS, and then that CSS has a import statement in it. And then that goes and loads some more CSS.

And then that CSS, maybe that has another import statement in it. And what happens is you load one thing, which then figures out it needs to load another thing, which then figures out it needs to load a third thing. And that already kind of happens because you download your HTML, and then your HTML starts to parse. And then you realize you have, like, scripts and and style tags and stuff like that in there, and you have to download those. And if they then go download other things Yeah.

Totally.

Definitely.

So the Node,

Yeah. Totally. Definitely. So the next Node we wanna talk about here are assets that are too large. So we mentioned that there's too many requests are a problem, but assets that are too large when they're requested is also a problem. Because, again, with moving of these files, the larger, more megabytes, more, gigabytes yeah. That's not happening. These files are the slower the whole thing's going to be to take to load. So images are often the best place to look for savings. Like, people wanna talk about, okay. My my site's slow. What can I do this? What can I do here? Number 1 number 1 first thing to do, check those dang images. Yeah. Sometimes those images are giant.

And there there's a lot of different fixes for stuff like this. I I I'd like to hear about some of your tips, but mine are compress and optimize your images via your build tool or something like ImageOptim.

If you don't have a build tool or it's a pain in the butt to modify with your images or your images live elsewhere or something, you can take your images and run them just drop them into this application.

It's gonna crunch them out, remove all that extra metadata, any of that extra the stuff, and it's not gonna have any degradation to quality. You'll also want to use like, I use a service called Cloudinary that does all this for me. It it makes them as small as possible and serve the optimized version.

Another one is make them smaller. Sometimes you're sending, like, a giant image, that really doesn't need to be giant, and it's only being displayed 400 pixels wide, but the image you're loading is 800 pixels Vercel, tune that thing up. Make it 400. Make it exact. Get that exactly how you want it to be. And if you're thinking, well, these images, will they need to be a certain size on mobile and a certain size on desktop? How can I accommodate for that? There's also a picture fill, which is also a great technique for using various image sizes. Wes, do you wanna, talk a little bit about what picture fill is? Yeah. Picture fill is just the polyfill for the picture element, which I don't even know. Let's look it up. What is the browser support for picture right now? Oh, that's funny because I've always used picture filled. It's so funny. I I like, I know it has the picture element, but I just say, oh, it's picture filled.

Yeah. Because for the longest time, it was a thing that you couldn't use. It seems like every browser except IE 11 currently supports it, which is fantastic. Hey. I don't support IE 11, so that means I can drop picture fill. There you go. There we go. Hey. Cool. See you later, picture fill. The idea is that you can you can pass multiple sources along with media queries and show and hide different sizes based on most likely the width of your device. And that's great because if you have a very large screen, then maybe you can Node a larger image that doesn't necessarily correlate with, like, the speed. Like, I'm talking to you right now. I'm I'm looking at a I'm on a 34 inch 4 k monitor and a 2 megabit down,

LTE connection at my cottage. Right? So I'm gonna serve you the biggest image possible for that monitor.

But, generally, I would say, like, yeah, you're you don't need to to load the those huge images if you're on a smaller mobile device. So that's a big one. And this stuff is great to talk about, but quite honestly, this is not something that I'm gonna do without a tool that does it for me because it's just too hard. Like, I'm not gonna sit there and resize all my images. You generally need something like Gatsby Image or Cloudinary or something like that that will automatically regenerate and and give you multiple versions of that image. And I think that's why this stuff is becoming much more popular because it's becoming almost effortless in a lot of these, tools that we use now. Yeah. I think firing up Gatsby and seeing that, like, SVG or the blurry image fade in, like, for free, I think seeing that was was very,

instrumental in me really loving the Gatsby platform just because I was like, oh, I don't have to do this myself. How amazing is that?

WordPress does this automatically for you as well right now. So if you're using WordPress, you just have to do nothing. It just comes for free in all of your intentionally turn it off, which I think was a really cool Yeah. Thing of them. Bos by default.

What else? I use this. Somebody sent a pull request to my own personal website for to add ImageBot, and I've never heard of this before. And it's just a little GitHub add on that you can add to your Git repo.

And every time that you add images to your repo, it will try to optimize them. And at first, I close a pull request. I'm like, I know. I don't wanna, like, yeah, compress my images in the repo. That's the source that's my source images. I want them to be full res, and then I'll use something like Gatsby Image to compress them and and resize them. But then he said, no. This this is lossless, which means that there's lossy and lossless compression with images, and lossless will compress them without actually pixelating them or making them, without throwing anything out the door. And and will depending on how aggressive you wanna be, it will degrade the quality of the image. So it's free for open source projects, which is cool. So if your Git repo is public, you can just add this thing on, and, I was surprised. I think it like, 30, 35% of my images got smaller.

Wow. Nice. Cool. That's a good tip.

So the next Node we wanna talk about is lazy loading. And I I chopped off the word images off of the headline here because there's a lot of stuff that you can lazy load, especially in reactor component land. You can lazy load entire components.

But, you wanna talk about specifically about lazy loading images and what exactly lazy loading images JS. Well, lazy loading is basically the idea here that if there's, say, an image being loaded at the bottom of your screen, so to say, this is an example. If there's an image being Node, the bottom of your screen off Canvas Scott of the viewport and you can't even see it, does it need to be downloaded at the same time as everything else that your site is needing to be to load? If you click refresh on your site and you look at the network panel, you could be seeing this like the footer image being loaded before the user could even interact with the site. And now does that footer image need to be loaded then if they're not even seeing it? No. Not at all. So that's where income lazy loading, which lazy loading basically looks for user scroll and at a certain offset or at a certain, like, if the user scrolling and they hit the image or they hit a margin above the image called an offset, then that's going to trigger a loading of that image. So that image is then loaded once the network is quite a bit more open and free with not a whole bunch of other stuff coming in. Yeah. Lazy loading is it can be done,

natively in a lot of the browsers now. So if you have an image, you just put lazy equals true attribute on the image, and it will only be downloaded once it's about to be in the viewport supported on latest Edge, Firefox, and Chrome, not in saf not in Safari or Bos Safari, but it's more progressive enhancement in that case because it's an attribute you add and not, like, in in the other case, you have to use, like, a library or something that will use Intersection Vercel under the hood. Yep. And, generally, how that works is that you you set an image tag with, like, a data dash source or like a you make up some attribute that's not actually the source attribute.

And because the browser doesn't know what that attribute is, it will just not download the image. And then what you can you can watch that element to come in on screen. And then when that element comes in on screen, you simply use JavaScript to set the source attribute of your image to whatever was stored in the Datadash source attribute. So that's almost doesn't need to happen anymore now that we have lazy equals true on images, but that's just sorta how it works.

Another thing you can do is just, like, preload things, like, ahead of time. So, like, one downside to lazy loading images is that they won't like, if you have a slider and you wanna lazy load the images, you generally wanna lazy load the slider image, like, 2 slides ahead.

Mhmm. Mhmm. Because, like, if somebody clicks on it, then then it starts to trigger to download. That's kind of annoying. Right? So, if that's the case, then you want to look 2 slides ahead and 2 slides back, and then make sure you set those images to to download them. And every time you change a slide, you you go ahead and figure out what are the the 2 ahead and 2 2 behind images.

Word. Cool.

So last on the list here is using a CDN or not using a CDN.

Now what is a CDN? Wes, you've actually covered this in in, very intelligent terms before. Would you like to just give a quick one liner JS what a CDN is? I did. I I don't remember intelligently

covering this, but, a CDN stands for content delivery network. Essentially, what that means is that when you have an asset, that asset will be put onto servers all over the world. And then when somebody requests dog dot JPEG, your CDN will be smart enough to route that user to the low the the closest server that contains that asset. So things like, CloudFront.

So, like, Amazon S3 is a good place to store images.

However, you have to choose where you wanna put your images on Amazon S3. They have locations all over the world. However, if you put CloudFront in front of it or just use an existing CDN, they will automatically take your asset of a dog dot JPEG and then distribute that all around the world on all of their different servers. And then when somebody requests it, they're smart enough to route that to the closest server that has it, and that sort of comes back to the time to 1st bite. That will be much faster to download it. Nice. Yeah. CDN is definitely one of those things you gotta have.

I mean, you gotta have it. I used CloudFront for a long time, but I'm Node on CloudFlare for everything. Good news, Netlify, folks. This is not an ad. They are not sponsoring this episode. But if you use Netlify to host your site, you automatically get a free CDN. You don't have to do anything to, set it up. It just it's just there. And I think that's really like, a lot of these things that we've talked about here, that's the way it's going. Right? They're making it fast by default. They're giving you the CDN by default. They're making it secure by default, giving you the SSL. Right? We see these things over and over again. And me, if I'm looking for platforms to host or places to move my site, those are definitely features that I'm going to be looking for because I don't really need or want to spend the time setting up a CDN if my host or whoever is going to do it for me. So I would imagine that you're going to be seeing this out of a ton of different hosts right now, just free CDN, automatic CDN, just to make it happen by default. Because this is really something that like, should we have to think about this as developers? I Wes, maybe. But I don't wanna have to think about it even though I already do.

Yeah. Yeah. I I don't think that we we should either.

The stuff will not be adopted by the masses until the tools do most of the heavy lifting for us Yeah. Because it's all good and stuff to talk about, lazy loading your images. And, actually, that that's one that you can do your yourself pretty easily. But, like, a CDN, like, all of a sudden, you you move from, like, a HTML, CSS, JS ESLint, like, this, like, networking specialist. That's not something you're gonna do. So tools are, I think, the way forward with a lot of these speed things.

Yeah.

Definitely. I I keep thinking about this. It's funny because the the genesis of this the show ideas came from me thinking about this YouTube video I have. It's my most disliked YouTube video.

My most disliked YouTube video, which is probably just ratioed in the all all whatever. I I get, like, mostly, you know, like, 98%, 99% thumbs ups. One of my videos is just, like, in the gutter, and that is, how to make or it's like website performance tips, and the tip is to reduce the amount of HTTP requests.

And, apparently, every single person who watched that video feels like there should be a one click button to fix the problem. People say, well, you explained what the problem is, but you didn't say how to fix it. I mean, I did say how to fix it. I just can't tell you for every individual platform.

Right? But the it really opened my eyes to the fact that if there isn't a one click fix problem, so many people are just dead in the water in terms of wanting to start to solve that problem. They just either can't do it, don't know how to do it, or don't want to do it. So I'd love to see these fast by default things coming into various platforms.

I'm so curious what my most disliked video is now. Yeah. You can't sort. I I get, like, the meanest comments on this video all the time, so that's the one reason I know about it.

Oh, I found it.

It is, how to set up Versus Node and Prettier in ESLint.

It has let me see here. This JS, a video I did a long time ago before I put together my own ESLint, and it has 90% like ratio, meaning that 1100 people liked it and a 125 disliked it.

Interesting. And I I get that. That's just because how frustrating this stuff is. And I actually superseded that video with a, with another one. Superseded JS a good word. It's a nice word. It with my own setup where it just it just tucked away all the complexity into its own tool, which is exactly what we're talking about today. Yeah. Mine mine has,

it has 30 34% likes. So it's, it's toasted.

It's toasted. Yeah. It's in the gutter. It's so funny because my average is so very high. That one brings my average down tremendously.

Man, that's that's really interesting.

Alright. I think that's our first five. We've got probably another 5, if not more, things you can do on your website. There's just, like, so many things in your new client side, on the server, caching caching on the server, caching on the client, different tools that you can use. Let's not give them all away here. Yeah. Okay. Well, make sure you tune in to the next one. It won't be the next show, but, in the coming weeks, we'll do another show here with, 5 more things you can do to make your website fast. Yeah. Let's do it. Alright. Thanks for tuning in. We will catch you on Wednesday.

Later.

Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.