Server response time, measured as time to first byte (TTFB), is how long a browser waits before the first byte of your page arrives. Google's web.dev guidance treats 0.8 seconds or less as good. You reduce it by caching pages, serving them from a CDN close to visitors, using HTTP/2 or HTTP/3, and keeping the HTML light so the browser can start work sooner.
Why does TTFB matter?
Nothing on the page can start loading until the HTML arrives, so a slow server delays every other metric, including Largest Contentful Paint. A slow server also limits how many pages search engines can crawl in a given time, which matters for large sites; see crawl budget.
TTFB includes DNS lookup, connection setup, any redirects and the time your server spends building the page. The web.dev TTFB article explains each part.
What are the biggest causes of a slow server?
The biggest cause is usually building every page from scratch on every request. A WordPress or custom PHP site that runs dozens of database queries per visit will be slow, especially on cheap shared hosting. Other causes are a server far from your visitors, chains of redirects, and slow plugins or API calls made while the page is generated.
How do you reduce TTFB?
Serve pages from a cache close to your visitors, so the server does as little work as possible on each request. These steps usually make the biggest difference.
- Cache full pages. Store the finished HTML and serve it directly. Most CMS platforms have page-cache plugins or built-in options.
- Use a CDN. A CDN keeps copies of your pages and files on servers near visitors. If your visitors are in Mumbai, Delhi and Bengaluru, a server in the US adds delay on every request.
- Upgrade hosting if needed. Very cheap shared plans often have slow, overloaded servers.
- Remove redirect chains. Link directly to the final URL, including the correct
httpsandwwwversion. - Speed up the database. Add indexes, remove unused plugins and clean up old revisions and expired data.
Do HTTP/2 and HTTP/3 help?
Yes. HTTP/2 lets the browser download many files over one connection at the same time, instead of queuing them. HTTP/3 runs over QUIC, which sets up connections faster and handles patchy mobile networks better. Most modern hosts and CDNs support both; often it is a single setting. Googlebot can crawl over HTTP/2 as well.
Do third-party scripts slow pages down?
Yes. Chat widgets, analytics tags, ad scripts, social embeds and A/B testing tools each need extra connections and JavaScript. They often slow the page more than your own code. List every third-party script, remove the ones nobody uses, and load the rest with defer or after the page is interactive.
What are resource hints?
Resource hints tell the browser about important files early, so it can start connecting or downloading before it would otherwise find them.
| Hint | Use it for |
|---|---|
preconnect | A third-party origin you will definitely use soon, such as a font or image CDN |
dns-prefetch | Less critical third-party origins |
preload | A critical file found late, such as the hero image or main web font |
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>Use them sparingly. Preloading too many files makes them compete with each other.
How should web fonts be loaded?
Set font-display so text is visible while fonts download. swap shows a fallback font immediately and swaps in the web font when it arrives; optional avoids the swap if the font is late. Self-host fonts in WOFF2 format where possible, and load only the weights and scripts you use. A Hindi or Tamil font with every weight can be very large.
How do HTML size, DOM size and inline code affect speed?
A large HTML file takes longer to download, and a page with a very large number of elements takes longer to style, lay out and update, which can hurt responsiveness. Large blocks of inline CSS and JavaScript repeat on every page and cannot be cached separately.
- Remove hidden duplicate menus and unused page-builder wrappers.
- Paginate or load long lists, such as hundreds of course cards, in smaller sets.
- Move large inline scripts and styles into cached external files, keeping only small critical CSS inline.
- Turn on Brotli or Gzip compression for HTML, CSS and JavaScript.
Checklist
- TTFB under 0.8 seconds for most visitors.
- Full-page caching and a CDN in place.
- HTTP/2 or HTTP/3 enabled.
- Third-party scripts audited and deferred.
- Fonts in WOFF2 with
font-displayset. - Lean HTML without large inline code.
How to check this with Spider
A Spider page audit measures response time and checks the HTTP version, third-party scripts, resource hints, font-display, inline code, DOM size and HTML size. It also shows Core Web Vitals from Google PageSpeed and the Chrome UX Report, so you can confirm fixes with real-user data. For images, see image optimisation.
Check this on your own site
Spider's free check tests this and about 100 other things on any page, and links each problem to a guide like this one.
