TTFB: the server response time that sinks your landing page before the first pixel

Before a landing page shows its headline, its hero image, or its call-to-action button, something invisible happens: the browser sends a request, and waits. That waiting time, between the moment the request leaves and the moment the first byte of the response arrives, is called TTFB (Time To First Byte, server response time). Not a single pixel has rendered yet — and still, this delay determines everything that follows. An 800ms TTFB is an automatic 800ms delay added to your LCP, no matter how good your hero image or front-end code is. It's the most upstream speed metric, the least visible in mainstream tools, and often the most neglected.

What TTFB actually measures

TTFB covers three consecutive steps: DNS resolution (turning the domain name into an IP address), connection setup (TCP, then TLS encryption for HTTPS), and finally the server's processing time before it sends the first byte of the response. That last step is where sites differ the most: a server that has to query a database, assemble a template, and run business logic on every visit naturally takes longer than a server that just serves an already-generated HTML file. On a landing page — a page whose content rarely changes, sometimes not at all between updates — that difference is almost always avoidable.

Why it isn't a Core Web Vital, yet determines every one of them

TTFB isn't one of Google's three Core Web Vitals (LCP, CLS, INP): it has no official "good / needs improvement / poor" threshold surfaced in the main Search Console report. But it mechanically drives the first of those metrics. LCP is measured from page load start until the largest visible element finishes rendering — and that measurement starts after TTFB, not before. In its own guidance on the topic, Google recommends staying under 800ms of TTFB to keep enough margin for an LCP under 2.5 seconds. A site that responds in 200ms has 2.3 seconds left for everything else (downloading the HTML, loading the hero image, rendering); a site that responds in 1.5 seconds has already blown past the "good" threshold before the browser has painted anything at all.

What research says about server speed and purchase decisions

The gut feeling that "slow is annoying" isn't enough to convince a client or a stakeholder to prioritize something this technical — the research is more precise. In a foundational study published in 2004 in Behaviour & Information Technology, Fiona Fui-Hoon Nah measured how long users tolerate waiting before abandoning a page: past roughly two seconds with no loading feedback at all, attention drops off and abandonment becomes likely (Nah, 2004). More recently, a study by Wojciech Stadnik and Zdzisław Nowak on a real e-commerce platform running Magento established a direct, measurable link between average page load time and observed conversion rate, drawing on real-world Google Analytics traffic data rather than lab tests (Stadnik & Nowak, 2018). TTFB is only one component of total load time, but it's the first one: any delay accumulated here carries through fully into every metric that follows.

Common causes of a slow TTFB on a landing page

• Overloaded or geographically distant shared hosting — a server handling hundreds of sites at once, or located far from the page's actual audience (geo-targeted ad traffic, for instance), adds compounding network latency and queuing time.
• Rendering generated fresh on every request — a CMS or framework that rebuilds the page dynamically (database queries, API calls, template assembly) instead of serving an already-ready static file.
• No caching or CDN — without edge caching, every visitor triggers the full processing cycle on the origin server, even when the content hasn't changed since the last visit.
• Cold-start serverless functions — an on-demand function architecture can add several hundred milliseconds on the first calls after a period of inactivity, if the main page depends on that kind of function instead of being pre-generated.
• Excessive plugins or middleware — on a general-purpose CMS, every active plugin (analytics, popups, server-side A/B testing, personalization) adds processing before the response is sent.

How to measure your TTFB

In Chrome DevTools, under the Network tab, click the main HTML document (usually the first row in the list) and check the Timing tab: the "Waiting for server response" line is your TTFB. PageSpeed Insights explicitly flags a "Reduce initial server response time" audit when it detects a degraded TTFB, along with the measured value. WebPageTest offers the most detailed view: its loading waterfall visually isolates DNS, TLS handshake, and server wait time, useful for pinpointing exactly which step is the problem instead of guessing. As with LCP, test from several geographic locations if your audience is spread out, not just from your own office connection — a fast local result over fiber often hides a very real problem for a mobile visitor farther from the server.

Reducing TTFB without touching the design

The good news: unlike LCP or CLS, fixing TTFB almost never requires touching the page's visible content. It's an infrastructure question, not a copywriting or layout one.

1. Pre-render the page as static HTML instead of rebuilding it on every request (static site generation, SSG) — the server just has to serve an already-ready file, with no computation or database call.
2. Serve the page from an edge CDN that replicates the static file as close as possible, geographically, to each visitor, removing most of the pure network latency.
3. Avoid any blocking external call (database, third-party API, personalization service) on the critical path before the first byte is sent — those calls can happen afterward, asynchronously, without delaying the initial render.
4. Set correct cache headers (Cache-Control) so repeat visits and intermediate CDNs reuse an already-computed response instead of requesting a fresh one.

We cover the full setup for a deployment built around this outcome in our article on deploying a Next.js landing page on Vercel: static generation at build time, distribution through a global edge network, and zero database to query to render the page. That's also part of what explains the TTFB gap between a site built this way and a traditional CMS that rebuilds every page dynamically — a topic we dig into in our Next.js vs. WordPress comparison.

The special case of pages fed by paid advertising

On a landing page driven by Google Ads or Meta Ads traffic, every millisecond of TTFB literally costs money: a visitor who just clicked an ad has an even lower patience threshold than an organic visitor, and a slow load hurts both the bounce rate and, indirectly, the ad's quality score on both platforms. A landing page built for a single campaign — unlike a complex e-commerce product page loaded with widgets and third-party scripts — is particularly well suited to full static generation, precisely because it needs no dynamic data to render: the capture form or payment link is enough, and it can run after the initial render.

That's the technical default on LanderKit templates: each of the 10 templates is a standalone Next.js project, with no database or backend to query in order to render the page, built for a TTFB close to the technical minimum right out of the gate. For an offer driving heavy ad traffic, the SaaS & Waitlist template or the Webinar template illustrate this principle: a simple capture form, no blocking server dependency, and a page that responds in tens of milliseconds rather than several hundred.

TTFB isn't the most visible topic in a landing page audit — nobody brings it up in a meeting, unlike button color or headline copy. That's exactly why it stays uncorrected for months on end: it doesn't show up to the naked eye, only in measurement tools and, indirectly, in a bounce rate that's slightly higher than the rest of the page would otherwise suggest.