Static vs. dynamic

By Noah Veltman

Confused about what people mean when they talk about "static" websites vs. "dynamic" websites? Let's try this:

A static website is a vending machine.

A dynamic website is a restaurant.

1. How you get your food (the pageview)

When you look at a URL, like, you are sending a request out into the ether:

"Hey,, send me back the content located at /meals/dinner.html"

Somewhere there is an actual computer that takes in that request and sends back some content (or an error message, if there's a problem with the request). This is what people talk about when they talk about web servers: computers that wait for requests and then serve you what you ask for.

A server might be a plain old computer like the one on your desk, or it might be a rented computer in a giant data center that looks like something from WarGames. It doesn't really matter.

2. The vending machine (static sites)

When people talk about a static server, they are talking about a server set up like a vending machine. When you ask for a URL, like, there is an actual file already on that computer called cheetos.html, and all it has to do is send you a copy of that file. Talking about "flat files" refers to the same thing: having actual files that match the URLs people might request.

You punch E6, you get the Cheetos that are already in the machine, packaged, ready to eat.

Like a vending machine, a static server can be:

3. The restaurant (dynamic sites)

When people talk about a dynamic server, they are talking about a server set up like a restaurant. The food is made-to-order. The kitchen has ingredients, and the cooks assemble those ingredients into the finished product only AFTER someone orders that dish.

In this version, if you ask for a URL, like, crabcakes.html doesn't exist yet. There is no such file. It's just a menu item. The server waits for your request, and when the request comes in, it uses ingredients (e.g. templates, a database, the Twitter API) and a "recipe" to create that page on the spot, just for you.

When people talk about the "back end" or "server side," they are talking about the kitchen: the stuff that a server does when it gets a new request.

Like a restaurant, a dynamic server can be:

4. Prep cooks (a little bit of both)

In the real world, most servers mix these two approaches. A restaurant doesn't wait until you order your fries to buy the potatoes. They have prep cooks organizing, chopping, and staging ingredients ahead of time to minimize how much of the process is dynamic.

When you load an image from a dynamic server, it probably isn't drawing that image for you, farm-to-table, pixel-by-pixel. That image is probably just an actual file that already sits on the server.

Part of managing dynamic servers is about having a good mise en place: figuring out what needs to be prepared at the last minute, and getting the rest ready ahead of time.

Some caveats

Like all analogies, this one is limited. I don't mean to suggest, for example, that content from a static server is stale and low-quality, or that dynamic servers are extravagant things.

There is also the question of caching, which doesn't have a great food prep analog. Dynamic servers can use various kinds of caching to serve pre-cooked content but update it dynamically.

There are not many absolutes. Most things that are easier on dynamic servers, like personalization and updating content in a central place, are possible on a static server. It just tends to be trickier. You have to figure out workarounds to make things seem dynamic, and have systems in place to regenerate your files in bulk when you need to make updates. Similarly, while dynamic servers tend to be more complex and easier to break, it doesn't mean they necessarily are. You can create extremely fast and robust dynamic servers that will stand up to any amount of traffic. It just tends to be trickier. You have to have the sysadmin savvy to use the right tools and employ the right strategies.