A static site ships pre-made files unchanged, while a dynamic site builds its content on the fly for each visitor.

The split is about when the HTML a visitor sees is produced. With a static site, every page already exists as a finished file sitting on the web server; the server just hands it over byte-for-byte. A personal portfolio or a restaurant's homepage is the classic example. With a dynamic site, a program assembles the page at runtime, so two people can get two different results from the same address.

Dynamic content can be produced in three ways (often combined): on the server (e.g. PHP querying a database), on the client (JavaScript running in the browser), or by calling out to a web service.

Gotcha: the line is blurry. Most real sites are hybrids — static assets like images and CSS served as files, with the surrounding page generated dynamically.

The browser fetches the HTML first, then makes a separate request for each image, stylesheet, and script the HTML points to.

This is the request-response cycle, and the key insight is that one webpage is almost never one download. An HTML document is mostly text plus references: a tag like <img src="hotel.jpg"> does not contain the photo, it only names it. The browser must go back and ask the server for each referenced file on its own.

1. Enter URL -> browser sends an HTTP request for the HTML document.
2. Receive HTML -> server returns the HTML text.
3. Parse references -> browser scans the HTML and finds links to images, CSS, and JS.
4. Additional requests -> browser fires a fresh request for each of those resources.
5. Render -> once the pieces arrive, the browser paints the complete page.

Why it matters: a page with 50 images means roughly 50 extra round-trips. This is exactly why "reduce the number of requests" is a core web-performance rule, and why tools bundle and combine assets.