Origin response and TTFB
A white screen in Sydney
Kai hears from players in Australia: a shared garden link shows a white screen for more than a second before anything appears. The page itself arrives late.
Time to First Byte (TTFB) is the time from starting to load a page until the first byte of the server's answer arrives. The origin is the server where our pages actually come from, not a copy kept by a CDN.
What hides inside TTFB
- RedirectsEach redirect (for example http to https) is a whole extra round trip.
- Service worker startupIf the site has one, it must start before it can answer.
- DNS lookupTurning the domain name into a server address.
- Connection and TLSOpening the connection and agreeing on encryption.
- The requestSending the request, the server doing its work, and the first byte travelling back.
Quick check
Which of these happens outside TTFB?
- Downloading the key art image
- The DNS lookup
- The TLS negotiation
Show the answer
Downloading the key art image
TTFB ends when the first byte of the page arrives. Images are fetched afterwards. DNS and TLS happen before the request, so they are inside TTFB.
How fast is fast enough
web.dev gives a rough guide: 0.8 seconds or less is good, and over 1.8 seconds is poor. TTFB is not a Core Web Vital itself, but it is the first of LCP's four parts, so everything else waits for it.
In the browser, the Navigation Timing API gives it as responseStart, and the web-vitals library has onTTFB. In the lab, the DevTools Network panel shows it for each request.
Server-Timing: where the time went
Our server can explain its own wait with a Server-Timing header:
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
Each entry names a step and its duration in milliseconds. DevTools shows them next to the request, and the page can read them from real players through the Navigation Timing API's serverTiming, so the field data can tell us which step is slow.
Read the numbers
1redirect to https 220 ms2DNS + connect 180 ms3Server-Timing:4 db 640 ms5 ssr 90 ms6network + rest 170 ms7---------------------------8TTFB 1300 ms
Remy reads the timings. Which fix saves the most time?
- Speed up the database lookup for a garden
- Shorten the domain name
- Shrink the key art image
Show the answer
Speed up the database lookup for a garden
The database takes 640 of the 1,300 ms, the biggest piece. Removing the redirect by linking straight to https would save another 220 ms. The image isn't part of TTFB at all.
Ways to cut TTFB
- Fewer redirectsLink to the final address: https, and the same trailing slash every time.
- Cache at the edgeA CDN keeps copies on servers near players. Pages that are the same for everyone can be served from there.
- 103 Early HintsWhile the server is still busy, it sends an early hint so the browser can start fetching CSS.
- Static or streamed HTMLBuild pages ahead of time, or send the HTML in chunks as it is ready.
Quick check
Caching each player's personal garden page at the CDN, one copy served to everyone, is a safe way to cut TTFB.
- True
- False
Show the answer
False
A page that is different for every player must not be shared. Edge caching fits pages that are the same for everyone, like the news page or a published level's description.
Who is allowed to keep a copy
Edge caching and browser caching both follow instructions we send with every file.
Bolt says: Next: Cache-Control, the header that tells every cache what it may keep and for how long.
Fact-checked 11 October 2026
- web.dev: Time to First Byte (TTFB) web.dev
- web.dev: Optimize Time to First Byte web.dev