Reduce initial server response time: PageSpeed fix guide

Why the number changes between runs

PageSpeed Insights runs its lab test from a Google data center, which may be far from your server and your visitors, and it records a single page load. If that request hits a cold cache, the server builds the page from scratch; a second run seconds later may come back much faster from cache. A borderline result can pass one run and fail the next.

The 600ms audit threshold is not the same as Time to First Byte targets for real visitors. web.dev treats a field TTFB of 0.8 seconds or less as good, but field TTFB also includes DNS lookup, connection setup and redirects. The audit focuses on the server's own response. Treat one failed run as a prompt to measure properly, not as a verdict.

Check the tested URL too. If PageSpeed was given an http:// address, or the non-canonical www or non-www version, the document request includes one or more redirects before the real page. The Document request latency insight flags redirects separately, but they still delay the first byte of the final page, so test the exact canonical URL.

Find where the time goes

Before fixing anything, split the response time into phases. The TTFB checker shows a waterfall of DNS lookup, connection, TLS handshake and server wait, and compares a cold request with a warm one.

If most of the time is server wait, the server is slow to generate the page: work on caching and the application. If DNS, connection or TLS dominate, the cause is distance or network setup: a CDN or a server region closer to visitors helps more than code changes. If the cold request is slow and the warm one fast, the cache works but expires or misses too often.

Fixes that work on any stack

Server response time comes down to doing less work per request, or doing it faster:

• Full-page caching. Serving stored HTML skips the application and database entirely. Use the application's cache, a reverse-proxy cache such as nginx's fastcgi_cache or Varnish, or the hosting platform's built-in cache.
• Edge caching. A CDN configured to cache HTML answers from a location near the visitor. Many CDNs, Cloudflare included, cache static files by default but not HTML, which needs an explicit cache rule.
• Object caching. Redis or Memcached keeps repeated database results in memory for pages that cannot be cached whole.
• Database work. Add missing indexes, remove queries that run on every page, and clean up tables that have grown without limit.
• A current runtime. Newer PHP, Node.js or Python versions are generally faster, and PHP's OPcache avoids recompiling code on every request.
• Enough resources. A plan that is constantly at its CPU or memory limit queues requests, which shows up directly as server wait.

WordPress specifics

Most slow WordPress responses come from a short list of causes, and most can be checked from the dashboard:

• No page cache, or a cache that misses. Install a caching plugin or enable the host's cache, then confirm pages are actually served from it. The HTTP header checker shows cache headers such as x-cache or cf-cache-status reporting HIT or MISS.
• Cache bypasses. Logged-in users, cart and checkout pages, and URLs with query strings such as utm tracking parameters often skip the cache by design. Test as a logged-out visitor, with a clean URL.
• PHP version. Site Health (Tools > Site Health) warns about outdated PHP versions; upgrading is usually a control panel setting.
• No persistent object cache. Site Health suggests one when it would help. Redis or Memcached support from the host plus a connector plugin provides it.
• Autoloaded options bloat. Plugins store settings that load on every request, and leftovers from removed plugins accumulate. Recent WordPress versions flag a large volume of autoloaded options in Site Health.
• Heavy plugins. The Query Monitor plugin shows the database queries, HTTP API calls and time per plugin on each request, which identifies the expensive ones.
• WP-Cron. Scheduled tasks run on visitor page loads by default. Setting DISABLE_WP_CRON in wp-config.php and triggering wp-cron.php from a system cron takes that work off visitor requests.

A step-by-step approach

Measure, change one thing, and measure again:

1. 1Run the TTFB checker several times on the URL PageSpeed flagged and note both the cold and warm server wait.
2. 2If the warm response is slow, caching is not working. Enable or fix full-page caching and confirm HIT responses in the headers.
3. 3If only the cold response is slow, extend cache lifetimes, preload the cache after clearing it, or add edge caching for HTML.
4. 4If even cached responses are slow, look at the server: resource limits, PHP version, and the distance between server and visitors.
5. 5For uncacheable pages, profile the application to find the slow queries and plugins, and add object caching.
6. 6Rerun PageSpeed Insights two or three times and judge the typical result, not a single run.

When the hosting is the limit

If a page served from cache still takes several hundred milliseconds of server wait, the application is not the bottleneck. A cached page should be one of the cheapest things a server can deliver. Slow cached responses point at an overloaded shared server, slow storage, or a data center far from the test location.

At that point the fix is a different hosting setup rather than more optimization: a plan with more resources, a server region closer to your audience, or a CDN that serves cached HTML from the edge. Measure TTFB before and after any change so you can see whether it helped.