How to reduce TTFB: fix a slow server response time

To reduce TTFB (time to first byte), fix it in this order: remove redirect hops, serve pages from a full-page cache, then speed up what the cache cannot cover (slow plugins and database queries, outbound API calls, cron jobs, an old PHP version), put a CDN in front for far-away visitors, and only then judge the hosting plan. On a typical CMS site the page cache alone takes the server's share from 1-2 s to around 100-300 ms, and every step before the last one is free. For what TTFB includes and what a good value is, start with the pillar guide, TTFB: what it is and what is good.

This guide is for site owners who see "Reduce initial server response time" in PageSpeed Insights or a slow first byte in a report. Most of it works on a cheap shared plan: the wait is rarely the hardware, and usually PHP building the same page for every visitor or one slow plugin.

Quick answer

1. Measure first: three runs of the TTFB test plus one curl timing, so you know whether the time is network, redirects or the server.
2. Remove redirect hops: one 301 from http:// to the final https:// URL at most.
3. Turn on page caching: the host's cache or one caching plugin. Cached pages should answer in 100-300 ms from nearby.
4. Find the slow plugin or query with a profiler (Query Monitor on WordPress) and remove or replace it.
5. Stop outbound calls and cron jobs during page loads, and run a supported PHP version (8.3 or newer in September 2026) with OPcache on.
6. Object cache and CDN where available; they cover uncached pages and far-away visitors.
7. Move hosts only when cached pages still take over 600 ms consistently.

What you are reducing

Time to first byte is the wait before the browser receives anything: any redirects, the DNS lookup, the TCP and TLS handshakes, and then the server's own think time. On a static file the think time is a few milliseconds. On an uncached CMS page it is everything PHP does: load the theme and every plugin, run 50-150 database queries and build the HTML, which on a busy shared server can take a second or two.

Google rates a TTFB of 800 ms or less at the 75th percentile of real visits as good, and over 1,800 ms as poor (web.dev, "Time to First Byte"). Lighthouse's server response time audit, shown in PageSpeed Insights as "Reduce initial server response time", flags a main document whose server share takes more than 600 ms. A page with a 1.5 s TTFB cannot reach an LCP under 2.5 s, whatever its images weigh.

Shared hosting adds two things: the CPU is shared, so the same work takes longer at busy times, and idle PHP workers are often stopped, so the first visitor after a quiet spell pays a start-up cost. Both make caching more valuable, because a cached page needs almost no CPU and no PHP.

How to check it

The test measures the first byte from Frankfurt with a fresh connection and lists each redirect hop. The speed module adds Lighthouse's number and, where the site has enough traffic, the field TTFB from real Chrome users.

The two findings use different thresholds on purpose: ttfb is rated against Google's field thresholds (800 ms and 1,800 ms), server-response-time against Lighthouse's 600 ms audit. A page can pass the first and fail the second; the second is the one to aim for on cached pages.

The field number is a 28-day rolling window of real visits, so use the lab numbers to see each change and the field number to confirm it a month later.

Step 1: measure properly

One run is not a measurement, least of all on shared hosting. Run the TTFB test three times, a minute apart, and write down the numbers. Then run curl from your own machine to split the wait into its parts:

curl -o /dev/null -s -w 'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  ttfb %{time_starttransfer}s  total %{time_total}s\n' \
  https://example-shop.hr/

Read it as a chain: dns is the lookup, connect adds the TCP handshake, tls adds the TLS handshake, ttfb is when the first byte arrived. The server's think time is roughly ttfb minus tls. If that is 50 ms and the total is still 900 ms, the time is in DNS, distance or a redirect, not in PHP: go to steps 2 and 7. If it is 800 ms, the server is the problem: steps 3 to 6.

Three patterns:

• Consistently slow (1,200 / 1,150 / 1,300 ms): the server does this much work every time. There is no page cache, or it is not being hit.
• First slow, then fast (1,800 / 220 / 240 ms): the cache was cold or PHP workers had to start. Longer cache lifetimes and preloading fix most of it.
• Random (300 / 1,400 / 500 ms): the server is overloaded, by other tenants or by your own cron jobs. Steps 3 and 5, then step 8.

