Three ways to make a page

The lesson Front and back showed that whatever happens on the servers, the browser always receives HTML, CSS and JavaScript. This lesson asks a narrower question: where and when is the page's HTML made? There are three answers.

The HTML can be made in advance. A program builds every page once, before anyone visits, and the host sends the same files to everyone. A photographer's portfolio or a conference programme often works this way. The HTML can be made by a server at each visit. A program on the server builds the page when someone asks for it, with the latest data. The results page of a classified ads site, or your account page at your energy supplier, work this way. Or the HTML can be made in the visitor's browser. The server sends an almost empty page and a script, and the script builds the screen. Gmail, Google Docs and Trello work this way.

In all three cases the visitor sees a page. What changes is who does the work, and when. That decides how fast the page appears, what search engines can read, how fresh the content is and what the site costs to run. The diagram follows the HTML from where it's made to the screen.

A static site is made in advance. A program, called a static site generator, reads the content (texts, pictures, a list of events) and builds every page of the site in one go. Hugo, Eleventy, Jekyll and Astro are well-known examples. Developers call this step a build. The host then has nothing to do but send files: GitHub Pages, Netlify and Cloudflare Pages do exactly that, often from a CDN, a network of servers in many cities, so each visitor gets the files from somewhere near them.

That's why these pages are the fastest and the cheapest. Nothing runs at each visit, so there's little that can break, and hosting a small site is often free. A thousand visitors or a million receive the same files. Search engines find the whole content in the HTML.

The cost is freshness. A change in the content appears only after the next build. For a small site that takes seconds, and for a site with thousands of pages it can take many minutes. And "static" doesn't mean that nothing moves. Menus, forms and videos still work, and a small script can still fetch a live figure, such as today's weather, when the page opens.

Here, nothing is ready in advance. Each time someone asks for a page, a program on the server reads the data, fills in a template and sends back finished HTML. The visitor, and any search engine, receives a complete page. This is the oldest way of making pages, and still one of the most common: WordPress makes its pages this way, and so do most online shops, newspapers and account areas.

Its strengths come from building each page at the last moment. The page is always up to date: a new listing appears as soon as it's saved. And it can be different for each visitor, with their name, their orders or their messages.

Its costs come from the same place. A server has to run day and night, even when nobody visits. Each visit gives it work, so a busy day needs more power, and the bill grows with the traffic. A common way to reduce the work is a cache: the server keeps a ready copy of a page for a minute and sends it to everyone who asks in that minute. How the server itself works is the subject of the topic Back ends.

In a single-page app, the server sends one almost empty page and a large script. The script asks the server for the data it needs, then builds each screen itself. When you click, it changes the screen directly, without loading a new page. Gmail, Google Docs and Trello work this way, and that's why they feel like applications rather than websites. For a tool that people use for hours, behind a login, it's often the best choice.

The first cost is the first screen. Before anything appears, the browser has to download the script, run it, ask for the data and draw the page. On a recent laptop that's quick. On an ordinary phone with a weak connection, it can take several seconds.

The second cost is for robots that read the HTML. When you paste a link into WhatsApp or LinkedIn, a robot reads the page to show a title and a picture, and it doesn't run scripts: it finds nothing to show. Google runs scripts, but later and not always, and many other search engines and AI assistants don't run them at all. And when the script fails or is blocked, the page stays blank, as the lesson When it breaks showed.

Most sites don't make all their pages the same way. Take a music festival's site. The programme and the artists' pages are made in advance and rebuilt when the programme changes. The "My tickets" page is made by the server, because it's different for each person. The map of the stages is built in the browser, because visitors zoom and tap on it. The diagram shows this site.

Frameworks such as Next.js (built on React), Nuxt (built on Vue) and SvelteKit (built on Svelte) let developers choose the way page by page. They also combine two ways in one page. The server makes the page with its content, so it appears fast and search engines read it. Then the framework's script takes over in the browser, so the page reacts to clicks like an app. Developers call this hydration. Its price is that the browser still downloads and runs the script.

Astro goes further for content sites. It makes pages in advance and, by default, sends them with no JavaScript at all. Only the parts that need to react, such as the festival's map, load a script. Developers call these parts islands. The next lessons of this topic explain what these frameworks are, and who makes them.

None of the three ways is best for every site. The table compares them on five questions.

How fast does the first screen appear? Pages made in advance are fastest, and apps built in the browser are slowest, because the script must arrive and run first. And after the first screen? There the browser app wins: each click changes the screen at once, without waiting for a new page. Can search engines and link previews read the page? Yes for pages made in advance or by a server, since the content is in the HTML. A browser app needs extra work, such as server rendering, to get there. How fresh is the content? Always fresh on a server, fresh after each build for pages made in advance, and fresh in a browser app, since it fetches the data live.

The running cost follows where the work happens. Pages made in advance are files, often hosted for free, whatever the traffic. A server runs all the time, and its cost grows with the visits. A browser app is cheap to host, because the visitor's phone does the work. So the question to start from is: what must this site be good at?

These questions work with an agency, a freelancer, or the plan an AI agent proposes.

Ask where each page is made: in advance, on a server or in the browser, page by page if the site mixes them. "We use React" doesn't answer that question. Ask what search engines and link previews find on each kind of page, and check it yourself: "View page source" shows the HTML that robots receive, and pasting a link into a chat shows whether a title and a picture appear.

Ask how long a change takes to reach visitors: at once, after a build of a few minutes, or the next night. And ask what happens if visits grow a hundred times, for a launch or a big advertising campaign. Pages sent as files from a CDN hardly notice. Pages made by a server at each visit need a cache or more power, and the bill grows with them.