Skip to content
atlookup

Time to First Byte is Poor (> 1.8 s)

TTFB > 1.8 seconds is Google "poor" — the server is taking too long to respond.

warning Impact: high PERF_TTFB_POOR 2 min read Updated

Why it matters

TTFB > 1.8 seconds is Google "poor" — the server is taking too long to respond. Cascades into poor LCP, FCP, INP — everything downstream is delayed.

Schedule a fix in your next sprint. Warnings won't block your site but they consistently leave performance on the table. Estimated SEO impact: high — direct effect on rankings or impressions.

How to fix

  • Profile server with APM (New Relic, Datadog) to find slow endpoint
  • Add server-side caching (Redis, Varnish, edge CDN)
  • Optimise heavy DB queries (add indexes, fix N+1)
  • Consider upgrading hosting if VM is CPU/RAM-bound
  • Use a CDN to serve static + edge-cached pages

Common causes

If the rule is firing across many pages, the root cause is almost always one of these:

  • Render-blocking third-party scripts (analytics, chat, ads) loaded synchronously in <head>.
  • Hero images served at full original size with no responsive variants.
  • CSS bundle ships every component for every route instead of route-splitting.
  • A single uncached API call dominates time-to-interactive.

Anti-patterns to avoid

Even with the best intentions, these "fixes" make the issue worse — recognise them so you don't ship them:

  • Synchronous third-party scripts in <head>.
  • Serving 4K hero images on mobile because the desktop version "looked fine".
  • Disabling caching headers because "we want fresh content".

How atlookup detects this

Our crawler renders each page with a real headless browser, then collects Core Web Vitals (LCP, CLS, INP), payload sizes, and third-party request counts via Lighthouse. Pages where the rule fires for time to first byte is poor (> 1.8 s) are flagged on the report.

If you'd like to see this rule fire on your own site, run a free 60-second audit — every page is reported with the exact lines that triggered it.

Tools to verify the fix

Once you've applied the fix, double-check with these external validators:

Frequently asked questions

Why does Time to First Byte is Poor (> 1.8 s) matter for SEO?

TTFB > 1.8 seconds is Google "poor" — the server is taking too long to respond. Cascades into poor LCP, FCP, INP — everything downstream is delayed.

How do I fix time to first byte is poor (> 1.8 s)?

Profile server with APM (New Relic, Datadog) to find slow endpoint Add server-side caching (Redis, Varnish, edge CDN) Optimise heavy DB queries (add indexes, fix N+1) Consider upgrading hosting if VM is CPU/RAM-bound Use a CDN to serve static + edge-cached pages

Is this a critical SEO issue?

Schedule a fix in your next sprint. Warnings won't block your site but they consistently leave performance on the table. Estimated SEO impact: high — direct effect on rankings or impressions.

How does atlookup detect time to first byte is poor (> 1.8 s)?

Our crawler renders each page with a real headless browser, then collects Core Web Vitals (LCP, CLS, INP), payload sizes, and third-party request counts via Lighthouse. Pages where the rule fires for time to first byte is poor (> 1.8 s) are flagged on the report.

How long does it take to fix?

15–30 minutes per page. Most teams batch similar issues across templates so the per-page time goes down at scale.

HTML_VERY_LARGE

HTML Document Extremely Large

Pages over several megabytes of HTML are often un-paginated lists or un-split SSR dumps.

PAGE_VERY_SLOW

Page Load Time Is Very Slow

Very slow pages (>5s load) fail Core Web Vitals thresholds and suffer dramatic CTR and conversion drop-offs.

PERF_CLS_POOR

Cumulative Layout Shift is Poor (> 0.25)

CLS measures unexpected layout shifts during page load.

PERF_TTFB_HIGH

High Time to First Byte

TTFB measures how long the server takes to respond.