Recommended Free Tools
TTFB (Time to First Byte) is the elapsed time from the start of a navigation until the browser begins receiving the first byte of the response. It is an excellent diagnostic clue for a slow request, but it is not a complete page-speed score or a Core Web Vitals metric. Measure it in both controlled lab tests and real-user data, identify which request phase is slow, then optimize that phase while checking the user-facing results, especially FCP and LCP.
What TTFB measures
For a document navigation, TTFB ends at the browser’s responseStart timestamp. The interval can contain several phases:
- Redirects before the final URL
- Service-worker startup or request handling
- DNS lookup
- TCP connection and TLS negotiation
- Time spent waiting after the request reaches the server
- The beginning of response delivery
Consequently, a high TTFB does not by itself prove that application code or a database is slow. It may reflect distance, a new connection, a redirect, cache state, or work performed before the response starts.
How to interpret a TTFB number
web.dev’s guide, originally published in 2021 and updated on November 18, 2025, gives rough guidance of 0.8 seconds or less for good TTFB and above 1.8 seconds for poor TTFB. The range between those values needs improvement. These are guidance thresholds, not pass/fail requirements.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitches#1 Best Overall
TTFB is not a Core Web Vitals metric. As the web.dev guide explains, a site does not have to meet the “good” TTFB threshold if its response still allows it to perform well on the metrics that matter. Judge TTFB with First Contentful Paint (FCP) and Largest Contentful Paint (LCP), and consider how the page renders:
- A server-rendered page may provide useful markup quickly even when its TTFB is somewhat higher.
- A client-rendered application may depend more heavily on early HTML because JavaScript must run before the initial content becomes meaningful.
When reporting real-user performance, use a percentile such as the 75th percentile and state the population, geography, device mix, and date. Do not present the web.dev 75th-percentile framing as a measured TTFB statistic.
Measure TTFB in the browser
Measure the main navigation with the Navigation Timing API
The navigation performance entry exposes responseStart. This example observes the navigation entry after it is available:
const observer = new PerformanceObserver((list) => {
const navigation = list.getEntriesByType('navigation')[0];
if (navigation) {
console.log('TTFB (ms):', navigation.responseStart);
}
});
observer.observe({ type: 'navigation', buffered: true });For production field data, the web-vitals JavaScript library also provides an onTTFB callback. Record the page, release, user geography, connection information, and the percentile you are evaluating so later comparisons use the same population.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Measure individual resources with Resource Timing
Resource Timing entries can show responseStart for scripts, stylesheets, images, and other requests. A value of zero can mean the resource came from cache or that timing information is unavailable. Cross-origin resources require the response to expose timing data with the Timing-Allow-Origin header; without it, the browser cannot provide accurate cross-origin timing details.
CrUX and similar field datasets may report only the main navigation request, so they do not replace resource-level investigation.
Rank #3
Lab measurements versus field measurements
| Context | Useful tools | What it tells you |
|---|---|---|
| Lab | Chrome DevTools Network panel; WebPageTest | Repeatable tests under controlled URL, location, device, connection, redirect, and cache conditions. |
| Field | Chrome User Experience Report (CrUX); the web-vitals library |
What real users experience across changing networks, geographies, devices, redirects, and cache states. |
Keep the request type (navigation or subresource), URL, test location, device profile, redirect path, and cache state constant when comparing lab runs. A warm edge-cache hit and an origin request are different experiments. If lab and field values disagree, investigate those conditions instead of treating either value as universally representative.
Find the slow phase before changing infrastructure
Check redirects and connection setup
List every redirect in the navigation chain and remove redirects you control, particularly unnecessary HTTP-to-HTTPS, host, or trailing-slash hops. In field data, inspect whether users are far from the serving region and whether connection and TLS setup dominate the interval.
Check service workers and cache status
Determine whether a service worker delays handling and whether the request was served by a browser, CDN edge, or origin. During diagnosis, compare a normal cache hit with an intentional cache bypass so an excellent edge TTFB does not hide a slow origin.
Expose backend timing
The web.dev optimization guide (originally published in 2023 and updated November 28, 2025) recommends adding a Server-Timing response header for selected operations, such as database queries, template rendering, or upstream calls. Browsers can surface these entries through timing APIs and Chrome DevTools. When adding this instrumentation is impractical, application performance monitoring (APM) can provide backend traces; choose tooling that supports your application stack and the timing detail you need.
Ways to improve TTFB
Remove avoidable redirects
Each redirect is another request that must complete before the final response begins. Point links, canonical URLs, and rewrites directly at the final destination wherever possible.
Cache responses at the edge
CDN edge caching can serve repeat requests near users instead of contacting the origin every time. For frequently changing pages, even a short freshness lifetime can reduce origin work for subsequent visitors. Set cache keys and invalidation rules carefully, and measure both cache-hit TTFB and origin TTFB.
Free tools Windows power users keep installed
One-click scans. No signup required.
Reduce origin work
Use the phase timings from Server-Timing or APM to target slow database operations, upstream calls, template generation, queue waits, or cold starts. Infrastructure changes are most useful when they address the measured bottleneck rather than TTFB in the abstract.
Stream markup as it becomes available
Response streaming lets the browser parse and process chunks before the complete document is generated. Remove unnecessary buffering and investigate backend work that blocks the first chunk. Streaming helps only when the early markup is useful to the rendering strategy.
Use 103 Early Hints selectively
HTTP 103 Early Hints can tell supporting browsers to fetch render-critical resources while the server continues expensive backend work. They tend to help less on static pages with little preparation. Early Hints can also make an apparent TTFB look fast while the origin remains slow, so track actual server time with Server-Timing or the browser’s finalResponseHeadersStart where available.
A practical TTFB troubleshooting checklist
- Record navigation TTFB, FCP, and LCP for the same page and user segment.
- Capture the redirect chain, DNS, connection, TLS, request, and response phases.
- Repeat the test from representative geographies with both warm-cache and origin/cache-bypass conditions.
- Inspect service-worker behavior and edge-cache status.
- Add targeted
Server-Timingentries or use APM to isolate backend work. - Apply the fix that matches the slow phase, then rerun identical lab tests and compare field percentiles after deployment.
A lower TTFB is not automatically a faster experience. The improvement matters when it lets the browser paint useful content sooner or reduces the work needed before FCP and LCP.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
