As I tweeted recently, when approaching performance, you need to start with profiling. The first thing you want to do is identifying the problem: finding what’s wrong is always the first step of making it right. That’s why measuring is so important when it comes to page load performance, if you don’t have metrics to compare, you don’t have a measure of success. You can’t just rely on “it feels faster”, you need data.
Measuring can be tricky. One needs tools to do the job right, but this is the easy part: you can open the Dev Tools, or rely on services like SiteSpeed.io or WebPageTest.org. You can even install Lighthouse or get your site audited by Google itself on PageSpeed Insights. The tricky part, however, is knowing what to measure, what different metrics represent, and why would they matter. Without a solid understanding of what the options are, it can be awfully difficult to understand what type of problems it might make sense to address in your specific scenario.
In this article, I’m going to focus on metrics that are specific to page load perofrmance. There are plenty of options. If you ever read anything on the topic, you’ve probably come across the terms Time To First Paint, Time To Interactive, and similar: well that’s what this article is going to be about. Let’s dive into this mess of acronyms, and hopefully bring light to what should be measured and why.
Whenever we approach this type of tasks, it is important that we keep in mind one fundamental thing: all it matters is the time passing between the user navigating to a page and the page reacting in some way. Depending on what aspect of the process of loading the page you are most interested in, you will consider different things as the reaction of the page.
In the following, we will see what this “reaction” can be and why.
It’s called this way the time it takes for the browser to begin the render. In this case, the reaction we are looking for is the rendering of the initial containing block.
This is the time it takes for the first content to be displayed on screen. It’s when the browser first paints any text, image, non-white canvas or SVG. As I found out recently this is very different from the first meaningful paint (which we’ll see right after), as it doesn’t imply the usefulness of the content being rendered. Think empty headers or background images.
If you’re doing things right, the FCP is probably going to be your App Shell, or part of it.
In the image you can see that — sadly — for this site WebPageTest.org reports the First Paint to happen at 4.3s on a Moto G on a 3G connection. It’s the first time that the user can see anything on screen, it’s the very first thing different from the blank screen.
It’s the time it takes to paint content that’s meaningful to the user. That’s when the things the user navigated for are actually ready. It’s not your App Shell, it’s something more: it’s content, text, an article, an image, anything that can be consumed by the user.
The FMP is the bit that people actually wanted to use, not just your app shell (Paul Lewis)
What I outlined above are, in my opinion, the most useful metrics that you can make use of when profiling your site. However, there are plenty of other metrics: here’s a perfect visualization of the full journey by Addy Osmani
In addition to all of these, you can still measure more. There’s no limit to it. You can count the number of HTTP requests, consider the global weight of the page, and much more. Your creativity is really the limit here.
The more I work on performance, the more I realize the real importance of having measurements to refer to. Everytime I approach a problem without a proper metric, I end up tweaking in the wrong places of the project. I learned the hard way that you have to always start with profiling. Two things happen for free from the moment you have proper data to work with:
That’s why a proper performance based strategy heavily relies on continuous assessment. It sets a clear performance budget, meaning the constraints your product is expected to meet, it gathers relevant metrics on every commit, and it compares with the budget.
I hope you found this helpful! Follow @westwingsols for daily #WebPerformance tips. If you think this might be useful to someone you know, please share it to let us reach more people! Also, we’d love to hear your feedback on this type of articles. Is it helpful? Would you rather read something more practical or theoretical? Let us know, by leaving a comment on Twitter!
If you feel this might interest someone else, please leave an heart to help us reach more people! Comments and thoughts are appreciated as well ;)
This article was originally published on the West Wing Solutions blog, a collection of learning material for professionals who are eager to explore the science behind building a successful online product.