Measure the actual entry journey, separate its phases and compare consistent cache and access conditions before changing the origin or purchasing capacity.
A slow first response does not automatically mean the application server is slow. TTFB can include redirects, connection setup and waiting for the response. Follow the actual entry journey, then use timing evidence to identify which phase deserves attention. Image compression cannot remove a delay that occurs before the document begins arriving.
Consider a fictional workshop site reached through an old newsletter URL. The reader follows a redirect to HTTPS, another to the preferred hostname and another to the current path. A developer testing only the final address sees a faster result. Neither observation is necessarily wrong; they measure different journeys.
Define what the reported number includes
web.dev’s TTFB explanation describes elapsed navigation time until the first response bytes, including redirects, service-worker startup where applicable, DNS, connection and TLS setup, and request waiting. TTFB is not itself a Core Web Vital, although it affects when later page work can begin.
Record the tool, metric definition, initial URL and final URL. A label such as server response time may measure only part of the navigation. Avoid comparing two tools’ numbers as if they necessarily start and stop at the same events.
For the workshop, keep one observation beginning at the newsletter URL and another beginning at the final page. That comparison can identify avoidable entry overhead without falsely claiming the origin generated HTML faster.
Preserve the conditions of each observation
Record login state, location, network, browser, cache condition and navigation type. A repeat load can reuse connections or cached content. An authenticated page may legitimately bypass a public page cache. These are different workloads.
MDN’s navigation-timing reference describes the current document’s navigation entry and properties including navigation type. It inherits resource-timing properties. Inspect the browser’s actual timeline and supported fields rather than assuming every duration is available or represents new network work.
Repeat a small set of equivalent observations and retain variation. One fast result after a slow first request does not establish a durable improvement. Likewise, a deliberately cold test should not be presented as the normal experience of every visitor.
| Phase or comparison | Question | Potential owner |
|---|---|---|
| Initial URL versus final URL | How much entry redirection occurs? | Link publisher and routing configuration |
| DNS and connection setup | Is connection establishment dominant? | Network path and delivery architecture |
| Request waiting | Which server-side work or dependency delays response? | Application and hosting maintainers |
| First bytes versus meaningful page | Does substantial delay remain after response starts? | Streaming, resource delivery and rendering |
Follow redirects from the actual entry point
Inspect the chain and its reasons. A necessary HTTPS upgrade and an avoidable obsolete-path detour deserve different decisions. When authorized, updating the source newsletter or internal link to the intended secure destination may remove future detours without changing old-link compatibility.
Do not delete useful redirects indiscriminately to improve a number. Existing bookmarks and external references may need them. Review whether the same intended destination can be reached through fewer deliberate steps while preserving correct old URLs.
For the fictional site, comparing the old newsletter link with a current direct link produces a concrete routing question. It does not yet establish whether DNS, the origin or a database query is slow.
Break down connection setup before blaming page code
Look at the browser’s DNS, connection and TLS phases. A distant or unstable network path can affect a visitor even when the application’s processing time is modest. Reused connections can make a later request look very different.
Compare relevant audience conditions where you have authorized evidence. Do not claim that one test location represents all readers or that adding a CDN universally fixes an authenticated dynamic workload. Identify what can be cached and which request still reaches the origin.
The WordPress performance triage guide covers broader resource and application questions. This investigation should first establish whether the delay is in setup, response preparation or later work.
Use backend timings with a defined scope
MDN documents Server-Timing for named response metrics, including backend durations visible through browser tools. It also warns that metrics can expose sensitive infrastructure information. Use reviewed instrumentation and safe names, with appropriate visibility.
A database duration, template-render duration and remote-API duration can help locate work. They do not automatically add up to the complete browser TTFB: some work can overlap or be uninstrumented, and network setup sits elsewhere.
For the workshop, if request waiting is high but the recorded database stage is small, do not add an index merely because the page uses a database. Inspect the remaining application boundary. The query diagnosis workflow applies when evidence actually implicates that workload.
Check what first bytes mean for this platform
Early Hints or an early partial response can make responseStart occur before the final document response or useful content. web.dev explicitly discusses this distinction. Where supported, finalResponseHeadersStart can help distinguish the final response boundary, but tool support and interpretation need checking.
Do not improve a reported TTFB by sending an early empty shell while leaving the reader waiting just as long. Record when meaningful content becomes available as a separate observation. A low first-byte number is useful evidence, not a complete statement that the page is fast.
If a repeat navigation uses a cached response or conditional validation, keep that exchange visible. The 304 guide explains why a reused representation and its validation need to be understood together.
Keep the affected percentile or observation range explicit when using audience data. A median can hide a slow group of readers, while one worst case can exaggerate ordinary performance. Describe the sample and conditions the existing measurement supports, and avoid turning a limited lab run into a claim about every visitor.
Choose one explained correction and repeat the same journey
- Retain the original entry URL and timing conditions.
- Identify the dominant phase and its responsible component.
- State the proposed correction and the result it should change.
- Rehearse on an authorized environment where possible.
- Compare equivalent cold and warm conditions separately.
- Check correct content, access behaviour and later page usability.
Accept a timing improvement only within the conditions actually observed. Your next step is a phase-level evidence sheet: original entry, redirect chain, setup, request waiting and meaningful-content boundary. That supports a targeted repair instead of a hosting purchase based on one undifferentiated number.
Sources and verification
Editorial review 2026-10-17. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- web.dev: Time to First ByteChecked TTFB includes navigation redirects, connection setup and request waiting; Early Hints affect the meaning of first bytes; TTFB is not itself a Core Web Vital.
Limits: Tool definitions and interim-versus-final response timing need checking; a rough threshold is not a provider guarantee. - MDN: PerformanceNavigationTimingChecked Current-document navigation entry, navigation type and timing properties inherited from resource timing.
Limits: Visibility, caching and supported fields limit what an individual timing entry reveals. - MDN: Server-TimingChecked Response metrics can expose named backend durations through browser tools, with privacy and cross-origin access considerations.
Limits: Only instrumented work is represented; timings do not automatically sum to complete navigation latency.