Site speed checks

The site speed check runs a Lighthouse audit against your domain once per day using the Google PageSpeed Insights API. It measures Core Web Vitals, overall performance, accessibility, best practices, and SEO scores, then computes an A–F letter grade from the weighted CWV metrics. If the grade drops, DomainCare fires an alert.

What it measures

Lighthouse lab scores (simulated mobile and desktop):

• Performance — overall Lighthouse performance score (0–100)
• Accessibility — Lighthouse accessibility audit score
• Best practices — security headers, console errors, deprecated APIs
• SEO — basic on-page SEO signals

Core Web Vitals (lab):

Metric	Good threshold	Poor threshold
LCP (Largest Contentful Paint)	≤ 2500 ms	≥ 4000 ms
TBT (Total Blocking Time)	≤ 200 ms	≥ 600 ms
CLS (Cumulative Layout Shift)	≤ 0.10	≥ 0.25
FCP (First Contentful Paint)	≤ 1800 ms	≥ 3000 ms
Speed Index	≤ 3400 ms	≥ 5800 ms

The check detail leads with the desktop grade — the site's base quality — with the mobile result shown alongside as a "Mobile stress test" chip (a simulated mid-range phone on slow 4G; deliberately harsh, and the reason tools like GTmetrix often show higher grades). In the check detail, LCP, TBT, and CLS are the primary cards with status indicators. FCP and Speed Index are secondary metrics — they appear under the collapsed Lab details section with their good/poor label, but they never color the check on their own (Speed Index is the noisiest Lighthouse metric).

Field data (CrUX) — when available, PageSpeed Insights also returns real-user measurements from the Chrome User Experience Report for LCP, FCP, INP, CLS, and TTFB. Field data reflects actual visitor experience and may differ from lab results.

What drags it down — the check records potential savings across image weight and sizing, lazy-loading, render-blocking resources, unused JavaScript/CSS, text compression, cache lifetimes, server response time, fonts, page weight, page complexity, and third-party scripts. The check detail turns these into ranked plain-language fix cards — biggest savings against the currently-failing metric first — each with an effort tag (Plugin / Hosting / Content / Developer) and the underlying Lighthouse audit id.

How the letter grade is computed

The grade uses a weighted composite of the five CWV lab metrics:

Metric	Weight
LCP	30%
TBT	25%
CLS	20%
FCP	15%
Speed Index	10%

Each metric is scored 0–100 linearly between its good and poor thresholds. The weighted composite maps to grades: A ≥ 90, B ≥ 80, C ≥ 70, D ≥ 60, F below 60.

How often it runs

The site speed check runs once every 24 hours (86,400 seconds). PageSpeed Insights scans take up to 60 seconds per strategy; mobile and desktop run in parallel.

Alerts this check produces

Event	Tone	When it fires
site_speed_degraded	Info	The smoothed desktop score slipped into the fair band (50–74). A heads-up, not an alarm
site_speed_below_target	Warning	The smoothed desktop score worsened into the poor band (30–49) — or the critical band (< 30), which alerts immediately: a score that low usually means something genuinely broken
site_speed_recovered	Recovery	The smoothed desktop score is back above 75 and has held there across two evaluations
cwv_field_failing	Warning	Google's real-user data (CrUX) now fails Core Web Vitals at the 75th percentile — measured from actual visitors over 28 days
cwv_field_recovered	Recovery	Real-user data passes Core Web Vitals again
lighthouse_score_dropped	Info	An accessibility, best-practices, or SEO score dropped ≥ 10 points (smoothed) — performance changes are covered by the band events above

Scores are smoothed (median of the last three completed runs) before any judgment, so a single noisy run never alerts. Sites with real-user CrUX data get the CWV events instead of lab band events — one source of truth per site — except the critical band, which stays on for everyone as a fast safety net.

How the check decides its status: real-user data outranks the lab. If CrUX shows visitors passing Core Web Vitals, the check is valid regardless of the harsh mobile lab number. If CrUX shows them failing, the finding is informational (since 2026-07-20): the failing-CWV verdict and its detail stay visible on the check page and the cwv_field_failing event still fires, but it doesn't turn the check or domain amber — performance advice, not an incident. Without CrUX, the smoothed desktop score decides: ≥ 75 good, 50–74 room to improve, 30–49 needs attention, under 30 critical. The mobile stress test never sets the status on its own.

What to do when the alert fires

• Check which metric drove the drop — the alert details include the current grade and per-metric values. A sudden LCP regression often points to a large hero image added without lazy loading or a slow server response. A TBT spike usually means new JavaScript added to the critical path.
• Work the "What drags it down" list top-down — cards are ranked by estimated savings against the metric currently failing, and each names the kind of fix it takes (a plugin, a hosting setting, lighter content, or developer work). The top three are usually worth more than everything below them combined.
• Common quick wins:
  • Add loading="lazy" to below-the-fold images
  • Defer or async non-critical JavaScript
  • Enable text compression (gzip or Brotli) on your server
  • Use a CDN to reduce TTFB for static assets
• Distinguish lab from field — a grade drop on the lab scan may not reflect what real users experience if the change affects synthetic conditions differently (e.g. a change to a third-party script that loads differently under simulated throttling).
• Re-test after fixes — the next automatic scan runs in 24 hours. You can also trigger a manual re-scan from the domain dashboard.

Related

• Uptime checks — slow server response time (TTFB) often shows up in both uptime latency and site speed scores
• Alert reference