Skip to content

Commit b174f7e

Browse files
csswizardrycsswizardry
committed
feat: Publish Web-Perf Wednesday 007
1 parent 6fa86f8 commit b174f7e

2 files changed

Lines changed: 132 additions & 0 deletions

File tree

‎_includes/web-perf-wednesdays.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
### More Web-Perf Wednesdays
22

33
<ol reversed>
4+
<li><a href="/2026/09/web-perf-wednesday-007-chrome-makes-busy-workers-measurable/">Web-Perf Wednesday 007 – Chrome Makes Busy Workers Measurable</a></li>
45
<li><a href="/2026/08/web-perf-wednesday-006-faster-browser-releases-change-your-rum-population/">Web-Perf Wednesday 006 – Faster Browser Releases Change Your RUM Population</a></li>
56
<li><a href="/2026/08/web-perf-wednesday-005-rum-needs-more-than-a-percentile/">Web-Perf Wednesday 005 – RUM Needs More Than a Percentile</a></li>
67
<li><a href="/2026/08/web-perf-wednesday-004-a-quiet-week-is-time-to-investigate/">Web-Perf Wednesday 004 – A Quiet Week Is Time to Investigate</a></li>

‎_posts/2026-09-02-web-perf-wednesday-007-chrome-makes-busy-workers-measurable.md‎

