Quicklink case study: faster pages, increased page views
Quicklink is a lightweight library created by Addy Osmani (Google) that prefetches pages linked to the current page, as the links to those pages enter the visible portion of the page (viewport).
We used Quicklink on some of our ecommerce websites to improve the rendering time of our product detail pages (PDPs), with good results both on performance and business KPIs.
The test
As we aimed to reduce the rendering time of PDPs, Quicklink was activated on product listing pages (PLPs) for all the links pointing to PDPs. In this way, while users browse through our products, QuickLink pre-fetches the HTML code of PDPs and stores it in the browser cache (or the service worker cache) for later usage.
How we measured impact
Short answer: A/B testing in the field.
After we experimented with the feature and got good results on lab tools such as Google Lighthouse and Sitespeed.io, we measured performance improvements in the field: real users on real devices and real network conditions. There are many tools to measure website performance in the field, such as Akamai mPulse, Dynatrace, Raygun, and Google Analytics.
The tools we used are:
- Akamai mPulse to get performance KPIs.
In particular, we measured page rendering speed using the Largest Contentful Paint web vital on the PDPs visited by users with an internal referrer (to exclude users who landed directly on the PDP). - Google Analytics to get user behaviours and business KPIs.
Specifically, we measured the click-through rate (CTR): the number of clicks to a PDP that occurred after visiting a PLP.
When measuring performance in the field — where users come at different times of the day, from different countries, and with different devices and network speeds — A/B testing performance is the only way to get clean results, excluding every other factor from the test.
By performance A/B testing I mean publishing two versions of the website, one (control) not containing the improvement and another one (test) containing the performance improvement, and that must be the only difference from the control version. In addition, the tests must be run in the same conditions (same period, same group of pages, same users base), and the traffic must be split equally between version A and version B, in order to get about 50% of the users on each version.
We collected data about performance and users behaviour, tagging the data with the A/B version it was collected from.
The tests were run for enough time to collect data to produce a statistically meaningful result. Depending on the website’s traffic, they were run from two to four weeks.
Results
At the time of writing, we’d activated Quicklink on a dozen of our websites. Here is what we achieved on average:
Half rendering time = 2x perceived speed
Rendering time was reduced by 50% both on smartphones and computers.
A website that was visually ready in 800 ms without Quicklink started to be visually ready in 400 ms after we enabled Quicklink.
Improving rendering time has a positive effect on the LCP (which is a core web vital) and ultimately on SEO.
Increased click-through rate (CTR)
The percentage of users who visited a PDP after visiting PLP increased by 2%.
In other words, our users visited more product detail pages with Quicklink enabled than after.
Be aware of the load
Quicklink brings performance and business improvements, but beware of the load it generates on your infrastructure, since it multiplies the requests to your PDPs. Make sure you test your infrastructure before activating Quicklink.
If your website is static, meaning the pages are generated at build time, the cost of using Quicklink will probably be only a network / CDN cost.
If your website is dynamic, meaning the pages are generated as users request them, a good caching strategy is fundamental. Without caching, there will be a server cost in terms of CPU, API consumption, Database access, locking time, etc., and the response time of your server might become longer, or worse.
Some data here:
- Tripled the network requests to our PDPs (3x)
- Tripled the CDN offload, the % of the pages served from our CDN edge servers without hitting our server farm (3x)
- Doubled the requests to our server farm (2x)
If you want some advice:
- Choose wisely the options to configure Quicklink (next chapter)
- Run a significant load test before activating Quicklink in production, to avoid discovering too late that your infrastructure doesn’t scale nicely.
Also, consider costs and benefits that might derive from scaling the infrastructure.
Optimal options
Quicklink has 3 main options we can use to control how aggressive it is:
throttle: the number of network requests that Quicklink can run in paralleldelay: the number of milliseconds a link must stay inside the viewport before it can start prefetching itthreshold: a number from 0 to 1 that expresses the portion of the link area (its pixels) that must have entered the viewport to be considered
Of course, those options have an impact on one another, for example if you set throttle to 4 but don’t set any delay, Quicklink would be busy fetching links that might have already exited the viewport, making it useless. And threshold is very useful to make Quicklink concentrate only on links that are truly in-viewport, and ignore the ones that are just slightly appearing.
What is the best mix of those 3 options? To help myself understand, I put together a simple POC to understand how Quicklink behaves with different combinations of the them, and find the optimal configuration of Quicklink.
🎮 Play with it and find your configuration | 👨💻 Fork it on Github
After a couple hours spent creating the POC and playing with it, I think I found the the optimal configuration for most of our PLPs.
const quicklink_options = {
throttle: window.innerWidth < 500? 4 : 8,
delay: 500,
threshold: 0.9
}The throttle value depends on the screen width, because more links fit on larger screens and we don’t want the queue to clog.
Conclusion
Quicklink makes sure that our product detail pages are loaded much faster and users are more engaged.
Be sure to set it up properly and to test your infrastructure against the increased load.
The rollout of Quicklink proved to be another success of our Performance Guild, as well as CLS optimisation and capping image fidelity. Stay tuned for more!
If you also have tried Quicklink or you have questions, let us know in the comments!
