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.
Fix your memory leaks in Chrome Dev Tools – here
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.
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.
is relevant to your platform.
Top Tips for JS Optimisation
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.
- 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
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.
Use a lightweight framework
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.
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.
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
Use local caching
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
When you’re doing things like animations, CSS is probably going to be more lightweight when it comes to doing some of those animations.
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.
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.