TTFB — Server Response

Slow TTFB —
Shared Hosting Bottleneck

Your server is the problem. No front-end optimization will fix a slow origin.

Where to find it: PageSpeed Insights > Diagnostics > Reduce Initial Server Response Time (TTFB) > Field Data

What It Is

TTFB — Time to First Byte — measures how long the browser waits from requesting a page to receiving the server's first response byte. It's the starting line for everything else: no CSS, JavaScript, or images can load until TTFB completes. Google's target is under 800ms. On shared hosting, TTFB of 1.5–4 seconds is common because dozens or hundreds of websites share the same server resources. When another site on the same server has a traffic spike, your client's TTFB spikes too — with no warning and no control.

Why It Matters

TTFB is the one Core Web Vitals-related metric that cannot be fixed through front-end optimization. You can compress images, defer JavaScript, and inline critical CSS — but all of that work happens after TTFB completes. A page with a 3-second TTFB will have an LCP of at least 3 seconds no matter how well everything else is optimized. Fixing TTFB is an infrastructure decision, and agencies that can present this clearly — with data showing the hosting bottleneck — have a clear path to a hosting migration project.

Root Diagnostics

Common Causes

Understanding why this failure occurs is the first step to fixing it permanently.

Shared Hosting Resource Contention

Multiple websites on the same server competing for CPU, RAM, and database connections. When any site on the shared server gets traffic, all other sites on that server slow down.

No Server-Side Caching

Every page request triggers a full database query and PHP execution cycle. Without page caching, even low traffic generates significant server load and slow response times.

No CDN in Front of Origin

The origin server handles all requests directly. Without a CDN, every visitor — regardless of geography — connects to the same server, and there's no edge caching to serve cached responses quickly.

Slow Database Queries

Unoptimized database queries — particularly on WordPress sites with large post counts, many plugins, or unindexed tables — add seconds to server response time on every page load.

Interactive Standard Operating Procedure

The Fix Blueprint (Interactive SOP)

Check off each step to monitor your implementation progress live!

Implementation Progress: 0% Completed (0/7)

1. Measure Baseline TTFB

Use WebPageTest (webpagetest.org) to measure TTFB from multiple locations. Run 3 tests from each location and record the median. Also check PageSpeed Insights Field Data for 'Server Response Times.' Document everything — this is your before state.

2. Implement Server-Side Page Caching Immediately

For WordPress: install WP Rocket or W3 Total Cache and enable page caching. This serves pre-built HTML files instead of generating pages dynamically — reducing TTFB from 2–4s to under 300ms on cached pages without changing hosting.

3. Add Cloudflare as a CDN Layer

Set up Cloudflare (free tier) in front of the origin server. Enable caching for HTML pages (Cache Everything rule), static assets, and images. Cloudflare's edge network serves cached responses from locations near each visitor, dramatically reducing effective TTFB.

4. Present the Hosting Migration Case

Use WebPageTest data to show the client their TTFB vs competitors on better hosting. Run the same page on GTmetrix and WebPageTest from multiple locations. Present it as a revenue conversation: a 2-second TTFB improvement translates to a 10–15% conversion rate improvement.

5. Migrate to VPS or Managed Hosting

Move the site to managed WordPress hosting (Kinsta, WP Engine, Pressable) or a VPS (DigitalOcean, Vultr). These environments provide dedicated resources, built-in caching, and dramatically faster TTFB. Expect TTFB to drop to 100–300ms.

6. Optimize Database After Migration

Post-migration, run a database optimization: delete post revisions, clean transients, optimize tables. Use a plugin like WP-Optimize for WordPress. Combine with an object cache (Redis or Memcached) if the new hosting supports it.

7. Re-measure TTFB Post-Migration

Run WebPageTest again from the same locations. Document the before/after TTFB improvement. Present this to the client as a concrete performance report. Search Console field data will update over the following 28-day collection window.

Tools

WebPageTest
Free (webpagetest.org) | The best tool for measuring TTFB from multiple global locations with waterfall charts — essential for the hosting case
Pingdom Speed Test
Free (tools.pingdom.com) | Simple TTFB measurement from multiple locations — good for before/after client reports
Cloudflare
Free tier available | Adds CDN caching, edge delivery, and performance optimization in front of any origin server — deploy this first before migration

Time to Fix

1 hour

To measure TTFB and diagnose origin vs CDN issue

Hours to Days

Caching (hours) | CDN (hours) | Migration (days)

Pro Tip

Implement server-side caching first — it's free and often cuts TTFB by 80%.

Before recommending a hosting migration (which requires client budget approval and planning time), implement server-side page caching. On WordPress, WP Rocket's page cache can take a 3-second TTFB to under 400ms on the same shared hosting — for free. Present the cached TTFB to the client as the floor, then show what managed hosting would achieve on top of that. This sequence makes the migration ROI obvious.

Slow TTFB — Shared Hosting Bottleneck