Browser Performance Timing

How to Use the Browser Performance Timing Tool

1. Load the page — timing data is captured automatically when the page loads. Switch between the three tabs to explore different views.
2. Navigation tab — shows the full page load waterfall: DNS, TCP, TLS, request, response, DOM parsing, and page interactive times.
3. Resources tab — lists every resource (scripts, stylesheets, images, fonts, fetch requests) with size and load time. Use the type filter to focus on specific resource types.
4. Core Web Vitals tab — displays LCP, CLS, and INP as they are observed by PerformanceObserver, the same API used by Google's CrUX data collection.
5. Refresh — click "Refresh Data" to re-read the current performance buffer if you've navigated or loaded additional resources.
6. Copy JSON — exports the raw timing data as JSON for use in CI pipelines, spreadsheets, or bug reports.

Understanding Browser Navigation Timing

The Navigation Timing API (part of the W3C Performance API) exposes a detailed breakdown of every phase your browser goes through when loading a page. This data is available via performance.getEntriesByType("navigation") and is the same data collected by Lighthouse, WebPageTest, and Chrome DevTools.

Navigation Timing Phases Explained

• DNS Lookup — time to resolve the domain name to an IP address using DNS. Cached lookups return in under 1ms; fresh lookups typically take 10–120ms depending on your DNS resolver and geographic distance to the resolver.
• TCP Connect — time to establish a TCP connection to the server (three-way handshake). For connections over long distances, TCP latency adds at least one round trip (RTT).
• TLS Handshake — time to negotiate TLS encryption. Modern TLS 1.3 requires only one round trip; older TLS 1.2 requires two. Expect 20–100ms for TLS on most connections.
• TTFB (Time to First Byte) — measures from the end of the request until the first byte of the response arrives. This includes your server's processing time and is one of the most important metrics for perceived load speed. Google considers TTFB under 800ms as good.
• Content Download — time for the browser to download the full HTML response body. Slow values here usually indicate a large HTML document or a slow network connection.
• DOM Processing — time from HTML download completing until the DOM is fully parsed and all deferred scripts have run. Large DOMs, synchronous scripts, and heavy CSS slow this phase.
• DOM Interactive — the point at which the document's DOM is ready and scripts can access it safely. This is when the DOMContentLoaded event fires.
• Load Complete — the window load event, after all synchronous images, stylesheets, and scripts have loaded.

Resource Timing

The Resource Timing API records the same phase breakdown for every sub-resource the browser fetches: JavaScript files, CSS stylesheets, images, web fonts, fetch() calls, and XMLHttpRequests. The resource timing buffer holds up to 250 entries by default; you can expand it with performance.setResourceTimingBufferSize().

Key metrics in the resource waterfall:

• Transfer size vs. decoded size — a large decoded size but small transfer size indicates effective compression (gzip/Brotli). No compression means transfer size equals decoded size.
• Duration — total time from initiating the request to downloading the last byte. This is the column to sort by when hunting for slow resources.
• Stacked same-origin requests — HTTP/1.1 allows only 6 concurrent connections per origin; HTTP/2 multiplexes requests, so you'll see true parallelism in the waterfall.

Core Web Vitals

Google's Core Web Vitals are three user-centric metrics that measure real-world page experience. Unlike synthetic metrics from Lighthouse, Core Web Vitals reflect actual browser behavior during your current session:

• LCP (Largest Contentful Paint) — measures loading performance. The LCP element is usually the hero image or the largest text block visible above the fold. Aim for under 2.5 seconds. Common causes of poor LCP: slow server response (TTFB), render-blocking resources, slow image loading.
• CLS (Cumulative Layout Shift) — measures visual stability. Each time a visible element moves unexpectedly (e.g., a banner loads and pushes content down), CLS increases. Aim for under 0.1. Reserve space for images and ads with explicit width/height attributes.
• INP (Interaction to Next Paint) — measures interactivity. It records the worst interaction delay observed during the session. Aim for under 200ms. Heavy JavaScript execution and long tasks on the main thread are the primary culprits.

How to Improve Performance

Once you've identified slow phases in the waterfall, here are targeted fixes:

• Slow DNS: Add DNS prefetch hints (<link rel="dns-prefetch" href="//example.com">) or switch to a faster DNS resolver like Cloudflare (1.1.1.1) or Google (8.8.8.8).
• Slow TLS: Upgrade to TLS 1.3, enable OCSP stapling, and use ECDHE key exchange to minimize handshake round trips.
• High TTFB: Add server-side caching (Redis, Varnish), use a CDN, or optimize database queries.
• Slow DOM: Defer non-critical JavaScript (defer / async attributes), reduce DOM node count, and split large synchronous scripts.
• Large resources: Compress images (WebP/AVIF), enable gzip/Brotli on your server, and code-split JavaScript bundles.