# NEW! Canonical: https://brew.new/browse/templates/email/pt1_k97hxnmysmcat90ztbp771vyx98e58h9 Brand: speedcurve.com Category: newsletter ![Preview of NEW!](https://cdn.brew.new/email-preview-0224dab933fb78d5-tracking_r57pg003vs2t1kejg4a18sj9kn8dvzy3-1789060939883.png) ## Email content Hi John, 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. Shift focus from Lighthouse to Core Web Vitals and RUM If you've ever watched someone obsess over getting a perfect Lighthouse score while the actual site still feels slow, this talk by Joshua Clare-Flagg is for you. Joshua makes the case for shifting our attention from synthetic scores to Core Web Vitals and real-user data, with some good examples of why a perfect Lighthouse score doesn't necessarily mean your users are having a great experience. 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. Fast by default Den Odell takes aim at the all-too-familiar cycle of ship → users complain → panic → fix → repeat. His answer is to make performance part of how software gets designed, built, tested, and maintained in the first place, rather than treating it as an emergency repair job. I particularly like the idea that "fast" should be an architectural property, not something we try to bolt on at the end. 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 element already exists to solve the problem. The hidden quality risks in AI-agentic development Ethan Gardner doesn't argue that we should stop using AI to write software. He asks a much more interesting question: what happens when the person using the AI no longer has a strong mental model of the system the AI is building? Ethan's concern is that agentic development doesn't eliminate the old cost/quality trade-off. It can simply hide it, making defects harder to trace back to their source. This one gets at some of the less obvious risks of the current "just let the agent build it" enthusiasm. 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. New research: The Core Web Vitals thresholds you trust may be wrong for your site What is OpenTelemetry? A plain-language guide for beginners Putting users first: What does "reliability" mean today? Copyright © 2026 SpeedCurve Limited, All rights reserved. Unsubscribe from this list. [Open and remix this design](https://brew.new/browse/templates/email/pt1_k97hxnmysmcat90ztbp771vyx98e58h9) [Browse email designs](https://brew.new/browse/templates)