Back to blog

Core Web Vitals: why uptime monitoring isn't enough

· 6 min read

In brief: The server returns HTTP 200, monitoring says "UP" - and you still lose traffic from Google. Core Web Vitals (LCP, INP, CLS) measure real user experience. A slow web is from Google's perspective "down" the same way as unavailable.

In brief: The server returns HTTP 200, monitoring says "UP" - and you still lose traffic from Google. Core Web Vitals (LCP, INP, CLS) measure real user experience. A slow web is from Google's perspective "down" the same way as unavailable.

Three CWV metrics

Google introduced Core Web Vitals as a ranking factor in 2020. Since March 2024 they consist of:

  • LCP (Largest Contentful Paint) - when the largest element of the page appears. Good: ≤ 2.5 s. Needs improvement: 2.5-4 s. Bad: > 4 s.
  • INP (Interaction to Next Paint) - how quickly the page responds to user interactions (click, tap). Replaced FID in March 2024. Good: ≤ 200 ms. Needs improvement: 200-500 ms. Bad: > 500 ms.
  • CLS (Cumulative Layout Shift) - how much page elements visually move during loading. Good: ≤ 0.1. Needs improvement: 0.1-0.25. Bad: > 0.25.

Why monitoring doesn't catch it

Classic uptime monitor sends HTTP GET request and measures:

  • Status code (200 = OK)
  • Time to first byte (TTFB)
  • Optionally keyword match in HTML

But it doesn't render the page in the browser. It doesn't see that:

  • JavaScript bundle is 3 MB and parsing takes 4 seconds
  • Hero image loads synchronously and blocks paint
  • Third party (analytics, advertising) blocks main thread
  • Layout jumps as elements load

From the visitor's perspective the web is slow and unusable - from the monitoring perspective everything is "UP".

Lab vs field data

CWV is measured two ways:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - controlled browser, defined network (typically 4G), specific device. Reproducible, suitable for regression testing after deploys.

Field data / RUM (Chrome User Experience Report, custom JS) - data collection from real visitors in their real conditions. What Google uses for ranking. Reflects actual variability (3G mobile client on a train, desktop fiber, etc.).

Lab data is a good reference, field data is the truth.

Note: ePulz.io does not currently track CWV metrics. To measure them, use specialized tools (PageSpeed Insights, WebPageTest, Lighthouse CI, or your own RUM JS snippet). For visual regressions, ePulz.io offers a monitor of type visual that compares screenshots - this partially covers "page renders completely differently" scenarios, but does not measure LCP/INP/CLS.

Practical monitoring strategy

  1. Synthetic uptime check - classic HTTP monitor every 1-5 min. Detects hard downtime, 5xx, expired certificates.
  2. CWV measurement (outside ePulz) - Lighthouse CI in deployment pipeline or nightly cron that runs Lighthouse and stores results. Detects regression after deployment (LCP rose from 1.8 s to 4.2 s after deploying a new JS bundle).
  3. Visual regression check - screenshot diff. Detects when the page renders completely differently than before (CSS broken, font fail, JS error).
  4. Real User Monitoring - JS snippet on the page collects CWV from real visitors. You watch the 75th percentile of metrics.

Top causes of bad CWV

LCP too high:

  • Large hero images without priority hint (fetchpriority="high")
  • Slow server / TTFB (CDN cache miss, slow DB query)
  • Blocking resources in <head> (analytics, fonts without display=swap)
  • Web fonts loaded from third-party CDN without preconnect

INP too high:

  • Large JS bundle blocking main thread
  • Synchronous event listeners that do heavy work
  • Slow third-party scripts (chat widgets, A/B testing)

CLS too high:

  • Images without explicit width and height attributes
  • Ads without reserved space
  • Dynamically injected content above the fold
  • Web fonts with FOUT (Flash of Unstyled Text) without proper fallback

SEO impact

Google uses CWV as a tie-breaker. When content is equally relevant, it prefers the faster page. In competitive niches it's decisive.

Practical impact:

  • A site with CWV in the "good" range has on average ~20% lower bounce rate
  • Conversion rate rises with every -100 ms LCP
  • Mobile-first indexing means Google evaluates the mobile version - test there

Conclusion

Uptime monitoring answers "Is the server reachable?". Core Web Vitals answer "Is the web usable?". Both metrics are independent and you need to monitor both. The server can have 100% uptime and the web still lose traffic because of LCP over 4 seconds.

Monitoring beyond uptime

Visual regression detects visual changes even when the server returns 200. Response time monitoring catches slow endpoints.

Try ePulz.io →

Try ePulz.io free - 7 days, no credit card needed.

Create account