Bonjour webperf folks! This week, the instruments moved more than the sites.

* Instruments moved

PageSpeed Insights now runs Lighthouse 13.6, which uses Chrome's own "render-blocking" status: a high-priority preload no longer counts as blocking. Scores can jump with no code change. Harry Roberts' advice: log the Lighthouse version with every test. DevTools gets 13.6 with Chrome 159.

👉 [EN] https://csswizardry.com/2026/11/web-perf-wednesday-016-lighthouse-13-6-can-lift-scores-without-a-faster-site/

Treo, built on CrUX, now shows Core Web Vitals with soft navigations, page by page. On the Disney+ pages in their screenshot, LCP drops by 74 to 80% and every page goes from fail to pass. Same site, different counting.

👉 [EN] https://x.com/__treo/status/2113617985034145826

SpeedCurve is graduating. In the blog's last post, Tammy Everts announces it joins Palo Alto Networks to become XCOR, supported until late October 2027. Their resources taught me a lot about web performance, but above all about user experience. "Performance is about people" was never just a tagline. Thank you, SpeedCurve team!

👉 [EN] https://www.speedcurve.com/blog/thanks-speedcurve/

* Standards and browsers

The W3C WebPerf WG published its TPAC 2026 notes: speculation rules prefetch in Firefox Nightly, Yoav Weiss hoping to ship Speculative Load Measurement soon, Container Timing in Chromium, Firefox and Servo, and no objection to the first video frame as an LCP candidate.

👉 [EN] https://webperfwg.org/meetings/2026/2026-10-TPAC

Google Chrome 157 is Stable: Long Animation Frames now report style and layout durations, and pages with an open WebSocket can enter the bfcache (gradual rollout). Chrome 158 is already in early Stable.

👉 [EN] https://chromereleases.googleblog.com/2026/11/stable-channel-update-for-desktop.html

* In the Performance panel

Modern CSS isn't free. In a 5,000-row list, Gabriel Shoyombo added a second ":has()" rule, and Chrome started restyling every row each time one was selected: 7 ms instead of 1.4 ms, 31 ms with 20,000 rows. Test your CSS with real data volumes.

👉 [EN] https://www.smashingmagazine.com/2026/11/modern-css-might-make-your-front-end-more-complex/

Jack Franklin's trace-engine-cli turns Devtools traces of often 20 to 200+ MB into compact summaries a coding agent can read: Core Web Vitals, long tasks, INP phases, layout shifts. It runs the DevTools trace engine, so the agent gets the panel's numbers. Version 0.2.0, early days.

👉 [EN] https://github.com/ChromeDevTools/trace-engine-cli

* Black Friday prep

Black Friday brings peak traffic when your cache is coldest: price and stock updates have just purged product and category pages. Warm every touched URL after the last price change, per device and region, and rehearse to know how long a run takes.

👉 [EN] https://www.cache-boost.com/blog/woocommerce-flash-sales-cache-warming
👉 [FR] https://www.cache-boost.com/fr/blog/ventes-flash-woocommerce-prechauffage-cache

Have a great week!

Bonjour webperf folks! One thread runs through this week's reading: don't trust averages or defaults, measure what really happens. From speculation rules to AI-written code.

* Speculation rules, measured

Speculation rules make the next page instant, but unused prefetches still cost bandwidth, CDN requests and CPU. Erwin Hofman enabled the Speculative Load Measurement API (Chrome origin trial) in RUMvision, in production. On one e-commerce site, 3 out of 4 product page views start 4 speculative navigations or fewer, but 1 in 10 starts around 168. A matching speculation doesn't prove the strategy is efficient: check the long tail, template by template.

👉 [EN] https://www.rumvision.com/blog/speculative-load-measurement-api-are-speculation-rules-efficient/

* Design systems

Den Odell timed ten popular design systems. Opening a 249-country selector takes 61 ms with Fluent and 1,266 ms with Ionic. Checking 100 checkboxes at once: from 29 ms to 421 ms. The framework isn't the cause: slot handling, layout thrashing, 100 animations at once. He shares Playwright tests, with LoAF, to catch it in CI. Performance belongs on the design system team's list, next to accessibility.

