How to Read Your Web Bench Score: 8 Categories and Single vs Multi-Core

When a Web Bench run finishes, you get one big overall score and a set of eight category bars. Higher means faster, which is easy enough to grasp. The questions come right after: why is my multi-core number ten times my single-core number, and is a low memory score a sign that my PC is slow? This guide walks through how to read the result screen, how each category connects to what you actually feel when you use a device, and what to watch out for when you compare scores.

What the overall score actually combines

The overall score is a weighted geometric mean of the category scores. Each individual test is run three times, and the median is converted into a score against a reference value. Tests inside a category are averaged evenly to give the category score, and the category scores are then averaged with weights to give the total. Higher is always faster.

The number is not a grade out of some fixed maximum. It is a relative scale: every measurement is converted the same way, and higher simply means faster. There is no pass mark hidden in any particular value. The scoring formula can change between versions, though, so compare results from the same formula version. CPU multi-core runs much higher than single-core by the core multiplier, as explained below.

The category weights are as follows. A heavier weight means that category moves the total more.

• CPU single-core 17% and CPU multi-core 17%
• Memory 12.75%, GPU graphics 12.75%, GPU compute 12.75%
• Browser 8.5%
• Storage 4.25%
• AI inference 15% (optional; left out of the total if you do not run it)

Because the total uses a geometric mean, one outstanding category will not lift it very much, while one very weak category will drag it down noticeably. A balanced device is favored over a lopsided one. Anything your device or browser cannot run is skipped automatically rather than treated as an error, and the total is calculated from the categories that were measured.

CPU single-core and multi-core: one fast core versus all of them

The single-core category measures how fast one core finishes real work: text processing, JSON parsing, compression, hashing, image processing, sorting, pathfinding, physics simulation, ray tracing and linear algebra. The unit is operations per second, so a higher number means more work done in the same time.

In daily life this tracks how snappy a device feels when it does one thing at a time. Page load speed, how quickly an app responds to a tap, and everyday document or spreadsheet work tend to follow the single-core score, because a program that works through its tasks in a single line is limited by the speed of one core no matter how many cores sit idle.

That is often the answer to the common complaint that a computer with plenty of cores still feels sluggish now and then. A low single-core score can make you wait on each individual task even when the core count looks impressive.

One note: tests that depend on a browser API, such as AES-GCM and Deflate, are skipped when the API is not available, and the score is calculated from the tests that remain.

So why does multi-core come out several times higher than single-core? The multi-core category splits the same kind of work across several Workers and measures throughput when the cores pull together. You notice the difference in video encoding, large file processing and heavy multitasking with many tabs and apps.

The size of the number is what surprises people most. In the current scoring formula (v4), the reference for each multi-core test is the reference for the matching single-core test, in other words the throughput of one core. As a result, the multi-core score works out to roughly the single-core score multiplied by how well the device uses its cores. A machine with many cores is expected to score far higher in multi-core than in single-core. Nothing is inflated. The "N times faster with multiple cores" line on the result screen shows exactly this multiplier.

The upside is that the multi-core score alone reveals how effectively a device uses its cores. The catch is that you should not set the two numbers side by side and conclude that multi-core is the better score. They answer different questions.

• High single-core: tasks that run one step at a time are fast. Good for everyday responsiveness.
• High multi-core: work that can be split and run in parallel is fast. Good for video conversion and batch jobs.
• Low multiplier: the device may have few cores, the browser may be using few Workers, or heat and power limits may stop the cores from running freely.

A caution about that multiplier. It depends on how many Workers the browser uses and how they synchronize, so do not convert it straight into a physical core count or a clock speed. On environments where encryption or compression APIs are unavailable, the affected tests are skipped. The advanced info on the result screen lists the logical core count and the number of multi-core Workers used for the run.

Memory: throughput and latency are different stories

The memory category looks at two things together: throughput when reading, writing and copying a contiguous 16 MB region, and latency when data is reached by following a chain of unpredictable accesses. Throughput is in GB/s, where higher is better. Random-access latency is in ns, where lower is better.

Throughput shows up in jobs that move lots of data, such as editing large images or video, keeping many tabs open, or loading a game. Work that hops between scattered pieces of data depends more on latency. It is possible for one number to look great while the other looks poor, so read them separately.

The latency test repeats while changing the size of the region it touches. When the region is small, the data sits in the fast cache inside the CPU and latency stays low. Once the region outgrows the cache, accesses reach slower memory and latency climbs. The point where the curve bends is roughly the edge of a cache level. The quick run measures only two representative sizes, so you see the full curve in the standard run.

A common misunderstanding: this is not a measure of how much memory you have. A machine running out of memory and spilling to disk is not part of this test either. Check capacity on the spec sheet, and treat the score as a measure of how fast memory passes data back and forth.

GPU graphics and GPU compute: drawing power and calculating power

The GPU is measured in two halves. GPU graphics draws a large number of triangles, 131,072 particles, and bloom and blur post-processing off screen, and reports average FPS. It relates to how smoothly web games, 3D maps and effect-heavy pages run. Because nothing is shown on screen, the monitor refresh rate does not cap the result, so you see how much work the GPU actually got through.

