Lighthouse and PageSpeed Insights are page audits run on a simulated device in Google's infrastructure. That is useful and free — but the phone it emulates is not the phone your customer owns. Redline measures the machine in front of you and tells you where its ceiling is.
| Dimension | Lighthouse / PSI | Redline |
|---|---|---|
| Device model | A simulated mid-tier phone with throttled CPU | The actual hardware running the test |
| Hardware signal | None — the machine is emulated | Cores, memory, GPU renderer, DPR, connection |
| Score meaning | How this page performs in a lab | How much headroom this device has, on any page |
| Cohort context | None | Percentile against every device tested |
| Diagnosis | Rule-based audit list | AI reading of the device profile plus the metrics |
| Best used for | Page-level regressions in CI | Deciding which devices you can still support |
Keep Lighthouse for page regressions. Use Redline when the question is "which devices are we losing?" — then set a device-score floor and gate releases on it with the Redline CI endpoint.
Test your deviceA Lighthouse mobile run does not use a phone. It runs headless Chrome on a server and applies a CPU slowdown multiplier plus a modelled network profile. That model is a reasonable average, and averages are useful — but a multiplier cannot reproduce the things that make real phones slow: a small shared memory pool, a mobile GPU with a different fill-rate profile, thermal throttling that appears a minute into a session, battery-saver modes that cap clock speed, and a network whose latency changes while the page is loading.
So two devices with identical Lighthouse scores can feel completely different in a hand. The audit is measuring the page under a fixed hypothetical; the hand is experiencing actual hardware.
The page is well built but the hardware is weak, or the device is throttling. The fix is usually to reduce total JavaScript work rather than to shave bytes — the simulated CPU was kinder than the real one.
Your test hardware is much faster than the modelled device, so the page's real cost is hidden. Trust the audit here and treat your device result as a best case, not a representative one.
An unambiguous signal, and the easiest case to act on. Start with the largest blocking resource and work down; both tools will move together as you fix it.
Step 1
Lighthouse in CI on every pull request
Cheap, deterministic and good at catching page-level regressions such as a newly added blocking script or an unoptimised image.
Step 2
A device run on the floor handset each release
Confirms the page is still usable on the weakest hardware you support, which the simulation can only approximate.
Step 3
Field data as the referee
When the lab and the device disagree, real-user metrics decide. Both synthetic tools describe chosen conditions; only field data describes encountered ones.
For accessibility checks, SEO audits, best-practice rules and a deterministic CI signal that never varies by battery temperature, Lighthouse is the better tool and Redline does not attempt to compete. Redline is narrower on purpose: it answers which physical devices can still run your site acceptably. Keep both, and use each for the question it was built to answer.
What the CPU, memory, layout, GPU and network numbers in a device benchmark actually mean, and how to tell a real problem from normal variance.
The hardware gap, thermal throttling, network variance and cache warmth that make developer machines a misleading place to judge performance.
LCP, INP and CLS explained without jargon: what each one measures, what usually breaks it, and the change that most often moves it.