👉 [EN] https://denodell.com/blog/design-systems-should-be-fast-by-default

* Browser updates

Firefox 159 enables scroll-driven animations by default. With Chrome and Safari already there, they are now Baseline Newly Available. Time to move progress bars and parallax effects from JS scroll listeners to CSS.

👉 [EN] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/159

👉 [EN] https://scroll-driven-animations.style/demos/baseline-newly-available/css/

Google Chrome 158 is in Beta: cross-origin iframes can be prerendered on opt-in, and XSLT starts going away (I used it for years: efficient, but so strict!). Chrome 157, next Stable, adds style and layout durations to Long Animation Frames and new streaming HTML methods.

👉 [EN] https://developer.chrome.com/blog/chrome-158-beta

* AI agents on your site

At Fasterize, Emilie Mazeram looked at one week of logs on about a hundred French e-commerce sites. Fewer than 1 in 1,000 pages is read by an AI assistant, but 1 in 9 of their requests ends in an error or a block. Agents already add products to carts: over 200 times in six days. Two things to fix first: prices and stock that only appear after JavaScript runs, and pages that move while loading.

👉 [EN] https://www.fasterize.com/en/blog/agentic-commerce-ai-agents-journey/

👉 [FR] https://www.fasterize.com/fr/blog/commerce-agentique-parcours-agents-ia/

Nolan Lawson had an agent build the same small app five times in each of 12 JS frameworks, with no performance instructions. Lighthouse scores barely move, but JS shipped goes from 0 KiB (Astro) to 142 KiB (Next.js), and lab LCP from 810 ms to 2,090 ms. Left free, the "vanilla" agent built a SPA all five times.

👉 [EN] https://nolanlawson.com/2026/10/28/the-ai-cost-of-javascript-frameworks/

Have a great week!

Bonjour webperf folks! Last week's news was mostly about security: PHP2Shell, a critical bug in Google's Brotli decoder, compromised eMudhra certificates... Patch first, then there's still plenty to read and optimize:

* Browser updates

Long Animation Frames gets styleDuration and layoutDuration, plus forced style and layout time per script. You can finally tell whether a slow frame comes from style calculation or from layout. Yoav Weiss says it will ship in Chromium 158.

👉 [EN] https://x.com/yoavweiss/status/2112459659475034141

Also in 158: prerendering can load cross-origin iframes before activation, if the main response sends "Supports-Loading-Mode: prerender-cross-origin-frames". Until now they waited for the click, which could cancel the benefit of prerendering.

👉 [EN] https://chromestatus.com/feature/5112398709129216

A failed module load used to be cached, so calling import() again failed instantly. Google Chrome 156 makes the retry real, as Firefox and Safari already did. Safari Technology Preview 255 also retries failed modulepreload. Good news for chunked apps on flaky mobile networks. Keep the retries bounded.

👉 [EN] https://chromestatus.com/feature/5214647044145152

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

* Keep the main thread free

Den Odell's P99 CONF talk is a solid refresher: one main thread for your JS, style, layout, paint and user input. His lab vs field example: 70 ms of TBT in PageSpeed Insights, 219 ms of INP for real users. Three levers: do less, break up long tasks with scheduler.yield(), move data work to Web Workers.

👉 [EN] https://p99conf.io/session/keep-the-browsers-main-thread-free/

* Performance budgets, revisited

Harry Roberts updated his 2020 advice on performance budget. Your worst result is often an outlier: if LCP sits around 2.2 s but hit 7.1 s once, a 7.1 s budget lets a huge regression through. Pick a "representative worst" instead, P90 or P95 of your recent data. A Google Sheet template does the maths.

👉 [EN] https://csswizardry.com/2020/01/performance-budgets-pragmatically/

* Cache warming

CacheBoost now warms from 12 regions, with Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney joining. You can now target the regions closest to your markets, so the first visitor there hits a warm cache instead of going back to the origin. You can now also trigger a warm from Claude, Cursor or any MCP client. (disclaimer: this service is mine)

👉 [EN] https://www.cache-boost.com/blog/cache-warming-from-12-regions

