Skip to content

Web QoE Scoring Model

Note

This model is currently in beta. We welcome feedback on the scoring methodology and curve parameters, and we are currently evaluating it in practical situations.

The Web QoE Score is an overall Quality of Experience score for web page loads, expressed on a 0–100 scale. It combines multiple web performance metrics into a single value that answers a simple question: "How good was this page load for the user?" The score is provided as the statistic value web_qoe_score.

How it works

Each web performance metric (e.g. how fast content appears, how stable the layout is) is scored individually on a 0–100 scale using a log-normal scoring curve. The individual scores are then combined into a single weighted average — the Web QoE Score.

The scoring curve is an S-shaped function that maps raw metric values (like "1.2 seconds for first paint") to a quality score. Fast values score close to 100, slow values score close to 0, and the transition between good and bad is smooth rather than abrupt. Two parameters define each curve:

  • p10 — the metric value at which the score reaches approximately 90 (the "good" threshold). Values better than this produce diminishing returns in the score.
  • median — the metric value at which the score is approximately 50. This represents the boundary between acceptable and poor performance.

This approach is based on Google's Lighthouse performance scoring methodology, which describes the process as follows:

The Lighthouse scoring curve model uses HTTPArchive data to determine two control points that then set the shape of a log-normal curve. The 25th percentile of HTTPArchive data becomes a score of 50 (the median control point), and the 8th percentile becomes a score of 90 (the good/green control point). Between 0.50 and 0.92, there's a near-linear relationship between metric value and score. Around a score of 0.96 is the "point of diminishing returns" as higher, the curve pulls away, requiring increasingly more metric improvement to improve an already high score.

— Lighthouse Performance Scoring, Google Chrome Developers

Google also provides a Lighthouse scoring calculator and a graphing function for exploring the log-normal curve behavior.

Score interpretation

The Web QoE Score can be interpreted using a simple traffic-light scheme:

Score range Rating Meaning
90–100 🟢 Good The page loaded quickly and felt responsive. Users are unlikely to notice any performance issues.
50–89 🟡 Needs improvement The page load was noticeably slow or had some issues (e.g. layout shifts, sluggish interactions). Users may be mildly frustrated.
0–49 🔴 Poor The page load was significantly below expectations. Users are likely to abandon the page or have a bad experience.

These thresholds follow the same 90/50 boundaries used by Lighthouse for its performance score.

Input metrics

The model uses the following web performance metrics as inputs.

Notably, we do not use Total Blocking Time (TBT) as an input metric, as it is not directly measurable in all environments. Similarly, the Speed Index (SI) is not used, as it is difficult to measure.

Metric sets

The model has been adapted to work with different sets of input metrics, depending on what data is available from the measurement platform. The scoring function accepts exactly one of four predefined metric combinations; any other combination produces no score.

  • 4-metric (no INP): FCP + LCP + CLS + TTFB — the primary metric set for synthetic/lab measurements (e.g. Lighthouse lab mode), where no real user interaction occurs and INP cannot be measured. Uses the same Lighthouse v10 scoring curves; INP's weight is redistributed proportionally among the remaining four metrics. This is the most common set for network-style monitoring with Surfmeter.
  • Full (5 metrics): FCP + LCP + CLS + INP + TTFB — uses Lighthouse v10 curves and weights. Requires Real User Monitoring (RUM) data for INP.
  • 4-metric (no TTFB): FCP + LCP + CLS + INP — same Lighthouse curves; TTFB's weight is redistributed proportionally among the remaining four metrics.
  • 2-metric: FCP + LCP only — uses Web Vitals threshold-aligned curves with equal weights (see below).

Scoring curves

Full and 4-metric sets

The scoring curves for the full and both 4-metric sets are as follows:

Metric PC median PC p10 Mobile median Mobile p10 Weight
FCP 1600 ms 934 ms 3000 ms 1800 ms 0.10
LCP 2400 ms 1200 ms 4000 ms 2500 ms 0.25
CLS 0.25 0.1 0.25 0.1 0.25
INP 500 ms 200 ms 500 ms 200 ms 0.25
TTFB 1800 ms 800 ms 1800 ms 800 ms 0.15

