Chrome 157 and the latest DevTools — what Indian web teams should test this week

Key takeaways

• Chrome 157 was scheduled to reach stable on 3 November 2026, per Chrome Platform Status. Chrome rolls out in stages, so your users will move over during the next few weeks.
• The most useful change for performance work is small: the Long Animation Frames (LoAF) API now reports styleDuration and forcedStyleDuration. That lets you see how much of a slow interaction was spent on style recalculation, and how much of it your own JavaScript forced.
• One change can break things: Background Fetch now enforces CORS and Local Network Access checks. If a PWA used it to download cross-origin files without CORS headers, those downloads will now fail.
• The CSS additions are progressive-enhancement material, not something to rush: corner shorthands, text-decoration-inset, a custom string for text-overflow, and renamed anchor-positioning values (anchor-valid, anchor-visible).
• DevTools improved the boring parts that matter: a smoother Performance panel, local overrides that survive navigation, an Early Hints warning, and more tooling for AI agents that drive the browser (Chrome for Developers).
• Plan about one working day to check RUM data, test Background Fetch flows, and add the two new LoAF fields to your INP reporting.

1. Why a Chrome release matters more in India than most places

In India, most web traffic comes from Android phones, and Chrome is the default browser on most of them. Many of those phones are mid-range or budget devices, so they are slower to run JavaScript. That makes Chrome changes to how pages are measured or what they may load more important here than on desktop-heavy markets.

It also means your Core Web Vitals field data (the Chrome UX Report that feeds Google Search) is measured mostly on those devices. Interaction to Next Paint (INP), the responsiveness metric, is where Indian sites most often fail. So the INP-related tooling in this release is the part to pay attention to.

2. What changed in Chrome 157, at a glance

All items below are from the Chrome 157 release notes on Chrome Platform Status. Some entries there are still marked "pending review", and those are noted.

3. The INP change, explained plainly

INP measures the delay between a tap and the next frame on screen. When that delay is long, it is usually caused by one of three things: a long JavaScript task, style and layout recalculation, or rendering.

The Long Animation Frames API already told you which script ran during a slow frame. The gap was style and layout. A frame could be slow because a script changed a class on <body> and the browser had to restyle thousands of elements. Or the script read a value such as offsetHeight right after changing the DOM, forcing the browser to compute styles early. That second pattern is called a forced style recalculation, or "layout thrashing".

Chrome 157 adds two fields to each long frame entry:

• styleDuration: the total time spent on style recalculation in that frame.
• forcedStyleDuration: the part that was forced by script reading styles too early.

What to do with it:

1. If you already collect LoAF entries (the web-vitals library's attribution build does this for you), add these two fields to what you send to your analytics.
2. Group slow interactions by page template. A high forcedStyleDuration points at code you own, such as carousels, sticky headers, or "read height then animate" scripts. A high styleDuration with little forced time usually means the DOM or the CSS selectors are too big.
3. Fix the forced cases first. Batch DOM reads before writes, or move the reads into requestAnimationFrame. These fixes are usually small and safe.

These fields only show up in Chrome 157 and later, so treat missing values as "unknown", not zero.

4. The change that can break things: Background Fetch

Background Fetch lets a PWA download large files, such as videos, course material or app bundles, and keep going after the user closes the tab. It is popular with Indian ed-tech and media apps that support offline viewing on patchy mobile networks.

Starting with Chrome 157, these downloads follow the same CORS rules as a normal fetch(), and Local Network Access checks apply as well. Two common setups will now fail:

• Files on a separate CDN or storage bucket that do not send Access-Control-Allow-Origin. Before, Background Fetch worked anyway. Now the download fails.
• Requests to private IP addresses or intranet hosts from a public site, such as an on-premise media server.

Fix: add the right CORS headers on the file origin (an S3, Cloud Storage or Azure Blob CORS rule, or a header in your CDN config), and retest the offline flow on a real Android device. If you are not sure what your server sends, our HTTP headers checker shows the response headers for any URL.

5. DevTools: what is new and worth using

The November 2026 "What's new in DevTools" post covers features that reached stable in Chrome 155 and 156. The ones that help day-to-day work:

The CPU Performance Tier control is the one most Indian teams should start using. Test your key flows (search, add to cart, checkout, lead form) on a low tier, not just on your developer laptop. That is closer to what your real users have.

6. A one-day test plan for this release

For a small business site, this is half a day of one developer's time. For a PWA with offline downloads, test Background Fetch first, since it is the only item in this release that can break a working feature.

7. What not to do

• Do not ship the new CSS without fallbacks. Firefox and Safari users, and Chrome users who have not updated yet, will not see it. Use @supports.
• Do not build on "pending review" items such as the new HTML streaming methods or icon-only capability elements. They may change before they ship.
• Do not judge INP from lab tests alone. A standard Lighthouse page-load run does not report INP. Use field data, then use DevTools to reproduce the problem.

Want your INP and Core Web Vitals checked against real Indian mobile conditions? Start with our free website speed and SEO check, or read Core Web Vitals in 2026: what to fix first.