How to Fix Slow Server Response Time

How to Fix Slow Server Response Time (TTFB) for Core Web Vitals

Time to First Byte (TTFB) is how long your server takes to respond after a browser requests your page. A good TTFB is under 800ms. Slow TTFB is the most common root cause of poor LCP scores. The fastest fixes are adding a CDN, enabling server-side caching, and upgrading your hosting plan. Most sites can cut TTFB by 50–70% without touching a single line of code.

Your page cannot load faster than your server responds. It sounds obvious — but TTFB is the most overlooked performance bottleneck on the web.

You can preload every image, compress every file, and defer every script. If your server takes 2 seconds to respond, your LCP cannot be better than 2 seconds. Full stop.

This article covers exactly what TTFB is, why it matters for Core Web Vitals, and every fix in order of impact — from zero-effort CDN setup to server-level optimisation for developers.

If you are still working out which Core Web Vitals are failing on your site, start with the complete Core Web Vitals fix guide before coming back here.

What is TTFB?

TTFB stands for Time to First Byte. It measures the time between a browser sending an HTTP request for your page and receiving the first byte of the response from your server.

It covers three phases:

1. DNS lookup — the browser translates your domain name into an IP address
2. TCP connection — the browser establishes a connection with your server
3. Server processing time — your server receives the request, generates the HTML, and sends the first byte back

The third phase — server processing time — is where most TTFB problems live. DNS and TCP connection times are relatively fixed. Server processing time varies wildly depending on your hosting, caching setup, and how much work your server does to generate each page.

Why TTFB matters for Core Web Vitals

TTFB is not a direct Core Web Vital — Google does not score it on its own. But it is the foundation on which everything else is built.

Here is why it matters so much for LCP specifically:

LCP measures when the largest visible element finishes loading. Before that element can load, the browser needs the HTML from your server. The HTML contains a reference to the LCP image or text block. The browser cannot start loading the LCP element until it has the HTML. The HTML cannot arrive until the server responds.

The chain looks like this:

User requests page

  → DNS lookup (~20–100ms)
  → TCP connection (~10–50ms)
  → Server processing (~200ms to 3,000ms) ← this is TTFB
  → Browser receives HTML
  → Browser discovers LCP element
  → LCP element loads
  → LCP timestamp recorded

Every millisecond of TTFB is added directly to your LCP time before anything else even starts. A 2,000ms TTFB makes a 2.5s LCP target mathematically impossible.

This is also why fixing TTFB often resolves Core Web Vitals failures that other fixes have not been able to move — because those other fixes were working against an unfixable baseline.

How to check your TTFB

Method 1: PageSpeed Insights

1. Go to pagespeed.web.dev
2. Run your URL
3. In the Diagnostics section, look for "Reduce initial server response time."
4. It will show your current TTFB and flag it if it is above 600ms

Method 2: Chrome DevTools Network panel

1. Open Chrome DevTools (F12)
2. Go to the Network panel
3. Reload the page
4. Click the first request in the list — your HTML document
5. In the Timing tab, look for "Waiting for server response (TTFB)"

This gives you the most accurate TTFB reading because it shows exactly how long the server took to respond from your location.

Method 3: WebPageTest

Go to webpagetest.org and run a test from a location close to your target audience. WebPageTest shows a detailed waterfall with TTFB broken down into DNS, TCP, and server processing time separately — useful for identifying exactly which phase is slow.

The 6 most effective TTFB fixes

Fix 1: Add a CDN (biggest impact, easiest to implement)

A Content Delivery Network stores cached copies of your pages on servers around the world. When a user requests your page, the CDN serves it from the server closest to them — not from your origin server thousands of miles away.

This single change can cut TTFB from 1,500ms to under 100ms for users far from your origin server. It is the highest-impact TTFB fix available and requires zero code changes on most platforms.

For most sites: Cloudflare free plan

Cloudflare is free, takes about 20 minutes to set up, and works for every platform — WordPress, Shopify, static sites, and custom applications. The setup process:

1. Create a Cloudflare account
2. Add your domain
3. Cloudflare scans your existing DNS records
4. Update your domain's nameservers to Cloudflare's nameservers at your registrar
5. Enable "Cache Everything" page rule for static pages

