1. Chapter One: From Content to Page: The Other Half of the Story

In the previous article (The Evolution of the Web (Part 1): From Pages to Content – What Has WordPress Changed?We take "content" in web pages as our starting point and introduce the development process of content from being closely coupled with the page in the early days of static web pages to gradually becoming an independent object.

In the era of static web pages, content and pages were almost inseparable; a single HTML file both stored the content and determined the final presentation. However, with the emergence of CMSs like WordPress, content began to separate from the page, becoming an object that could be stored and managed independently. Later, the separation of front-end and back-end further reinforced this trend, allowing content to exist entirely detached from specific pages.

Thus, the Web underwent a significant transformation:The content on the webpage is no longer attached to the page itself. However, this is only half of the story.

In reality, whether the content is stored in an HTML file, a database, or retrieved via an API, it's all irrelevant to the user. What they ultimately see is always a complete webpage. The user's browser neither directly displays a record from the database nor directly interprets a piece of JSON data; what it ultimately needs is an HTML result that can complete the page display.

in other words,Content can exist independently, but web pages still need to be "generated" in some way at some point.

Then, a more natural question arises:When and how exactly do these independent pieces of content become the webpages we ultimately see?

This problem didn't seem to exist in the era of static web pages, because the page itself was the final result; but as content gradually decoupled from the page, "generating a page" became an independent task.

What's even more interesting is that although the way users browse web pages hasn't fundamentally changed over the past two decades, the process of generating web pages has been constantly evolving: sometimes, it's prepared before the user visits it; sometimes, it's generated temporarily when the user initiates the visit; and sometimes, it's generated by the browser at runtime.

From the user's perspective, we are always browsing the same web pages; but internally, the Web...The exact time and who created the webpage have been constantly evolving.

2. The Era of Static Web Pages: When "Generation" Wasn't Yet an Issue

If we shift our perspective back to the early stages of the Web, we'll discover an interesting fact:“The question of "how web pages are generated" did not actually exist in that era. The reason is simple—in the early days of the Web, a webpage was already a completed result.

In the era of static web pages, a website was essentially a set of HTML files scattered across a server. When a user accessed a URL, the server's job was very straightforward: find the corresponding file and return it to the browser as is. There was no database involved, no runtime logic, and no so-called "page assembly" process.

In other words, the web pages at that time were not "generated," but rather...It already existedWhat the browser receives is not a "generated result", but a pre-written HTML document. Its job is simple: parse the document and render it into the page that the user sees.

At this stage,The page, the HTML file, and the final display result can almost be considered as the same object. One URL corresponds to one HTML file, and one HTML file corresponds to one page. This relationship is so simple and direct that the entire system does not need to introduce an abstraction layer called "generating pages".

Looking back from today's perspective, this structure might even seem somewhat "overly simple": there's no middleware, no dynamic computation, and no runtime generation; everything is determined before the user even accesses it. But precisely because of this, it possesses a characteristic that many later systems have struggled to achieve—CertaintyRegardless of when you access it, the same URL always returns the same HTML file; the content the browser sees remains consistent. Therefore, in that era, the complexity of the Web was almost entirely focused on "how the content is written," rather than "how the page is generated."

However, this simplicity comes at a price.

With the development of the internet, websites are carrying increasingly more information. News websites publish new articles daily, corporate websites continuously add product introductions, personal blogs constantly accumulate content, and forums and communities generate new posts almost every moment. Websites have grown from dozens of pages to hundreds, thousands, or even more. At this point, people gradually realized that what was truly growing was not the page structure, but the content within those pages.

Taking blogs as an example, each article has almost the same page layout: title, body, publication time, author information, comment section... What really differs is often just the content of the article itself.

However, in the era of static web pages, adding an article meant adding a complete HTML file; if you needed to modify the entire website's navigation bar, footer, or sidebar, you had to modify all the related pages one by one.

The problem is not that this method is impossible, but that...All changes can only be applied directly to the final HTML file.Content updates require HTML modifications; page layout adjustments also require HTML modifications; even structures shared between multiple pages can only be maintained manually.

Only then did people gradually realize a problem they had never seriously considered before:Since many web pages have the same page structure, and the only thing that changes is the content, why bother writing them into separate HTML files? In other words, what we really need to maintain may not be the page itself, but the content on the page and the rules that determine how that content is organized and displayed.

When this line of thinking emerged, the Web also ushered in its first major turning point—The page is no longer a directly saved final object, but rather a result that can be "generated" based on the content.

It was at this moment that "generating web pages" became a real problem that needed to be solved for the first time.

3. From "Save Page" to "Generate Page"“

At the end of Chapter Two, we mentioned an important shift: as websites grew larger, people realized that what needed long-term maintenance wasn't a series of similar HTML files, but rather the constantly changing content within them. Thus, for the first time, web pages were no longer seen as final objects to be saved directly, but rather as a kind of...Results generated dynamically based on content.

Then, a new question naturally arises:If the page is no longer saved in advance, when exactly is it generated?

The earliest answer to this question wasn't from a specific technology, but from a completely new Web concept. It argued that what truly needs to be preserved long-term is the content, while the page itself can be generated on the fly based on the content when a user visits. In other words, the server no longer simply returns an existing HTML file to the browser, as it did in the era of static web pages; instead, it begins to undertake a new task:Generate the final HTML page in real time based on existing content.WordPress, as a representative CMS, is the most typical practice of this idea.

For browsers, almost nothing has changed: when a user visits a URL, the browser still receives a complete HTML document, and the final page display is essentially no different from the static webpage era. The real change lies in what the browser cannot see: in the past, the server returned an existing HTML file; now, the server returns a...Newly generatedThe HTML page.

This means that every time a user initiates a request, the server undergoes a new processing step: it first locates the content requested by the user, then fills in information such as the title, body text, author, and publication time according to a pre-designed page template, and finally generates the complete HTML and sends it to the browser. The entire process occurs within the short few hundred milliseconds the user waits for the webpage to load.

For the browser, it doesn't matter where the HTML comes from; it simply receives a standard HTML document and is responsible for rendering it.

Therefore, from the user's perspective, the Web has hardly changed.What has truly changed is the time when web pages were created.In the era of static web pages, web pages existed long before users accessed them; but in the WordPress era, web pages are only truly "born" after a user initiates a visit.

This is why the Web has, for the first time, possessed true "dynamic" capabilities: adding a new article no longer means adding a new HTML file, but simply adding a new content record; modifying the layout of the entire website no longer requires modifying each page individually, but only adjusting a unified page template.

Web pages began to truly become aRuntime generated resultsIt is not a file that requires long-term maintenance.

Today we usually refer to thisAfter a user makes a request, the server dynamically generates an HTML page and returns it to the browser.The method is called SSR (Server-Side Rendering)For example, in WordPress, which everyone is familiar with, each time an article is accessed, it reads the database, executes a PHP program, and finally generates a complete HTML page to return to the browser. This is a typical SSR (Site Response Time) pattern.

It's important to note that SSR is not a new technology invented by WordPress, but rather a general term that has come to represent this type of page generation method. For the purposes of this article, it's more important to understand the evolutionary thinking behind it:Web pages have changed from "existing in advance" to "generated on request".

However, while this approach solves one problem, it also introduces new costs. Since the page needs to be regenerated for every visit, the server must repeat the same work over and over again. For websites with low traffic, this extra overhead is almost negligible; but as the website grows, this "regenerate once per visit" model begins to reveal new problems.

Thus, the evolution of the Web did not stop. People began to think:Is it really necessary to regenerate web pages every time you visit a site that rarely changes?

4. When "generate once every time" begins to become unnecessary

In CMS systems represented by WordPress, the web entered the stage of "dynamically generated pages" for the first time. Pages no longer existed in advance as HTML files, but were generated in real-time by the server based on the content and template when a user initiated a visit. This approach was reasonable for a long time; for websites with constantly changing content, this model solved a core problem:After the content and page structure are decoupled, the page can be dynamically reconstructed.

However, as the Web has further developed, a new problem has gradually emerged: not all content changes frequently. On the contrary, many web pages remain stable for a long time after they are generated. For example, a blog post, a documentation page, or a product introduction page, once published, are often only modified occasionally, rather than changing continuously.

However, under the SSR model, these pages are still treated as objects that "need to be regenerated on every visit." That is, even if the content remains completely unchanged, the server must still repeat the same process: read the content → apply the template → generate HTML → return it to the browser. As a result, the generated HTML is almost identical each time.

The problem gradually emerges here:If the result is the same every time, is it still necessary to "regenerate it every time"?

Once this problem is raised, the entire premise of the model begins to crumble. This is because the essence of SSR is that the page is recalculated for each request. However, the reality is that most requests are simply recalculating a predetermined result.

Thus, a new optimization approach emerged: since pages are stable in most cases, could the result be saved after the initial generation? If the page remains unchanged, subsequent requests would no longer need to re-execute the generation process; instead, the already generated result could be returned directly. In other words, the Web began to shift from "generate every time" to "generate once."

This is the background to the emergence of static page generation. In this model, the page generation time is further advanced, no longer occurring when a user visits, but at an earlier stage—when content is updated or the website is built. The generation process no longer depends on each request, but becomes a one-time computation process. Subsequent visits simply reuse the already generated results.

From the user's perspective, nothing has changed. They still see a complete webpage, and the loading speed may even be faster. But internally, the way the webpage is generated has undergone a subtle but crucial change—it is no longer "request-driven generation," but rather "pre-generated + reused."

Today, this method of "pre-generating HTML pages before user access and reusing them in subsequent requests" is generally referred to as... SSG (Static Site Generation).For example Hexo,Hugo Static blogging systems, such as [example systems], are typical examples of the SSG (Service-Side Grid) model. They generate all HTML pages in advance when the website is published. When a user visits the site, the web server simply returns the pre-generated files without needing to generate the pages on the fly.

The key difference between it and SSR (Server-Side Rendering) is not whether a page is generated, but rather...The time point when the page is generatedSSR occurs at request time, while SSG is completed earlier in the release phase.

From an evolutionary perspective, SSG is not a replacement for SSR, but a structural optimization to address the problem of "the same content being repeatedly generated".

However, this approach also raises a new question: if the pages are already generated during the build phase, how should these already generated pages be updated when the content changes?

The evolution of the Web does not stop here; on the contrary, this issue will further drive the next structural change.

5. When "Generation" begins in the browser

In the SSG model, webpage generation is further pre-empted: the page is no longer dynamically generated when a user visits, but is completed during the build phase. Subsequent requests simply return the pre-generated HTML result. From the results, this approach is highly efficient—the page is no longer repeatedly calculated, server load is significantly reduced, and response speed is more stable.

However, as this model developed, a new problem began to emerge: if the page is completed in advance during the build phase, how should changes that only occur after the user actually visits it be handled? In other words, SSG solved the problem of "too slow generation," but it also made another type of need more prominent:Not all page content can be determined in advance during the build phase.

For websites with stable content, this isn't a problem. But another important characteristic of the Web is interactivity. Users don't just read pages; they interact with them. Clicking buttons, switching states, filtering content, loading more data… these actions mean that a page is not just about "displaying results," but also about constantly changing as it runs.

In the SSG model, this change is difficult to express naturally because the page is fixed during the generation phase and no longer has the ability to be "regenerated." Therefore, a new boundary begins to emerge:Static generation addresses "how a page is built," but it doesn't answer "how a page changes during use."

This issue ultimately came down to the browser's side. With the continuous enhancement of JavaScript's capabilities, browsers are no longer just "tools for displaying HTML," but have begun to possess the ability to execute complex logic. Pages no longer rely entirely on servers for generation; instead, after loading, the browser can continue to "supplement" and "modify" them.

In this mode, the browser begins to take on some of the work that originally belonged to the server. Data can be retrieved after the page loads; the interface can be recalculated during user interaction; even the entire page structure can be reorganized during runtime. In other words, the "generation" of a webpage no longer happens only once, nor solely on the server, but has entered a new phase:Runtime Generation.

This change ultimately led to a very clear model: the page is no longer the final output of the server, but rather an application that continuously runs within the browser. In this model, the server's role is further weakened. It is no longer responsible for generating the complete page, but merely for providing data and interfaces. The actual page structure and change logic are entirely handled by JavaScript in the browser.

Thus, the logic for generating the Web underwent a complete migration for the first time: from the server to the client.

Today, this method, in which "pages are primarily generated at runtime by JavaScript in the browser," is generally referred to as... CSR (Client-Side Rendering)In recent years, a large number of [projects] based on React,Vue Web applications developed using modern front-end technologies all fall into this category. When a user visits a website, the browser first downloads the application code, and then JavaScript generates the page content on the client side.

Unlike SSR and SSG, the core change in CSR lies not in the "timing of generation," but in...The generation location has moved from the server to the browser..

In this model, the server is primarily responsible for providing data interfaces, while the page structure and rendering logic are handled by the browser at runtime.

However, this model also brings new structural changes because when generation occurs entirely within the browser, the initially loaded page is often just an "empty shell." The actual content needs to be built up gradually through additional logic after the page loads. This leads to a significant difference between the initial rendering of a page and its final state. The structure of the Web has thus become more dynamic, but also more complex.

Therefore, the question of "who should generate the page" no longer has only one answer.

6. From "Select Generation Method" to "Assign Generation Method"“

Throughout its evolution, the changes in the Web have consistently revolved around the same core issue:When should a webpage be generated?

In the era of static web pages, this problem didn't even exist because the web pages themselves were already existing files. With the advent of CMS, represented by WordPress, web pages began to be dynamically generated when a user accessed them; generation occurred at the time of the request. Subsequently, SSG moved generation forward to the build phase, ensuring the page was fixed before being accessed. CSR further changed the location of generation, shifting this process to the browser's runtime.

From this main perspective, the evolution of the Web seems to have been doing the same thing all along: constantly adjusting the "timing of generation" and the "location of occurrence." But as the Web developed into a stage of complex applications, a more fundamental problem began to emerge. Real-world web pages are often not a unified whole.

Take a typical modern webpage as an example. It usually contains a variety of different types of content: some parts hardly change, such as the article text or documentation; some parts update over time, such as recommended content or list data; some parts depend on user status, such as login information or personalized content; and some parts require frequent interaction, such as comment sections, pop-ups, or partial components.

If we still insist on "one page using only one generation method", a structural problem will arise:Any single generative model can only optimize a certain type of scenario and cannot adapt to all parts at the same time.

For example, for websites that need to display the latest content in real time, such as news homepages and forums, if static generation is used entirely, the page needs to be rebuilt every time the content is updated, which obviously lacks flexibility. However, if everything is generated on request, even long-term unchanging content such as website navigation, footer, and article content needs to be recalculated every time it is accessed, which will bring additional operating costs.

Some pages emphasize real-time interaction, such as backend management, online documents, or instant messaging, which are more suitable for browsers to handle at runtime. Meanwhile, other pages emphasize content display, and if they also rely entirely on browser generation, they will often have significant disadvantages in terms of first-screen loading speed, search engine indexing, and social media platform previews.

This illustrates that different types of content and different usage scenarios have different requirements for webpage generation methods.The real question is no longer "which generation method is best", but "which part of the page is more suitable for which generation method".

Thus, the evolution of the Web entered a new stage:The page is no longer generated as a whole. Instead, the generation work is allocated to different times and different locations based on the characteristics of different parts.

In this new structure, a single page can have multiple generation logics simultaneously: stable parts can be generated in advance during the build phase; dynamic parts can be generated by the server upon request; and interactive parts can be completed at browser runtime. These different generation methods no longer compete with each other but begin to coexist on the same page.

From the outside, users still see a complete webpage. But internally, this webpage is no longer a unified generated result, but a structure assembled from multiple different generation mechanisms.

As the Web evolved to this stage, the problem of "generating web pages" itself changed. It was no longer a choice between "SSR, SSG, or CSR," but a structural problem: where should the different parts of the page be generated?

Frameworks like React, Next.js, and Nuxt, commonly found in modern web applications, are not inherently new generation paradigms. They are simply the result of combining and allocating the three "generation occurrence locations" discussed earlier—Supported Request Generation (SSR), Prior Request Generation (SSG), and Computed Runtime Generation (CSR)—within the same system.

7. The Shift in the Right to Generate: A Unified Interpretive Model for the Web

If we return to the initial question, the entire article actually revolves around the same core:When and where exactly are web pages generated?

In the era of static web pages, this problem was not apparent because the web page itself was an existing result. When a user accessed a URL, they were essentially just retrieving a pre-written HTML file; "generation" was not an independent process. As the web structure became increasingly complex and pages and content began to decouple, this problem gradually emerged. Even so, for a long time it remained merely an internal implementation detail of the system, rather than an independent design dimension.

It wasn't until the Web entered a more complex phase that "how web pages are generated" truly became a question that could be explicitly designed. From that moment on, the evolution of the Web no longer revolved around specific technologies, but rather around a single core dimension:Location and timing of page generationIf we abstract this dimension, we can roughly obtain the following evolutionary axis:

Under this dimension, the Web at different stages is simply choosing different ways of taking values, rather than introducing new problems: ultimately, whether it is SSR, SSG, CSR, or their combination, they are essentially just different expressions of this dimension under different constraints.

From this perspective, the so-called technological evolution of the Web is not a linear technological history, but a process in which the same problem is constantly redistributed in different parts of the system.

When we return to this level of abstraction, we find that all complex concepts can ultimately be reduced to a simpler problem:At this stage, which part of the system is responsible for page generation?

This is the unified explanation for the evolution of the entire Web form.

Note: SSR, SSG, and CSR are not strictly chronological evolutionary chains, but rather three abstract ways of classifying the question of "when webpage generation occurs and which part of the system is responsible for it." In actual Web development, these methods have coexisted for a long time and have been continuously combined and reused in different scenarios. For the sake of narrative coherence, this article unfolds linearly according to the evolutionary path of this question, but this is only the order of expression and does not mean that these technologies appeared in this order historically.