Time to First Byte (TTFB) is the time between starting to navigate to a page and the moment the first byte of the server's response begins to arrive. Nothing on the page, no text and no image, can be drawn before that byte shows up, which makes server response time the first link in the page speed chain. If you publish content or run a site, the practical questions are whether TTFB matters for SEO, how it matters, and which levers (caching, a CDN, fewer redirects) actually shorten it.
This guide is written for publishers and developers. It covers what TTFB measures and the thresholds web.dev gives, how to measure it without fooling yourself, the layers that make up a server response, what each Cache-Control directive does, what a CDN can and cannot fix, why personalized pages must stay out of shared caches, and how Google's crawlers treat HTTP caching. Image, JavaScript and the rest of Core Web Vitals are a separate subject and are pointed to where they belong.
What Is TTFB and What Counts as Good?
The definition and its parts
The web.dev article on TTFB (Opens in a new tab) defines it as the time from the start of navigation until the first byte of the response begins to arrive. It is not a single server task. According to the article, TTFB adds up redirect time, service worker startup time where applicable, DNS lookup, connection and TLS negotiation, and the request itself up to the point where the first byte arrives.
That breakdown changes how you debug. A complaint such as "the server is slow" often hides a chain: a redirect from an outdated address, a connection to a faraway machine, or an application waiting on its database. Buying a bigger server before you know which link is long can leave the real problem untouched.
The thresholds web.dev gives
On the same page web.dev offers a rough guide for most sites: 0.8 seconds (800 ms) or less is good, more than 1.8 seconds (1,800 ms) is poor, and anything in between needs improvement. The article frames these as approximate guidance rather than hard rules, and it talks about the 75th percentile of users. One fast test from your own laptop therefore proves little. What matters is the distribution across real visitors in different places and on different networks.
| Range | web.dev rating | How to read it |
|---|---|---|
| 0.8 seconds or less | Good | A rough guide, assessed at the 75th percentile of users. |
| Between 0.8 and 1.8 seconds | Needs improvement | Find out which component is long: redirects, connection setup or server work. |
| More than 1.8 seconds | Poor | Review the whole chain: hosting, caching and redirects together. |
TTFB is not a Core Web Vital
The article says plainly that TTFB is not one of the Core Web Vitals. Sites do not strictly need to hit the good threshold, as long as the value does not stop them from scoring well on the metrics that count. It also notes that a server-rendered site can have a somewhat higher TTFB and still deliver better FCP and LCP, and that a low TTFB matters most for client-rendered applications. Treat TTFB as a diagnostic, not as a score to chase.
How Does Server Response Time Affect SEO?
Indirect path one: loading metrics
web.dev points out that TTFB comes before FCP and LCP, so any delay in the first byte is carried into everything that follows. A slow response can therefore cap how much you gain from LCP work further down the line. The measurement framework itself is covered in our page speed and Core Web Vitals guide; this article stays on the server-side link of that chain.
Indirect path two: crawl capacity
Google Search Central's guide to managing crawl budget for large sites (Opens in a new tab) describes a crawl capacity limit, also called host load, which limits the total time your server spends holding connections open for Google. Every site starts from the same conservative default. The limit rises when the site answers consistently and quickly, and it drops when responses slow down or when the server returns errors (5xx) or rate limiting signals such as 429. To speed up crawling, the guide advises optimizing server response times and resources.
The same guide describes who it is for. It gives examples such as sites with a million or more unique pages that change about weekly, and medium or larger sites with ten thousand or more pages that change daily, and it labels those figures a rough estimate. For a small site, crawl budget is often not the main concern. Our crawl budget optimization guide puts the topic in a wider frame.
The limit of the TTFB and ranking relationship
Google and web.dev documentation does not describe TTFB as a direct ranking signal. The relationship runs through two indirect paths: a slow first byte can lengthen the loading experience users see, and it can limit how much Google crawls. If you want to compare popular beliefs about speed and rankings with what Google's documents say, read SEO myths and what Google documentation says.
How to Measure TTFB Without Fooling Yourself
Field data versus lab data
web.dev lists the Chrome User Experience Report (CrUX) and the web-vitals JavaScript library as field tools, and the Network panel in Chrome DevTools and WebPageTest as lab tools. The difference is practical. A lab run is one controlled request. Field data reflects real visitors on real networks. A page that looks fast from a laptop near your server can feel slow to someone on another continent.
Measuring in the browser
For a page navigation, the article says to read the responseStart value of the navigation entry from the Navigation Timing API. The web-vitals library exposes the same value through its onTTFB function. For sub-resources, the Resource Timing API applies, with one catch: to measure cross-origin requests in the field, the serving origin has to send a Timing-Allow-Origin header. This matters if you track third-party scripts or resources served from a separate CDN hostname.
Three measurement traps
- A 103 Early Hints response counts as the first bytes. A server that sends early hints can show a low TTFB while the real HTML arrives late. web.dev warns that early hints can mask a slow backend, so measure actual server time too.
- Cached and uncached responses behave differently. web.dev recommends building a way to skip the CDN and other caching layers for diagnosis. Without it you only measure how fast the cache is, never how slow the origin is.
- Browser details can change. web.dev notes that Chrome changed what responseStart reports in one version and reverted it in a later one, so version differences can affect comparisons over time.
Making server time visible with Server-Timing
The web.dev article on how to optimize TTFB (Opens in a new tab) recommends the Server-Timing header for measuring backend steps such as database queries, server-side rendering, disk seeks, and CDN cache hits or misses. The data can be read through the Navigation Timing API, Chrome DevTools, or the document request latency insight in Lighthouse. Keep the metric names short and generic on public responses; they exist for measurement, not to describe your internal systems.
The Layers Behind a Server Response
Which layer causes which symptom?
Splitting the path to the first byte into layers helps you look in the right place. The table below turns the components from the web.dev articles into a symptom and first-check list.
| Layer | What it does | Typical symptom | First check |
|---|---|---|---|
| Redirects | Sends the browser from one address to another | Several requests and waits for a single page | Trace http, https, www and trailing slash chains |
| DNS and connection | Resolves the hostname and sets up TLS | A long wait before any byte arrives | Check connection and TLS time in the network panel |
| Hosting and compute | Provides the resources that process the request | TTFB climbs at busy hours | Review memory, CPU limits and stack versions |
| Application and database | Builds the page dynamically | Uncached requests are slow, cached ones are fast | Break the work into steps with Server-Timing |
| Cache layers | Reuse a ready response | The same URL is sometimes fast, sometimes slow | Measure hit and miss behavior explicitly |
| CDN or edge | Serves the response from a point near the visitor | High TTFB for visitors far from the origin | Look at field data by location |
Questions to ask before changing hosting
web.dev's general advice is to make sure the host can handle your traffic, check the memory allocated, keep the backend stack up to date, and re-evaluate hosting if TTFB stays long. This article does not name a hosting provider or price tier; that choice should follow your own measurements. Exhausting the cheaper steps first, such as redirects and caching, usually makes the hardware decision much clearer.
Caching Layers and Cache-Control Directives
Private caches and shared caches
The MDN reference for Cache-Control (Opens in a new tab) separates two kinds of cache. A private cache lives in the client, such as the browser cache, and can store personalized content for one user. A shared cache sits between the origin and clients, such as a proxy or a CDN, and reuses one stored response for many users. That is why personalized content should not be stored in a shared cache. The most expensive mistake people make while chasing a lower TTFB is skipping this distinction and turning a personal page into a public one.
The directives that matter most
Based on the MDN reference, these are the directives you will use most on responses:
- max-age=N: the response stays fresh for N seconds after it was generated on the origin server. The clock starts at generation, not at receipt, and time spent in other caches is deducted using the Age header.
- s-maxage=N: sets freshness for shared caches only. Private caches ignore it, and in shared caches it overrides max-age and Expires.
- no-cache: does not mean do not cache. The response may be stored, but it must be validated with the origin before each reuse.
- no-store: asks every cache, private or shared, not to store the response.
- public: the response may be stored in a shared cache.
- private: the response may be stored only in a private cache such as a browser.
- must-revalidate: once the response is stale it must be validated with the origin before reuse. It is typically combined with max-age.
- stale-while-revalidate=N: allows a stale response to be reused for N seconds while the cache revalidates it in the background.
- immutable: says the response will not be updated while it is fresh, and is intended for versioned or hashed static files.
Check the exact header syntax against the MDN page when you edit your server configuration.
Versioned static files can be cached for a long time
The web.dev HTTP cache article, last updated on 2018-11-05 and therefore an older source, recommends long-lived caching for URLs whose content never changes and changing the file name when the content does. Its example embeds a fingerprint in the file name and sets a lifetime of about one year. The strength of the approach is that a changed file gets a new address, so users fetch it immediately, while an unchanged file causes no network request at all. It fits CSS, JavaScript and images. Applying the same idea to HTML is usually not possible.
HTML and unversioned URLs: cache with validation
The same article explains that HTTP caching alone cannot avoid the network entirely for URLs that stay the same, and it suggests making the browser revalidate with the server before each use. For validation, the server returns an ETag, usually a hash of the content. The browser sends it back on the next request, and if the content is unchanged the server answers 304 Not Modified without resending the body. The article prefers ETag to Last-Modified because it is more accurate. This does not zero out TTFB, since the validation request still reaches a server, but the response body shrinks. A real TTFB gain usually comes from a server or edge cache that can return ready-made HTML without running the application.
What a CDN Does for SEO and What It Does Not
Edge caches and distance
According to web.dev's CDN article (last updated 2023-12-05), a CDN is a distributed network of servers that serves content from locations closer to users than the origin, reducing round-trip latency. The nearby points are called edge caches. In the origin pull model the first request for a resource is a miss: the CDN fetches it from the origin, stores it, and answers later requests from the cache. Even for content that cannot be cached, a CDN can still help by terminating connections near the visitor and using warm connections back to the origin.
Cache hit ratio
The article introduces the cache hit ratio, hits divided by total requests, and calls 90 percent a good goal for most sites. That is a rule of thumb from the article, not a guarantee or a universal threshold, so measure your own ratio first. The usual causes of a low ratio are easy to spot: one resource split across many URLs by query parameters, cache entries multiplied by the Vary header, and responses with Set-Cookie, which are generally not cached.
Cache keys, Vary and cookies
The URL is the basic cache key. Query parameters can split one resource into several entries, so ignoring unneeded parameters or sorting them helps. The Vary header creates separate entries per request header value, and normalizing headers such as Accept-Language protects the hit ratio. On a bilingual site, keeping the language in the URL path (for example /en/ and /tr/) avoids that kind of header-based duplication. Avoid setting cookies on public pages unless you need them.
TTL and purging
For static content such as images, videos and versioned libraries, the article gives long TTLs of six months or a year as examples. For dynamic content it says that even a few seconds of caching under heavy traffic can reduce origin load at little freshness cost. It also describes a hold-till-told approach: cache for a long time and purge when the content changes. If you use it, add a purge step to your publishing process, otherwise updated content keeps being served in its old form.
What a CDN cannot fix
A CDN does not make a slow application fast; it only prevents the same response from being generated again and again. For pages that cannot be cached because they differ per user, TTFB still depends mostly on the origin. A CDN can also introduce its own problems, such as an extra redirect, a wrong header or a broken certificate. This article does not recommend any CDN brand. Your traffic distribution, budget and maintenance capacity should drive that choice.
Keep Personalized Pages Out of Public Caches
Why this is critical
MDN advises adding private to personalized responses, especially those received after login and for sessions managed with cookies, and it warns that forgetting private on such a response can let it be stored in a shared cache and reused for multiple users, which can leak personal information. That is a security and privacy matter before it is a speed matter. web.dev's CDN article adds that responses marked private, which are per user, should not be cached by a CDN, and that responses with no-store are excluded as well.
A quick sorting list
- Identical for everyone: published articles, category pages, public listing and product pages. These are candidates for an edge cache.
- Specific to one user: account, dashboard, cart, orders, messages, checkout and anything tied to a session. These must stay out of public caches. Consider private for per-user responses and no-store for anything that should not be stored at all.
- Mixed pages: a public page body that includes a small personal part, such as the name of the signed-in user. Load the personal part with a separate request, or do not cache the whole page.
Test the rule before release: sign in, sign out, and inspect the headers and body of the same address, then repeat as a different user from a different browser. Cache mistakes often appear only under real traffic, so set up monitoring as well. A page that must stay out of public caches but also should not be indexed is a different question, handled with noindex and access control rather than with cache headers.
Redirects, HSTS and Server-Side Work
Same-origin redirects
web.dev recommends focusing on same-origin redirects because you control them directly. It suggests fixing redirects caused by a missing https:// or inconsistent trailing slashes, using HSTS, and considering HSTS preloading to remove the HTTP to HTTPS redirect. Consistent addresses help users and search engines alike, and they shorten the chain before the first byte.
Streaming, early hints and static generation
For server-side rendering, web.dev suggests starting the response stream as early as possible, using streaming rendering if your runtime supports it, and using static rendering for pages without personalized content. A 103 Early Hints response tells the browser to start fetching render-critical resources while the server prepares the full response, which helps when backend processing is slow. As noted above, it can also hide a slow backend, so keep measuring real server time.
JavaScript-heavy sites
On client-rendered pages the first response is often an empty shell and the content arrives later. web.dev says a low TTFB matters most for such applications. How search engines render and index that kind of page is explained in JavaScript SEO: rendering and indexing.
How Google's Crawlers Treat HTTP Caching
Which headers are supported
Google's overview of crawlers and fetchers (Opens in a new tab) (last updated 2026-06-12) says Google's crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard. It names the pairs ETag with If-None-Match and Last-Modified with If-Modified-Since, and suggests that setting max-age is optional but can help. The same page recommends ETag over Last-Modified for Google's crawlers, uses ETag when both are present, and prefers it because it avoids date formatting problems.
304 responses and crawl efficiency
The crawl budget guide encourages supporting 304 Not Modified for unchanged pages so Google can reuse its own copy and save bandwidth. It does not name ETag or If-Modified-Since; that detail is on the crawler overview page above. In short, caching helps visitors and crawlers in the same direction: repeated responses get smaller and the server does less work.
Watch your errors
Because server errors and rate limiting responses lower crawl capacity, monitor 5xx and 429 responses alongside TTFB. Your server logs show which URLs return slowly and when errors spike; we explain the method in server log analysis for SEO. Logs tie caching and measurement decisions to concrete data.
A Step-by-Step Server Response Audit
The order of work
Working in a fixed order is less risky than changing settings at random:
- Record a baseline first: field TTFB from CrUX or web-vitals, lab TTFB from DevTools or WebPageTest.
- Measure important page types separately (home, category, article, listing), because one average hides different problems.
- Find redirect chains and shorten same-origin redirects.
- Split server work into steps with Server-Timing or application logs, so database, rendering and external calls appear separately.
- Give static files versioned URLs and long-lived caching.
- Choose a caching strategy for public HTML and keep per-user responses out of scope.
- If you use a CDN, check the hit ratio, cache key, Vary and cookie behavior.
- Bypass caches to measure the bare origin; if the problem is there, the cache is only a cover.
- After each change, re-measure the same pages with the same method and compare.
Verifying after the change
Field data takes days or weeks to accumulate, so do not expect instant proof. You can check some things right away: do the response headers carry the Cache-Control values you intended, does a signed-in page stay invisible to another browser, are redirect chains shorter, and did the 5xx rate change? These are safe checks while the field data catches up.
Priorities for Publishers and Developers
Which step for which site?
| Situation | Suggested first step | Watch out for |
|---|---|---|
| Blog or small publisher site | Clean up redirects, version static files, then measure | Unneeded plugins or scripts can lengthen server work |
| Dynamic, content-heavy site (news, listings, marketplace) | Short-lived caching for public pages with a purge routine | Per-user responses must not enter public caches |
| Multilingual site | Keep the language in the URL path | Header-based Vary can multiply cache entries |
| Client-rendered application | Speed up the first response and confirm content exists in the first HTML | A low TTFB alone does not mean a good LCP |
| Large site with very many URLs | Watch bot requests and the 5xx and 429 rate in server logs | The crawl budget guide is written for sites of this kind |
Extra care on pages with ads
On pages that carry ads, the server is not the only source of slowness; ad scripts and layout shifts also affect speed and user experience. We looked at that balance in ads and Core Web Vitals: a publisher balance. Keeping the server response healthy is only the first step; the placement and loading of the ad slot need their own review.
Common Mistakes
Measurement mistakes
The first is relying on a single lab run, which hides the distribution and faraway visitors. The second is measuring with caches on and never seeing the real speed of the origin. The third is treating TTFB as a target in itself; web.dev states that TTFB is not a Core Web Vital and that a strict threshold is not needed as long as it does not hold back the metrics that matter.
Configuration mistakes
Common configuration mistakes include leaving out private or no-store on per-user responses, keeping HTML in cache for a long time without a purge routine, giving long lifetimes to unversioned file names (users keep the old file), setting needless cookies on every page, and leaving redirect chains in place. A single checklist catches most of them.
Expectation mistakes
Installing a CDN and expecting your SEO problems to disappear is the wrong expectation. A CDN improves one link in the chain; content quality, crawlability and relevant links are separate work. Be careful with any service that promises quick ranking gains in return for speed work; Google and web.dev documentation does not promise that speed work brings a ranking gain.
Frequently Asked Questions
What is TTFB?
TTFB is the time from starting to navigate to a page until the first byte of the server's response arrives. It covers redirects, DNS lookup, connection and TLS setup, and the time the server takes to start answering. It is a diagnostic loading metric, not a Core Web Vital.
What is a good TTFB?
According to web.dev, 0.8 seconds or less is good and more than 1.8 seconds is poor, with the range in between needing improvement. These are rough guides assessed at the 75th percentile of users. Track field data rather than relying on one measurement.
Does TTFB affect Google rankings?
Google and web.dev documentation does not describe TTFB as a direct ranking signal. Any effect is expected through indirect paths: a slow response can delay loading metrics such as LCP and can lower Google's crawl capacity limit. No ranking outcome can be guaranteed.
Does a CDN help SEO?
A CDN can reduce latency and origin load by serving content from nearby points, which may help TTFB and loading times indirectly. It does not fix a slow application on its own, it must not cache per-user pages, and it does not promise any ranking result.
What is the difference between no-cache and no-store?
no-cache lets a response be stored but requires validation with the origin before every reuse. no-store asks caches not to store the response at all. For per-user responses, decide between private and no-store based on what the response contains.
Can personalized pages be cached on a CDN?
They should not be. If a personalized response is stored in a shared cache it can be served to other users and leak personal information. Mark such responses private or, where needed, no-store, and test with signed-in and signed-out requests before release.
Do Google's crawlers use HTTP caching?
Yes. Google's documentation says its crawling infrastructure supports heuristic HTTP caching, including ETag with If-None-Match and Last-Modified with If-Modified-Since, and recommends ETag for its crawlers. Answering 304 for unchanged pages makes crawling more efficient.
Conclusion and Next Step
TTFB measures server response time and is not a Core Web Vital. Its link to SEO is indirect: it can delay loading metrics and limit crawl capacity. The sensible order is to measure first, then inspect redirects and server work, then add caching and, if it fits, a CDN for public content, keep per-user responses out of shared caches without exception, and re-measure after every change.
If your pages carry ads, a healthy server response is only the first step of the balance described in the "Extra care on pages with ads" section, and fast responses are part of the environment in which an ad is shown. If you are considering offering ad space, you can browse ad space listings on Akua Adforce. The scope and terms of each listing are written on the relevant product and policy pages, and Akua does not promise that any TTFB, caching or CDN setup will bring ranking or traffic gains.
Post a comment
Please log in to leave a comment. Login