Introduction to Dev Tools, v3 What Can Slow Down a Website
Transcript from the "What Can Slow Down a Website" Lesson
>> 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 antidote, 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've only guys 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 me the database is an index property. I properly I know Brian Hall just did like a huge course on front of 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 centres 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 jesup 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 g zip 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 unexpressed node, compress, plugin, right, some kind of middleware.
[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: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: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: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 F 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.