You open a supplier’s site and the screen stays blank a beat too long before even the logo appears. That initial pause is not just “slow internet”: it is TTFB (Time to First Byte)—how long the server takes to send the first byte of the HTML response. In 2026, with shared hosting, CDNs, and headless content APIs, it still separates a responsive business website from one that feels neglected.
This article explains what TTFB includes, practical thresholds, how it relates to LCP, CLS, and INP, and which concrete changes usually shorten server wait without rebuilding the entire site.
What TTFB is and what it measures
TTFB is the time from the browser’s request for a document (usually the page URL) until the first byte of the response arrives. In simplified terms it covers:
- DNS resolution and connection setup (TLS on HTTPS).
- Server processing time (PHP, templates, database queries).
- Hosting queueing under load or concurrency limits.
- Network hop to the origin or nearest CDN node.
It is not the same as full page load or LCP: you can have acceptable TTFB and poor LCP if the hero is heavy, or high TTFB that delays everything even when images are optimized.
web.dev’s TTFB guide shows how it fits the navigation timing breakdown and why you should measure it on HTML documents, not only static assets.
Practical thresholds in 2026
TTFB is not a standalone Core Web Vital, but performance tooling and Lighthouse often use these references for the main document:
- Good: under 800 ms.
- Needs improvement: 800 ms to 1.8 s.
- Poor: above 1.8 s.
Always interpret the 75th percentile for real users in your markets. A European server with Latin American traffic may show high TTFB in CrUX while feeling fast in your office. Compare homepage, contact, and top lead-generating landing pages.
TTFB vs LCP, CLS, and INP
Core Web Vitals measure perceived experience once the browser can paint and interact. TTFB is the prelude: if HTML is late, the browser cannot parse critical resources, apply CSS, or reserve space to avoid layout shifts.
Prioritize TTFB when PageSpeed flags “Reduce initial server response time,” when every URL slows after a deploy, or when the backend hits the database on every view without cache.
Common causes on business websites
- Marketing-heavy stack on tight infrastructure: CPU or PHP-FPM limits at peak hours.
- N+1 queries or unindexed listings in blog, catalog, or client areas.
- Plugins or modules running heavy logic on every request (geo, personalization, A/B).
- No page or object cache on routes that could be mostly static.
- Misconfigured TLS or CDN-to-origin causing constant revalidation.
- Synchronous external APIs during render (pricing, stock, CRM) blocking HTML.
Gzip or Brotli compression shrinks transfer size but does not fix high TTFB: the first byte still waits on server generation.
How to measure TTFB
- PageSpeed Insights / Lighthouse: “Time to First Byte” in opportunities.
- Chrome DevTools → Network: “Waiting (TTFB)” with cache disabled.
- WebPageTest: phase breakdown (DNS, connect, SSL, TTFB) from multiple regions.
- Search Console and RUM: tie slow URLs to form conversion drops.
- Uptime monitoring: alert on 5xx or latency thresholds at the origin.
Measure the HTML document URL, not only CSS or JS. Repeat after purging server and CDN cache to see the cold path a new visitor hits.
Actions that usually lower TTFB
Page and fragment caching
Enable HTTP caching on public routes (home, services, stable blog posts) and object cache for repeated queries. Align TTL with editorial workflow: publishing should invalidate only needed keys. Pair with sensible browser caching for versioned assets, not personalized HTML without rules.
Tune backend and database
Fix slow queries, index catalog filters, and use eager loading in listings. Move non-critical work to queues (email, sync). In Laravel or similar CMS stacks, disable debug and unnecessary autoload in production.
CDN and origin connection
Serve static or semi-static HTML from the edge when possible. Keep-alive between CDN and origin; avoid new TLS handshakes per request. If the origin is far from users, consider hosting region or preconnect as a complement, not a fix for a slow server.
Defer non-critical work
Do not block HTML waiting for analytics, chat, or maps. Apply the same discipline as for third-party scripts: anything not required for first paint should load later.
Scale infrastructure with data
If TTFB spikes at peak but code is lean, review PHP-FPM limits, workers, and hosting plan. A targeted upgrade often costs less than lost paid traffic.
Mistakes that keep TTFB high
- Treating TTFB as total load time and only optimizing images.
- Aggressive HTML cache on session- or price-personalized pages without Vary rules.
- Front-end micro-optimizations without measuring the origin.
- Ignoring redirect chains from poorly planned 301 redirects.
Checklist before calling it done
- Did TTFB improve in DevTools on a cold HTML load?
- Does WebPageTest from your target region confirm the gain?
- Did LCP and CLS on the same URLs stay healthy after enabling cache?
- Do forms and logged-in areas still show fresh data?
Conclusion
TTFB answers a direct question: “How long until the server starts responding?” On a business website, every fraction of a second before the first byte delays the whole resource tree and erodes trust. Measure critical URLs, combine sensible caching, a tuned backend, and infrastructure that matches traffic, and review impact alongside your other performance metrics.
If you want to prioritize speed and Core Web Vitals with measurable conversion impact, AATSOFT audits origin, CDN, and key templates and proposes changes scoped to your current stack.
