Why your website's Time to First Byte is killing your Google rankings (and how to fix it)

Ask most web agencies how they improve site speed and you'll hear the same answer: compress images, use a CDN, maybe add lazy loading. Tick. Job done. Except it isn't — because if your Time to First Byte (TTFB) is slow, none of those fixes will move the needle on your Google rankings in any meaningful way.

TTFB is the time between a browser making an HTTP request and receiving the first byte of a response from the server. It's a server-side metric, and it's one of the most overlooked factors in website performance in the UK market right now.

Why TTFB matters for Core Web Vitals

Google's Core Web Vitals framework centres on three metrics: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). TTFB directly affects LCP — the time it takes for your page's largest visible element to render.

Google's own guidance states that TTFB should be under 800ms for a "good" rating, with under 200ms being ideal. If your server takes 1.5 seconds just to start responding, your LCP will be poor regardless of how optimised your images are. You're building performance on a broken foundation.

LCP is a confirmed Google ranking signal. A consistently poor LCP score means you are actively being penalised in organic search results. For competitive keywords — especially in local UK search — this can be the difference between page one and page three.

What causes a high TTFB?

There are several common culprits, and most of them are the direct result of how a site was built and where it's hosted:

• Shared hosting. Budget shared hosting plans put hundreds of sites on the same server. When neighbouring sites spike in traffic, your server resources drop and your TTFB climbs. A £3/month hosting plan is rarely a bargain once you account for the organic traffic you're losing.
• No server-side caching. If every page request triggers a full PHP execution cycle and a database query — even for static content — your server is doing redundant work on every single visit. Object caching (Redis, Memcached) or full-page caching can reduce TTFB dramatically.
• Unoptimised database queries. Page builders and bloated CMSs are notorious for this. A single WordPress page with Elementor can fire 80–120 database queries on load. Each query adds latency. Compound this over a slow server and your TTFB can easily hit 2–3 seconds.
• No CDN, or a CDN that isn't caching HTML. Many sites use a CDN (Content Delivery Network) for images and static assets but still serve their HTML from a single origin server. If that origin is in the US and your visitors are in the UK, the round-trip adds 150–200ms before a single byte is received. Properly configured CDNs can cache HTML at the edge and serve it from data centres close to your users.
• Render-blocking server-side logic. In custom-built PHP applications, poorly structured code that executes heavy logic before sending headers — third-party API calls, synchronous email triggers, excessive middleware — will hold up the initial response for every request.

How to actually fix it

The fixes depend on the root cause, but here's what genuinely moves the metric:

• Move to managed or VPS hosting. Providers like Cloudways, Kinsta, or a well-configured VPS on Hetzner or DigitalOcean give you dedicated resources, fast storage (NVMe), and the ability to configure your own caching stack. For most UK SME websites, a £20–40/month VPS will outperform a £100/month shared plan on TTFB.
• Implement full-page caching. For sites built on custom PHP or WordPress, implement page-level caching so the server returns a pre-built HTML file instead of executing PHP and querying the database on every request. This alone can drop TTFB from 1,200ms to under 100ms on a mid-range server.
• Profile and optimise your database queries. Use a query monitor or profiling tool to identify N+1 query problems, missing indexes, and unnecessary joins. On a custom-built site, a developer with database knowledge can reduce query counts by 60–80% in a single session.
• Use a CDN that caches at the origin. Cloudflare's free tier is a solid starting point, but make sure your cache rules are configured to actually cache HTML responses, not just assets. With proper configuration, Cloudflare can serve cached HTML from data centres across the UK and Europe.
• Output buffering and early flushing. In PHP, you can start flushing the HTTP response early — sending the HTML head and initial content before heavy server-side processing is complete. This gives the browser a head start on loading CSS and fonts while the server finishes its work.

Why this is a development problem, not a design problem

This is where template-based agencies hit a wall. If your site was built on a drag-and-drop page builder stacked with plugins, the query bloat and PHP overhead are architectural — you can't fix them without rebuilding the site. There's no plugin that makes Elementor lean. There's no hosting plan that fully compensates for 100 unnecessary database queries per page load.

Custom-built sites, written by developers who understand server architecture and PHP performance, simply don't have these problems by default. The codebase is lean, queries are intentional, and caching is designed in from the start — not bolted on as an afterthought.

If you're serious about Google rankings and you're currently on a page builder site, the honest answer is that you're competing with one hand tied behind your back. Get in touch with us and we'll audit your site — we'll tell you exactly where your TTFB is coming from and what it would take to fix it properly. Or if you're ready to explore a custom build, we can talk through what that looks like for your business.