When you measure client-side performance, there are usually two main categories of visitors: those who visit your page the first time and others who have already visited our page and have some data cached. By convention, those groups are named correspondingly: first view and cached view (which also is known as “repeat view” or “second view”).

As the name suggests, the first view is a situation, when a user opens your website for the very first time and no files or cookies are stored in her or his browser to improve the experience. In that case, the browser needs to download the page code as well as all the resources required to render the page (images, CSS, JavaScript).

Chrome dev tools Network tab with no effective cache. A dozen images are downloaded over HTTP, each taking dozens or hundreds of milliseconds.

A cached view is a situation when the user opens a page that already was visited and some resources are saved in the browser. The repeat view is usually much faster than the first view.

Chrome dev tools Network tab with cache enabled. A dozen images are loaded from memory in negligible time (0ms each).

A known fact is that measuring a webpage first view is the only way to truly replicate what a real first-time user is experiencing. And that experience is measured by tools like sitespeed.io, Lighthouse, WebPageTest.

On the other hand, developers usually put a lot of effort into optimizing caching (using proper Headers, cache layers such as Content Delivery Network (CDN) or even using Service Workers in Progressive Web App (PWA)).

In this short blogpost, I will show you how to use an open-source tool sitespeed.io to measure client-side performance in the situation when a user returns to the page.

Running the tests

Starting tests with sitespeed.io can be simplified using Docker. You can run tests with a default configuration by executing the following command:

docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:13.3.2 https://tech.cognifide.com/

After a while, you will have a report generated and stored under sitespeed-result/tech.cognifide.com.

But that will measure only results for the page that was visited for the first time.

Testing cached view

In sitespeed.io there are currently two ways to warm-up cache before visiting the website, both use additional parameters passed to the sitespeed.io container:

  • preUrl
  • preScript

We can distinguish two sub-scenarios:

  1. The user visited one page and then another (only the common assets are cached).
  2. The user visited the same page more than once.

PreURL

Sitespeed.io docs summarize preURL as follows:

--browsertime.preURL, --preURL A URL that will be accessed first by the browser before the URL that you wanna analyse. Use it to fill the cache.

The docs also recommend using the --preURL parameter to test cached pages (read more in sitespeed.io best-practices). And that is perfectly fine in most of the cases when we talk about the first sub-scenario (warming-up cache with a different page than the one we want to test).

However, when warming up the cache with exactly the same page you would like to measure (the second sub-scenario) there is a small problem with gathering visual metrics - they might not work (all visual metrics such as FirstVisualChange or SpeedIndex will display 0ms). This is a side-effect of the way Chrome and the sitespeed.io --preURL mechanic work together. You can read more about that in the getting correct visual metrics section of the documentation.

PreScript

Another way to manipulate the browser's cache before the actual tests start is to specify a preScript:

--browsertime.preScript, --preScript Selenium script(s) to run before you test your URL. They will run outside of the analyse phase. Note that --preScript can be passed multiple times.

And in most cases that would be the way you might want to prepare your test because it gives you a lot more control than the previous option. For example, a simple script that you can use to warm-up cache in the browser and make your visual metrics work could look like this:

module.exports = async function(context, commands) {
  let urlToWarmUp = context.options.urlToWarmUp;
  context.log.info('Warming up cache for page: ' + urlToWarmUp);
  await commands.navigate(urlToWarmUp + '?warmup=true');
  // Remove body of the page for visual metrics to start with blank view
  await commands.js.run('document.body.innerHTML = ""; document.body.style.backgroundColor = "white";');
};

With such a script (saved as warm_up_cache.js) you can simply run the tests:

docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:13.3.2 \
    --preScript warm_up_cache.js --browsertime.urlToWarmUp https://tech.cognifide.com/ \
    https://tech.cognifide.com/

You noticed the warmup=true param, right? It is there because sitespeed.io uses the page's URL as a unique identifier (which makes a lot of sense). When running the same URL for warming-up the cache like the one you want to test, some metrics (especially those connected with page's HAR) may start too early. Just by adding this query param, sitespeed.io recognizes both URLs as different pages.

Why cached page performance is worth testing

You may ask, why measure cached page performance at all? There are at least a couple of good reasons why it is worth doing:

  • Assuming you are building a website that is going to keep users for a longer time and make them come back - some very good part of your users will experience a cached view.
  • As mentioned above, your team is putting a lot of effort into caching strategies. That's worth checking if more work is required or the level of satisfaction for the cached view has been met (make sure you have a way to measure your satisfaction level).
  • Some tools that focus on the first view also check the best practices and optimisation techniques for the cached view. But they are only checks (if best practice was applied). Measuring it is a different thing and only by running such tests, you can simulate what a real user is experiencing.

Summary

In this blogpost, I explained the difference between the first and cached view in terms of the user’s experience. While most of the available client-site performance testing tools focus on the first view, it is also worth measuring the repeat view user’s experience. That can be fairly simply achieved with open-source tools like sitespeed.io.

But that's not the end. As the next step, you may extend measurements into monitoring and continuously check trends of your page's performance (for first and repeat views). Sitespeed.io is also a great tool for that combined with metrics DB (e.g. InfluxDB) and visualization tool (e.g. Grafana).