Arrange a Masterclass

Measuring the Hard-to-Measure

Written by on CSS Wizardry.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples

Table of Contents
  1. Beacons and Tracking Pixels
    1. Update 2018-03-01 12:53:00 UTC
  2. Print Stylesheets

Last night I gave a performance-oriented talk at the wonderful DaFED event in Novi Sad, Serbia. In the talk, I go into detail about third parties, and how they can have tremendous negative impact on our performance. I also mention that, sometimes, it’s more important to think about resilience than speed. For example, what happens to us if a third party script fails to load? Can we recover from that? What happens if a third party has an outage? Do we suffer the effects of it?

This led to a great question from Dragan along the lines of Nowadays, how important is it to test sites with JavaScript disabled? It’s certainly a thought-provoking question, but I won’t be going into my answer in this post. Instead, I want to talk about being able to measure just how many users do have JavaScript disabled. Most analytics software is powered by JavaScript, so detecting JavaScript becomes self-fulfillingly impossible. I want to share an incredibly quick tip to measure how many of your users turn up on a device with no JavaScript capabilities…

Beacons and Tracking Pixels

I recently wrote an article about finding dead CSS by using a tracking pixel… we can use almost the exact same technique to detect non-JavaScript browsers:

<noscript>
  <img src="/pixels/no-js.gif" alt="" />
</noscript>

Now, any browsers that have JavaScript disabled will make a request for no-js.gif, and all we need to do is check our server logs after a few months and we’ll get a rough idea of just how many users arrive with JavaScript disabled. Based on this data, you can make much more informed decisions about your policy for non-JavaScript users.

I set up a local server to test this out. After disabling JavaScript and visiting the relevant test page, sure enough, no-js.gif began to appear in my logs:

A screenshot
  showing non-JavaScript browsers making HTTP requests for a specific tracking
  pixel.

Update 2018-03-01 12:53:00 UTC

Ryan makes a great point:

Might be worth noting on your new article that you’ll want to set a far-future Cache-Control expiry header for the no-js.gif (or even use immutable) if you want to count the number of users without JS rather than counting the number of pageviews.

In recent discussions with the NHS, a client of mine, we wondering whether a print stylesheet would be appropriate. Most of the discussion centred around hypotheticals and maybes: I can imagine x user might want to print y information. These were sensible and educated guesses, but guesses nonetheless. Let’s gather some data:

@media print {

  html::after {
    content: url('/pixels/print.gif');
  }

}

Note that most printers will not print background-images and -colours by default, so we insert the image via content rather than, say, background-image.

Now, whenever someone wants to print our page, a request for print.gif will fire off and we can capture that information: we can make informed decisions about if and how to implement a print stylesheet, and how much effort we should put into it.

Once again, I built a quick demo to test it out. Expectedly, as soon as I hit ⌘+P, a request for print.gif fires off:

A screenshot
  showing how printing a page makes an HTTP request for a specific tracking
  pixel.

While tracking pixels are far from a new idea, there are creative ways in which we can use them to collect data useful to developers. Once the data is gathered, we can begin to make much more informed decisions about how we work.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples




By Harry Roberts

Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.


Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.

You can now find me on Mastodon.


Suffering? Fix It Fast!

Projects

  • inuitcss
  • ITCSS – coming soon…
  • CSS Guidelines

Next Appearance

Learn:

I help teams achieve class-leading web performance, providing consultancy, guidance, and hands-on expertise.

I specialise in tackling complex, large-scale projects where speed, scalability, and reliability are critical to success.