When INP is unavailable (4-metric, no INP), as in synthetic/lab measurements, its weight of 0.25 is redistributed proportionally among FCP, LCP, CLS, and TTFB. The resulting effective weights are approximately FCP 0.13, LCP 0.33, CLS 0.33, TTFB 0.20.

When TTFB is unavailable (4-metric, no TTFB), its weight of 0.15 is redistributed proportionally among FCP, LCP, CLS, and INP. The resulting effective weights are approximately FCP 0.12, LCP 0.29, CLS 0.29, INP 0.29.

Generally, mobile device types use more lenient FCP/LCP curves than PC, reflecting the typically slower rendering on mobile devices.

Two-metric set

When only FCP and LCP are available, the Lighthouse curves are too harsh to use directly. This is because they were calibrated for a multi-metric set where CLS, INP, and TTFB — which tend to score high at their "good" thresholds — compensate for the steeper FCP/LCP curves. Using the Lighthouse FCP/LCP curves alone would give a score of only ~45 for a page that meets all Web Vitals "good" thresholds.

However, in some cases, only FCP and LCP are available, e.g. when interactivity cannot be simulated in automated measurement scenarios. So instead, the 2-metric set uses curves aligned to the Web Vitals thresholds directly, with equal weights:

Metric median (= "poor" threshold) p10 (= "good" threshold) Weight
FCP 3000 ms 1800 ms 0.50
LCP 4000 ms 2500 ms 0.50

These curves are the same for PC and mobile. This produces scores that align with the standard quality tiers: approximately 90 at the "good" boundary, 50 at "needs improvement".

Note

The 2-metric score only reflects loading performance (FCP + LCP). It cannot capture interactivity or visual stability issues. A page with fast paint times but terrible responsiveness will score well in the 2-metric set.

Example scores

The following table shows example scores for the PC device type across representative performance scenarios. The traffic-light rating column shows the score interpretation for the full 5-metric set.

Scenario Rating 4 (no INP) Full (5) 4 (no TTFB) 2-metric
Excellent Good 98 99 98 100
Good (WebVitals thresh) Needs improvement 69 74 71 90
Needs improvement Poor 33 37 35 50
Poor Poor 11 13 11 12

The "Good (WebVitals thresh)" row uses the Web Vitals "good" threshold for each metric (FCP=1.8 s, LCP=2.5 s, CLS=0.1, INP=0.2 s, TTFB=0.8 s). A page meeting all "good" thresholds scores only 74 in the full set — solidly in the 🟡 Needs improvement range. This is because the Lighthouse scoring curves for FCP and LCP have p10 values (934 ms and 1200 ms for PC) that are much more aggressive than the Web Vitals "good" thresholds (1800 ms and 2500 ms). At the Web Vitals thresholds, CLS, INP, and TTFB each score around 90, but FCP and LCP score well below that, pulling the weighted average down. The 2-metric set avoids this by using the Web Vitals thresholds directly as its p10 values, so meeting "good" thresholds there produces a score of ~90.

Scenario FCP LCP CLS INP TTFB 4 (no INP) Full 4 (no TTFB) 2-met
Fast CDN-served landing page 0.6s 0.9s 0 0.03s 0.15s 99 99 99 100
Well-optimized news site 1.2s 2.0s 0.05 0.12s 0.4s 84 87 85 98
Typical corporate website 2.0s 3.0s 0.12 0.25s 0.9s 61 66 63 81
Heavy SPA (React/Angular) 2.8s 3.5s 0.03 0.40s 0.6s 62 62 56 61
Ad-heavy media site 3.5s 5.0s 0.35 0.80s 1.2s 29 28 20 31
Slow shared hosting blog 4.5s 7.0s 0.20 0.60s 2.5s 28 31 31 11
Overloaded e-commerce site 5.5s 8.0s 0.45 1.20s 3.5s 10 10 10 5
Broken/failing site 12s 18s 1.50 3.0s 6.0s 1 1 0 0

Here's a comparison of the scores for PC vs. mobile device types across the same scenarios, using the full and 2-metric sets.

Scenario PC Full Mobile Full PC 2-met Mobile 2-met
Well-optimized news site 87 98 98 98
Typical corporate site 66 83 81 81
Heavy SPA 62 77 61 61
Slow shared hosting 31 33 11 11