Step 2: remove redirect hops

Every redirect before the page is a full round trip, plus a new connection when it changes scheme or hostname. http://www.example-shop.hr/ → https://www.example-shop.hr/ → https://example-shop.hr/ costs two round trips before the server even starts on the page. The TTFB test lists the hops; the target is one 301 from any variant straight to the final URL, and zero from the URL in your links, ads and sitemap. Redirects without chains has the server rules.

Also look at dns in the curl output: after the first lookup it should be well under 50 ms. Some registrars' bundled nameservers are slow or far away; a large DNS provider costs nothing and fixes it.

Step 3: turn on page caching

A page cache stores the finished HTML the first time a page is built and serves that copy to the next visitors without starting PHP. It is the one fix that turns a 1.2 s think time into a few milliseconds. In order of preference:

• The host's own cache, if there is one: LiteSpeed Cache on a LiteSpeed server (look for server: LiteSpeed in the response headers), or the cache built into the host's panel or plugin. Server-level caches answer before PHP starts, which is the fastest kind.
• One caching plugin on Apache and nginx hosts, such as WP Super Cache (free) or WP Rocket (paid) on WordPress. WP Super Cache's "Expert" delivery mode serves cached files through .htaccess rules without PHP; its "Simple" mode still starts PHP but skips most of the work.
• The CMS's built-in cache elsewhere: System → Global Configuration → System → Cache in Joomla, the Internal Page Cache module in Drupal.

Whichever you use: set a cache lifetime of 12-24 hours so pages stay warm, purge on update, preload if offered, and exclude cart, checkout and account pages. Use one cache only; two fight over purges and headers.

Expect cached pages to answer in 100-300 ms from a nearby test location. If they are still over 600 ms, either the cache is not hit (test in a private window, because logged-in visitors bypass it) or the time is not in PHP at all (step 1). On WordPress, reducing server response time on WordPress covers the cache-bypass cases in detail: session cookies, query strings and over-broad exclusions.

Step 4: find the slow plugin or query

Pages the cache cannot serve (cart, search, logged-in views, the first visit after a purge) depend on how fast the application builds them, and a slow one usually has one component responsible.

On WordPress, install Query Monitor, open a page while logged in and read the admin-bar panel: "Queries by Component" lists database time per plugin, and "HTTP API Calls" lists outbound requests made during the page load. Look for one plugin with hundreds of queries, a single query over 100 ms, or any HTTP call at all.

The usual suspects: visitor-log plugins writing a row per visit, related-posts plugins scanning the whole post table, broken-link checkers running on the front end, and page builders loading their whole framework everywhere. Remove what you do not use, replace what you do with a lighter equivalent, and measure again. Which WordPress plugin is slowing your site has the full method. Deactivate Query Monitor when you are done; it has its own cost.

Step 5: stop outbound calls and move cron

Plugins that phone home during the request (licence checks, update checks, feeds, "latest news" widgets) show in Query Monitor's HTTP API Calls panel with the time each took. When the remote service is down, some wait for a timeout of several seconds. Remove the plugin or ask its author for a setting to turn the call off.

The second is wp-cron. WordPress runs scheduled tasks (publishing, backups, e-mails, plugin housekeeping) by piggy-backing on visitor requests, so busy moments can slow a visitor's page. Turn that off and run the queue from a real cron job every five minutes:

// wp-config.php, above the "That's all, stop editing" line
define('DISABLE_WP_CRON', true);

# cPanel → Cron Jobs (or the host's scheduler), every 5 minutes
*/5 * * * * wget -q -O - "https://example-shop.hr/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

Step 6: update PHP, keep workers warm, add an object cache

Newer PHP versions are faster and still get security fixes. As of September 2026, PHP 8.1 and older are out of support, 8.2 gets security fixes only until the end of 2026, and 8.3, 8.4 and 8.5 are the safe choices (php.net, "Supported Versions"). The switch is a dropdown in the hosting panel ("Select PHP Version" or "MultiPHP Manager" in cPanel); test on a staging copy first.

