A weekly web-performance roundup covers a new SpeedCurve companion plugin called LUX Sidecar, which adds browser and navigation context (RTT, cache state, protocol, service-worker involvement, TTLB, UNO) alongside RUM percentile data to help diagnose why performance metrics shift. Also covered: Safari Technology Preview 250 fixed Web Inspector's 'Ignore Cache' setting overwriting page-authored Cache-Control headers, a Chrome DevTools fix (merged 20 July, verified in Canary but not yet stable) moves the optional 'Request #' column to the first position, and Safari Technology Preview 250 adds initial, limited support for streaming fetch() uploads via ReadableStream request bodies.
Table of contents
RUM Needs Context It Can KeepSafari’s ‘Ignore Cache’ Was Changing RequestsDevTools’ Request Numbers Move LeftSafari Begins Streaming Fetch UploadsNeed Help Adding Context to Your RUM?Questions this post answers
What does the LUX Sidecar plugin add to SpeedCurve's RUM data?
LUX Sidecar is an independent plugin that runs alongside SpeedCurve's LUX agent and sends extra context through the LUX.addData() API. It captures browser-reported round-trip time and downlink, cache state, protocol, content encoding, service-worker involvement, bfcache or prerender use, and timings like Time to Last Byte and Unattributed Navigation Overhead. It feature-detects each value and omits unavailable data rather than reporting a misleading zero. Teams refining RUM dashboards can track tooling like this on daily.dev to spot real causes behind performance shifts.
Did Safari fix the Web Inspector Ignore Cache bug that changed Cache-Control request headers?
Yes, Safari Technology Preview 250 fixed Web Inspector's 'Ignore Cache' setting so it no longer overwrites a page-authored Cache-Control request header with no-cache. Previously WebKit bypassed its local resource cache and replaced the intended header, which could alter how an origin, CDN, or shared cache responded during debugging. The fix is confirmed only in Technology Preview 250, not yet in a stable Safari release. Developers validating caching behavior across browser versions can follow fixes like this on daily.dev.
Has Chrome DevTools fixed the Request # column position in the Network panel?
A fix has been merged (20 July) that moves the optional 'Request #' column to the first position instead of appearing after 'Name', and it was verified working in Canary build 152.0.7962.0. However, the public Chromium issue is still marked 'In Progress (Accepted)', so it has not yet reached a stable Chrome release. Anyone tracking Chrome DevTools changes before they ship stable can follow updates like this on daily.dev.