Hi <<First Name>>,
This month's roundup of web performance and observability goodness includes some helpful how-to pieces:
- Cultivate "stubborn empathy" for your users
- Understand how the 28-day rolling window in CrUX affects your ability to see the impact of performance optimizations
- Use Core Web Vitals subparts to debug issues
- Fight the "double HTML" pattern
- Why your page may stay the same but your test results change
- What you need to know about JavaScript in 2026
And some compelling arguments for thinking about performance in new ways:
- Shift your focus away from Lighthouse
- Make performance a feature you build into your product, not something you fix later
- Don't optimize: delete
- Build mental software models in the age of AI
I hope you enjoy reading and watching these pieces as much as I did.
If you have any questions or feedback, I'd love to hear from you. And if you have any great resources you think belong in the next edition of this newsletter, please send them my way!
Until next month,
Tammy
@tammyeverts.com
|
|
|
Stubborn empathy
This inspiring talk – given by Tim Kadlec at performance.now() last October – is a reminder that performance work is ultimately about people, not milliseconds. Tim argues that we need to foster "stubborn empathy" for users, and that two forces are making that harder:
- Increasing monoculture around the web platform
- Rise of machine-generated software
Tim makes a particularly good connection between cross-browser testing and user advocacy: if we don't test the experiences we're not seeing ourselves, can we really advocate for those users?
|
|
|
The CrUX 28-day rolling window
Joan León tackles one of the most confusing things about CrUX: why you can ship a fix, see it working in the lab, and then stare at the CrUX number for weeks wondering if anything happened. The key distinction is between the 28-day window and how often the data is published. I particularly love Joan's framing of CrUX as the scoreboard, not the feedback loop.
Takeaway: If you want to get a more immediate sense of how your performance optimizations affect your metrics, use RUM instead of CrUX.
|
|
|
Guide: How to use Core Web Vitals subparts to debug performance issues
A Core Web Vital tells you that something is wrong. Its subparts can tell you where to start looking. Andy Davies walks through using LCP and INP subparts to move from "this page is slow" to "aha, this is the bit that's eating all the time." It's a nice practical guide to turning RUM data into an actual debugging plan.
|
|
|
Same page, different test results?
Why can you test the exact same page twice and get wildly different performance results? This piece digs into the non-deterministic nature of browsers – including one particularly nasty pattern where multiple versions of an image are downloaded even though only one will ever be displayed. It's a good reminder that sometimes "measurement noise" is actually telling you something helpful about how the page is built.
|
|
|
The wicked reason removing code beats better scheduling
Alex Russell makes the case for a radical performance strategy: delete stuff. Rather than endlessly trying to schedule, prioritize, defer, and otherwise cajole a mountain of code into behaving itself, sometimes the biggest performance win comes from eliminating work altogether. This is an inspiring antidote to the idea that every new performance problem needs a yet more sophisticated optimization trick.
|
|
|
Frontend Observability Week!
So excited about this! FOW is a FREE virtual mini-conference that's dedicated to frontend observability for web and mobile. The lineup includes luminaries like Annie Sullivan (Google), Alex Russell (Microsoft Edge), Paul Calvano (Etsy), Jonny Thompson (Target) and more! Reserve your spot here.
|
|
|
This “double HTML” pattern must stop!
Aaron T. Grogg has a delightfully cranky take on a pattern I see all the time: putting both the mobile and desktop versions of an image in the HTML and using CSS to hide whichever one the browser doesn't need. The problem? The browser may download both anyway. Aaron explains why this bloats the page, wastes bandwidth, and can actually hurt LCP – and then points out that HTML's <picture> element already exists to solve the problem.
|
|
|
The hidden quality risks in AI-agentic development
|
|
|
What to know in JavaScript (2026 edition)
Chris Coyier has put together a sprawling-but-readable tour of the JavaScript landscape in 2026: new language features, React/Vue/Svelte, Node, Vite, TypeScript, testing, meta-frameworks, npm, and (inevitably) AI. I like this as a "what the hell is happening in frontend?" piece rather than a deep dive into any one technology. It's especially useful if you've lost track of which framework/toolchain is doing what to whom.
|
|
|
|
