When defining Service Level Objectives, one of the critical items to think about is the speed of response. This would be the Page Speed Core Web Vitals for a website or web application.
Below is a transcription of the video above which covers Marc Firth’s (our Managing Director and 15-year Software Engineer) top tips on how to reduce the size of JavaScript; in order to improve your Page Speed and achieve your Service Level Objectives.
Links:
Fix your memory leaks in Chrome Dev Tools – here
Video transcript:
Faster JavaScript improves your sales.
Marc: JavaScript tends to account for about 20 to 40% of page weight. We know that speed is a ranking factor when it comes to our SEO and we know that speed helps user experience and that it affects brand perception.
So the faster your website is, the more it’s going to improve that UX and the higher your conversion rate is likely to be. And that’s what we’re discussing today.
Hi everyone. Welcome to the Channel. For those of you who don’t know me. My name is Marc Firth. I’m a Managing Director at Firney. I spent the last eight years working at a global Digital Marketing agency, where we worked on a range of websites and applications for Fortune 500 companies.
I’ve also worked client-side too on large-scale e-billing systems. Between my colleagues and me, we’ve built a whole range of systems when it comes to reliability.
We’ve seen what works and what doesn’t. We saw an opportunity to share what we’ve learned and help others
achieve the same levels of reliability that we’ve achieved. One of the critical aspects of that is page speed; because if your site’s up, but it’s so slow that users can’t reach it, it may as well be down.
So today we’re talking about my top JavaScript optimization techniques to make your website faster.
Key Considerations for Service Level Objectives
Marc: When you’re agreeing on your service level objectives for your platform, website, app, service or API; there are some key considerations to make with regards to defining what reliability actually means.
You want to be sure that the thing you’re focusing on is that critical user path. That is a path a user takes to reach the goal or action or whatever it is you want them to do.
You need to think about the things that make that flow possible. We want to build processes that mean we can build a fantastic experience for the user.
Such as them being able to perform said action error-free, with low latency and with a fast page speed. Now defining what those signals are, the key metrics to use and how to reduce errors is a far larger topic and is the content for another video.
But for now, we’re going to focus on page speed; and in particular, improving JavaScript load times, so that you can be sure your application works for users wherever they are; and with a slower network connection, such as 3G; using whatever device
is relevant to your platform.
Top Tips for JS Optimisation
Minification
Marc: So the number one thing is minification. So what you can do is take your JavaScript files and run them through a minifier.
This will compress the size of those files down by removing additional characters that aren’t needed, reducing those files down massively. So it will have a big impact on the eventual size of that JavaScript file being sent to the browser.
Split critical components from combined JS files
Marc: The second thing is to split critical components from combined JS files. So, for those initial components that your user needs to be interacting with first, make sure that they’re loaded separately and that they’re loaded as a priority. That way you can make sure that they get the experience as soon as possible.
For any non-critical JavaScript files, make sure that they’re loaded asynchronously; or only load them when needed, i.e. in the background.
So:
- If you’re clicking on a form, you can load up the CAPTCHA.
- If your user scrolls to a map or clicks on a map, you can replace an image of the map with the actual map. An image file is a lot smaller than the full weight of an interactive map.
Use a task runner
Marc: The next thing you can do is use a task runner. A task runner like Webpack will help automate these processes for you; by automating the minification and aggregation of those JavaScript files, and it makes sure that it can split them, as needed, into bundles.
If you’re not familiar with a task runner like Webpack, then take the time to understand and learn how they work. They are quite comprehensive in their scope, but they make life a lot easier and a lot faster when it comes to doing all of these performance actions.
Lose weighty JavaScript libraries.
Marc: If you’re using a large library like JQuery or something like that, where you’re not maximizing its use (maybe you’re just using a couple of functions from it), try converting those functions into raw JavaScript; because that’s going to perform better and be a lot smaller.
Use a lightweight framework
Marc: My next recommendation is to use a lightweight framework, so something like Preact or even just using raw JavaScript. If you can do that, do it because it’s more likely to be quite lightweight.
If you are using a framework, then try and use the in-built functions of your framework (like Vue, React or Angular). Use the functionality that they give you in those packages, rather than trying to bundle in additional JavaScripts that are external. That way you can reduce the number of third-party libraries that you’re including in your code, as they tend to be one of the heaviest things that you’ll have on your page.
If you’re loading those frameworks, well, you may as well use them. You’ve already invested in using that framework for your code, so make sure you’re making the best possible use of that.
If you can convert to using raw JavaScript for the items that you need (if you don’t need to use a large-scale framework)
then convert it into raw JavaScript as that will perform better.
Make sure that you eliminate any dead JavaScript code.
Marc: It is probably more relevant to older sites that have evolved over time, but make sure you’re doing cleanup actions
to remove any old code and keep that code as streamlined as possible; so that anything that’s not needed (any waste) is removed and you can keep your code small.
Host those third-party libraries on your server.
Marc: This reduces the points of failure.
If your CDN was to go down, that you’re using, then your code would no longer work. Whereas, if you host [any third-party libraries] on your environment, then it’s only if your code base [and assets], on your CDN, go down that you’ll run into a problem.
Use Edge Caching
Marc: The next thing I advise you to do is to use edge caching on the CDN.
This makes sure that any images, JavaScripts and CSS files are as close as possible to the user; within the network where they’re being hosted.
You have your hosting, and you have your CDN in front of that. That CDN (Content Delivery Network) has data centres around the world that ensures that when the user’s requesting one of those assets, they’re only going to their local CDN data centre. So they can get the asset from there, and it’s a shorter round trip to get that image or that JavaScript, when they make the request from the browser.
Push and Preload
Marc: Make sure you’re using push and preload. This is a way to make sure you can get those assets before you need them [and cache them locally], and speed up the overall time of loading and rendering your page.
Use GZip Compression
Marc: Make sure you’re using GZIP to transfer your assets. JavaScript files that have been minified can be compressed even further using GZIP making them even smaller, meaning there’s even less data to transfer to the browser.
Use local caching
Marc: Local caching is when the user can request some of your assets such as your CSS, or your JavaScript, or images and cache those items locally to allow them to be reused.
When I say local caching, I mean on the browser itself. So you can set up a service worker, which will go and pull down any assets that you need, and then [your users] can cache those locally on the browser and keep those assets locally. That means the user doesn’t have to download them again from the CDN or the server.
Again, load only what you need when you need it.
Marc: You can use a service worker to download things in the background, and that’s fine. It will go and pull down those assets
and then you can use them when needed. But, when it comes to that initial load, make sure [that for the initial load] you’re only downloading what you need when your user is loading the page.
Use CSS for animations
Marc: My next tip for JavaScript optimization is to actually use CSS if possible.
When you’re doing things like animations, CSS is probably going to be more lightweight when it comes to doing some of those animations.
Memory leaks:
If you’re doing animations using JavaScript, make sure you’re checking for memory leaks. This isn’t so much a “performance optimization” as it is just a “running optimization”. It is making sure that those animations continue to run so that you don’t have that period of time where the website works… then it starts getting a bit slow… and the page eventually breaks.
So make sure that you’re checking the inspector. If you’re not sure how to do that, I’ll leave a link in the description that shows you how.
It is a more advanced topic, but one worth looking into if you’re using animation.
Summary
Marc: So those were my top tips for JavaScript optimisation.
Hopefully, that’s useful. If it was, don’t forget to like, subscribe and share and I’ll see you in the next [YouTube] video.