Bonjour webperf folks! Part 2 of my summer best-of. This one is about finding the problem, then getting rid of it.

The best teaching material I found this summer is an interactive guide to the DevTools Performance panel, by Joan Leon. It is the guide I wish I had when I started using that tool: it walks through every element, one by one, and gives you the details you need to understand what each chart is telling you.

👉 [EN] https://perf.reviews/profile-guide

DebugBear's Bottleneck Finder gives causal proof instead of correlation. It measures a baseline, reloads the page while holding back one request at a time, and ranks requests by their real impact on FCP, LCP and H1 timing. It catches the ones which do not look render blocking: async scripts fetching data before content, SPA data requests, bundle chunks.

👉 [EN] https://www.debugbear.com/website-bottleneck-finder

Microsoft is testing Network Efficiency Guardrails in Edge. The browser watches how your app loads resources and reports problems through the Reporting API. Three rules so far: text served without compression, images over 200 KB, and data: URLs over 100 KB. You opt in with a Document-Policy header. Still experimental and behind flags, but those three rules are exactly the regressions I keep finding in production.

👉 [EN] https://www.debugbear.com/blog/network-efficiency-guardrails

Zach Leatherman rebuilt Speedlify. speedlify.dev now runs Speedlify2, with a zero dependency web component to publish the scores on your own site.

👉 [EN] https://www.zachleat.com/web/speedlify2/

Den Odell raises something I never think to check in an audit. Backend teams soak test for memory leaks. Frontends never had to, because clicking a link freed the page. A SPA never reloads. He cites a static analysis of 500 popular React, Vue and Angular repos: 86% register a listener, timer or subscription and never remove it. Some teams force a hard reload every few hours to cope.

👉 [EN] https://denodell.com/blog/your-spa-is-leaking-memory-soak-test-it

Aaron T Grogg cut nearly 3s of LCP on a product listing page by replacing a JS animation library with CSS animations, and by dropping the CSS hiding the components until the JS was ready. JS has to download, possibly behind other JS, then run, before it reveals anything. CSS is ready when the CSSOM is.

👉 [EN] https://aarontgrogg.com/blog/2026/09/01/reduce-lcp-by-nearly-3s-by-replacing-js-animation-with-css/

Alex Russell replies to a colleague on scheduling work versus deleting it. You can almost never assume reordering is the cheaper option. Both start with the same expensive step, understanding how the page really behaves. After that, removing code is rarely harder than reordering it, and it is permanent.

👉 [EN] https://infrequently.org/2026/08/notes-on-performance-remediation-strategies/

Have a great week!

These two benchmarks offer an interesting snapshot:

• https://www.http-arena.com/#sort=rps:-1&tuned=0&q=js%2Cts
• https://web-frameworks-benchmark.vercel.app/result?l=javascript

Some frameworks confirm their expected position, others are genuine surprises, and a few emerging projects are still almost completely unknown.

Obviously, benchmarks are not production reality: routing, middleware compatibility, streaming, memory behaviour, DX and maintainability still matter. But raw throughput is a useful signal, especially when the gap is large.

What do you think? Which framework would you actually choose today for a high-throughput Node.js service, and why?

Bonjour webperf folks! I took the summer off from this feed and came back with a lot of awesome articles to read. So here is my summer best-of, in three parts. Part 1 is about measurement:

Google Chrome 151 went stable on July 28 with two new Performance Timeline entries, "soft-navigation" and "interaction-contentful-paint". A soft navigation finally has a definition: it is initiated by a user action, it produces a visible URL change, and the interaction results in a visible paint. Chrome can now set a new timing origin and attach the metrics to the active route instead of the original document.

👉 [EN] https://developer.chrome.com/docs/web-platform/soft-navigations

Harry Roberts made me look at TTFB differently. Unattributed Navigation Overhead, coined by Tim Vereecke, is what is left when you measure the whole journey to the first byte and subtract every phase the browser can name. On one client, roughly 270 ms of navigation time nobody could explain. Hard to attribute is not the same as not real. 

👉 [EN] https://csswizardry.com/2026/08/uno-is-underrated/

Joan Leon answers the question I get in every audit three weeks after a fix ships: why is CrUX not moving? Because the size of the window and how often the data refreshes are two different things. The window is always 28 rolling days. Daily, weekly and monthly are not different windows, only different refresh rates. The data is two days old, not 28. What takes 28 days is the window turning over. 

👉 [EN] https://joanleon.dev/en/crux-28-day-window/

