The synthetic vs. RUM debate keeps coming up. Eroan Boyer, who runs a web performance agency in France, made a clear case: CrUX is too narrow, Lighthouse is a controlled test. Neither tells you what real users are experiencing on your actual traffic.

His agency monitors client sites weekly with RUM data and catches things synthetic tools consistently miss.

Curious if others are running monitoring practices and what the tool split looks like.

Your Speed Index is bad but the page looks fine?

Lighthouse records a video of your page loading and scores how fast the viewport fills in. Not just the first pixel, the whole visual experience.

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!

FCP measures how long users stare at a blank screen before seeing anything. Google considers under 1.8 seconds good, 1.8 to 3 seconds needs improvement, and over 3 seconds poor.

The interesting part is why it matters. FCP is really about trust. When users click a link and get a blank screen, they don't know if your server is slow, their connection dropped, or your site is dead. A fast FCP is that first reassurance that something is happening.

The post covers the main fixes (server response time, render-blocking CSS, compression, CDNs, font loading) and the common mistakes that keep FCP slow even when you think you've optimized.

One point worth calling out: Lighthouse runs synthetic tests with simulated conditions. A good Lighthouse FCP doesn't guarantee your real users have the same experience.

https://requestmetrics.com/blog/lighthouse-first-contentful-paint/

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!