Page speed is one of the most important metrics in technical SEO today. Users expect a page to load fast, and are quick to abandon pages that take too long to load; in fact, a study for one online retailer found that just a 1-second increase in page load time resulted in a 56% increase in bounce rate.
Since page speed is such an important user experience factor, Google has been using it as a ranking factor in desktop search since 2010. Recently, Google announced that starting in July 2018, page speed will be a ranking factor in mobile search as well; this is particularly important in light of Google’s move to mobile-first indexing.
With this in mind, it behooves marketers on the modern web to keep a close eye on page load time and page speed metrics.
Google Analytics and PageSpeed Insights
When tracking page speed, the first place most marketers will look is at the Site Speed report in Google Analytics:
This report will show you the average page load time, in seconds, for pages across your site; it’s an easy way to spot any anomalies. You can also drill down into individual page timings, to find pages that take significantly longer than the rest of the site to load.
Note: If you’re using the Site Speed report regularly, you may want to consider increasing the sample rate. By default, Google Analytics only samples 1% of users to gauge Site Speed; increasing the sample rate will give you a larger sample size, which may result in more accurate data. Get the code here.
The Site Speed report is a great overall snapshot of how fast your site is loading; it also dovetails nicely with the PageSpeed Insights report, which will load your page in real-time and give you suggestions for improving page load time.
To access PageSpeed Insights, open the page in question in a Chrome browser window, then select View > Developer > Developer Tools > PageSpeed Insights.
In my opinion, there are two big problems with relying solely on the Site Speed report in Google Analytics and on PageSpeed Insights for speed optimization recommendations:
- PageSpeed Insights’ recommendations focus on how to make the existing page, with all its assets, load faster; often, bigger speed improvements can be made by changing what is on the page.
- Both the Site Speed report and PageSpeed Insights focus on the time it takes the page to fully load, which provides an incomplete picture of a user’s experience as the page loads. Looking at average page load time also obscures the fact that different users may experience dramatically different load times based on their device, browser, and connection.
Fortunately, Chrome Dev Tools now includes a new tool called Lighthouse Audits.
While some of the audits included in Lighthouse are less useful than others (their “SEO” audit, for example, provides a woefully incomplete picture of the factors that impact performance in organic search), their Performance audit is a great look into more granular page speed metrics, particularly those that matter on a mobile device, where page speed becomes even more important. Let’s take a look at some of these metrics:
User-Centric Page Speed Metrics
Time to First Byte
What it is: Time to First Byte, or TTFB, is pretty self-explanatory: it’s the time it takes for the very first byte of your page’s data to be delivered to to the browser requesting it.
How to optimize for it: Ideally, your TTFB should be under 200 milliseconds; if that’s not possible for your site, aim for a TTFB of under 500 milliseconds. Since TTFB is, in part, a measure of your server’s responsiveness, there may not always be much you can do to improve it, short of switching servers or hosting providers. However, you can often improve TTFB by optimizing your existing server, and by leveraging caching to reduce the portion of your page that needs to be served dynamically each time the page is loaded.
First Paint
What it is: The first time anything appears on the screen; the first point at which the screen can said to be something other than “blank.” If you can’t make your page fully load any faster than it already does, you may be able to give users the impression that the page is loading faster by optimizing your time to first paint, reducing the amount of time that they spend staring at a blank screen.
How to optimize for it: Removing render-blocking scripts from the head of your document is a web performance optimization best practice in general, but one benefit of doing so is it will make your time to first paint faster. You may want to look at inlining key styles in the head, so they can begin displaying before your full stylesheet has loaded.
First Meaningful Paint
What it is: Whereas first paint just means that anything has appeared on the screen (which often means it’s a background color or other not-very-useful item), first meaningful paint measures when the page first becomes useful in a meaningful way. This often means that the main page content is displaying, or at least has started to be displayed. Most people who regularly use a mobile browser have, for example, been able to start reading an article before the page an article is on has finished loading. This is another way to give users the impression that your page is loading faster than it really is; once the content the user is there to see has started loading, they may not care or even notice that the rest of the page is continuing to load.
How to optimize for it: Make sure your “hero” content loads as early in the page load process as it can. Consider delaying code that isn’t necessary to display the main content, so that code doesn’t load until after the main useful content has finished loading.
Time to Interactive
What it is: Like Time to First Byte, Time to Interactive (TTI) is pretty self-explanatory: it’s the time it takes for your page to be able to receive user input in some way, whether that’s through clicking, scrolling, playing a video, etc.
How to optimize for it: Having a fast TTI is good (for all of these metrics, the rule of thumb should be “faster is better”), but almost as important is making sure that the time between your first meaningful paint and your TTI is as short as possible. Nothing’s more frustrating to users than seeing a link, and being able to click on it; or reading an article, but being unable to scroll down. To optimize for interactivity, make sure that the code that makes elements visually render and the code that makes them able to receive input load in short succession. You should also avoid long tasks that can tie up the main thread and prevent interactivity, by breaking large chunks of code into smaller pieces that can then load asynchronously. Finally, wherever possible, reduce your page’s dependency on third-party resources to load, as these can tie up the main thread as well.
Optimize the Waterfall
Lighthouse Audits are a great free tool to start digging into some of these more advanced page speed metrics. At UpBuild, we also use a tool called GTMetrix. Registered users of GTMetrix can view page performance timings; their free tool also allows you to view a page’s waterfall, a chart of all the resources a page loads in the order they load.
It’s a great way to quickly spot resources that are blocking the rest of the page load, so they can be deferred or broken up into smaller tasks.