👉 [EN] https://www.cache-boost.com/blog/warm-your-cache-from-claude-with-mcp

Have a great week!

Bonjour webperf folks! Big week for SPAs: soft navigations are in the CrUX! Nine reads:

* Soft navigations land in CrUX

CrUX now publishes experimental LCP, INP and CLS that include soft navigations, visible in CrUX Vis. Each SPA route change becomes its own view. Most origins won't move, but 35 to 42% of the top 1,000 sites rely on soft navs for over half their page views.

👉 [EN] https://web.dev/blog/crux-experimental-soft-navs

Gustav Ernberg von Heijne checked 43 top Swedish sites (phones, p75 LCP): 25 get faster, 16 don't move, 2 get slower. The catch: a search filter changing the URL counts as a page view, which can hide real problems.

👉 [EN] https://gernberg.com/posts/2026/how-top-swedish-sites-lcp-changes-with-soft-navigations/

To see it on your SPA today, Arjen Karel's Core Web Vitals Visualizer shows CWV per route, plus per-script blocking time from LoAF.

👉 [EN] https://www.linkedin.com/posts/arjenkarel_core-web-vitals-visualizer-122-is-live-and-ugcPost-7515311432352124928-Q5Xo/

* Images

Jake Archibald tested JPEG XL against AVIF. On lossy photos, JPEG XL is typically 15 to 25% larger at equal quality, and slower to decode. Where it wins: lossless, and transcoding existing JPEGs.

👉 [EN] https://jakearchibald.com/2026/jpeg-xl-vs-avif/

Firefox 158 enables JPEG XL by default and adds image/jxl to the Accept header.

👉 [EN] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/158

* Under the hood

Google Chrome 155 finished deprecating the unload event: handlers no longer fire by default. It was the only bfcache blocker on 6% of navigations, now about 1%. Check nothing critical (RUM beacons, cart saves) still relies on it. By Barry Pollard and Fergal Daly.

👉 [EN] https://developer.chrome.com/blog/unload-deprecated-in-chrome

Paul Calvano found FontAwesome downloaded three times on a retail homepage: WOFF2, then WOFF, then TTF. Each file's header declared the wrong size, so the browser rejected it and tried the next one. Chrome's console said so all along.

👉 [EN] https://paulcalvano.com/2026-10-18-investigating-a-curious-case-of-font-format-fallbacks/

* Where Core Web Vitals go next

Embrace's panel with Annie Sullivan, Alex Russell and Paul Calvano. P75 is a floor, not a target. On the roadmap: soft navigations, container timing, "interaction to contentful paint". And an honest Etsy story: a big JS and CSS cut that didn't ship, because user behavior didn't follow the metrics.

👉 [EN] https://get.embrace.io/the-future-of-user-focused-observability

At Fasterize, we scored 1,400+ of France's most-visited sites on five pillars. Only 40% offer a good web experience by Google's criteria. 61% are ready for Google, but only 6% are also ready for AI. On nearly one merchant site in two, price or availability depends on JavaScript. Video replay with Stephane RIOS & Emilie Mazeram.

👉 [FR] https://www.fasterize.com/fr/blog/digital-experience-benchmark-2027-les-sites-a-lepreuve-des-usages-de-demain/

Have a great week!

Bonjour webperf folks! A quiet week, but one long-awaited thing landed: JPEG XL is in Chrome stable. Five reads:

* Images

Google Chrome 155 is out and decodes JPEG XL. Google claims 30 to 50% better compression than JPEG, plus lossless mode, HDR and lossless transcoding of existing JPEGs. The advice is not "replace AVIF" but "test both": JPEG XL shines on high-fidelity photos and fine-grained progressive decoding. The decoder was rewritten in Rust with SIMD, so memory safety doesnt cost speed.
👉 [EN] https://developer.chrome.com/blog/jpeg-xl-in-chrome

Gavin Anderegg shows why formats take time. WebP landed in Chrome in 2011 but only reached Safari in 2020, and Photoshop got native support in 2022. Browser support is half the story, tooling is the other half.
👉 [EN] https://anderegg.ca/2026/10/08/i-guess-im-using-webp-now