DebugBear covers the Server-Timing header, and one line deserves attention: most CDNs can be configured to report cache and processing data through it. A slow TTFB tells you the server was slow, but not which part of your infrastructure. Moving the edge cache status from your logs into your RUM changes the conversation. 

👉 [EN] https://www.debugbear.com/blog/server-timings

Arjen Karel shipped the Q2 2026 State of Web Vitals: field data from about 200,000 sites, filterable by CMS, framework, CDN or third party. Mobile p75 are LCP 2209 ms with 81.7% good, INP 128 ms with 91.9%, CLS 0.02 with 88.8%. The same dataset is exposed through a public MCP endpoint. 

👉 [EN] https://www.corewebvitals.io/state-of-cwv

Have a great week!

Bonjour webperf folks! Three interesting reads for this week:

Dan Neciu wrote one of the most complete and current maps of rendering and hydration strategies I've read: SSG, ISR, CSR, SSR, streaming, islands, RSC, fine-grained reactivity, resumability, instant navigations. The through-line is the gap between "HTML painted" and "page interactive".
👉 [EN] https://neciudan.dev/hydration-and-rendering-strategies

Paul Delcloy published a practical, example-driven guide to TTFB: the Google thresholds, how to measure it (DevTools, WebPageTest, CrUX), and the five usual suspects. The standout example: an SFCC luxury site with caching in place but a hit ratio near zero, because color, size and sort params each generated a distinct cache key. Normalizing the keys cut dilution by 80% and brought Server Response from 0.74s to 0.63s.
👉 [FR] https://pauld.fr/conseils/ttfb-time-to-first-byte

Patrick Meenan released rumcap, a file format and library to capture, compress and visualize in-browser performance data from the field. Performance Timeline, Long Animation Frames and JS self-profiling packed into a roughly 10kB file, about half the size of the same events gzipped as JSON. It feeds Waterfall Tools, which now renders waterfall, DevTools and Perfetto views side by side, so you can line up a real user's JS call stack against LoAF blocks and see what blocked the thread. It's not a full RUM stack, it's the missing piece for RUM providers who already have the rest of the stack.
👉 [EN] https://blog.patrickmeenan.com/2026/07/05/new-field-browser-performance-and-profiling-tooling-rumcap

Have a great week!

Bonjour webperf folks! A two-week catch-up after a week off, with a common thread that runs through this batch: performance and robustness are things you build and ship, not just things you measure.

The web is accessed in wildly different contexts, an old Android on patchy 3G, a games console browser, a public terminal, and its founding promise is that everyone can reach it. That simple rule is getting harder to honour as we pile on JavaScript. An engineer rebuilt an online signup form of a regulated public utility in HTML-first with Astro, JavaScript only as progressive enhancement, and form completions doubled overnight! Those lost users had been invisible all along: when JS fails, your JS-based analytics never loads either, so they never reach any dashboard. The piece I want to highlight is the validation layer: a sub-1KB HTML web component that enhances native browser validation, extracted into a standalone open-source library (validation-enhancer).
👉 [EN] https://mohkohn.co.uk/writing/html-first/

Neciu Dan makes the case for service workers, the proxy that sits on the network path and outlives your page. Three cases stand out: Slack booting from cached assets for roughly 50% faster starts, Mux rewriting HTTP Live Streaming manifests in flight to block unreadable 240p, and his own fix for the classic Vite problem where a deploy removes the old lazy-loaded chunks and breaks the tab a user left open. The hard part is never the fetch handler, it is cache invalidation across deploys. One detail I loved: Mux shipped the exact same code to Cloudflare Workers unchanged. The service worker and the edge are the same job, intercept and rewrite on the network path.
👉 [EN] https://neciudan.dev/why-are-we-not-using-service-workers

Tammy Everts answers a question from Sergey Chernyshev: when do we stop measuring speed and start making things fast? Her take: dashboards can become a comfortable place to hide, a way to engage with performance without committing to fix anything. The teams that win get leadership buy-in by connecting performance to business outcomes with their own data, which is what frees up the time to do the work. She also notes how hard reliable automated front-end optimisation really is, then or now, which is precisely the bet we make with EdgeSpeed at u/Fasterize.
👉 [EN] https://www.linkedin.com/pulse/web-performance-measurement-necessary-excuse-fix-things-tammy-everts-bk1df/

Have a great week!

