In the never-ending pursuit of speed, us site builders trundle our hamster wheels round an array of different technologies. Image compression, JavaScript and CSS minification, CDNs, conformance with web standards, server cacheing and response times, redirect reduction and the removal of render-blocking are some regular issues.


As part of this month’s turn on the wheel, I’ve been having a close look at the Quicklink module, available for Backdrop and for Drupal. These modules make use of Google Chrome Lab’s Quicklink library, which is a lightweight JavaScript library which prefetches during idle time any links in the browser’s viewport, enabling faster subsequent page-loads.

There is a Chrome Quicklink Extension that offers this for the browser — and therefore for all websites — and reviews there show that the extension has recently been given a prefetch maximum of 5 URLs within the viewport, but this maximum does not apply to the Drupal and Backdrop modules. If you attach this functionality to your website, for every page that a user visits, Quicklink will also download all pages linked from it that are in the viewport.

The TL;DR is that the Quicklink module will definitely speed up your website and appear to improve your users’ experience of it. But there are some gotchas, so read on.

Because Quicklink uses prefetch behaviour, it works client-side, instructing the user’s browser to cache pages that the user might visit next. To visualise this, first choose a widget that displays live download statistics. (Windows Task Manager will do.) Then view a page of a site that has Quicklink installed. The site map page of this website demonstrated this best because of the quantity of links that is contains. You’ll see an initial spike in download data as the page loads. This will be substantially in excess of the size of the page itself, as the links visible in the viewport are also pulled in. Let that spike fall back to zero then scroll down the page to see the numbers rise once again as more links are consumed into the browser’s cache. Repeat the delay-then-scroll until you reach the bottom of the page. Here’s a screenshot of Windows Task Manager’s logging of this activity:

Screenshot of Windows Task Manager looging the scroll of a page with Quicklink configured

Viewed from a speed-freak perspective, this is welcome stuff. Site owners can speed up their websites by forcing their visitors’ browsers to do a lot more work behind the scenes. No matter that all these URL resources will have been consumed. The lucky link that the user might click next will have been prefetched and ready to go. Everything will be so much more responsive — and it really does work.

Viewed from an alternate perspective, not all that processing would have accomplished anything. Only a small sub-set of the links prefetched will end up being clicked. The rest of the downloaded resources will remain unused. More to the point, users on mobiles with metered data contracts will be paying for data whether they use it — or like it — or not. Website owners with Quicklink installed may hit hosting bandwidth ceilings if these are part of their contracts or may have to pay for increased traffic and server loads, as would be the case, for example, with Pantheon where plans are expressed in the number of visits and pages served per month. (See the Pantheon plan prices to appreciate this.) Furthermore, although this technology doesn’t trigger click events, it will affect server-based analytics.

There are more potential downsides to installing the Quicklink module to a website than first meets the eye. The best that could be said is that you shouldn’t install this module at all. At a pinch, install the extension for Chrome. The thinking here is: do it to yourself; don’t do it to others. Quicklink is no longer installed on this site!

Website Carbon

All of which brings me to the Website Carbon Calculator, whose widget you may have spotted newly-installed at the bottom of the pages of this site. Your best introduction to WCC is to go there and test any web page that you frequently view. After a short test delay, the calculator will give you a measure of how ‘clean’ or how ‘dirty’ that page is, using the following metrics:

  • A green or red result score showing that the page is cleaner/dirtier than x% of web pages tested (by the WCC). This is therefore a relative measure not an absolute one.
  • How many grams of CO2 are produced every time someone visits the page.
  • Whether the site is running on sustainable energy (as reported to the Green Web Foundation).
  • How much CO2 that page will produce if viewed c.10,000 times a month, measured in kilograms, sumo wrestlers (one of which lurks in the home page icon for this post) and cups of tea.
  • How many trees would be needed per year to absorb the above CO2.
  • How much energy this represents, expressed in kWh and miles driven in an electric vehicle.

There’s no charge for using this service and you can retest pages. Just note that each page result is cached for that day. If you’ve made a change to a page (making it ‘cleaner’, presumably), then don’t re-test by hitting F5. Just wait until the next day. Better still, install the widget, which they call a ‘badge’.

Does the fact that I’ve installed the Website Carbon Calculator badge on this website mean that I’m holier than thou? Almost certainly not! But I hope its presence there will be a permanent reminder to me to think about the issue of internet energy use and do something about it. What I do notice is that the ‘dirtiest’ pages on this site are the ones that use big image files. Where I have made them available in a lightbox which users can choose to view — or leave alone, then this sort of page scores a cleaner score than ones that impose these bigger images on users whether they want them or not. But I knew that anyway. I am now reminded by the WCC widget every time I revisit these pages, which I hope may nudge me to do something about it.

Of course, adding the WCC widget will in itself produce a bit more CO2 as the call to the WCC code each day a page is first viewed has a cost. With luck, the reminder to me and the message to the curious who spot the widget will spread the word and do enough good to offset that cost.

[Just note that the Website Carbon code for adding their ‘badge’ widget to your own website won’t validate. It throws an error because of an “illegal character in path segment”. To get round that you will need to encode the URL. At the time of writing, Backdrop is decoding the encoded URL before rendering it to the page, so the validation error persists. Note to self about this.]

You might like to follow-up the topic of internet energy use by checking out the post 17 ways to make your website more energy efficient by Tom Greenwood of Wholegrain Digital.

On balance

This twinned experiment seems to have yielded the best of both worlds. For a short while I discovered a blazingly-fast way of appearing to accelerate this website. Thinking it through, made me uninstall the Quicklink code and replace it with the Website Carbon Calculator code. I have a new perspective and the site has whatever speed it has. For some pudding proof, the site’s scores on Web Page Test remain unchanged:

Screenshot of Web Page Test results, November 2020

Further reading

  • Author Gerry McGovern writes about Webwaste on one of my favourite websites, A List Apart. He addresses the subject of site bloat and obesity in an engaging way. Should be mandatory reading for all site builders.
  • Hero of the web standards brigade, Aaron Gustafson, looks at caching strategies in Request with Intent: Caching Strategies in the Age of PWAs, also on A List Apart. This is more technical than Gerry McGovern’s post and is germane to the debate about what web builders should or should not cache.
  • A monetary calculator that shows what it costs users on mobile networks to access a web page: What Does My Site Cost?.