A lot of websites are slow.
Many web developers don’t even know our websites slow because we’re on fast internet with great hardware and we live close to our servers.
But what if you have users on the opposite side of the globe from your server? What if their bandwidth is miniscule? What if they’re on a phone? It could take them ages to load your site. And users’ slow CPUs might spend an eternity computing the next animation frame.
What’s an engineer to do? Here I’ll introduce how to think about web performance and how to go about identifying and fixing web performance problems. This article will familiarize you with web performance concepts. I’ll point you in the right direction so you can figure out where to get started and where to invest your time when you’re tackling your website’s performance.
To understand why websites can be slow, let’s go through the stages of everything that goes into loading a web page. This article focuses on page load speed, not how responsive your website is once it’s done loading, but some of the same tools apply to both stages.
Before you can start loading any website, you’ve got to open a connection between the browser and the target site. This includes DNS lookup to find your website’s IP address; a TCP handshake to establish a connection; and an SSL handshake to set up encryption (I hope!). That means you’ve already got several round trips to and from your servers before the user even begins to load your content. If your servers are on the other side of the planet from your client, each round trip is going to be over 100 milliseconds. You can’t beat the speed of light! If you’re looking for a page load of less than a second, you already have slashed off almost a third of your time with the three round trips needed to initiate a secure connection.
Note that there’s a quick fix here if your stack is up to date. HTTP/2 can use caching to reduce SSL setup to only one round trip — just one of many reasons to consider HTTP/2 if you don’t use it already.
Okay, you’ve connected! Now your servers have to start doing some work to deliver bytes to the user. Depending on the design and nature of your service, response time can vary wildly. Is your website a bit of static content, or do you need to do all sorts of database lookups and computation to prepare a response? Do you compute the whole page and push it at once, or do you send a shell and push other content as it becomes available? Are you rendering React on the server? Your server response could take anywhere from a few milliseconds to hundreds of milliseconds or more.
So some sort of response has been prepared. Now clients have to download that response from your servers. Transferring a large response could take a while on a slow or flakey connection.
Wow! That’s a lot of stuff that goes on just to load a page! The good news is there’s a lot of great tools to help you dig in and understand your performance.
As with any performance problem, the first step is simply to profile. No point putting your codebase through the ringer if it turns out performance isn’t a pressing problem for you.
You can use these browser dev tools to emulate slower connections, so you can see what some of your users might be experiencing. Pretending to be on 2G is a fun one.
Make sure you test your page with static resources both uncached and cached.
You can also use tools like webpagetest to see what page loads are like from different browsers and different places around the world.
On top of that, strongly consider logging page load times for your users. The Navigation Timing API and Resource Timing API are your friends. Send the information from these APIs on your users’ machines to your servers and collect it for analysis.
But careful when interpreting results: these APIs measure many different stages of your page load. Make sure you figure out which event actually lines up with when the user can view or interact with your page.
This user data will let you see the actual performance real users are experiencing and help you get a breakdown of where time is being spent. Logging will help you home in on problems by looking at which countries, browsers, and devices are suffering.
If your investigations reveal that your website is slower than you want to be in a way that you believe is impacting user experience, it’s time to get to work. Your profiling information should already have revealed to you where to get started.
For many web pages, the main thing you can do to make your website faster is load less stuff. Google recommends you keep your page weight to 1 megabyte uncompressed.
But be careful to keep the big picture in mind instead of only adding on some hacks that will make your code more complicated and will break in a few months. Upgrading to HTTP/2.0 won’t solve all your problems if you’re just loading too much data. On the other hand, a thoughtful rearchitecting to make your website’s performance stable for a long period might be the best investment of your time. For instance, you might want to make it so that your page’s components load in parallel, use GraphQL to load only necessary data, or implement server-side rendering.
But don’t miss the forest for the trees. Your end goal should always be focused on your users and improving their experience. Performance is just one aspect of the overall experience of your website. If you’re smart about your development process, you’ll make a page that’s not only snappy but also delightful to use.