Lines changed: 131 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,131 @@
1+
---
2+
layout: post
3+
title: "Web-Perf Wednesday 007 – Chrome Makes Busy Workers Measurable"
4+
date: 2026-09-02 12:00:00 +0100
5+
categories: Web Development
6+
main: ""
7+
meta: "Chrome 153 starts exposing dedicated-worker congestion to RUM, while browser releases tighten privacy, module recovery, and image preloading."
8+
---
9+
10+
There’s been a useful amount of movement since [last
11+
week](/2026/08/web-perf-wednesday-006-faster-browser-releases-change-your-rum-population/),
12+
although most of it is arriving through browser releases rather than grand
13+
announcements. Chrome has started exposing slow work inside dedicated Web
14+
Workers, Firefox now lets failed module loads recover, and WebKit has fixed a
15+
responsive-image preload edge case. Chrome exposes work we couldn’t see,
16+
Firefox can retry a load it had written off, and WebKit asks for the image it
17+
actually selected. Chrome’s worker change offers the most interesting field
18+
data, provided we’re careful about what it actually reports.
19+
20+
## Chrome Makes Busy Workers Measurable
21+
22+
[Chrome 153 has reached Early
23+
Stable](https://chromereleases.googleblog.com/2026/08/early-stable-update-for-desktop_0935803414.html)
24+
for a small percentage of Windows and Mac users, ahead of its full Stable
25+
release on 8 September. Among its performance changes, Chrome is [extending
26+
the Long Animation Frames API to dedicated Web
27+
Workers](https://chromestatus.com/feature/5387465121726464).
28+
29+
Long Animation Frames (LoAF) currently helps explain congested moments on the
30+
main thread by combining long-running script with the rendering work that
31+
follows it. A Worker has no rendering frame of its own, so the name becomes a
32+
little odd here, but the practical result is useful: a long task that blocks a
33+
dedicated Worker’s event loop can produce a `long-animation-frame` entry,
34+
observable from inside that Worker with `PerformanceObserver` and carrying the
35+
usual per-script attribution.
36+
37+
Moving work off the main thread keeps it away from rendering and input
38+
handling, but it doesn’t make the work free. A Worker that spends too long
39+
decoding data, filtering a large catalogue, processing an image, or running a
40+
client-side model can still delay the result the interface is waiting for.
41+
Main-thread INP may look perfectly respectable while the product feels slow
42+
because the useful answer is still queued elsewhere. Worker-side LoAF gives a
43+
[RUM strategy](/consultancy/) a browser-native signal for that missing part of
44+
the journey.
45+
46+
The first implementation is deliberately narrow. It starts with dedicated
47+
Workers and reports a single long task blocking the Worker event loop. Chrome’s
48+
broader idea of identifying congestion caused by a flood of smaller tasks is
49+
follow-up work. A page-level observer also won’t collect Worker entries for us;
50+
the observer needs to run in the Worker, and the application needs to join that
51+
evidence to the user action or task it was meant to complete.
52+
53+
Start with one Worker-backed journey where users already experience a delay.
54+
Feature-detect `long-animation-frame` support inside the Worker, retain the
55+
script attribution and duration, then add an application mark or task ID that
56+
lets the main thread connect the result to the initiating action. Keep the
57+
browser version and instrumentation version alongside it, because Early Stable
58+
is a small cohort and this signal will initially be Chrome-only.
59+
60+
As with main-thread LoAF, collecting every entry is likely to create far more
61+
data than insight. Sample the worst cases, set a threshold that reflects the
62+
product interaction, and compare them with a trace before assigning blame. The
63+
useful outcome is a view of where an asynchronous journey actually waited,
64+
rather than a new chart whose busiest line merely happens to belong to a
65+
Worker.
66+
67+
## Chrome 153 Also Removes Privacy Sandbox APIs
68+
69+
Chrome’s decision to retain its current approach to third-party cookies did not
70+
preserve every API designed for a cookieless browser. Chrome 153 [removes
71+
Related Website Sets](https://chromestatus.com/feature/5194473869017088) and
72+
`document.requestStorageAccessFor()`, and it is also removing the [Attribution
73+
Reporting API](https://chromestatus.com/feature/6320639375966208) alongside
74+
other Privacy Sandbox APIs.
75+
76+
Teams using these features for embedded sign-in, cross-site journeys, or
77+
conversion measurement should inventory production use now and test what the
78+
browser does without them. The continued availability of third-party cookies
79+
doesn’t recreate the same access or attribution model, particularly where
80+
users, browser settings, policy, or consent already restrict those cookies.
81+
Record the Chrome version in any measurement comparison, and make the fallback
82+
an explicit product and privacy decision rather than an accidental return to an
83+
older mechanism.
84+
85+
## Firefox Lets Failed Module Loads Recover
86+
87+
[Firefox 155 was released on 1
88+
September](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/155),
89+
and a failed module load is no longer cached as a permanent failure. If a
90+
network error or incorrect MIME type is corrected, importing the same specifier
91+
again can now succeed. The change covers JavaScript, JSON, CSS, and text
92+
modules, loaded statically or dynamically in windows and Workers.
93+
94+
This is a useful resilience improvement for applications that retry after a
95+
brief CDN or deployment fault. It also means failure testing should check the
96+
whole recovery path: restore the response, retry the import, and confirm that
97+
the interface and telemetry recover without a reload. Firefox also adjusted
98+
`modulepreload` behaviour around already-fetched modules and failed integrity
99+
checks, so include preload failures in [team performance
100+
testing](/workshops/) where modules sit on a critical route.
101+
102+
## WebKit Fixes Responsive-Image Preloads
103+
104+
[Safari Technology Preview
105+
251](https://webkit.org/blog/18194/release-notes-for-safari-technology-preview-251/)
106+
fixes `imagesrcset` failing to override `href` on `<link rel="preload"
107+
as="image">`. In affected builds, a responsive-image preload could fetch the
108+
fallback URL instead of the candidate selected from `imagesrcset`, leaving the
109+
eventual image request to choose something else. The same release also fixes
110+
`as` keywords on preload links being matched case-sensitively.
111+
112+
Neither change makes every responsive preload correct: `imagesizes`, viewport,
113+
device pixel ratio, and the eventual `<picture>` or `<img>` selection still
114+
need to agree. If Safari shows an unexpected early image request, a
115+
[performance audit](/performance-audits/) should compare the preload and image
116+
candidates before treating the wasted transfer as an application bug.
117+
118+
## Need Help Finding Work Your Main-Thread Metrics Miss?
119+
120+
If an interaction looks healthy in the usual main-thread metrics but still
121+
finishes late, I can help trace the complete journey across Workers, network
122+
requests, rendering, and application state. We can decide which Worker tasks
123+
are worth measuring, join them to the actions users actually took, and keep the
124+
result small enough for the team to interpret.
125+
126+
You don’t need a finished instrumentation plan to begin; an awkward trace, a
127+
slow feature, or a result that arrives inexplicably late is plenty. If your
128+
current RUM stops just before the interesting delay, [get in
129+
touch](/contact/).
130+
131+
{% include web-perf-wednesdays.md %}

0 commit comments

Comments
 (0)