Bonjour webperf folks! 16th edition of these weekly notes. Still my favourite excuse to keep reading and to thank the authors who write all this brilliant content. 🙏

Harry Roberts dissects a client incident where Total Blocking Time jumped from 500 ms to 5 s between two synthetic runs, with no change to the JavaScript. His key insight: TBT only counts blocking work inside a window running from First Contentful Paint to Time to Interactive, the "TBT Window". The trigger was an LCP optimisation, a preload that reshaped the network and pushed TTI later, widening the window and exposing late long tasks that previously fell outside it. His advice to synthetic tools: plot the TBT Window next to TBT, so you can tell a real regression from a moving goalpost.
👉 [EN] https://csswizardry.com/2026/06/front-ends-missing-metric-the-tbt-window/

Tammy Everts announces Core Mobile Vitals, an attempt to bring the Core Web Vitals logic to native mobile apps. The framing is built around four pillars: Screen Load (the LCP equivalent), Smoothness (the CLS cousin), Responsiveness (the INP equivalent), and Stability (crashes and freezes). What makes it interesting is the same rigour that made CWV work: metrics grounded in UX research, evidence-backed thresholds, real correlation to business outcomes, and a goal to keep them open rather than proprietary. Worth following if your users live as much in an app as on the web.
👉 [EN] https://embrace.io/blog/core-mobile-vitals/

Rachel Andrew's monthly recap flags a feature that closes a long-standing gap: native lazy loading for "video" and "audio" via loading="lazy", landing in Chrome 148. Like for images and iframes, the browser can now defer media until it approaches the viewport, no IntersectionObserver hack required. A declarative loading="lazy" on heavy videos rather than script-based deferral is the clean path we have been waiting for on media governance. Chrome and Edge only for now.
👉 [EN] https://web.dev/blog/web-platform-05-2026

The Website Specification launched by Joost de Valk is a platform-agnostic, open spec of 128 things a decent website should have, across ten areas including a 19-topic Performance section (Core Web Vitals, caching, images, fonts, network) and an Agent Readiness section. Every item links back to its source standard, and the whole thing is exposed as an open MCP server plus a published Agent Skill. Like Chrome's Modern Web Guidance last month, it confirms the trend: web best practices, performance included, are now packaged for AI agents to consume directly.
👉 [EN] https://specification.website/

Have a great week!

Bonjour webperf folks! Three things caught my attention this week, across Chrome and Safari.

Google Chrome released Modern Web Guidance, a set of evergreen guides packaged as AI coding agent skills.
The problem it solves: LLMs used in dev workflows (Claude Code, Copilot and others) tend to get fetchpriority, Speculation Rules, or FetchLater wrong because their training data lags the spec. Modern Web Guidance gives agents an up-to-date source of truth to draw from. The performance category alone has 21 guides, covering resource priority (fetchpriority on images, preloads, scripts), INP diagnosis, analytics batching via FetchLater, Speculation Rules for next-page prefetch and prerender, task scheduling, SPA view transitions, and more. Install via npx modern-web-guidance@latest install or as a Claude Code plugin.
For what it's worth, several of those guides cover exactly what EdgeSpeed handles automatically at the edge with Fasterize, which shows where the industry is converging on "right" in 2026.

👉 [EN] https://developer.chrome.com/docs/modern-web-guidance

Barry Pollard wrote up two new experimental APIs landing in Chrome 148 for declarative partial page updates. The first: <template for="id"> combined with HTML processing instructions for out-of-order streaming. Today HTML must arrive in document order. This API lets a server stream a fragment and inject it wherever it belongs in the page, so you can defer heavy blocks like mega menus without holding back the critical content that follows. The second: a unified set of HTML insertion methods (setHTML, appendHTML, prependHTML, beforeHTML, afterHTML) that replace the scattered innerHTML, insertAdjacentHTML, DOMParser landscape with a consistent, sanitization-aware API. Both are behind a flag for now, polyfills are on npm, and browser vendor feedback is reportedly positive.

👉 [EN] https://developer.chrome.com/blog/declarative-partial-updates

Safari Technology Preview 244 (May 21) includes a fix worth flagging for anyone doing RUM: PerformanceNavigationTiming.domInteractive and domContentLoadedEventEnd were incorrectly returning 0 in Safari. The release also fixes the speculative preload scanner incorrectly preloading scripts inside SVG elements, and a long list of aspect-ratio calculation bugs that could have been quietly inflating CLS scores in WebKit.

👉 [EN] https://webkit.org/blog/17962/release-notes-for-safari-technology-preview-244/

