Speedometer 3.0: A shared browser benchmark for web application responsiveness
A new version of the Speedometer browser benchmark, developed jointly by the teams behind Chrome, Firefox and Safari, aims to measure real‑world web application responsiveness across modern JavaScript frameworks and devices. Users report a wide range of scores across desktops and mobiles, highlighting factors like hardware differences, browser engines, power settings and heavy extensions (especially content blockers and Dark Reader) as major performance variables. While many welcome a shared, realistic benchmark that has already driven engine optimizations, others argue that bloated site design and DOM complexity still dominate perceived performance, limiting how much benchmarks alone can improve everyday browsing.
Cross‑engine collaboration and goals
- Speedometer 3.0 is highlighted as the first major browser benchmark built jointly by all three engine teams (Blink/V8, Gecko/SpiderMonkey, WebKit/JavaScriptCore).
- Many see it as a de‑facto standard for measuring web app responsiveness and expect it to drive real optimizations, as earlier Speedometer versions did.
What the score means
- Higher scores are better; the number is a rescaled inverse of total time for a suite of web‑app interactions.
- Rough intuition: halve the time, double the score; a 5% score increase ≈ 5% faster on the subtests (with some nuance due to geometric mean).
- The dial goes to 140 only as a visual scale with headroom; scores can exceed that, but the gauge saturates.
Observed performance patterns
- Desktop: modern high‑end CPUs and Apple Silicon hit ~25–35; mid‑range laptops and older desktops see ~10–20.
- Mobile: recent iPhones typically outscore flagship Android phones by a large margin; some users note their phones beating older laptops.
- Different browsers on the same machine are often close, though per‑device ordering varies (Safari vs Chrome vs Firefox).
Effects of extensions, privacy, and configs
- Ad blockers, content blockers, and Dark Reader can dramatically lower scores, especially on Safari and Firefox.
- Private/incognito modes or disabling extensions often raise scores significantly.
- Timer‑rounding privacy protections can break the test and yield “Infinity” scores.
Bugs and anomalies
- Some report Safari on iOS crashing or killing the test, especially outside private tabs.
- Others see extreme per‑subtest outliers on Firefox, heavily skewing variance.
Mobile and iOS specifics
- On iOS, all browsers use WebKit, but app‑level differences and added overhead still produce noticeably different scores.
Critiques and skepticism
- Several argue real‑world slowness comes more from bloated, complex sites and DOM limitations than from engines.
- There is concern that benchmarks optimize engines while sites (including those of browser vendors) remain heavy and slow.
- Others counter that Speedometer‑driven engine work has already translated into measurable user‑visible gains.
Latency and user experience
- Some users feel modern systems still have higher input latency than old hardware and crave “tactility.”
- Others report no noticeable click/tap lag and emphasize that bad developer choices, not the web platform itself, often cause delays.