GPU compute measures what happens when you hand calculation, not drawing, to the GPU. It runs f32 and f16 matrix multiplication, image convolution, a particle simulation and a parallel sum, and it checks that the output buffers are correct. This is the closest match to parallel-heavy work such as video processing or AI inference in the browser. Matrix multiplication is shown in GFLOPS and the rest in elements processed per second, all higher-is-better.

You may see a good graphics score next to a weak or missing compute score. GPU tests prefer WebGPU, and when it is unavailable only the graphics tests fall back to WebGL2. Compute tests need WebGPU, and the f16 matrix test runs only if the shader-f16 feature is supported. Putting a WebGPU result and a WebGL2 result on the same line invites misreading, so check first that both results used the same graphics path. Tests that were skipped show the reason on the result screen.

Browser and storage: how the web feels, and how files feel

The browser category measures DOM manipulation and layout, Canvas 2D drawing, and display refresh and frame consistency. It ties directly to everyday impressions: how a complex web app responds when you open it, and how smooth scrolling and animation look. DOM and Canvas are in operations per second, so higher is better, while frame interval is in ms, so lower is better.

This category depends heavily on the browser engine and display settings, not only the hardware. The same machine can score differently in a different browser, so compare it only within the same browser.

Storage creates temporary files in the browser's OPFS (origin private file system), measures sequential write, sequential read, random write and random read, then deletes the files when it is done. It relates to downloading large files or loading offline app data. The unit is MB/s and higher is better. If the browser does not support OPFS, or it is blocked by a privacy mode, the category is skipped.

Storage carries the smallest weight in the total (4.25%). A low storage score will not shake the total much, but for someone who handles large files all day it may be the category that matters most. A weight describes influence on the total score, not importance to your own use.

AI inference: optional, so handled differently

AI inference is optional and runs only if you agree to download the model. It feeds a fixed set of test sentences and images to models inside the browser to see how quickly text generation and an image model run, and it never touches your personal files. It is a reference for how smoothly on-device AI features might run, and a higher speed value is better.

If you do not agree, it does not run and is left out of the total. Results with and without AI use different formula versions (AI-included is v4-ai), so they cannot be compared directly. When the AI category shows as "not measured" on the result screen, that is not an error. It simply means you did not opt in.

When WebGPU is unavailable, AI falls back to a WASM path, and the result states that separately. WASM computes on the CPU, so the same device can be much slower. That is a difference in execution path, not a fault. Compare AI results only when both used the same path and precision.

Reading strengths, weaknesses and the bar chart

The result screen shows a line like "Strength: X · Relative weakness: Y". The strength is the measured category with the highest score and the weakness is the one with the lowest. The word that matters is relative. A weakness label does not say that area is bad. It says that, within this device, that category came out lowest compared with the others. Even a device that is excellent across the board gets a weakness line.

The category bar chart comes with one thing to know. Bar length is drawn as the square root of the ratio to the highest score. A hundredfold difference in score appears as a tenfold difference in bar length. This keeps the other bars from shrinking to slivers when one category, such as CPU multi-core, scores very high. The number beside each bar is the actual score.

• Use the bars to judge overall balance. Check the number beside them for the exact gap.
• A bar half as long does not mean half the score. Because of the square-root scaling, the score can be much lower than that.
• A category with no bar and the label "excluded" or "not measured" was either unsupported or not chosen. It does not mean a score of zero.

Why scores are reference values, and how to compare devices

Web Bench runs inside a browser. The same device can therefore score differently depending on the browser and its version, the power mode, heat, background apps, and whether the tab stays in front. A score is not a guarantee of a hardware tier. It shows how fast the device was in that environment at that moment, which is why the result screen calls it a reference value that varies with browser, power mode and heat.

When you compare two devices, or yesterday's run with today's, a few habits make the reading much more reliable.

1. Compare results from the same formula version. If the formula changes, the comparison key changes so results do not mix. For example, the v4 CPU multi-core score is far larger than under earlier versions, so results from different versions cannot be compared directly.
2. Compare the same run type. The quick run (about 30 seconds) and the standard run (about 2 to 3 minutes) cover different numbers of tests.
3. Check that the browser, the GPU path (WebGPU or WebGL2) and the AI path match. The rule is to compare results whose set of valid tests is the same.
4. On a laptop, match the plugged-in state and the power mode. Close other apps before you start and keep the tab in front during the run.
5. Do not draw conclusions from a single run. Run it two or three times under the same conditions and look at the range. A difference of a few percent is safest treated as noise.

Ignore small gaps and focus on the categories that differ a lot. If two devices have similar single-core scores but very different multi-core scores, they differ in how well they use their cores. If only the GPU compute score differs sharply, check the GPU path and supported features first.

To see whether performance holds up under sustained load, use the stress test (5 or 10 minutes) separately. Stress scores are separate from the standard run, and throttling is inferred from a drop in performance, not read from a temperature sensor.

Web Bench runs in your browser with no installation and no sign-in. Measurements happen on your device, and results are not sent to a server unless you agree to join the ranking. Start with the quick run of about 30 seconds to get a rough picture, then move to the standard run when you want more detail. Once you have a result, keep this guide open and walk through the total, the gap between single and multi-core, and the strength and weakness line. Your device's character will come into focus.

Open Web Bench