Metrics and thresholds
The good, needs improvement and poor limits that VitalSentinel uses for Core Web Vitals, Lighthouse scores, uptime and the Health score.
This page lists the limits that VitalSentinel uses to rate a value as good, needs improvement or poor. It covers RUM Monitoring, CrUX Monitoring, Synthetic Monitoring, Uptime Monitoring, Site Health Monitoring and the Dashboard.
How VitalSentinel rates a value
VitalSentinel puts most values in one of three bands: Good, Needs improvement and Poor. Each band has a color:
- Green means that all is well.
- Amber means that something is worth a look.
- Red means that a problem needs you now.
On the Dashboard, a grey dot has nothing to judge yet, and an empty ring is a module that is not set up. Hover a dot, a chip or the "?" next to a figure to see what the rating uses.
Some uptime and error figures use the word Warning for the middle band instead of Needs improvement. The meaning is the same.
The typical visit
RUM Monitoring and CrUX Monitoring show one figure for each metric: the value of a typical visit. In tooltips, this figure has the label Typical visit. The tooltip explains it in words: 3 out of 4 visits were this fast or faster.
So the figure does not describe the fastest visit or the slowest visit. Google uses the same statistic, so you can compare the figures of VitalSentinel with the figures of Google.
How Google judges Core Web Vitals
Google judges LCP, INP and CLS each on its own. A metric passes when at least 3 out of 4 page loads are Good. Google judges phones and desktops separately. A page can pass on desktop and fail on phones.
Good visits
Some charts show the share of visits in each band. Good is the share of visits fast enough to count as a good experience. Needs improvement is the share in the middle band: usable, but with room to get faster. Poor is the share of visits slow enough to hurt the experience.
Core Web Vitals limits
Core Web Vitals are the three speed metrics that Google uses in search ranking: LCP, INP and CLS. VitalSentinel also rates FCP and TTFB.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | 2.5 s or less | 4 s or less | more than 4 s |
| INP (Interaction to Next Paint) | 200 ms or less | 500 ms or less | more than 500 ms |
| CLS (Cumulative Layout Shift) | 0.1 or less | 0.25 or less | more than 0.25 |
| FCP (First Contentful Paint) | 1.8 s or less | 3 s or less | more than 3 s |
| TTFB (Time to First Byte) | 800 ms or less | 1.8 s or less | more than 1.8 s |
These limits apply to field data: measurements from real visitors in RUM Monitoring and CrUX Monitoring. Phones and desktops use the same limits.
LCP limits
LCP (Largest Contentful Paint) is how long visitors wait until the main content of the page is on screen. The main content is the largest image, video or block of text. An LCP of 2.5 seconds or less is good. More than 4 seconds is poor.
INP limits
INP (Interaction to Next Paint) is how quickly the page reacts when a visitor taps, clicks or presses a key. It reflects the slowest reactions during the visit. An INP of 200 milliseconds or less is good. More than 500 milliseconds is poor.
CLS limits
CLS (Cumulative Layout Shift) is how much the page jumps around while it loads, for example a button that moves just as you tap it. A score of 0 means that nothing moved. A CLS of 0.1 or less is good. More than 0.25 is poor.
FCP limits
FCP (First Contentful Paint) is how long until the first text or image appears. Until then, the visitor sees a blank page. An FCP of 1.8 seconds or less is good. More than 3 seconds is poor.
TTFB limits
TTFB (Time to First Byte) is how long your server takes to start answering a page request. Every other speed number starts after it, so a slow server slows everything. A TTFB of 800 milliseconds or less is good in field data. More than 1.8 seconds is poor.
Synthetic Monitoring limits
Synthetic Monitoring runs Lighthouse tests in a lab. A lab test is one controlled run, not a real visit. Lighthouse uses its own limits for lab results.
Lighthouse scores
Lighthouse gives four scores from 0 to 100: Performance score, Accessibility, Best practices and SEO. All four scores use the same bands.
| Score | Rating |
|---|---|
| 90 to 100 | Good |
| 50 to 89 | Needs improvement |
| 0 to 49 | Poor |
The Performance score is a weighted blend of LCP, TBT, CLS and the other speed measures.
Lab speed measures
| Measure | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 s or less | 4 s or less | more than 4 s |
| FCP | 1.8 s or less | 3 s or less | more than 3 s |
| TBT (Total Blocking Time) | 200 ms or less | 600 ms or less | more than 600 ms |
| CLS | 0.1 or less | 0.25 or less | more than 0.25 |
| TTFB (lab) | 600 ms or less | 1.8 s or less | more than 1.8 s |
| SI (Speed Index) | 3.4 s or less | 5.8 s or less | more than 5.8 s |
| TTI (Time to Interactive) | 3.8 s or less | 7.3 s or less | more than 7.3 s |
| Requests | 50 or fewer | 100 or fewer | more than 100 |
| Data transferred | 1.5 MB or less | 3 MB or less | more than 3 MB |
The lab TTFB has a stricter good limit (600 ms) than the field TTFB (800 ms). The lab TTFB is not the same as the TTFB that real visitors get. Lighthouse no longer uses TTI in the Performance score.
One test or many tests
A single Synthetic Monitoring test is one run, so it has no typical value. When a figure covers many tests, the score is an average. The speed measures show the typical value: 3 out of 4 tests were this fast or faster.
CrUX ad metrics
CrUX Monitoring can show four experimental Google measures about ads: Ads in view, Screen covered by ads, Ad CPU time and Ad data transferred. Google gives no good or poor limits for these measures, so VitalSentinel does not color them.
Uptime Monitoring limits
Uptime Monitoring rates these figures in its tooltips:
| Figure | Good | Warning | Poor |
|---|---|---|---|
| Uptime percentage | 99.9% or more | 99% or more | less than 99% |
| Average response time | 200 ms or less | 500 ms or less | more than 500 ms |
| SSL certificate expiry | more than 30 days | more than 7 days | 7 days or less |
| Domain registration expiry | more than 60 days | more than 14 days | 14 days or less |
An uptime of 99.9% allows about 43 minutes of downtime in a month.
JavaScript error limits
Two places rate the errors that real visitors hit:
- Domain Overview: the RUM Monitoring card shows a JS errors tile only when more than 1% of page loads hit an error. The tile is amber up to 5% and red above 5%. Its tooltip, JavaScript error rate, says "Good: ≤1% | Warning: ≤5% | Poor: >5%".
- RUM Monitoring Errors page: the Visits with an error tile is green below 2%, amber from 2% and red from 10%. The verdict shows from 2%. See Errors.
Health score bands
Site Health Monitoring gives your site a Health score from 0 to 100. A score of 90 or more is Good. A score below 70 is Poor. A score between the two is Needs attention.
The score starts at 100. Each open issue takes points off by how serious it is and how much of your site it affects. Before the first score, the Overview shows a word instead, such as Not checked yet, Getting to know your site or Not scored yet. For the details, see Site Health Monitoring.
Related
- Glossary - plain definitions of every metric and term
- RUM Monitoring - Core Web Vitals from your real visitors
- CrUX Monitoring - the field data that Google uses
- Synthetic Monitoring - Lighthouse lab tests
- Uptime Monitoring - availability, SSL and domain expiry
