Reduce Initial Server Response Time

Everything else on this list is about what happens after the browser has the HTML document. This audit is about how long it takes to get that document in the first place: Time to First Byte (TTFB), the gap between the request being sent and the first byte of the response arriving.

What it means

Lighthouse flags this audit when the main document's TTFB is roughly 600ms or higher. That number covers DNS lookup, connection setup, server-side processing (database queries, template rendering, any backend logic), and the network round trip. All of it happens before the browser has a single byte to parse.

Why it matters

TTFB is the floor under every other metric on the page: nothing else can start, not CSS, not JavaScript, not the LCP image, until the HTML document itself starts arriving. A slow TTFB doesn't just cost its own time; it pushes back FCP and LCP by the same amount, and it compounds with every other issue on this list rather than replacing them. TTFB is also, on its own, one of the underlying field metrics that CrUX collects, so it directly affects real-user data too.

How to fix it

• Cache what doesn't need to be generated fresh on every request. Full-page caching for anonymous visitors, object/fragment caching for expensive database queries, and a reverse proxy (Varnish, Nginx cache, or your host's built-in page cache) can turn a 700ms dynamic response into a 40ms cached one. This is a different layer from an efficient cache policy for static assets, which speeds up repeat visits rather than the dynamic response itself.
• Put a CDN in front of the origin. Even for dynamic content, a CDN edge node closer to the visitor cuts the network portion of TTFB; for cacheable content it can serve the response without touching the origin server at all.
• Optimize the slow part of the backend directly. Profile the request (most frameworks have a built-in profiler or debug bar) to find out whether the time is going into database queries, external API calls, or template rendering, and fix that specific bottleneck rather than guessing.
• Enable opcode caching on PHP. A production PHP server without OPcache re-compiles every script on every request:

; php.ini
opcache.enable=1
opcache.validate_timestamps=0 ; on production, with a deploy step that clears the cache

• Cut unnecessary redirect chains. Each redirect before the final document adds a full round trip to the effective TTFB the browser experiences.

How to verify

Re-run the test and check the TTFB figure directly in the report's timing breakdown. For field confirmation, TTFB is also tracked by Chrome UX Report, so a real improvement should show up there over the following weeks, not just in the lab test.