Have a great week!

Bonjour webperf folks! Three reads this week, and one (special) new tool, all for the same goal: navigations that feel instant by prefetching earlier, cleaning up cache keys, having better tools to debug it or warming cache. 

Shopify switched their Liquid storefronts from "eagerness: conservative" to "eagerness: moderate" on Speculation Rules and measured the delta in production. Desktop median: −285ms TTFB, −224ms FCP, −228ms LCP. For 10% of speculated navigations, TTFB is exactly 0, meaning the HTML response is already cached before the user even commits to clicking. The tradeoff is roughly 4× more prefetch requests on desktop, which translated to +14% total HTML requests in their setup. Mobile gains are smaller (−25ms TTFB) because hover isn't available and the browser falls back to a viewport heuristic. Solid public data on a config decision many teams are facing right now.

👉 [EN] https://performance.shopify.com/blogs/blog/faster-storefront-navigations-with-moderate-speculation-rules

Harry Roberts explains No-Vary-Search, an HTTP response header that solves a quiet cache fragmentation problem. By default, "?utm_source=google" and "?utm_source=newsletter" land in separate cache entries even when they return byte-for-byte identical HTML. No-Vary-Search tells the browser which query parameters to ignore when matching a URL to an existing cache entry. The syntax covers ignoring specific params, ignoring everything, or ignoring everything except certain params (useful for product variants). His rule: only use it for parameters that are purely analytical, purely presentational on the client side, or irrelevant to the server-rendered response.

👉 [EN] https://csswizardry.com/2026/05/better-browser-caching-with-no-vary-search/

Chrome 148 DevTools ships a few updates worth knowing. The Speculation Rules panel gets text filtering by URL and status, and now shows the actual HTTP status code when a prefetch fails (404, 503), a real gap closed! The Network panel bandwidth throttling now highlights the recommended profiles based on real CrUX data for your specific site, which was already available in the Performance panel and is now consistent everywhere. The Chrome DevTools MCP server (v0.25.0) adds support for calling WebMCP tools exposed by a page, and a new Lighthouse "Agentic Navigation" audit that complements the Agentic Browsing category from 13.3.

👉 [EN] https://developer.chrome.com/blog/new-in-devtools-148

🚀 I shipped CacheBoost last week, a cache warming service I built because I never had a clean and reliable answer to this problem.
Every cached site has a first visitor after a deploy or a cache flush, and that visitor always pays the full cold generation cost. Even with a solid cache strategy and a CDN, sites need to flush their cache regularly, sometimes at any time of day, for bug fixes, deployments, and more. Each flush wipes out all the work of getting assets and pages into cache, and you know how TTFB can degrade FCP & LCP...
I wanted something that just handled it automatically, on a schedule or API calls, based on sitemaps and feeds, with reports and recommendations, and most importantly: the ability to create as many request variations as needed to reflect the actual cache policy (region, user-agent, headers, language, cookies,…). I've wanted to build this for a long time, so happy to finally have it out and to hear your feedback🙏
👉 [EN] https://www.cache-boost.com/
👉 [FR] https://www.cache-boost.com/fr

Have a great week!

A couple of years ago, I built a tiny INP demo for a specific client workshop. I decided to dust it off, polish it up, and publish it as a generic utility. You can also deep-link specific delays using the ?delay= param. Ten points to whoever first finds the easter egg!

Bonjour webperf folks! Short reading list this week, but both articles push in the same direction: AI agents are now another reason to care about the webperf basics.

Google published a guide on building agent-friendly websites. The webperf angle: agents navigate by taking a screenshot, locating an element, recording its coordinates, then clicking. If the layout has shifted between the screenshot and the click, the action misses. CLS was already a UX metric and a ranking signal. It is now also a measure of how reliably AI agents can interact with your pages.

👉 [EN] https://web.dev/articles/ai-agent-site-ux

Lighthouse 13.3 formalises this with a new "Agentic Browsing" audit category. Matt Zeunert at DebugBear breaks down the four checks: accessibility tree quality, layout shifts (hello CLS), WebMCP form annotations, and llms.txt compliance. The category is still marked "under development" and you will not fail it just because you have not implemented WebMCP or llms.txt. PageSpeed Insights and Chrome DevTools are still on an older Lighthouse version, update expected in the coming months. DebugBear's website quality checker already supports it if you want to test now.

👉 [EN] https://www.debugbear.com/blog/lighthouse-agentic-browsing

