Reduce Cloudflare telemetry requests in the initial reader dependency chain #134

Problem

The initial document starts a Cloudflare beacon request and, on some runs, a follow-up RUM request before the page has finished its startup work.

Production audit evidence

Measured on 2026-10-07 UTC against https://devfeed.tech using Lighthouse 12.6.1 and Chrome 154.0.8037.97, with fresh anonymous browser profiles. Mobile uses the default simulated mobile network/4× CPU profile (412×823, DPR 1.75); desktop uses the default desktop profile (1350×940, DPR 1). These are lab observations, not field p75 data.

Direct-page network-dependency-tree-insight showed /latest → static.cloudflareinsights.com/beacon.min.js → /cdn-cgi/rum, with a 1,949ms observed chain on desktop; /topics had a 1,567ms chain. The beacon transferred about 10KiB and its one-day TTL appeared in cache diagnostics. Lighthouse estimated zero LCP savings for these chains, so their presence alone does not establish render blocking.

Audit IDs: network-dependency-tree-insight, uses-long-cache-ttl, cache-insight.

Work required

• Locate whether the beacon is injected by Cloudflare configuration or the application. Verify real request priority/timing and startup impact before changing initialization.
• Defer or reduce unnecessary early telemetry where supported while retaining required RUM coverage. Do not add broad preconnects, proxy a vendor script blindly, or claim DevFeed controls the vendor's cache headers.

Acceptance criteria

• Trace comparisons show reduced unnecessary startup network competition without reducing required telemetry coverage.
• If the diagnostic has no actionable impact or only externally controlled policy, record that evidence and retain correct instrumentation instead of changing it solely for the audit score.
• Capture comparable before/after reports and add regression coverage for the changed behavior. For shared reader changes, verify browser behavior on web and both built Chrome/Edge extensions.