Once live, Cloudflare serves your HTML from its global network of 300+ data centres. Users in India, Brazil, or Australia get your page from a nearby server instead of one in the US or Europe.

For WordPress specifically:

Cloudflare pairs with your existing caching plugin. WP Rocket + Cloudflare is one of the most effective TTFB combinations available for WordPress — Cloudflare handles edge caching, WP Rocket handles server-level and browser caching.

Important: A CDN only serves cached content fast. If your pages are not being cached (dynamic pages, logged-in user pages, uncached WordPress pages), a CDN alone will not fix TTFB. You need server-side caching too — covered in Fix 2.

Fix 2: Enable server-side caching

When a user requests a page on an uncached WordPress site, here is what happens:

1. PHP executes
2. WordPress queries the database (sometimes 20–80 queries per page)
3. The database returns results
4. PHP assembles the HTML
5. The server sends the HTML

This process takes 500ms to 3,000ms, depending on your server and how complex your pages are. Every single visitor triggers this entire process from scratch.

With full-page caching enabled, steps 1–4 happen once. After that, the server serves a pre-built HTML file directly. Response time drops to 50–200ms.

WordPress caching plugins:

• WP Rocket — the most complete solution. Handles page caching, database optimisation, and CDN integration in one plugin. Paid but worth it for serious sites.
• LiteSpeed Cache — free and extremely powerful if your host runs LiteSpeed Web Server (Hostinger, NameHero, A2 Hosting). Often outperforms WP Rocket on compatible hosts.
• W3 Total Cache — free, works on all hosts, more complex to configure correctly.

For custom applications:

• Varnish Cache — reverse proxy caching that sits in front of your application server. Highly effective but requires server access to configure.
• Redis object caching — caches database query results in memory. Significantly reduces database load on dynamic sites.
• Nginx FastCGI cache — built into Nginx, caches PHP responses at the web server level.

Fix 3: Upgrade your hosting

This is the fix most site owners resist because it costs money — but it is often the single most impactful change you can make.

Shared hosting puts your site on a server with hundreds or thousands of other websites. You share CPU, RAM, and database resources with all of them. When other sites on your server get traffic spikes, your TTFB suffers. Server processing times of 1,500ms to 3,000ms on shared hosting are common.

Hosting tiers and typical TTFB:

If you are on shared hosting and your TTFB is above 1,500ms, no amount of optimisation will consistently get you to a Good LCP score. The hardware ceiling is too low.

Recommended managed WordPress hosts:

• Kinsta — Google Cloud infrastructure, excellent TTFB globally, built-in CDN
• WP Engine — reliable, good support, strong caching layer
• Cloudways — most flexible, lets you choose your cloud provider (Google Cloud, AWS, DigitalOcean), better value than Kinsta at scale

The migration process for most WordPress sites takes 2–4 hours and most managed hosts offer free migration assistance.

Fix 4: Optimise your database

On WordPress sites that have been running for years, database bloat is a major TTFB cause that gets worse over time.

Every page view, draft save, revision, spam comment, and transient option adds rows to your database. After two years of operation, a WordPress database can contain hundreds of thousands of unnecessary rows. Every page request queries this bloated database, adding 200–800ms to server processing time.

What to clean:

• Post revisions — WordPress saves every draft version by default. A post edited 50 times has 50 revisions in the database. Limit revisions to 3–5 in wp-config.php:
• php

define('WP_POST_REVISIONS', 3);

• Auto-drafts and trashed posts — empty your trash regularly
• Spam and unapproved comments — delete in bulk from Comments → Spam
• Expired transients — temporary data stored by plugins that is never cleaned up automatically
• Orphaned post metadata — leftover data from deleted plugins

Tools to automate this:

• WP-Optimize — free plugin that cleans and optimises your database in one click
• WP Rocket — includes database optimisation in its settings
• WP CLI — wp db optimize for developers with server access

Run a database cleanup and you will typically see 100–400ms shaved off your TTFB immediately.

Fix 5: Reduce server-side processing time

If you have caching enabled but your TTFB is still slow for the initial uncached request (or for dynamic pages that cannot be cached), the server is doing too much work to generate each page.

For WordPress:

