How to Reduce TTFB on a Service-Business Website

Most page-speed advice hands you a checklist: compress the images, lazy-load the hero, minify the CSS. None of it matters if your server sits there for a second and a half before it says a single word.

That silence has a name — Time to First Byte — and it is the one performance number an owner can usually fix by moving hosts rather than rebuilding a site. Almost nobody tells you that, because 'change your host' is not a retainer.

What is TTFB and why does it decide everything downstream?

TTFB is the time between a visitor starting to navigate to your page and the first byte of the response arriving — Google defines it as covering redirects, DNS lookup, connection and TLS negotiation, and the request phase up to that first byte. Every other paint metric starts counting only after TTFB ends.

That is why it is load-bearing. The HTTP Archive's 2024 Web Almanac found that TTFB is the largest of the four Largest Contentful Paint sub-parts, and that websites with poor LCP spend 2.27 seconds on TTFB alone — nearly the entire 2.5-second budget Google allows for a good LCP, before a single pixel has been drawn.

In other words: a 2.3-second TTFB means you have already failed Core Web Vitals before your homepage image is even requested. No amount of WebP conversion claws that back.

TTFB itself is not a Core Web Vital. Google is explicit: 'Because TTFB isn't a Core Web Vitals metric, it's not absolutely necessary that sites meet the good TTFB threshold, provided that it doesn't impede their ability to score well on the metrics that matter.' For a slow shared-hosted site, it always impedes them.

How do you measure your TTFB in 30 seconds?

Open your site in Chrome, press F12, go to the Network tab, hard-reload, click the very first document request in the list, and read the 'Waiting for server response' line — that number is your TTFB, and it takes about 30 seconds to find.

That gives you one lab reading from your laptop on your connection. For the number Google actually uses, you want field data from real visitors:

Test the page that matters — the service page or location page that takes your paid and organic traffic, not just the homepage, which is often the only page the last agency cached.

What TTFB should you actually be aiming for?

Google's published thresholds are simple: 0.8 seconds or less is good, 0.8 to 1.8 seconds needs improvement, and anything over 1.8 seconds is poor. Aim for under 800ms at the 75th percentile of real users, not on your own machine.

For context on what 'normal' looks like: the 2024 Web Almanac reported that 42% of mobile websites had good TTFB, 40% needed improvement, and 19% were poor — and that this has barely shifted in five years. Being average here is not an achievement.

The Almanac's LCP breakdown gives you a cleaner target. Sites with a good LCP had a median TTFB of 600ms. Sites in the needs-improvement band: 1,360ms. Sites with poor LCP: 2,270ms. If you want good Core Web Vitals, budget roughly 600ms of server time and spend the rest on rendering. More on what that rendering budget buys you in our guide to hitting perfect Core Web Vitals scores.

Why is your WordPress site slow to answer at all?

Because a stock WordPress page is not a file — it is a program that runs on every single request. PHP boots, loads the theme, loads every active plugin, runs a dozen or more database queries, assembles the HTML, and only then starts sending bytes. Your visitor waits through all of it.

This is not a WordPress smear; it is the architecture — and it is fixable without leaving WordPress. But you have to fix it at the server, because the rendering work downstream cannot buy back the time.

The usual suspects behind a 1.4-second WordPress TTFB, in the order we would check them:

• No page cache. Every visitor triggers a fresh PHP execution and full database round-trip. A page cache turns that into serving a stored file. This is the single biggest TTFB lever on WordPress and it is usually free.
• Plugin bloat. Every active plugin runs on every request, even the SEO plugin you only use in the admin, even the form plugin on pages with no form. Twenty-two plugins is twenty-two chunks of code executing before the first byte.
• A page builder. Elementor, Divi and friends store layout as nested shortcodes that must be parsed and expanded server-side, then ship enormous CSS bundles that hurt rendering after TTFB is already blown.
• A $6/month shared host. Your site shares CPU, memory and a database server with hundreds of strangers. When their traffic spikes, your TTFB does.
• An old PHP version. Hosts that leave you on an unsupported PHP release are handing you slower execution and unpatched security in one package.

Diagnose in that order. If the server is slow, nothing else you fix is visible. And be honest about the ceiling: a plugin cannot fix an architecture problem, which is exactly the gap we cover in what WordPress SEO services can and can't fix.

What does each rung of the hosting ladder actually buy you?

Moving from a $6/month shared host to a managed host or a static/CDN-first build is the highest-leverage TTFB fix available to a service business, because it changes what happens on request instead of trimming what happens after. Here is the honest ladder.

Verdict: for most US service businesses on WordPress today, managed hosting with server-level page caching is the correct first cheque — it typically fixes TTFB for a fraction of what a rebuild costs, and you can do it this week. Move to a static or hybrid build when you are rebuilding anyway, not as a standalone speed project. That trade-off is what we lay out in Next.js vs WordPress for marketing sites, and it is baked into how we scope our website design work.

Google's own optimization guidance leads with the same point — the first section of its optimize-TTFB guide is literally titled 'Hosting, hosting, hosting.' Only after that does it get to CDNs, caching and avoiding redirects.

One thing to check before you sign: redirects count inside TTFB. If your site still does http to https to www to apex, you are stacking round-trips onto the metric before your server even starts working. Collapse it to one hop.

Does a slow server reduce how often Google crawls you?

Yes, and Google says so plainly. Its crawl budget documentation states: 'If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.'

The same doc adds: 'If Google can load and render your pages faster, we might be able to read more content from your site.' So a slow server costs you twice — worse Core Web Vitals for users, and fewer pages crawled per visit for Google.

Keep the scale honest, though. Google says crawl budget is a real concern mainly for large sites (1 million+ pages) or medium sites (10,000+ pages) with very rapidly changing content. A 40-page plumbing site is not going to get its crawl throttled into oblivion by a 1.2s TTFB. Fix TTFB for the users and the LCP; treat the crawl effect as a bonus, not the business case.

When is compressing images a waste of your time?

When your TTFB is above roughly 1 second, image work is close to worthless — you cannot get under a 2.5-second LCP by trimming an image that the browser has not even been told about yet. Measure the server first, every time.

The right order of operations for a service-business site:

• 1. Measure TTFB in DevTools and in field data. Under 800ms? Skip to step 4.
• 2. Turn on a real page cache (server-level, not a plugin bolted on top of a slow host).
• 3. If TTFB is still over 800ms, change hosts. This is a cheque, not a project.
• 4. Now do the front-end work — image compression, correct LCP image preloading, killing render-blocking CSS and third-party scripts.
• 5. Re-measure in field data after 28 days, because CrUX reports on a rolling window and your lab score is not what Google grades.

Skipping straight to step 4 is how agencies bill for six months of 'performance optimization' while the server keeps taking 1.4 seconds to say hello. And the reason any of this matters commercially — what the extra seconds cost you in booked jobs — is the page speed and conversion math, not a vanity score.

If you want to know whether your server or your front end is the actual bottleneck, we will pull your field data and tell you which cheque to write — no lock-in, no 12-month contract. Start with a website design and performance review, or Get my free audit.