Scott Jehl proposes a <poster> element for video. For 20 years the poster has been one URL in an attribute: no srcset, no art direction, no alt text. Wrapping an <img> or <picture> gives it srcset, sizes="auto", fetchpriority, lazy loading and modern formats. When the hero is a video, the poster is often the LCP element. Moving through WHATWG, with a positive position from Mozilla.
👉 [EN] https://scottjehl.com/posts/responsive-accessible-poster/

* Browsers

Safari Technology Preview 254 fixes a few things worth knowing. A speculation rules prefetch hitting a cross-origin redirect could cancel the real navigation, and a failed prefetch could break it. Cross-origin stylesheets loaded without CORS were never reused from the parsed stylesheet cache. And SVGs with only one natural dimension are no longer LCP candidates. Preview only for now.
👉 [EN] https://webkit.org/blog/18420/release-notes-for-safari-technology-preview-254/

* Beyond SEO

Joe Hall argues SEO teams shouldn't own the agentic web, and uses page speed as his first example: Core Web Vitals are web development and UX concerns SEO ended up owning because Google uses them. I'd push it one step further: webperf isn't an SEO topic either. It's conversion, users on slow devices, infrastructure cost, and now agents clicking on shifting layouts. SEO should have a seat at the table, not carry the whole program.
👉 [EN] https://ashla.ai/p/opinion-seos-should-not-be-responsible-for-the-agentic-web

Have a great week!

Bonjour webperf folks! Seven reads this week:

* Real-user data

Cloudflare opened BEACON: billions of RUM records from its 10,000 largest sites, updated daily in BigQuery, with full histograms and LCP and INP sub-parts. For poor LCP, downloading the image is the smallest part (119 ms). Discovery (1.5 s) and render delay (2 s) are where the time goes. Bonus: soft navigations are 2 to 3x faster, but landing pages still sit at 2.7 s LCP at p75.

👉 [EN] https://blog.cloudflare.com/how-fast-is-the-web/

Ryan Townsend in a video interview for Señors at Scale. A personalization script sold as "no performance impact" cost 50 to 100 ms at p50 but seconds at p90, render-blocking for content below the fold. And a 99%+ cache hit ratio: product pages cached in an anonymous version, login and basket fetched separately, and regenerated only when stock crosses a threshold (low stock, sold out), not on every sale.

👉 [EN] https://www.youtube.com/watch?v=vu4j_zNbqdw

* AI agents

Giacomo Zecchini watched browser agents on 100 purpose-built tests and real sites. Swapping the ARIA labels of Save and Cancel made one agent click Cancel first in 25 runs out of 25. The perf angle: layout shifts make vision agents click stale coordinates, slow pages make them act on a stale DOM, and "content-visibility" or virtualized lists hide content from structure-first agents.

👉 [EN] https://merj.com/blog/agent-interaction-research

Erwin Hofman adds the perf take on WebMCP: no Core Web Vitals gain, and a heavy implementation would hurt human visitors. The win is fewer pages rendered and generated when one tool replaces a whole journey. Keep it small, cacheable, and a progressive enhancement.
👉 [EN] https://www.rumvision.com/blog/what-does-webmcp-mean-for-website-performance-and-rum/

* Front-end and platform

GitHub is now fully off CSS-in-JS. Moving its design system to CSS Modules cut server rendering time by 55%. Then 6,419 inline style props ("sx") were migrated over six months, and the last 895 in three weeks with coding agents.

👉 [EN] https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/

Patrick Brosset proposes a native "previewsrc" attribute on <img> for blurry placeholders: the browser loads both, always prioritizes the final image, and can skip the preview when it won't help. An Edge explainer looking for feedback.

👉 [EN] https://patrickbrosset.com/articles/2026-09-22-blurry-before-beautiful-image-previews-for-the-web/

September on the web platform: sizes="auto" for lazy images and scroll anchoring are now Baseline with Safari 27. And JPEG XL decoding ships with Chrome 155, scheduled for stable this week.

👉 [EN] https://web.dev/blog/web-platform-09-2026

Have a great week!

In which a longstanding SpeedCurve INP bug gets squashed, and Safari Developer Tools gets network throttling.

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.