惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

L
Lohrmann on Cybersecurity
Martin Fowler
Martin Fowler
Engineering at Meta
Engineering at Meta
腾讯CDC
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Microsoft Azure Blog
Microsoft Azure Blog
G
Google Developers Blog
TaoSecurity Blog
TaoSecurity Blog
博客园_首页
Vercel News
Vercel News
Hugging Face - Blog
Hugging Face - Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Last Week in AI
Last Week in AI
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
T
The Exploit Database - CXSecurity.com
量子位
Project Zero
Project Zero
A
Arctic Wolf
小众软件
小众软件
NISL@THU
NISL@THU
C
CERT Recently Published Vulnerability Notes
有赞技术团队
有赞技术团队
MongoDB | Blog
MongoDB | Blog
博客园 - 聂微东
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
N
News and Events Feed by Topic
宝玉的分享
宝玉的分享
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Troy Hunt's Blog
P
Privacy & Cybersecurity Law Blog
Security Latest
Security Latest
B
Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
D
DataBreaches.Net
Schneier on Security
Schneier on Security
The Hacker News
The Hacker News
K
Kaspersky official blog
C
Check Point Blog
Hacker News: Ask HN
Hacker News: Ask HN
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Webroot Blog
Webroot Blog
www.infosecurity-magazine.com
www.infosecurity-magazine.com
人人都是产品经理
人人都是产品经理
AI
AI
Cisco Talos Blog
Cisco Talos Blog
MyScale Blog
MyScale Blog
Cloudbric
Cloudbric
B
Blog RSS Feed
S
Schneier on Security
P
Palo Alto Networks Blog

CSS Wizardry

Front-End’s Missing Metric: The TBT Window Meet Your Users Where They Are with Obs.js Better Browser Caching with No-Vary-Search font-family Doesn’t Fall Back the Way You Think What Is CSS Containment and How Can I Use It? When All You Can Do Is All or Nothing, Do Nothing Obs.js: Context-Aware Web Performance for Everyone Low- and Mid-Tier Mobile for the Real World (2025) The Fastest Site in the Tour de France Making Sense of the Performance Extensibility API Why Do We Have a Cache-Control Request Header? HTML Is Not a Programming Language… Build for the Web, Build on the Web, Build with the Web Licensing Code on CSS Wizardry A Layered Approach to Speculation Rules Designing (and Evolving) a New Web Performance Score Core Web Vitals Colours The Ultimate Contract Templates for Tech Consultants: Protect Your Business and Get Paid Optimising for High Latency Environments Cache Grab: How Much Are You Leaving on the Table? blocking=render: Why would you do that?! Correctly Configure (Pre) Connections The Three Cs: 🤝 Concatenate, 🗜️ Compress, 🗳️ Cache What Is the Maximum max-age? How to Clear Cache and Cookies on a Customer’s Device The Ultimate Low-Quality Image Placeholder Technique Core Web Vitals for Search Engine Optimisation: What Do We Need to Know? The HTTP/1-liness of HTTP/2 In Defence of DOM­Content­Loaded Site-Speed Topography Remapped Why Not document.write()? Speeding Up Async Snippets Critical CSS? Not So Fast! Measure What You Impact, Not What You Influence Optimising Largest Contentful Paint Measuring Web Performance in Mobile Safari Site-Speed Topography Speed Up Google Fonts Real-World Effectiveness of Brotli Performance Budgets, Pragmatically Lazy Pre-Browsing with Prefetch Making Cloud.typography Fast(er) Time to First Byte: What It Is and How to Improve It Self-Host Your Static Assets Tips for Technical Interviews Cache-Control for Civilians Bandwidth or Latency: When to Optimise for Which ITCSS × Skillshare What If? CSS and Network Performance The Three Types of Performance Testing Getting to Know a Legacy Codebase Image Inconsistencies: How and When Browsers Download Images Identifying, Auditing, and Discussing Third Parties My Digital Music Setup Finding Dead CSS The Fallacies of Distributed Computing (Applied to Front-End Performance) Ten Years Old Relative Requirements Airplanes and Ashtrays Performance and Resilience: Stress-Testing Third Parties Refactoring Tunnels Little Things I Like to Do with Git Writing Tidy Code Configuring Git and Vim Base64 Encoding & Performance, Part 2: Gathering Data Base64 Encoding & Performance, Part 1: What’s Up with Base64? Code Smells in CSS Revisited Typography for Developers Moving CSS Wizardry onto HTTPS and HTTP/2 Ack for CSS Developers A New Year, a New Focus Preparing Vim for Apple’s Touch Bar Choosing the Correct Average CSS Shorthand Syntax Considered an Anti-Pattern CSS Wizardry Newsletter Nesting Your BEM? Improving Perceived Performance with Multiple Background Images Continue Normalising Your CSS Pure CSS Content Filter Pragmatic, Practical, and Progressive Theming with Custom Properties Refactoring CSS: The Three I’s Speaker’s Checklist: Before and After Your Talk Improving Your CSS with Parker The Importance of !important: Forcing Immutability in CSS Mixins Better for Performance Managing Typography on Large Apps White October Events Workshop Partnership BEMIT: Taking the BEM Naming Convention a Step Further Travelling Like You Want to, When You Have To Contextual Styling: UI Components, Nesting, and Implementation Detail Subtleties with Self-Chained Classes Cyclomatic Complexity: Logic in CSS Immutable CSS Can CSS Be Too Modular? More Transparent UI Code with Namespaces When to use @extend; when to use a mixin The Specificity Graph CSS Wizardry Ltd.: Year 1 in review CSS Guidelines 2.0.0
Measuring the Hard-to-Measure
Harry Roberts · 2018-03-01 · via CSS Wizardry

Written by on CSS Wizardry.

Table of Contents

Independent writing is brought to you via my wonderful Supporters.

  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.