How the web works

What happens between typing a URL and seeing a page: DNS, HTTP, HTTPS and how the browser turns bytes into pixels.

From URL to page

Also called what happens when you type a URL

What: The browser resolves the domain to an IP address with DNS, opens a connection (TCP or QUIC), negotiates TLS, sends an HTTP request, then parses the HTML response and fetches the CSS, JavaScript and images it references.
Why: Every performance and debugging question maps to one of these steps. Knowing the order tells you whether a slow page is a DNS, network, server or rendering problem.

Watch out

Treating "the page is slow" as one problem instead of checking the Network tab timing breakdown for where the time actually goes.

DNS

Also called Domain Name System

What: The internet's phone book: it turns a name like example.com into an IP address through a chain of resolvers, and caches the answer for the record's TTL (time to live).
Why: Custom domains, deploys to a new host and email all depend on DNS records such as A, AAAA and CNAME. Changes can take until the old TTL expires to reach everyone.

Watch out

Changing a record and assuming it is broken when your own machine is still using a cached answer.

HTTP methods

Also called GET, POST, HTTP verbs

What: The verb of a request: GET reads, POST creates or triggers an action, PUT replaces, PATCH partially updates, DELETE removes. GET, PUT and DELETE are idempotent: repeating them has the same effect as sending once.
Why: Methods tell browsers, caches and servers what is safe to retry or cache. Only GET responses are normally cached, and a form that changes data must never use GET.

HTTP

GET /api/products?page=2 HTTP/1.1
Host: shop.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

HTTP status codes

What: Three digit results of a request: 2xx success (200 OK, 201 Created, 204 No Content), 3xx redirect (301, 304 Not Modified), 4xx client error (400, 401, 403, 404, 429) and 5xx server error (500, 502, 503).
Why: Your UI decides what to show from them: a 401 means sign in again, a 404 means show a not found state, a 5xx means offer a retry.

Watch out

fetch does not reject on 404 or 500: only network failures reject, so you must check response.ok yourself.

HTTPS and TLS

Also called SSL, HTTPS, TLS

What: HTTP over TLS, which encrypts traffic and proves with a certificate that you are talking to the real domain. Browsers require HTTPS for service workers, geolocation, clipboard and most modern APIs.
Why: Without it anyone on the network can read or change pages, cookies and passwords. Hosts and Let's Encrypt make certificates free, so every site should use it.

Watch out

Loading an http:// script or image on an HTTPS page, which browsers block or flag as mixed content.

CORS

Also called Cross-Origin Resource Sharing, same-origin policy

What: Browsers block JavaScript from reading responses from another origin (scheme, host and port) unless that server sends headers such as Access-Control-Allow-Origin allowing it. Some requests first send an OPTIONS preflight.
Why: It explains the classic "blocked by CORS policy" error when your frontend on one port calls an API on another. The fix is always on the server or through a dev proxy.

Watch out

Trying to fix CORS in frontend code or with a browser extension: the API must send the headers, or you proxy the request.

Critical rendering path

Also called browser rendering, reflow, repaint

What: The browser builds the DOM from HTML and the CSSOM from CSS, combines them into a render tree, calculates layout (sizes and positions), paints pixels and composites layers.
Why: CSS and synchronous scripts in the head block the first paint, and changing layout properties forces layout again. It explains why defer scripts and animating transform are faster.

Watch out

Reading offsetHeight and then writing styles in a loop, which forces a layout on every iteration (layout thrashing).

Go deeper