• Deactivate unused plugins — every active plugin runs code on every page load, even pages where the plugin does nothing. Audit your plugins and deactivate anything you are not actively using. This directly reduces PHP execution time.
• Use a lightweight theme — heavy page builder themes execute hundreds of PHP functions per page load. GeneratePress, Kadence, and Blocksy are significantly faster than Divi, Avada, or WPBakery themes.
• Enable PHP 8.x — PHP 8.1 and 8.2 are significantly faster than PHP 7.x. Check your hosting control panel and upgrade if you are still on an older version.
• Use persistent object caching — if your host supports Redis or Memcached, enable object caching to store database query results in memory between requests.

For custom applications:

• Profile your application to find slow database queries — queries without proper indexes are the most common cause of high server processing time
• Implement query result caching for frequently-run queries
• Move expensive operations (image processing, PDF generation, email sending) to background queues instead of running them synchronously on each request

Fix 6: Optimise your DNS

DNS lookup time adds to your TTFB even though it is outside your server. If your DNS provider is slow, every new visitor pays a DNS penalty before your server even starts responding.

Most domain registrars have slow DNS. Cloudflare DNS (1.1.1.1) and AWS Route 53 are consistently the fastest DNS providers globally.

How to switch to faster DNS:

If you are already using Cloudflare for CDN (Fix 1), your DNS is already on Cloudflare — no further action needed.

If you are not using Cloudflare, you can switch your DNS nameservers to Cloudflare without using their CDN:

1. Create a free Cloudflare account
2. Add your domain
3. Select the "DNS only" option (no proxying)
4. Update nameservers at your registrar

Cloudflare DNS resolves in an average of 11ms globally. Most registrar DNS resolves in 50–100ms. For users visiting your site for the first time (no DNS cache), this saves 40–90ms from TTFB.

TTFB fixes by platform

WordPress

The fastest path to a good TTFB on WordPress:

1. Install LiteSpeed Cache (if your host supports LiteSpeed) or WP Rocket
2. Enable full-page caching with cache preloading
3. Add Cloudflare free plan and enable HTML caching
4. Run WP-Optimize to clean the database
5. Deactivate unused plugins
6. Upgrade PHP to 8.2 in your hosting control panel

This combination consistently gets WordPress TTFB from 1,500–2,500ms down to 200–400ms without changing hosts.

If you are also experiencing Google Search Console errors or crawl issues, slow TTFB is often a contributing factor. Googlebot experiences the same slow response times as your users, which can affect crawl budget and indexing frequency.

Shopify

Shopify manages your hosting infrastructure, so you cannot directly control server response time. However, you can reduce the work Shopify's servers do to generate your pages:

• Remove unused apps — every installed Shopify app can add server-side processing time even if the app is not active on a given page
• Simplify your theme's Liquid templates — complex nested loops and large collections iterated in Liquid add processing time
• Use Shopify's built-in CDN — Shopify automatically serves assets through Fastly's CDN. Make sure you are referencing assets through Shopify's CDN URLs, not external sources

Shopify's typical TTFB is 200–600ms for well-optimised stores. If you are above 800ms on a Shopify store, unused apps and complex Liquid templates are the most likely causes.

Next.js and React

For Next.js applications, TTFB depends heavily on your rendering strategy:

• Static Site Generation (SSG) — pre-built HTML served directly, TTFB typically 50–150ms
• Server-Side Rendering (SSR) — HTML generated on each request, TTFB varies with server load (200–800ms typical)
• Client-Side Rendering (CSR) — server sends minimal HTML, JavaScript builds the page, TTFB is fast, but LCP is slow because content is not in the initial HTML

For the best Core Web Vitals results, use SSG for pages with content that does not change per-user, SSR for personalised pages, and avoid CSR for above-the-fold content.

Next.js specific optimisations:

• Deploy on Vercel or Netlify Edge Functions to serve SSR responses from edge locations globally
• Use next/headers cache control to cache SSR responses at the CDN layer
• Implement Incremental Static Regeneration (ISR) for pages that need fresh data without full SSR overhead

TTFB connects to your other Core Web Vitals issues

TTFB does not just affect LCP. A slow server response ripples through every metric:

TTFB → LCP: As covered above — LCP cannot be faster than TTFB. Every millisecond of server delay is added directly to your LCP time.

