How to read a device performance score

A single performance number is easy to quote and easy to misread. A phone that scores 62 is not "62% as good" as a laptop that scores 94, and a score that drops from 80 to 74 between two runs usually means the room got warmer, not that your site got worse. This guide walks through what each subsystem measurement is doing, what a healthy range looks like on different classes of hardware, and how to separate a real regression from noise.

What a composite score is actually made of

Redline's index is a weighted combination of five independent measurements. Each one stresses a different part of the device, because a device is not slow in general — it is slow at something specific, and the fix depends entirely on which something.

• CPU throughput. Mixed integer and floating-point work on the main thread until it saturates. This is the number that predicts how long your JavaScript will block input. It tracks single-core performance far more than core count, because most web work is single-threaded.
• Memory bandwidth. Large typed-array copies and traversals. A low score here means large data structures, long lists and image decoding will be expensive, and the device will hit garbage-collection pauses sooner.
• Layout and DOM. Forced reflow against a deep element tree. This predicts jank during scrolling, expanding accordions, virtualised lists and anything that changes geometry.
• GPU fill rate. Compositing and overdraw pressure. A low score predicts dropped frames on animations, parallax, blurs, shadows and large translucent overlays.
• Network latency and jitter. Round-trip time and its variability from where the device is actually sitting. Jitter matters more than raw bandwidth for perceived speed, because it decides whether requests arrive predictably.

The composite is a convenience for comparison and ranking. The five components are what you act on.

What a good number looks like

There is no universal pass mark, because the question is always "good for whom". The useful framing is device class. Rough bands, measured on a device that is cool, plugged in or well-charged, and not running a dozen other tabs:

The single most valuable habit is to stop treating your own machine as the reference. Pick the slowest device class you are willing to support, measure it once, and make that score the number your budgets are written against.

Reading the shape, not just the size

Two devices can share a composite score with completely different problems. The shape of the five components tells you which.

Low CPU, everything else fine

Usually an older or heavily throttled processor. Your priority is reducing main-thread work: less JavaScript parsed and executed at startup, heavy loops broken into chunks that yield to the browser, and expensive computation moved off the main thread or cached.

Low layout score with an acceptable CPU

The processor is fine but your DOM is expensive to reflow. This points to very deep element trees, layout-triggering CSS, or components that read geometry and then write styles in the same frame. Containment, virtualised lists and animating only transform and opacity are the usual wins.

Low GPU with everything else healthy

The device composites slowly, which is common on integrated graphics and older phones. Backdrop blurs, large box shadows, stacked translucency and full-screen gradients are the usual culprits. Each is cheap on a developer machine and brutal on a budget phone.

Low memory score

Expect garbage-collection pauses under load. Large in-memory caches, unbounded lists and keeping decoded images alive are the things to audit. On constrained devices the browser may also discard your tab in the background, so recovering state cleanly matters.

High everything, bad network

The device is capable and the connection is not. Nothing you do in JavaScript will fix this. Fewer round trips, smaller critical payloads and honest offline or slow-network states are the levers.

Variance: when a change is real

Benchmarks on consumer hardware are noisy by nature. Before reacting to a difference, know the floor of what noise can produce.

• Run-to-run variance of 5-8% on the same device in the same minute is normal. Treat anything inside that band as unchanged.
• Temperature is the biggest single factor. A phone that has just run a benchmark, been charging, or sat in sunlight can score 20-30% lower purely from thermal throttling. Let the device rest for a minute between runs.
• Battery saver modes cap clock speeds aggressively. A device under 20% battery is measuring a different machine.
• Other tabs, video calls and sync clients compete for the same cores. Measure in a clean window.
• Browsers differ. Comparing a score from one engine to another tells you about the engines as much as about the device.

Turning a score into a decision

A score is only useful if it changes what you build. The workflow that tends to stick:

• Define your floor device — the slowest hardware you commit to supporting — and record its score once, properly, with the median of several runs.
• Identify which of the five components is weakest on that device. That subsystem is your optimisation target for the next cycle; the other four are not.
• Write a budget in terms the floor device can pass, not in terms your laptop passes comfortably.
• Re-measure after each significant change, on the same device, in the same conditions. Consistency of conditions matters more than laboratory precision.
• Record the numbers somewhere durable. The value of performance measurement compounds only if you can see the trend.

Common misreadings

• Treating the composite as a grade. It is a comparison aid. Two sites can share a score and have entirely different user experiences.
• Comparing scores across device classes as if they were one scale. A 65 on a mid-range phone can be a healthier result than an 80 on a laptop that should be scoring 95.
• Optimising the strongest subsystem because it is the one you know how to fix. The weakest component is what your users feel.
• Measuring once. A single run on a warm device is the least reliable number you can produce.
• Assuming a good score means a fast site. Device capability is the ceiling; what your page does with it is a separate question — that is what the delivery probe and Core Web Vitals cover.

Where to go next

If your own device scores well but users still report slowness, the gap between developer hardware and real hardware is the place to look — that is covered in why your site is fast on your laptop and slow on a phone. If you already know which subsystem is weak and want an ordered list of fixes, start with the checklist for fixing slow page loads.