Static and dynamic

A static page is built in advance and served to everyone as the same file. A dynamic page is built by the server at the moment of the request, for one visitor.

Ready or built

When you open a page, it could have got its final form in one of two ways.

A static page is built in advance. It’s a file lying on the server, and the server hands it out as it is, the same to everybody. You have written such pages all through this course: an index.html opened in a browser is static.

A dynamic page is built at the moment of the request. The server receives the request and runs a program. The program looks at who is asking and what for (which user, what they searched, what is in their cart), takes the data from a database and builds HTML out of it. Two visitors who open the same address may see different things.

The difference isn’t whether a page is pretty or has animation (that happens in the browser). It’s when the page gets its final form: in advance, or on request.

What static gives you

• Speed. Handing out a ready file is faster than running code and asking a database. A file can go into a cache (more on that below) and be handed out through a network of servers around the world (a CDN, covered in the part on infrastructure), so it sits close to every visitor.
• Price. Serving files is almost free, and often included in hosting. The load grows, and the bill hardly does.
• Security. There’s no code on the server to hack, no database to steal and no passwords. There’s almost nothing to attack.
• Simplicity. There’s nothing to update, monitor or mend at three in the morning.

What dynamic gives you

• Pages that depend on the person: an account, a cart, “your orders”.
• Fresh data without re-uploading the site: stock levels, exchange rates, timetables.
• Receiving data: inquiries, comments, payments.
• Search and filters over a large catalog.
• Login and roles: who may do what.

You pay for this: in speed (code and a database on every request), in money (a server with room for the peak load), in security (more places to attack: code, a database, passwords) and in attention (updates, backups, monitoring).

Look at the same load handled both ways. As the number of visitors grows, the difference shows:

Cache: how to make dynamic fast

A dynamic page can be made much faster if it isn’t built afresh for every visitor. That’s the job of a cache: a memory where the ready answer waits in case it’s asked for again.

• A page that’s the same for everybody and changes once every few minutes is built once and handed out ready. The Cache-Control header (you met it in the lesson on HTTP) allows both the browser and intermediate servers to keep the answer.
• Database queries that repeat are cached separately, in fast memory.
• Images, styles and scripts are served separately, as static files, through a CDN.
• In the database itself you build indexes: a kind of table of contents, so that the right record is found at once instead of going through them all.

A page that depends on the person (a cart, an account) must not be cached, or only with great care: otherwise one person will see another’s page. It’s one of the nastiest mistakes on the web.

Static goes further than it seems

In recent years an approach called Jamstack has appeared: the site is built in advance into static files (that is the part on site generators, still ahead), and whatever needs a server is plugged in as ready-made services and cloud functions. An inquiry form, for example, is sent to an intermediary service that forwards it to your email: no server of your own, and the site stays static.

The conclusion for your choice is simple: start with static, and add dynamic only where you can’t do without it. Most business-card sites, landing pages and blogs live very well without a server of their own.

Practice

You’re on a site from 2010: the age of content management systems (WordPress, Drupal) had begun, when sites started to be built from a database on every request. Decide which parts of your project really need that.

Fill in the table: for each section of your brief, and for the list of offers, the inquiry form and the visitor login, write “static” or “dynamic” and a reason. Notice that an inquiry form can’t be purely static: somebody has to receive the data. Then answer whether your project needs a database, and what you’ll cache. An honest “not yet” is a good answer too.

What was wrong with 2010

In the 2000s a content management system and a database were treated as the normal thing for any site, even a business card of five pages. Every page view started PHP, which went to the database for the same five paragraphs as yesterday and the day before. Business-card sites opened slowly, fell over when visitors flocked in, and were broken into through holes in the system and its plugins (often found out about only after the break-in).

What stays right is the idea that dynamic is for places where the answer depends on the person and on fresh data. What doesn’t depend on them is better handed out as a ready file.