페이지 로드의 구조

A page load runs a fixed sequence: DNS, TCP/TLS handshake, request, response, parse, render, interactivity. Each step adds latency — and shows you where to optimize.

First the browser resolves a hostname to an IP via DNS. A cold lookup can cost 20-120ms; caching and dns-prefetch cut it down.

Next come the TCP and TLS handshakes — round trips that hurt on high-latency networks. preconnect warms the connection in advance.

TTFB measures the wait until the response's first byte arrives. It captures network latency plus server time, and delays everything after it.

As bytes arrive, the browser parses HTML into the DOM tree. It also finds linked CSS and JS, which can pause parsing (render-blocking).

The browser merges the DOM with the CSSOM into a render tree, then runs layout (geometry) and paint (pixels) to put content on screen.

First Contentful Paint (FCP) is the first moment the user sees any text or image — the earliest real signal the page is loading.

Scripts must be parsed, compiled, and run on the main thread. Heavy JavaScript blocks rendering and input, dragging down interactivity.

The page is truly usable only when the main thread is free for clicks. Time to Interactive and Total Blocking Time capture this final stage.

DevTools' Performance panel and the PerformanceNavigationTiming API expose every phase — DNS, connection, TTFB, paint — for precise measurement.

Optimize by layer: prefetch and CDN for network, caching to cut TTFB, fewer render-blocking assets, and smaller, deferred JavaScript.

Which metric measures the delay until the first byte of the server response arrives?

You traced a load from DNS through connection, TTFB, parsing, render tree, FCP, JS, and interactivity. Each phase shows where to reclaim seconds.