Audit Stability

Lighthouse scores vary between runs, even on the same page. The variance has two sources: the environment (test hardware, network conditions, machine noise) and the page itself (a server answering at different speeds, different content between visits). xcelera removes the environmental variance and reports the page's own variance instead of hiding it.

A controlled environment

Run Lighthouse on your own machine and the score moves with everything else the machine is doing: background tabs, thermal throttling, browser extensions, a VPN, the office Wi-Fi. CI runners are little better, sharing hardware and network with whatever jobs run alongside. When the environment shifts under you, a score drop looks exactly like a regression, and you end up chasing a fix for a problem that doesn't exist or dismissing a real one as noise. Diagnosing performance needs lab conditions.

Each xcelera audit runs on its own dedicated, high-performance machine, provisioned fresh and destroyed afterwards, never shared between organizations. The machines sit on one of the world's largest private fiber backbones.

Lighthouse's CPU throttle is relative to host speed, so the same setting simulates a different device on different hardware. We benchmark every machine and compute a multiplier that targets a fixed simulated device, whichever machine picks up the audit.

Packet-level network shaping

Most Lighthouse services, PageSpeed Insights included, load the page over a fast connection and simulate what a slow one would have done. The simulation reconstructs the load from an unthrottled trace and predicts where every byte would have landed. It's a model, and pages the model doesn't anticipate (a server that stalls under load, an unusual request chain, scripts competing for bandwidth) get estimates that can land far from what users experience.

xcelera throttles for real. Every audit machine shapes its network at the operating-system level, so every packet in every run genuinely travels under the audit's device profile: 150ms of round-trip latency and slow-4G bandwidth on mobile. The browser loads the page under the conditions your users face, and every metric is observed rather than predicted: a slow server response moves LCP by exactly as much as it delays your users. Because nothing is modelled, an entire class of estimation error disappears from run-to-run comparisons.

Statistical measurement

A single Lighthouse run has inherent variance from network timing, GC pauses, and JIT warmup, so no audit is a single run. Each audit measures at least 3 times and picks a representative result using robust statistics that a single outlier can't skew.

Every run also records hardware signals (CPU contention, scheduler noise, throttling drift), and each machine's effective speed is checked against its calibration target, with thresholds tuned on thousands of production runs. When a machine fails these checks we discard it and re-run the audit on a fresh one before you see a result.

Stabilized audits

Paid plans add two stabilization steps, on by default and toggleable per page:

• Warm-up pass. A fresh machine starts cold (empty caches, browser not yet in memory), which makes its first run the most variable. We run one throwaway warm-up and discard the result, so measurement starts once the machine has settled.
• Extra runs. When the measured runs disagree, we add more (up to 5 in total) and stop as soon as they converge. We only add runs when analysis says they can help: variance caused by the page itself won't converge, so we report it instead.

Reporting

Every audit shows the spread of its runs next to the score, with a Consistent or Variable badge. When runs disagree we name the cause: a different largest element between visits, a server answering at two speeds, or blocking time crossing a rating boundary. We attribute variance to your page only after verifying our environment was clean.