Skip to content

Basics

How to improve time to first byte

Everything else — rendering, fonts, images — queues behind it. Above roughly 1.8 seconds the page fails Core Web Vitals on server response alone, before any of your own code runs. It is usually the cheapest part of load time to improve.

What 13x checks

This is rule basics.ttfb in the public registry: Time to first byte. It runs on every audit, against the pages we actually fetched, and its result is derived from the response rather than estimated.

Surface
Basics
Score weight
5 of the readiness score
Scope
Runs on every audited page
Applies
To every site

Registry version 2026-07-30. Every rule is published, and the audit is deterministic — the same page produces the same finding every time.

The fix

The same text the audit hands you when this check fails on your own site.

Time to first byte was ms. Reduce it in this order, cheapest first:

1. Cache the response. A static or incrementally-regenerated page served from a CDN edge answers in tens of milliseconds. Most marketing pages need no per-request rendering at all. 2. Move the server closer to your users, or to the same region as your database. A cross-region database round trip is the most common cause of a slow first byte. 3. Check for a blocking query in the request path — an uncached API call or an unindexed query in your layout blocks the entire response.

Measured once from one location, so treat it as a signal rather than a benchmark.

Does your site have this problem?

13x checks this and 112 others against your live URL in about 30 seconds. No account, and every finding comes with the fix for your framework.

No signup. Results in 30 seconds.

More basics checks