Learn Frontend Part 1: How the Web Works - DNS, HTTP, HTTPS, Caching and APIs

Before writing HTML, CSS or React, it helps to understand what actually happens between typing a URL and seeing a page. This knowledge explains why pages are slow, why caching matters, why HTTPS exists and how the frontend talks to the backend. It is also one of the most common opening questions in frontend interviews: "What happens when you type a URL into the browser and press Enter?"

This is Part 1 of the Learn Frontend series. We walk through DNS, TCP and TLS, HTTP requests and responses, status codes, caching, cookies and browser storage, and how a frontend calls APIs.

1. What happens when you type a URL and press Enter

1. URL parsing: the browser splits https://example.com/products?id=7 into the scheme (https), host (example.com), path (/products) and query (?id=7).
2. DNS lookup: the host name is translated into an IP address, checking the browser cache, the OS cache and then DNS servers.
3. Connection: the browser opens a TCP connection to that IP (or QUIC for HTTP/3) and performs a TLS handshake to set up encryption for HTTPS.
4. HTTP request: the browser sends a request such as GET /products?id=7 with headers (cookies, accepted formats, caching info).
5. Server response: the server (or a CDN close to the user) returns a status code, headers and the HTML body.
6. Parsing and sub-resources: the browser parses HTML into the DOM and discovers CSS, JavaScript, images and fonts, requesting each one.
7. Rendering: the browser builds the CSSOM, combines it with the DOM, calculates layout, paints pixels and composites layers onto the screen (covered in depth in Part 9).
8. JavaScript and interactivity: scripts run, attach event listeners and may fetch more data from APIs.

2. DNS: turning names into addresses

Computers connect using IP addresses, but people remember names. The Domain Name System is a distributed directory that maps names to addresses. A lookup checks caches first (browser, operating system, router) and then asks a recursive resolver, which walks from the root servers to the .com servers to the domain's own name servers.

Each record has a TTL (time to live) saying how long it may be cached. Frontend performance tip: <link rel="dns-prefetch"> and <link rel="preconnect"> start DNS lookups and connections to third-party origins early.

3. HTTP requests, responses and status codes

HTTP is a request-response protocol. Every request has a method, a path, headers and sometimes a body; every response has a status code, headers and usually a body.

GET /api/products/7 HTTP/1.1
Host: shop.example.com
Accept: application/json
Cookie: session=abc123

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "v42"

{"id": 7, "name": "Keyboard", "price": 2499}

HTTP/1.1 sends one request at a time per connection, so browsers open several connections. HTTP/2 multiplexes many requests over one connection and compresses headers. HTTP/3 runs over QUIC (UDP), avoiding head-of-line blocking when packets are lost.

4. HTTPS and TLS

HTTPS is HTTP inside an encrypted TLS connection. During the TLS handshake the server presents a certificate signed by a trusted certificate authority, proving it owns the domain; the two sides then agree on session keys. TLS gives:

• Confidentiality: nobody on the network can read passwords or cookies.
• Integrity: nobody can modify the page in transit, for example to inject ads or scripts.
• Authentication: you are really talking to the domain in the address bar.

Modern browser features such as service workers, geolocation and HTTP/2 in practice require HTTPS, and browsers mark plain HTTP pages as "Not secure".

5. Caching, cookies and browser storage

HTTP caching avoids downloading the same files again. The server controls it with headers:

• Cache-Control: max-age=31536000, immutable for versioned files like app.3f9a.js: cache for a year.
• Cache-Control: no-cache plus an ETag for HTML: the browser revalidates, and the server replies 304 Not Modified if nothing changed.
• A CDN stores copies of files on servers near users, cutting latency.

Store session tokens in HttpOnly, Secure, SameSite cookies rather than localStorage, so injected scripts cannot read them (more in Part 14).

6. How the frontend talks to the backend

The browser loads the frontend (HTML, CSS, JavaScript), and the JavaScript then calls APIs on servers to read and change data, usually exchanging JSON over HTTPS. A REST API maps resources to URLs (/api/users/42) and actions to HTTP methods.

async function loadProduct(id) {
  const res = await fetch('/api/products/' + id, {
    headers: { Accept: 'application/json' },
    credentials: 'include',            // send cookies
  });
  if (!res.ok) {                        // fetch does not throw on 404 or 500
    throw new Error('Request failed with status ' + res.status);
  }
  return res.json();
}

When the API lives on a different origin (scheme, host or port), the browser applies CORS rules: the server must send headers such as Access-Control-Allow-Origin, and some requests trigger a preflight OPTIONS request first. CORS is enforced by browsers to protect users, and it is a frequent source of "it works in Postman but not in the browser" bugs.

Practice problems

Try these hands-on exercises in your browser's DevTools (press F12) to see everything in this article for yourself.

1. Open the Network tab, reload any site and find the HTML document request. Note its status code, size and timing breakdown (DNS, connect, TLS, waiting).
2. Reload again and spot files served from memory or disk cache, and any 304 Not Modified responses.
3. Click a JavaScript or CSS file and read its Cache-Control header. Is it long-lived and versioned?
4. Check the Protocol column (enable it by right-clicking the column headers) to see h2 or h3.
5. In the Application tab, inspect cookies and look for the HttpOnly, Secure and SameSite flags.
6. Run fetch('https://api.github.com/users/octocat').then(r => r.json()).then(console.log) in the console and inspect the response headers.
7. Try fetching a different site's page from the console and read the CORS error message.