The first part of Declarative Partial Updates (`<template for>` out-of-order HTML) is now available, unflagged, in Chrome 150!! https://lnkd.in/dAsV4agd The second part (the new JS setting APIs, include the streaming ones) we’re still working on the spec side, but maybe for Chrome 152? You can read more about it here: https://lnkd.in/dnwKJ3YW I’m really excited to see this starting to land as honestly believe it will change the way we write HTML (whether directly, or through frameworks!!). And now it’s starting to land you can think about starting to use it for real! This is shipping fast thanks to excellent work by Noam Rosenthal and Philip Jägenstedt along with lots of help from others like Anne van Kesteren from Apple and Simon Pieters from Mozilla, in participating in the design and reviewing and helping land this in the HTML spec! We’re getting positive vibes from those other browsers and have polyfills in the meantime. Super interesting in hearing anyone using it and how you’re finding?

I’ve just released v6.0.0 of the web-vitals library. It includes support for measuring Web Vitals per soft navigation (like those used in SPAs) for supporting browsers (Chrome 151+) to give more accurate performance metrics for those sites. github.com/GoogleChrome… https://lnkd.in/djc3iz4g github.com More details on the soft navigations work and how to enable this using the web-vitals library. https://lnkd.in/dCAbXp2A Any questions let me know!

We just launched experimental ad metrics in the Chrome User Experience Report (CrUX): – Ad Count – the average number of ads in the viewport. – Ad Density – the average % of the viewport area occupied by ads. – Ad Weight: Network – the total network KB fetched by ad scripts and frames. – Ad Weight: CPU – milliseconds of CPU time used by ads frames. These metrics are a set of ad-related measurements that provide transparency into sites’ ad experiences. https://lnkd.in/dW9bwaJp We think these are some of the key measures of ad experiences and are excited to share this data. It’s difficult to measure these types of metrics given technical constrains on the web platform, so CrUX is in a unique position to publish this data. The metrics are available in the CrUX API and the CrUX History API today and you can view these metrics for sites with third-party ads in CrUX Vis: https://lnkd.in/eZf9bZAt (We’re also working on adding them to CrUX BigQuery dataset.) We’ve heard from a large cross-section of ad ecosystem stakeholders that these metrics could enhance how they value ad opportunities and make ad product decisions. We’re encouraged by this as we think users ultimately benefit from more collective attention paid to tuning web ad experiences. While inspired by Core Web Vitals, which help provide visibility into websites’ speed, responsiveness and visual stability, CrUX ad metrics are not part of Core Web Vitals and don’t have suggested targets or thresholds. Each of the four metrics is labeled “experimental” to make clear we are open to community feedback, evolving these metrics and exploring additional metrics that focus sites’ investments on improving users’ browsing experience. We’re excited to see what insights can be gained from publishing this new data and encourage feedback either here at our discussion forum: https://lnkd.in/dyjqKG5Y

This is a great post and shows how you can use the BigQuery CrUX data to do analysis across sites to see the impact of the soft nav change announced this week. SQL included too to make it easier for you to do similar!

Toggle CSS classes in bulk. Then reset scroll with scrollTop = 0. Looks harmless. The browser cannot wait: it has to recalculate styles and layout synchronously, right there, blocking the main thread. That is a Forced Synchronous Layout. To document it I built a Vanilla JS demo with 3,000 DOM elements and :nth-child selectors that amplify the effect. In the Performance Panel, the flame chart makes it clear: a long RunTask with Recalculate Style and Layout forced inside the same task. Enabling “Enable CSS Selector Stats” in the panel settings, the Selector Stats tab shows the cost per selector: 1,220 ms of total evaluation time, 12,002 invalidations, and the :nth-child selectors at 100% slow-path. The fix is a double requestAnimationFrame. One rAF is not enough: it fires before the browser completes the Recalculate Style for that frame, so the styles are still dirty. The second rAF ensures the style tree is clean before touching scrollTop. I wrote the full article with the example repo, Performance Panel screenshots, and the complete explanation of why you need two rAFs. #WebPerf #Performance #ChromeDevTools #JavaScript