TTFB → CLS: A slow server means the browser receives the HTML late. Stylesheets, fonts, and scripts all load later. Late font loading causes text reflow. Late stylesheet loading causes layout recalculations. Both contribute to CLS. Fixing TTFB often reduces CLS simultaneously. For a full breakdown of CLS causes, see what causes cumulative layout shift.

TTFB → INP: Slow initial page load means JavaScript executes later, which can delay the point at which the page becomes interactive. Users who try to interact before JavaScript has finished executing experience input delays that contribute to poor INP.

TTFB → Crawlability: Googlebot has a crawl budget — a limit on how many pages it will crawl per day on your site. If your server responds slowly, Googlebot crawls fewer pages. For large sites, this can mean that new or updated content takes weeks longer to be indexed. Combined with other technical issues, this can contribute to Google deindexing your content.

TTFB optimisation checklist

Frequently asked questions

Q1. What is a good TTFB for Core Web Vitals? 

Google's threshold for a good TTFB is under 800ms. However, to consistently achieve a good LCP score of 2.5 seconds or less, you should aim for a TTFB under 400ms. The lower your TTFB, the more headroom you have for the remaining LCP phases — resource discovery, download time, and render delay.

Q2. Does TTFB directly affect Google rankings? 

TTFB is not scored directly as a ranking factor. However, it directly determines your LCP score, which is a Core Web Vitals and an official Page Experience ranking signal. A TTFB above 1,800ms makes it nearly impossible to achieve a Good LCP score, which indirectly costs you rankings in competitive results.

Q3. Why is my TTFB fast in testing but slow in Google Search Console? 

Your testing location matters. If you test from a server close to your origin (same country or region), TTFB looks fast. But if a significant portion of your users are in different regions, they experience much higher TTFB. Google Search Console uses real-user data from actual visitors — this reflects your global audience, not just local tests. Use a CDN to serve your content from locations close to your actual users.

Q4. Is TTFB the same as page load time? 

No. TTFB is just the time until the first byte of the HTML response arrives. Page load time includes everything after that — downloading the HTML, parsing it, loading all CSS, JavaScript, images, and fonts, and rendering them. TTFB is the very beginning of the page load process.

Q5. My TTFB is under 800ms but my LCP is still failing. Why?

TTFB is just one of four phases that make up LCP time. Even with a fast TTFB, LCP can fail due to slow image download time, render-blocking resources, or late LCP element discovery. Check PageSpeed Insights diagnostics to identify which phase is causing the delay. See what is a good LCP score for a full breakdown of the four LCP phases and fixes for each.

Q6. Does shared hosting always cause slow TTFB? 

Not always — but it frequently does, especially under load. Shared hosting TTFB is highly variable. At 2am, with minimal traffic, it might be 400ms. At 2pm, during a traffic spike it might be 3,000ms. This inconsistency is why shared hosting often passes lab tests (run at low-traffic times) but fails real-user field data (which includes peak traffic periods).

Q7. Can slow TTFB cause Google to not index my pages? 

Slow TTFB does not directly cause deindexing, but it reduces Googlebot's crawl efficiency on your site. If Googlebot consistently encounters slow responses, it crawls fewer pages per visit. For large sites, this means new content gets indexed more slowly. If you are experiencing indexing problems, slow TTFB is worth fixing as part of a broader technical SEO audit.

Summary

TTFB is the foundation of every other performance metric. Before your LCP element can load, before your fonts can render, before your JavaScript can execute — the server has to respond.

The fastest fixes in order:

1. Add Cloudflare CDN — free, 20 minutes to set up, immediate impact
2. Enable full-page caching — WP Rocket or LiteSpeed Cache for WordPress
3. Upgrade hosting if you are on shared hosting
4. Clean your database and deactivate unused plugins
5. Upgrade to PHP 8.2

Most sites with TTFB above 1,500ms can get to under 400ms using just the first three fixes — without touching a single line of code.

Once your TTFB is under control, the remaining LCP fixes (image preloading, compression, render-blocking resources) will have their full impact. If you have not already worked through the other Core Web Vitals, the complete guide to fixing Core Web Vitals covers LCP, INP, and CLS in the same level of detail.

Hardeep Singh

Hardeep Singh is a tech and money-blogging enthusiast, sharing guides on earning apps, affiliate programs, online business tips, AI tools, SEO, and blogging tutorials. About Author.