What Can Slow Down a Website

[00:00:00]
>> It's always fun, like it's fun to go to a new site and just give it like some kind of audit, like a very high level view of like, what's going on with it, I remember this one time as an anecdote, I was doing an interview. I was interviewing for a job and one of the questions was what can slow down a website [LAUGH] I feel like I just ranted for like 45 minutes I was like kind of disappointed when the interview was over.

[00:00:23]
I was like I still have more things, so it's kind of wanted to talk through some of the things that I've seen very commonly slow down websites, and I always kind of group it into like back end and front end stuff. Obviously, those groups they don't really hold true today as things have gotten very complicated [LAUGH] when you have server less sites or you have a front end service team and then a back end service team, but I really mean you have the user's computer and then you have where your code is stored at your data center and kinda one or the other side.

[00:00:55]
So when you think about back end things that can slow down websites, Database calls can happen a lot like maybe the database is an index property. I know Brian Holt just did like a huge course on Frontend Masters on introduction to databases. Sure it covers a bunch of great stuff on like being efficient queries, but I've seen it often where you have a lightning fast server but a really slow my SQL database and that's just going to slow down the request.

[00:01:19]
The server can be slow Or there can be not enough servers, it's just overwhelmed and it's having a hard time responding. The network can be bad, this can kinda both into front end or back end, so either some calls between services can be too slow network connection or from the client to the server can be slow.

[00:01:40]
And those are really interesting to fix because there's lots of different things you can do, you can put your static assets out on a CDN can be great. There's also all sorts of cool serverless technologies that let you host your code in multiple places, basically like a CDN for dynamic stuff.

[00:01:58]
A lot of bigger companies will have data centers located strategically all over the world, or they'll buy like a small presence like a pop or something like that in certain areas to make connections faster. There's a lot of interesting stuff you can do there, and then the last thing which you talked about a little bit is compression.

[00:02:16]
I wanted to give like a quick shout out to Gzip and Brotli here because they also kind of belongs in the network section. But there's two compression formats that browsers actually understand which are Gzip and Brotli. Which means that if you use them to compress your code and send that compressed code over the wire.

[00:02:36]
The browser doesn't need any extensions or anything special to be able to uncompressed your code and read it back out, which is great. So it's Think of it as like a zip format that all browsers understand, which means that you should be probably compressing everything that you use, so for example, if you have like a node app, let's say use Express node or whatever, then you would just wanna look for like an express node, compress, plugin, right, some kind of middleware.

[00:03:03]
They all have these, whether it's like a Java app or a Ruby app or whatever, you just want something that's gonna Gzip all of your requests that get sent over and all your static assets as well. So compression is great, on the front end, we see a lot of things these days, one of the things I see most often are really large JavaScript bundle sizes.

[00:03:23]
That's probably 90% of the cases that I diagnose, come down to that where it's like people say like, can you try to stick under like 2, 3, 400 kilobytes of JavaScript and then you go look at some of these sites, and you're looking at like 5, 6, 7 megabytes of JavaScript.

[00:03:40]
And it's just, it's so easy, I mean, it's so easy to get set up, you need a cool thing and you go to NPM and you find the cool thing and you NPM install it and you just add it and like before long you've got, just so much code.

[00:03:56]
This could be its whole own class, so I'm not gonna go too deep into it, but reducing the dependencies you have is great. Making sure that you're your bundler is optimized is great and another thing is taking advantage of all the modern things. I said Webpack is very flexible, you can say, hey, I need this, but I don't need it on page load, so just download it asynchronously.

[00:04:18]
There's lots of really cool things you can do with bundlers to make the site faster, too many files we kinda covered this already. I always like doing audits at the end even though audit is the easiest on a technical level. It also kinda nicely wraps up all the stuff that we've been learning as you're like, yeah, we kind of covered that, so we covered in the networking section that you can only do 6 synchronous requests at a time.

[00:04:41]
So if you have Like 700 images that need to come down, it's just gonna be queuing installed for a really long time. Again, with images, just like JavaScript, you can make a lot of them asynchronous if you don't need it for the actual page load, like if it's just presentational or if it's below the fold, like down, scroll lower, just make them asynchronous.

[00:05:00]
It can be a huge savings, Images also are tricky like, they can be uncompressed they can be too big. So I we see this a lot where in your CSS you'll have like image style, width 500, height 500 great, and then you hover over the image, and it'll be like, well, the natural size of this image is like 2600 by 1400.

[00:05:24]
And it's like, well, why are you sending this like giant image over the network if you're only going to render it in a very small way. The other thing is that images have all of this metadata, so if you open as someone who works for one of the largest Companies that puts that metadata [LAUGH] there.

[00:05:39]
When you open something and like Photoshop or whatever, it's gonna save all this really, really handy stuff so that when you open it again, you know has all this history and what file or what program it was last edited with all this stuff. It's really good for keeping local files but it's really bad for the web, so if you use something like image optimizer, or any number of cloud services do the same thing they'll like trim all this metadata off.

[00:06:04]
One, it can be a security issue, we often read about hacks where like Exif, data was left on images and people could find where they were posted from. Number two its file sizes, you don't need all that metadata just makes the image bigger, so would they call that as lossless image compression.

[00:06:19]
That's the thing to look into, which is making the image smaller without losing any quality, that's basically what it means. So images to large images on compressed, unused JavaScript and CSS, this one could be another kind of workshop, so Chrome dev tools can tell you unused code. But the story is like never really that simple, right, because you'll often have CSS that's there to style a modal that the user just hasn't clicked on yet.

[00:06:45]
So it's not really unused, it just hasn't been used yet, so I think the better thing to do is to use the bundle async stuff. So like use your Webpack, like dynamic imports or whatever bundler you're using to be like, hey, my that modal the JavaScript and the accompanying CSS does not need to come on page load.

[00:07:04]
It can come later, is a good way to do it, CSS in the document body, that's another one is where you put stuff will trigger when, so if you put stuff in the head versus the body the CSS and the body will be like an asynchronous, like a lower priority loads, then it'll cause everything to kind of warp in afterwards.

[00:07:27]
But then a lot of JavaScript libraries, like analytics ones always want you to put that in the head, which will then block a lot of the thing. So you are like waiting on Google analytics before your page loads, so really tricky and last one, browser caching. So setting cache headers on your server, and then respecting them in the browser is great, I actually over the break I had seen some questions over E tags which I think now is a good segue into.

[00:07:55]
So I mentioned E tags earlier is like a standard, that people use for, caching something until it changes basically, and so they're not necessarily for free though. So the E tag is a header that your server will need to set, and you can look it up on MDN, but it's just E tag, and so your server will send an E tag header with a unique hash to like the file.

[00:08:18]
And then the client also needs to do some work, the client will need to with the fetch request send an if non match header itself and this is all you can find this on MDN. But basically the server will need to send the unique hash, and then the client will need to send only give me a new file if it's not this hash and and that's how they can kind of communicate very quickly together.

[00:08:39]
So these things are a little confusing but there, hugely important when you're, working on a big site that has like user uploaded images that can change but they don't change very often. So ideally, you would cache them all but sometimes you need to purge that cache.