Fast Train

How fast is your website?

We all know that faster is better but how fast is fast enough? The unsatisfying, squishy answer is, as fast as you can make it without sacrificing the user experience. If you want a number from Google, they want to see page load times of 2 seconds or less, which is a lot faster than most websites. A 2016 study found:

  • if your site loads in 5 seconds, it is faster than approximately 25% of the web
  • if your site loads in 2.9 seconds, it is faster than approximately 50% of the web
  • if your site loads in 1.7 seconds, it is faster than approximately 75% of the web
  • if your site loads in 0.8 seconds, it is faster than approximately 94% of the web

Some load time factors are out of your control, such as the speed of the visitor’s computer and internet connection, network congestion and the efficiency of your website’s hosting platform. However, there is much you can do and endless information online about how to do it. In all cases though, the first step is to find out how fast your site loads now.

Speed testing methods

It’s important to realize that the experience you have looking at your site on your own computer will not be the same as that of your visitors. The biggest difference will be for those visitors on mobile devices, using a cellular data connection. Any information you gather about page loading time needs to be adjusted for these different devices and connections. Luckily, the testing methods below take these differences into account.

Google Audits

Google uses its own speed testing tool, called Lighthouse, in a number of products. I like using their Page Speed Insights page, because it tests both desktop and mobile at the same time. Just enter your website’s URL into the text box and click the “Analyze” button.

Google likes to score things, so at the top of the results page is an overall score based on the measurements that were taken of your site. These metrics and their relative importance change over time, as Google teams research and gather feedback to understand what has the biggest impact on user-perceived performance. As of this writing, the overall score is a weighted average of these metric scores:

Here’s how Google describes the top two metrics:

Largest Contentful Paint

Largest Contentful Paint (LCP) is an important, user-centric metric for measuring perceived load speed because it marks the point in the page load timeline when the page’s main content has likely loaded—a fast LCP helps reassure the user that the page is useful.

Total Blocking Time

TBT measures the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses. The sum is calculated by adding the blocking portion of all long tasks between First Contentful Paint and Time to Interactive. Any task that executes for more than 50 ms is a long task. The amount of time after 50 ms is the blocking portion. For example, if Lighthouse detects a 70 ms long task, the blocking portion would be 20 ms.

Following the performance section are diagnostics, which include Google’s recommendations for improving performance. Some of these are quite technical and should be referred to your developer. They will know which ones are out of your control and where you can make meaningful improvements.

Web based test

There are many web based speed tests that can measure your site’s performance but the one I like best is the aptly named WebPageTest. From this site’s home page you can select the location from which the test will take place and the browser type it will use to connect to your site. In the advanced section, I like to select “First view and repeat view”, to see the page load times for both a new visitor to your site and one who has visited before and already has some of your content in their browser cache.

One of the key results of a speed test is called the waterfall view. This graphs the amount of time it takes to load every element of the page, including text, graphics, scripts and other outside resources. For example, during the recent redesign of the Webdancers site, I noticed an abnormally long load time coming from Google Fonts. Further investigation revealed that the form plugin for my mailing list was loading dozens of fonts, on the off chance that I might want to use one of them. By coding this form manually instead of using the plugin, none of those extra fonts were loaded, improving page load time across the entire site.

Most likely culprits

Fixing slow websites is a topic for another day but if you’re looking for somewhere to start, take a look at:

  • Image optimization
  • Page caching instructions sent to browsers
  • Minify CSS and JavaScript
  • Server-side caching
  • Minimize the use of outside resources (see font example above)

Note: this post first appeared in the weekly Webdancers Newsletter. If you’d like to see more like this in your inbox, please subscribe.

Leave a Reply

Your email address will not be published. Required fields are marked *