Speaker 1: This is 10 ways to speed up your or your client's websites as a developer. We're going to talk about why speed is important, how you actually measure the speed of your site, and the different factors that are slowing it down. And then 10 different ways you can actually speed up your site. First off, it's pretty obvious why speed is important for the user experience. People just don't want to wait around for sites to load, and people are pretty impatient on the internet. But it turns out if your site takes one second to load versus three seconds, it reduces your bounce rate. That's the rate at which people just hit the back button by 30%, which is pretty huge. It gets even crazier. Now, if you have an e-commerce site, on the other hand, each additional second of load speed actually increases conversion rates by 2%. That is the rate at which people buy. And now they're putting an even greater importance on speed than ever before. So a lot of sites are going to be looking for speed optimization, and this is a service you as a developer can provide. Okay, first we need to know how to evaluate a site's speed with what's called a performance audit. This is not only something we can send to potential clients saying, look, your site's really slow. Let me help you out. But these audits actually give us specific insights into what is slowing our page down. We could have huge images, too many dependencies. Our files are just too big. We have the wrong file formats or any number of different things, and we'll talk about those in the 10 things we can speed up. But for now, let's talk about how you actually do the audit. And the good news is it's really easy. One way is to go to Google Speed Test, and you'll get a score out of a hundred points. And you'll find that a lot of sites, even really popular ones, aren't even close to this. They're usually in the 50, 60 range. And you could definitely find sites even under 10. They could definitely use your help. Beyond that, you can also use the Lighthouse tool built directly into Chrome DevTools. And this will measure both mobile and desktop scores because a lot of the time they're different if a site isn't mobile-optimized. And you can augment your site with something like AMP to make it super, super fast. Anyway, like I said, if you're a freelance developer, this is a really powerful service you can sell. And you can craft an insanely good offer around this. For example, speeding up your site by 20% or it's completely free. Just a quick plug, we train freelance developers from scratch in Fremote, the freelance developer bootcamp. Link below if you're interested. Okay, now let's talk about fixing these issues. 10 ways you can actually speed up your sites after you've done your speed audit. Now, the first one's pretty obvious. You want to compress your images and iframe your videos. There's a ton of online compression tools. For example, TinyPNG is usually going to reduce your image file size by up to 60% or more. And it's almost always better to use an optimized video player like YouTube or Wistia instead of loading the actual video files into your project. Beyond this, you want to make sure your images are the right size. You don't want an absolutely huge 3 megabyte image. You don't want a 2000 wide pixel image that's only being displayed at a 300 wide resolution. Now, there's a really cool way to make images smaller from the command line. You just use the sipsz unix command. You pass in a width, for example, 300 and then the file name after it. Cool little trick for developers there. Okay, the next tip is to remove dependencies. A lot of developers out there just include jQuery and Bootstrap by default and these alone aren't huge libraries, but they do really add up when you combine them with everything else. I recently paid a freelancer to code a website. They were importing jQuery and only using it one time. And if you're building fast, simple landing pages, there's really no need for jQuery in most cases. Anyway, Lighthouse and Speedtest will usually tell you which libraries are barely being used and give you suggestions on which ones you can remove. Okay, the next speed tip is to minify your code and you can do this with a compiler or also online. Now granted, this one won't have as big of an impact as the other tips because frankly code is not going to take up nearly as much space as an image would, but it all counts. So what you can do is also use an online converter or an offline compiler to uglify your code or just make it condensed down into an unreadable format. The downside to this is you have to maintain two files in parallel and keep them updated. That is your readable code and your non-readable code, but it is something that's going to have a non-zero effect. Next up, you can actually gzip your files, which is converting them to a different format. Without going too far into it, this is basically compressing your files into something like a hash table where there's keys that will then look up different parts of the file that needs to be retrieved. Okay, number five, we want to reduce render blocking resources and this would be of any non-critical asset on our page. So first, what does render blocking mean? Well, it's the things that need to happen before our page can actually be fully loaded. And what about critical resources? Well, we usually consider these any assets that are above the fold or on the top of the page before scrolling. Now, these are not really optional before the first paint, which is the first time things appear on the screen because if we defer their loading, things are going to pop in and just look really bad. Now, this is okay for things further down the page because they have more time to load and those are actually called non-critical assets. And for each, we do this in different ways. On scripts, we can put defer and async. For CSS, we have to be a bit more clever. And for images, it's pretty cool. We can just put loading lazy in modern HTML. Of course, you can get deeper into it and have multiple versions of images. For example, a smaller one that loads first and then a larger one comes in. You can also have different image sizes for different resolutions. But let's stick to the simple low-hanging fruit for now. Anyway, that was at least two different tips in there. So let's just make that two. Okay, the next tip is to use a CDN or content distribution network. Basically, a CDN is just different servers located around the world and your asset will be loaded from the closest one to the request. Now, of course, you could set this up yourself by creating, let's say, different AWS servers manually. There's also a lot of services that do this for you. But the way you're going to usually do this in practice is using the CDN link of a library rather than downloading that code. Because if you download it, it will only come from your server. So best example is like jQuery again. You have a CDN link and you have a download link. If you use that CDN link, it'll most of the time just load faster than the downloaded code. And you also don't have to deal with the complexity of downloading it. So it's usually the better option. And you can do this with any asset. It can be libraries, it can be images, whatever. Number seven is using browser caching. Now, a lot of this happens by default, but you can slightly change the configuration to last longer. And you can do this by setting the cache control header. And you can also use the browser local storage object. Though, be careful. This is not very secure. You got to be a bit careful with caching, though, because cache invalidation is notoriously one of the hardest things to manage in programming. That is, when is your cache stale? And when do you need to go back to the server for a new version of that file? This tip is kind of for advanced developers only. So if that doesn't sound like you, I would just make sure your cache isn't doing anything weird. I wouldn't worry about this one too much. Number nine, you can switch your site to using static pages. Now, there are three main types of websites or web apps out there. The first one is static. And this is like traditional HTML, CSS, JavaScript. But now that a lot of things are done with frameworks, client-side single-page apps were created, which basically creates all of our HTML when we do the request using JavaScript. And this can actually dramatically increase the amount of time it takes our site to load if we have a lot of JavaScript or a large bundle. And then there's a third type called server-side rendering, where this same build with JavaScript thing will happen on our server. And then it'll send that built code to the client. So the difference is it's going to take us longer to receive our first byte if we're building things on the server. And with client-side rendering, we'll get our code faster, but it still has to load on the client. Now, if static pages are faster, why would you use the other two at all? Well, the answer is for dynamic content. You don't always know what content is going to be requested until the request is made. So a lot of people think you need dynamic pages, but in a lot of cases, you don't. If you have a blog, for example, you can pre-build all the pages into static pages and then send that already built page over at runtime. So my long-winded point is you should switch to static pages entirely if you can. And in a lot of cases, you actually can do that. That brings us to number 10, which is to rewrite your site completely. If 1 through 9 fail us, we might actually just have to do this because we've all been there when our app gets so crazy that we can't possibly make a change without creating a bug. This is just a natural part of the software lifecycle. Apps live and die, so eventually you do have to do this anyway. But in short, re-architecting everything is the most deterministic way to speed things up and just make the developer experience better too. All right, that is all 10 tips. Even if you're not a developer, you can probably manage a few of those. And if you are a developer, now you kind of know the A to Z of speed optimization. Now, I know that's not everything. So if you have more ideas for speed optimization, leave it down below. And with all that said, I'll see you in the next one. Thank you.