Bringing TTFB down: database, cache and hosting fixes

Time to First Byte is not a Core Web Vital, but it sits underneath all of them. Every millisecond before the first byte of HTML arrives is a millisecond the browser cannot spend discovering images, loading styles or rendering content. The commonly cited guidance treats a TTFB of 800 milliseconds or less as good. Many of the sites we audit are well above that on uncached pages, and far above it for visitors on the other side of the world from the origin server. Here is how we find out where server response time goes and how we bring it down.

Break TTFB into its parts

TTFB is the sum of several stages, and treating it as one number leads to the wrong fixes. We break it down using real user monitoring, which exposes navigation timing for each visit, and server-side timing headers.

• Redirects: each redirect before the final URL adds a full round trip. Chains from HTTP to HTTPS to www to a trailing slash are more common than they should be.
• DNS, connection and TLS: setting up the connection, which depends on network distance and protocol support.
• Waiting for the server: the time the origin or CDN takes to produce the response, including application code and database work.

We add a Server-Timing header to responses that reports how long the application spent in key phases, such as database queries, cache lookups and template rendering. Browsers expose that header to RUM scripts and DevTools, so we can see server-side breakdowns for real traffic without guessing.

Server-Timing: db;dur=182, cache;desc="miss";dur=3, render;dur=64, app;dur=271

Fix the network path first

Network fixes are often the cheapest.

1. Remove redirect chains so every internal link, sitemap entry and canonical tag points at the final URL.
2. Serve through a CDN with points of presence near your users, so connection setup happens close to them even when the HTML itself is not cached.
3. Enable HTTP/2 or HTTP/3 and TLS 1.3, which reduce the number of round trips needed before data flows.
4. Keep origin connections warm between the CDN and the origin, so the CDN does not negotiate a new TLS connection for each request.

For a client with a single origin in the US and a large audience in Europe and Asia, these changes alone reduced median TTFB for international visitors by around 300 milliseconds before any application work began.

Then fix the application and database

When the server wait dominates, the cause is almost always one of a few things.

• Slow or repeated database queries. We profile queries per request, look for N+1 patterns where a list page runs one query per item, and add indexes or rewrite queries where they help. Slow query logs over a full day of traffic catch the queries that only appear on certain pages.
• Missing application caching. Expensive computations, such as navigation menus, price calculations or aggregated counts, can often be cached for minutes in Redis or Memcached rather than recalculated on every request.
• Synchronous external calls. Calls to third-party APIs during page rendering, for reviews, inventory or recommendations, add their latency to every request. We move them to background jobs, cache their results or load them on the client after render.
• Cold starts and under-provisioned workers. Serverless functions that start cold and application servers with too few workers queue requests under load, turning average response times into long tails.

Average TTFB hides the problem. Look at the 75th and 95th percentiles, where the queueing and the cache misses live.

On a recent Laravel platform, profiling showed that a category page ran more than 200 queries, most of them to load related records one at a time. Eager loading and a short-lived cache for the category tree reduced that to a dozen queries, and the 75th percentile server time for the template fell from about 900 milliseconds to 160.

Cache the whole response where you can

The fastest server response is one the server never has to produce. Once the application is efficient, we look at caching full responses: at the edge for anonymous pages, and in a reverse proxy in front of the application for pages that vary by a small number of factors. Stale-while-revalidate headers let the cache serve a slightly stale page while refreshing it in the background, so users almost never wait on the origin.

Caching does not replace the application work. Cache misses still happen, after purges, for new pages and for long-tail URLs, and crawlers hit many of those. A fast application keeps those misses tolerable, and a high hit rate makes them rare.

Right-size the hosting

Finally, the infrastructure. We compare resource usage against traffic patterns to see whether the database is under-provisioned, whether application servers run out of workers at peak, and whether the origin is in the right region for the audience. Sometimes the answer is a larger database instance or a read replica. Sometimes it is autoscaling configured to react before queues build. Occasionally it is a smaller, cheaper setup, because caching has removed most of the load.

We keep TTFB on the monitoring dashboard alongside Core Web Vitals, segmented by template, country and cache status, with alerts on the 75th percentile. That makes regressions visible within hours, usually traced to a deployment or a new query.

Server response work spans several of our services. Database scaling covers query and infrastructure changes, CDN configuration handles the network path and edge caching, and managed cloud hosting keeps the platform sized correctly as traffic grows.

Find out where your first byte goes

If your pages are slow before they even start rendering, we can trace the delay and fix it at the source. Get in touch for a fixed-price quote within 24 hours.