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

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.

Optimization opportunities — the check records potential savings for unused JavaScript, unused CSS, render-blocking resources, and uncompressed assets (in KB and ms).

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
lighthouse_score_dropped	Info	The site speed grade dropped compared to the previous scan

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.
• Review the opportunities — the check captures which specific JS and CSS files have the largest unused-bytes savings, and which resources are blocking rendering. Start with the highest-savings items.
• 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