PERFORMANCE Signal 500
Updated 2026 network and device benchmarks reveal growing performance inequality as page sizes outpace budgets
Developers must now keep JavaScript-heavy pages under 1.2 MiB to meet three-second interactive targets, yet the median mobile page already exceeds 2.6 MiB.
The updated benchmarks target the 75th percentile, meaning a quarter of users experience slower-than-baseline performance when pages exceed these limits. Growing JavaScript payloads widen this gap, turning performance into both a technical shortfall and an ethical issue for less-privileged audiences.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Updated 2026 benchmarks set a 9 Mbps downlink, 3 Mbps uplink and 100 ms RTT baseline, targeting the 75th percentile user experience.
For a three-second load goal, JS-light pages may total 2.0 MiB while JS-heavy pages are limited to 1.2 MiB, but median mobile pages now weigh 2.6 MiB.
Growth in JavaScript payloads, 680 KiB at P50 and 1.3 MiB at P75, drives the coffin-corner effect, shrinking effective budgets and worsening Core Web Vitals pass rates.
THE READ
What the cluster adds up to.
The 2026 update revises network test parameters to 9 Mbps downlink, 3 Mbps uplink and 100 ms round-trip time, using a Samsung Galaxy A24 4G or equivalent and an HP 14 laptop to emulate the 75th percentile user experience. This baseline means that one quarter of devices and networks will perform worse than the specified thresholds. The revised budget calculator derives critical-path resource limits for three-second and five-second page load targets, distinguishing JS-light and JS-heavy compositions. Compared with early 2024 estimates, the three-second budget grew by over 600 KiB and the five-second budget gained a full megabyte of headroom.
Adopting these tighter effective limits requires developers to keep JavaScript-heavy pages under 1.2 MiB for a three-second interactive goal, while JS-light pages may reach 2.0 MiB. Achieving this often means consolidating TLS connections, migrating to H/2 or H/3, and trimming non-essential scripts and assets. The material notes that using four connections instead of two cuts the three-second budget by 350 KiB, illustrating the cost of extra round trips. Even with the increased headroom, the median mobile page at 2.6 MiB still exceeds the JS-light three-second budget, indicating a necessary reduction in overall payload.
Where the approach stops working is when page sizes continue to outpace the inflated budgets, particularly for JavaScript-heavy sites that already surpass the 1.2 MiB limit. The coffin-corner effect describes how a higher proportion of JavaScript raises CPU cost per byte, further shrinking usable budgets and harming byte-for-byte performance relative to image- or CSS-focused pages. As a result, Core Web Vitals pass rates remain below half for mobile origins and stagnate for desktop, showing that current practices fail to meet performance goals for a substantial user segment. Consequently, the performance inequality gap widens, leaving a quarter of users with slower-than-baseline experiences.
Beyond the technical mismatch, the framing highlights an ethical dimension: developers receive abundant compute and bandwidth yet often deliver business-undermining, low-quality results that disproportionately affect less-privileged users. The material calls this a classic case of under-priced externalities from induced demand within a privilege bubble, suggesting that restraint is unlikely without aligned incentives. To close the gap, teams must adopt stricter payload budgets, prioritize connection efficiency, and treat performance as a shared responsibility rather than an individual shortcoming.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER
↗