In the same panel, make sure OPcache is on; it keeps compiled PHP in memory instead of recompiling every file per request.

On your own server or VPS, keep PHP-FPM workers ready instead of starting them per request: pm = static, or pm = dynamic with enough pm.min_spare_servers for your traffic. And if the host offers Redis or Memcached, an object cache keeps the results of repeated database queries in memory, which speeds up uncached pages and the admin.

Step 7: put a CDN in front

A CDN answers from a location near the visitor. For cached files, and for HTML once you add a rule to cache it, the request never reaches your server, which removes both the distance and the think time. For visitors far from your host that is the only way to a good TTFB. It does not speed up what it cannot cache (cart, checkout, search, logged-in pages); what a CDN is and what it fixes covers the setup and bypass rules.

Step 8: when it really is the plan

If cached pages still take over 600 ms from a nearby location after steps 2-7, or TTFB swings between 200 ms and 2 s while the site does the same work, the server is overloaded and the plan is the limit. Other signs: 503 or 508 errors at peaks and CPU throttling notices. Before paying, measure the candidate during its trial: how to choose a web host shows how to compare hosts with your own pages.

Platform notes

• WordPress: Tools → Site Health lists the PHP version, OPcache, the object cache and whether a page cache was detected. The WordPress-specific causes are in the guide linked in step 3.
• Joomla and Drupal: the built-in page cache does the job of step 3.
• Shopify, Wix, Squarespace: the platform's server time is not yours to change, only the redirects in front of the page.
• Custom applications: time the database and every outbound API call. A 400 ms API call on every page is a 400 ms floor for TTFB.

How to verify

• Three TTFB test runs of a public page agree within 100 ms and are under 300 ms.
• The server-response-time finding passes (under 600 ms) and the ttfb finding is rated good.
• The second request for the same page carries the cache's header: x-litespeed-cache: hit, x-cache: HIT, cf-cache-status: HIT, or an age: header above zero.
• The field TTFB is under 800 ms at the 75th percentile four weeks later.

Common mistakes

• Testing while logged in. Logged-in users bypass page caches, so every test looks slow. Test in a private window.
• Two caching plugins. Pages are served stale or not cached at all. Keep one in charge.
• Upgrading the plan first. Uncached PHP is slow on any shared server, so the bigger plan shows the same 1.2 s. Cache first, then judge the plan on cached pages.

Questions people ask

How do I reduce TTFB?

Remove redirect hops first, then turn on full-page caching, which on WordPress and most CMSs cuts the server's share from over a second to around 100-300 ms. After that, speed up what the cache cannot cover: slow database queries, plugins calling external APIs, cron jobs during visits and an out-of-date PHP version. Put a CDN in front for visitors far from the server, and only then consider a faster hosting plan. Measure after each step.

How do I reduce initial server response time?

"Reduce initial server response time" is the Lighthouse audit for a main document whose server share takes more than 600 ms, so it measures the server's work rather than the network. Serve cached HTML, find the slow query or plugin with a profiler such as Query Monitor, stop outbound calls during page loads and use a supported PHP version with OPcache. On shared hosting these free fixes usually work before an upgrade does.

Will a better hosting plan fix a slow TTFB?

Only when the server is really the limit. An uncached WordPress page that takes 1.2 s on a shared plan often takes nearly as long on a bigger one, because the time is spent in PHP and plugins, not waiting for hardware. Fix caching and the slow plugin first, then compare cached-page TTFB on both plans. If cached pages are still slower than 600 ms from nearby, move.

Does upgrading PHP make a website faster?

Usually yes, and it matters for security too. Each recent PHP release has made common CMS workloads somewhat faster, and versions out of support no longer get security fixes. As of September 2026, PHP 8.3 or newer is the sensible choice. The switch is a dropdown in most hosting panels; test on a staging copy first, because an old plugin can break on a new version.