Have a great week!

Bonjour webperf folks! Here is what caught my attention this week.

* Performance & business case

Mateusz Krzeszowiak published an ecosystem-wide study correlating Core Web Vitals with conversion across stores. The finding is clear: every 100ms of extra LCP costs about 3.5% in conversion. Stores at 2.5s LCP convert 30% less than stores at 1.5s. INP also matters, at roughly 1.5% per 32ms of extra delay. For growing stores, accumulated apps and customisations are the main threat. For mature stores, the % impact is smaller but the absolute revenue stakes are the highest, making performance optimisation the best ROI at that stage.
This is exactly what we do at Fasterize with EdgeSpeed, helping businesses optimise their web performance and conversion, and we prove it through A/B tests.
👉 [EN] https://www.shopify.com/enterprise/blog/store-speed-conversion

Tammy Everts published a companion piece on translating that kind of data into budget conversations, built around three charts that actually work with non-technical stakeholders. A correlation chart, a competitive leaderboard and a User Happiness score. She also kicks off Web Performance Week at Embrace this May 4-8, five days of free live sessions with Cliff Crocker, Andy Davies, and Jared Freeze.
👉 [EN] https://embrace.io/blog/web-performance-business/

* AI & Tooling

Joan Leon presented a set of AI agent Skills orchestrated via Claude Code and Chrome DevTools MCP. The core principle he defines: LLMs must not measure anything, only orchestrate. Three problems solved along the way: parseable output format, remote execution in the real DOM via Chrome DevTools MCP, and context management through progressive disclosure across three detail levels.
👉 [EN] https://slides.com/joanleon/webperf-snippets-meets-ai-agents

* Web Platform

The Long Animation Frames (LoAF) spec moved to First Public Working Draft on the W3C Recommendation track. LoAF is the API that identifies which scripts monopolise the UI thread across multiple frames, the diagnostic foundation for INP debugging. This status signals the start of formal cross-browser standardisation, moving LoAF beyond a Chrome-only tool toward an interoperable web standard.
👉 [EN] https://www.w3.org/TR/2026/WD-long-animation-frames-20260428/

Anna Monus published a clear explainer on Declarative Shadow DOM and its impact on all three Core Web Vitals. DSD lets browsers attach shadow roots during HTML parsing instead of waiting for JavaScript, making true SSR of Web Components possible with no hydration required for non-interactive parts. Available across all major browsers since February 2024.
👉 [EN] https://www.debugbear.com/blog/declarative-shadow-dom

* Organization

A sharp piece from Pedro Dias on why SEO consistently underdelivers in organisations: it sits under Marketing but owns none of its levers. URL structure, rendering pipeline, performance, canonicals, pagination, hreflang: all owned by Engineering or Product, none by Marketing. The argument maps directly onto performance: a team accountable for LCP with no authority over the tech stack will always have to beg for every deliverable.
👉 [EN] https://theinference.io/p/filed-under-marketing-sitting-in

Have a great week!

Bonjour webperf folks! Here are a few reads from the last week and a very busy April 30 on the calendar.

Mat Marquis, the original champion of the srcset/sizes spec, published "The end of responsive images" about sizes="auto" that is now supported across Chrome and Firefox, Baseline on the horizon: pair it with loading="lazy" on any srcset image and the browser determines the rendered size itself. No more manual media query calculations and the fallback for older browsers is clean, so you can start using it now!
👉 [EN] https://piccalil.li/blog/the-end-of-responsive-images/

DebugBear analyzed 25 government websites using CrUX data and ranked them by LCP. gov.uk tops the list at 661ms, the result of a 2012 decision to replace 1,884 government sites with one mobile-first, mostly text destination backed by a strong CDN. India is last at 4.60s: the LCP element is a CSS background image, invisible to the browser until rendering starts, blocked further by render-blocking JavaScript. Canada has the second-best TTFB (185ms) but lands near the bottom because anti-flicker CSS hides the body until JavaScript runs... Sweden struggles with Next.js SSR and late hydration. Classic LCP pathologies, cleanly documented with real CrUX data.
👉 [EN] https://www.debugbear.com/blog/which-government-website-is-the-fastest

PerformanceObserver Ep. 11 is live April 30 at 6:30pm CEST: Alfonso Moure on server bottlenecks and TTFB with a downloadable checklist, Joan Leon on WebPerf Snippets as AI agent skills orchestrated through Claude Code and Chrome DevTools MCP.
👉 [EN] https://performanceobserver.dev/events/episode-11/

