In this article, Damien Jubeau (founder and CEO of Dareboost) discusses the various pitfalls to be avoided in order to effectively measure and optimize the speed of your Web pages. You will also discover 4 performance indicators to bear in mind, (TTFB, Start Render, Visually Complete, and Speed Index) with some valuable advice for interpreting them correctly.

“We can only improve what we measure”. This is an essential saying to apply if you want to speed up the loading of your web pages.

First, knowing what we measure!

We will start this presentation of the main speed indicators by setting the record straight on the infamous load time. In fact, this notion must be considered very cautiously.

Indeed, not everyone is talking about the same thing when they use the term, “load time”! In (too) many cases, people will in fact be talking about the response time of your server, or other partial measures. So be sure to verify the information provided by the measurement tool you are using regarding its methodology and what it measures exactly.

  • At Alexa, you learn, for example, that the loading of images and other stylesheets is not included in the speed measurements that the site returns” “The load time of an individual page is how long it takes for the DOM -¬ the structure of the page – to be loaded. This measurement doesn’t include the time taken to load all images and stylesheets, for example.”
  • On Dareboost, the “load time” indicator corresponds to the full loading of the page, and the tool waits to do this until the network traffic linked to loading the page is interrupted. Therefore, of course, this includes the loading of CSS, Javascripts, etc., but also all associated dependencies, as is the case for your visitors!

As for the tools that don’t give you information on test conditions or on the type of indicators measured, we can only urge you to greatly mistrust the reliability of the information provided.

Another reservation regarding load time: it is rarely relevant today for evaluating the actual performance of your pages, particularly in the area of user experience (UX). In fact, a typical web page loads over a hundred different resources, with more and more asynchronous behaviors and progressive loading. Because of this, measuring the time needed to fully load the contents of a page becomes less and less revealing of what occurs for the user.

Start Render, Visually Complete and Speed Index for UX

What other indicators should we turn to? To get as faithful an image possible of the user experience, we recommend you pay attention to the following 3 indicators, derived from the video analysis of the loading of a web page:

  • Start Render: this indicator measures the delay before your page starts rendering. Before this, the user is looking at a blank page. In fact, the shorter this delay is, the less your visitors risk being frustrated and subject to bouncing to other websites. It should be noted that the render start does not mean that the elements that are displayed are relevant or useful to the user: something has started to render, this can be as simple as a little bit of text or almost your whole page!
  • Visually Complete: this is the time needed to fully render the area located above the fold (the portion of the screen visible without scrolling) – one way of focusing on what is immediately necessary for the visitor!
  • Speed Index: this performance indicator transcribes the render speed of the visible portion of the web page tested (above the fold). Thus it takes into account the gradual rendering of the different components of the page. This gives the Speed Index the reputation for being the most revealing indicator of the user experience. Benchmark: a page whose elements above the fold render in 1 second will get a Speed Index under 1,000. This is a reference point that Google also recommends on the subject.

TTFB: the basis of your performance


In addition to these UX indicators, and to monitor its technical performance over the first step of loading your page, we recommend you look to TTFB. Time To First Byte measures the time between the query and the HTTP response, i.e., the time needed for your visitors’ browsers to receive the start of the HTML code for your webpage through your Web application or CMS. In fact, this indicator will give you information on the performance of your scripts (e.g., the time your CMS will take to produce the page requested) and the hosting. Note however: to find out the real processing time at the level of your server, you should subtract network latency from the TTFB, i.e., the time it takes the data to go through your server and the visitors’ web browser.

In addition to indicating the technical performance of your hosting and your backend application, TTFB is important to observe because of its potential impact on your site’s SEO. This is all the more so true if your site contains a large number of pages: the higher your TTFB, the less the Google bots can visit the pages in the time budget the search engine has given you for the crawl.

Even if TTFB is important, it should be looked at in relative terms: an excellent response time from your server does not in any way guarantee the speed of your site. Steve Souders, one of the gurus of web performance, has even come up with a golden rule: 90% of the wait perceived by web users is found in the subsequent steps, during frontend processing. Therefore it is important to follow TTFB in parallel, but also more UX oriented indicators like those mentioned earlier.

Measuring speed: pay attention to context!

Now that you have a clearer idea of the indicators to choose in order to monitor the performance of your website, you will now need to precisely determine how to take these measurements. Any negligence on this point can lead to significant bias in your results and in the analyses you make from them!

  • First, pay special attention to the methodology used by the measurement tool you are using. As mentioned above in this article, all services available online do not measure the same indicators on the same way! As much as possible, focus on tools that clearly display their methodology and which enable you to conduct tests under conditions closer to the actual conditions of your users. Example: Dareboost web performance tests are conducted with real browsers used by the general public (Google Chrome) and not with simple robots.
  • Not all visitors have the same web access conditions, far from it. Browsing from a mobile device or a computer, from France or abroad, using a fiber, DLS, or lower connection or 3G: there are many different browsing conditions that have a very heavy impact on the loading speed of your webpages for your visitors. Consequently, it is essential for you to be able to evaluate the performance of your web pages under different conditions. And in particular those of your strategic targets. So make sure that your tool can vary these test parameters in order to get you as close as possible to the browsing conditions of your visitors.
  • Lastly, keep in mind that the performance of your pages isn’t set in stone! As content is published, features are added, updates and other revisions are made, the loading speeds of your site will inevitably evolve. It is up to you to implement a monitoring strategy adapted to your situation, in order to monitor the changes in your performance and to detect any regressions. In short, go from occasionally measuring the speed of your page to monitoring your web performance, over a frequency more suited to the stakes of your business.


To properly measure the loading speed of your web pages:

  • Take your measurements under contexts that are realistic, stable, and representative of your audience.
  • Select the appropriate indicators. Consider the user experience, not just technical performance: don’t limit yourself to a single indicator.
  • Your site evolves, and so does its speed: keep a watchful eye on this, and be up to the stakes of your site.

Check out Dareboost, the online service specializing in performance tests and website analysis

Find out more