The 202609 Chrome User Experience (CrUX) release is now live on BigQuery, and we also have an exciting addition to CrUX this month! Here’s a look at origins’ Core Web Vitals performance this month — for the current definition of Core Web Vitals: – 68.3% of origins (↑ 0.2%) had good LCP – 81.7% of origins (↑ 0.2%) had good CLS – 85.4% of origins (↑ 0.1%) had good INP – 55.9% of origins (↑ 0.5%) had good LCP, CLS and INP This month, we are adding new experimental variants of the Core Web Vitals (LCP, INP, and CLS) including soft navigation metrics as used by SPA sites. These metrics are available in both the BigQuery data set and CrUX APIs. We have also published a detailed blog post from Annie Sullivan with details about how these data change the Core Web Vitals metrics for sites that experience a lot of soft navigations. And when we expect to migrate them out of the experimental stage. https://lnkd.in/dMM5EBQK With soft navigations included we’d see these differences: – 72.1% of origins have good LCP (↑ 5.6% from current LCP) – 85.1% of origins had good CLS (↑ 4.2%) – 87.4% of origins had good INP (↑ 2.3%) – 59.5 % of origins had good LCP, CLS and INP (↑ 6.4%) The CrUX Vis tool has also been updated allowing you to visualize the impact of the changes on a site by site basis: https://lnkd.in/g5eshKKh Use it to check out how your site’s Core Web Vitals will change. We’ve launched these as experimental metrics for now while we continue to evaluate them, and get feedback from you all. However, barring any major issues, we’re aiming to integrate them into Core Web Vitals from May next year. We’ll keep you updated on that date! This is an exciting launch involving years of work and we think that it can finally help us understand the true performance impact (+ve AND -ve) of SPAs. We look forward to the discussion on both individual sites, and with the BigQuery dataset, analysis across the web as a whole!

I installed chrome-devtools-mcp to use it with agents. Then I found the same package includes an experimental CLI that controls Chrome directly from the terminal. A persistent daemon that starts itself the first time. Direct subcommands without writing scripts. In the article I cover: • Navigation and tab management • Emulation: network, CPU, viewport, geolocation • Interaction with elements via accessibility tree • Network: filter by resource type and inspect individual requests • Performance: traces, Core Web Vitals and insights without opening the browser • Lighthouse from the terminal • Memory snapshots ready to import into DevTools And what connects it all: the same WebPerf Snippets script an agent runs can be launched directly from the shell with evaluate_script. The CLI closes the loop for manual use. https://lnkd.in/eE6RPvHk #WebPerf #DevTools #Performance #JavaScript

WebPerf Snippets started as a collection of snippets to paste into the DevTools console. With version 2.0, they are also built for AI agents to run. Over the last few weeks I went through every snippet: they all return an object with the same contract (status, value, rating, issues), so an agent can read the result without parsing the console. That is why this is a major version: if you read the output from code, some fields have changed. What 2.0 brings: • 56 snippets, 7 of them new (compression, Early Hints, Speculation Rules, third-party impact by domain…) • A “Copy prompt” button next to the snippets, with a prompt for an agent to run it with the CLI and report back • The CLI reaches 1.0: audit, loading and interaction workflows, CrUX data, and a GitHub Action with LCP and CLS budgets • Agent Skills for Claude Code, Gemini CLI and other agents • A Markdown version of every page, llms.txt and WebMCP tools • 17 interactive demos, and the browser support of each snippet • A DevTools extension, in beta And a new domain: webperf-snippets.net https://lnkd.in/exEDWtdY #WebPerf #Performance #CoreWebVitals #DevTools #AI #agents

Forced Synchronous Layout is one of those bugs that shows up as a long task in DevTools but is hard to pinpoint in the code. The pattern is deceptively simple: a class mutation followed immediately by a geometric property read (`scrollTop`, `getBoundingClientRect`…). The browser can’t defer the layout — it recalculates right now, blocking the main thread. I’ve added a new snippet to WebPerf Snippets that detects it at runtime. Run it in DevTools, reproduce the interaction, and every FSL event gets logged with: – The property accessed and whether it was a read or write – The element descriptor (tagName + id/class) – Milliseconds since the last mutation – Full stack trace to locate the offending code One thing I had to work out while building it: MutationObserver fires asynchronously, so it can’t catch mutations and geometric reads in the same synchronous block. The fix was intercepting `classList`, `setAttribute`, `setProperty`, and `cssText` directly at the prototype level, synchronously. Call `getFSLSummary()` for an aggregated report by property and element. Call `stopFSLDetector()` to restore all prototypes when you’re done. https://lnkd.in/dhNciS5B #WebPerf #Performance #JavaScript #FrontEnd #WebPerfSnippets

A really great idea, and powerful tool, from Theodore L.! Input your URL, get a page back highlighting “where modern HTML and CSS can replace custom code” (i.e. using `popover` instead of layers of HTML and custom JS, etc.). Bravo, Theo!!