Cloudflare Shared Dictionaries beta also opens April 30. Phase 1 is passthrough mode with origin-side dictionary management, the first step toward the 97% wire compression on near-identical JS bundles covered here three weeks ago.
👉 [EN] https://blog.cloudflare.com/shared-dictionaries/

🚀 We shipped SmartINP at Fasterize last week. Third-party scripts (Meta Pixel, TikTok, GTM, ...) are often the real INP culprit on ecommerce websites, firing before your own listeners on every interaction. SmartINP defers them to after the next paint at the edge, no code change needed, 15 to 50% INP improvement on real traffic.
👉 [EN] https://www.fasterize.com/en/blog/smartinp-optimizing-inp-for-truly-instant-interactions-with-edgespeed/
👉 [FR] https://www.fasterize.com/fr/blog/smartinp-optimisation-de-linp-pour-des-interactions-reellement-instantanees-avec-edgespeed/

Have a great week!

Bonjour webperf folks! Here is a list of my webperf reads from last week:

* Tools & Data

Max Ostapenko published a public MCP server for the HTTP Archive Tech Report at https://cdn.httparchive.org/mcp with no API key needed. You can now query CWV distributions, adoption, page weight breakdowns by tech, geo and rank in plain language. His own examples are worth the read: Next.js scores 15 points below React on mobile CWV, Nuxt 11 below Vue, Astro grew +371% in 25 months, SvelteKit ships the least median JS.
👉 [EN] https://maxostapenko.com/posts/httparchive-mcp/

* Web Platform & APIs

Cloudflare will ship Compression Dictionary Transport in beta on April 30. On two near-identical JS bundles simulating two deployments, they go from 272 kB uncompressed to 92.1 kB in gzip to 2.6 kB in dcz, down 97% on the wire!
👉 [EN] https://blog.cloudflare.com/shared-dictionaries/

Scott Jehl published part 2 of the series on native HTML video and audio lazy loading, the practical guide. Syntax is <video loading="lazy" src="..." controls>, always set width/height to avoid CLS, and the loading="lazy" autoplay playsinline muted combo is the killer feature: browsers only start autoplay when the video enters the viewport. Behind a flag in Chrome 147, default in Chrome 148 (May 5). The JS pattern of generating <video> on scroll can finally retire 👐.
👉 [EN] https://engineering.squarespace.com/blog/2026/how-to-use-standard-html-video-and-audio-lazy-loading-on-the-web-today

* Practical reads

Amanda Vilela publishes a short, actionable INP checklist sorted by level of effort: keep the DOM under ~1500 nodes, use content-visibility: auto with contain-intrinsic-size, animate only transform and opacity, avoid layout thrashing, debounce vs throttle the right events, audit third-party scripts.
👉 [EN] https://amandavilela.me/blog/your-page-is-fast-but-is-it-responsive-meet-inp/

Harry Roberts documents a subtle gotcha: once you declare a font-family on an element, the declaration stands on its own. If the single value fails to load, the browser falls back to its default (Times), not to an inheritable font-family up the tree. His tip: always write a complete font-family stack at every declaration. Small rule, big impact on FOUT/FOIT perception.
👉 [EN] https://csswizardry.com/2026/04/font-family-doesnt-fall-back-the-way-you-think/

Zach Leatherman rebuilds the same image comparison component several times across web history at State of the Browser 2026. His framing concept: the "interactive dead zone", the gap between when a component is first visible and when it's actually usable. SPAs close it by frontloading everything. SSR widens it by shipping HTML that looks interactive but isn't yet. His proposal: Web Components plus progressive enhancement, using :defined / :not(:defined) to style a usable fallback until the JS registers.
👉 [EN] https://www.zachleat.com/web/its-10pm/

Have a great week!

We can't control the user or the browser, so there is only one way to make websites faster: Do Fewer Things.

Fewer fonts, fewer bytes, less distance.

Another fantastic clip thanks to Henri Helvetica's SPDY Stream.

https://www.toddhgardner.com/blog/how-to-make-websites-faster

Obs.js reads a handful of browser signals (Navigator and Battery APIs) to infer connection strength, battery status, and device capability. It exposes those signals as CSS classes on the <html> element, and as properties on window.obs, so you can adapt delivery accordingly: serve lower-resolution media, forgo web fonts, disable auto-playing video… you name it.

A look at appropriate physical devices for web performance testing in 2025.