What Is Prerendering?

Prerendering means generating a page's HTML before anyone requests it, usually when the site is built, and serving it ready-made. When the first visit arrives the work is done, and nothing remains to be executed in order to see the content.

It is a direct answer to the problem JavaScript SEO raises: if everything important appears only after the code runs, any reader who does not run it — or runs it later — sees an incomplete page.

The word is used with two different scopes, and they deserve keeping apart. In SEO it usually means static generation of every page of a CMS; in the browser there is also a feature that preloads and prerenders the likely next link. Same name, different purpose.

It is worth saying what does NOT change. Prerendering touches neither content nor internal linking: the same page, the same text, the same links. The only thing that changes is the moment that HTML exists — and that alone is enough to make the conversation with a search engine a different one.

Nor is it a new or particularly sophisticated technique. Before sites were built in the browser, every page was a file written in advance; what we call prerendering is largely a return to that, with tools that generate those files from templates and data.

Every way of building a site differs on a single question: at what moment the HTML exists. When the site is built, on every request, in the visitor's browser — or differently depending on who asks.

The first three are legitimate decisions with different costs. The fourth deserves a note, because it was recommended for years and is not any more: Google describes it as a workaround and not a long-term solution, recommending server-side rendering, static rendering or hydration instead.

Nor should it be read as a ladder from worse to better. A blog that changes weekly and an e-commerce with live stock do not have the same right answer; what you choose is where the work gets paid for, not how much quality you want.

A fifth form does not fit the list because it combines two: generate in advance and refresh in batches when something changes. It is today's most widespread middle ground, because it keeps instant delivery without condemning the content to freeze.

And it is worth noting who decides in each case. In the first three the team building the site decides; in the fourth the server decides at the moment, by looking at who is asking. That difference is the underlying reason the last one ages badly: any change in how a crawler is recognised can break it without anyone touching the code.

What it gains is predictability. The page arrives complete for everyone, the crawler sees it whole in the first phase, and TTFB is usually the best available, because nothing has to be computed at request time.

What it costs is freshness. HTML generated yesterday keeps saying what was true yesterday until it is generated again — and that collides head-on with a catalog whose prices and availability change through the day while the index keeps the old version.

And one cost arrives with size: build time. Generating a hundred thousand pages on every publish stops being free, and past a certain point it forces you to generate only what changed, which is an architecture decision rather than a setting.

A less obvious and quite valuable gain is robustness. A page already generated keeps being served even if the database fails, which would otherwise give a 500 error, because at that moment it is no more than a file. For critical sections — prices, contact, legal notices — that is worth more than a few tenths of a second.

And a cost at the other end: debugging. When something goes wrong, the error happened at build time, hours earlier and on another machine, not on the visit that revealed it. The useful records there are not the server's but the build run's — something worth having sorted before you need it, as with log file analysis.

It clearly makes sense when content changes less often than visits arrive: articles, service pages, documentation, glossaries — everything a crawl finds unchanged a week later. There, generating once and serving a thousand times is simply the right arithmetic.

It stops making sense as soon as every visitor must see something different — their basket, their session, their prices — because that cannot be shared. The usual way out is mixed: the stable part prerendered and the personal part loaded separately, which also avoids the problem of caching in a CDN what should not be cached.

And there is a very common middle case: content that changes daily but not by the minute. There it is enough to regenerate in batches or on detected change — and it pays to check in log file analysis how often the crawler actually returns before settling on a rhythm.

A practical sign for deciding: look at how many of your URLs show exactly the same thing to anyone who arrives. If most do — and on most sites they do — generating in advance is the obvious choice for that part, even if the rest needs something else.

And a caution about size: as the catalog grows, build time grows with it, and eventually publishing a minor change forces regenerating everything. Before reaching that point you want to be able to generate only what is affected, especially where pagination multiplies the URLs; setting it up from the start is easier than rebuilding it once the e-commerce already has a hundred thousand product pages.

The first is prerendering only for search engines. That is exactly the dynamic rendering Google advises against, and it also forces you to maintain two versions that end up diverging unnoticed.

The second is forgetting regeneration. A page generated once and never again freezes: old prices, expired notices, links to sections that no longer exist and end in 404 errors.

And the third is assuming this settles the performance problems. The HTML arrives sooner, but if three megabytes of code load afterwards, INP and the feeling of slowness stay exactly where they were.

A fourth mistake, typical of migrations: prerender and forget the headers. The HTML arrives perfectly, but the instructions travelling in the response — among them the X-Robots-Tag — depend on HOW the files are served, not on how they were generated. They are easily lost unnoticed when changing servers.

And the last: believing generated HTML is good simply because it was generated. A generator faithfully reproduces whatever it is told, including a misplaced canonical or a title repeated across a thousand pages, that is duplicate content. Prerendering speeds up delivery of what is there; it does not correct it.