1 When a website is no longer just a webpage

Before I knew it, it was 2026. Looking back, my blog has been running stably for over two years now, from its initial setup to now. It's not a particularly long time, but it's enough for me to fully experience the process from "building the website" to "starting to repeatedly think about what a website really is."

I still vividly remember the feeling I had when I first started using WordPress: a pure and direct sense of bewilderment. Not because it was complex, quite the opposite, because it...Too smoothInstall a theme, and the overall style of the site is instantly established; add a few menu items in the backend and drag their order, and the website's structure is "built"; if you need a certain function, you often only need to install a plugin; and what you call a webpage is mostly just adding an article or a page, and the system will naturally generate an accessible address.

All of this seemed reasonable and efficient, but at the time, I had a vague feeling that something was amiss—because I realized that I didn't seem to be truly "creating pages," yet I already had a complete website. Many operations that I once thought I had to do manually were automatically taken over by the system in WordPress. This experience didn't just bring ease, but a kind of...Cognitive weightlessnessFor a long time, I couldn't understand why I couldn't find the text content in the page's source code. Previously, editing text content meant directly modifying the source code, but WordPress hides these underlying operations, forcing me to adapt to a completely new way of thinking.

Later I realized that this discomfort didn't stem from WordPress itself, but from my pre-existing cognitive model of websites. If we rewind twenty years, my understanding of "websites" was actually very clear and perfectly aligned with the technological environment at the time—the era of the "web trio" (Fireworks, Dreamweaver, and Flash).

Fireworks was used for visual page design, Dreamweaver handled the HTML structure and layout, and Flash provided the interaction and animation. The page was "created" step-by-step from design to implementation, and finally deployed to the server as files. My graduation project website was completed using this process.

In that context, "building a website" is essentially "building web pages": web pages are the final form, and a website is simply a collection of these pages. As for content, structure, and interaction, they are naturally attached to the web pages and are rarely considered separately.

That's why the impact was so strong when I first encountered WordPress, a completely different way of working—it wasn't that I was unfamiliar with a specific technical aspect, but rather that it skipped over the entire evolutionary process I was familiar with at the overall cognitive level.

Looking back now, my shock at the time was perfectly normal. It wasn't a gradual transition from "static pages" to "dynamic websites"; rather, it was a near-absolute leap across more than a decade of accumulated technology and concepts, directly jumping from the old understanding that "a website equals a collection of pages" to the modern Web model centered on "content." This shift from a page-centric to a content-centric approach is precisely the key leap represented and profoundly driven by WordPress.

As I used it more, I gradually realized that what WordPress truly changed wasn't just the way websites were built, but the way people understood "how a website exists on the Web." From that moment on, the page was no longer the sole focus; content began to become something that could be managed, reused, and accumulated over the long term. It was on this basis that a series of subsequent issues, such as caching, comments, and front-end/back-end separation, gradually emerged.

Based on these personal experiences and reflections, this article attempts to review the cognitive evolution of the Web, starting with the specific system WordPress. It is not a tutorial, nor a tool comparison, but a retrospective: a look back at how we gradually moved from "creating pages" to "managing content," and in the process, continuously redefining the "website" itself.

2. The Web as it once was: A website was simply a "collection of pages"”

If we go back to the early context of the Web, the idea that "a website is equal to a collection of pages" was not a narrow understanding, but a consensus that hardly needed explanation. At that stage, the Web itself was a document-oriented system, and its core capability was very simple: request a resource on a server via a URL, and then return the result to the browser for display.

In this model, the page naturally becomes the center of everything. The URL points to a file path, and the server's responsibility is very clear—to read the corresponding file and send it out. Whether the file contains articles, images, or forms is not important; what matters is that it is an accessible and displayable page. Therefore, a website is naturally understood as a collection of these pages.

Taking my static blog "staticblog.tangwudi.com" as an example, the access path for an article titled "The Awakening of Sound: Basics (Part Two): From Pitch Names to Simplified Notation" is... https://staticblog.tangwudi.com/technology/innerlight14026/:

In the traditional page model, the URI path "/technology/innerlight14026/" can directly correspond to the file path on the local disk of the host machine./data/staticblog/index/technology/innerlight14026/index.html:

When a browser requests this URL from a server, the server simply reads the file and returns the content, which the browser then renders. The article content, images, comments, and other elements are all statically written into the page file itself, and the page itself is the final form the user sees.

This example visually illustrates the typical thinking behind the early Web:A URL corresponds one-to-one with a file path; a page is the carrier of content; and a website is a collection of these pages.In this mode, if you want to update the article content, you must directly modify the corresponding page file; otherwise, the browser will still see the old page. The core assumption of the entire system is that the page is the content, and the content is the final form.

This understanding was not only reasonable at the time, but also efficient—the page was the final result, and almost all of the developer's work revolved around "how to create the page": page design, page layout, page interaction, and page publishing formed a clear and linear production chain. As long as the page existed, the website existed; as long as the page could be accessed, the website was considered to be "operating normally."

It was against this backdrop that "building a website" and "building a webpage" were almost synonymous for a long time. Content was not discussed in isolation; it was simply a piece of text or a set of media resources on the page. Updating content was equivalent to modifying the page; adding new content often meant adding a new page file. The relationships, reuse, and evolution of content were not within the core scope of design.

This page-centric model implicitly contained some premises that were almost universally accepted at the time: content was not an independent object, but rather a component of the page; comments, interactions, and feedback were only a part of the page's rendering result. They were tightly coupled with the page, together forming a complete output.

These assumptions worked quite well in the early days of the Web. The number of pages was limited, update frequency was low, and content lifecycles often coincided with the page itself. At this scale, binding everything to the page was not only intuitive but also easy to understand and maintain. Almost no one questioned, "Should the content itself be abstracted separately?"“

However, as websites grow, this model begins to show its limitations. The same type of content needs to be frequently updated, referenced, and aggregated, leading to a rapid increase in the number and complexity of pages. As the lifecycle of content gradually extends beyond individual pages, maintenance costs no longer increase linearly, and pages begin to transform from the "final destination" into temporary containers for content.

It was during this stage that people began to realize that the problem might not be that the page wasn't well-designed, but rather...Should the page continue to bear all the responsibility?When web pages are forced to bear the responsibility of content organization, structural relationships, and long-term evolution, this page-centric cognitive model of the Web gradually reaches its tipping point.

The next change is not simply making pages more complex, but a more fundamental shift: what would the Web look like if content were freed from pages?

3 From Page to Content Entity

If the previous chapter depicted a well-functioning old world centered around the webpage, then this chapter discusses the moment when that world was truly shaken for the first time. This change wasn't a performance improvement brought about by a specific technology, but rather a more fundamental shift in perception: the webpage was no longer the sole center, and content began to be treated as an independent object.

Before WordPress, people rarely discussed "content" in isolation. Content was always embedded in the page, along with layout, style, and interaction, and was considered part of the final output. The content existed only because the page existed; when the page was deleted, the content disappeared as well. The page was both a container and the endpoint.

The first important thing WordPress did was precisely to break this binding relationship. It introduced the concepts of "post" and "page," but this is not a simple page classification; rather, it is a semantic abstraction (Note: In the context of WordPress, a "page" does not refer to the final rendered page result, but rather another type of content, just like a "post," which is a data object managed by the system. This point will not be elaborated on later; just remember that they are essentially all "content").

From this moment on, content "detaches" itself from the page for the first time, becoming an entity that can be stored, managed, and evolved independently—the page is no longer the content itself, but merely a way of presenting the content.

This change seems very natural from a user perspective, but it brings about a fundamental difference in perception: URLs no longer point to a specific file path, but instead become the entry point for content access. The actual content is stored in the database as structured data, with each article being simply an independent record.

Taking the article with the URI path /technology/innerlight14026/ mentioned earlier as an example, in my main blog site, it does not exist in a disk directory, but corresponds to a record in the wp_posts table of the WordPress database in MariaDB, with an ID of 14026:

Therefore, the page is no longer an indivisible final result, but merely a view output of the content by the system in a specific context.

Content has transformed from "outcome" into "asset," beginning to be stored long-term in the form of structured data, and possessing a lifecycle that can be maintained, evolved, and reused.It is on this abstraction that a Content Management System (CMS) truly comes into being. Content can be updated without disrupting the overall structure, reorganized without redesigning pages, and aggregated, filtered, and re-presented at different times and in different scenarios.

The semantic changes in comment systems also stem from this: in WordPress, comments are no longer just a piece of text on a page, but exist as data attached to the content, establishing a relationship with the post, yet remaining relatively independent in storage and logic. This design provides natural space for interaction, statistics, and expansion.

However, this content-centric model is not without its costs. As pages evolve from "fixed results" to "generative views," new complexities emerge. Issues such as content stability, real-time interaction, and caching effectiveness—problems previously masked by the page model—begin to surface. It is here that the next phase of Web architecture evolution is forced to unfold—and this is the topic of the next chapter.

4. When content encounters cache

In Chapter 3, we saw that websites underwent a crucial cognitive leap: content no longer existed solely as an appendage to a page, but was abstracted into "content entities" that could be independently managed, preserved long-term, and reused repeatedly. Once this step was taken, the nature of a website fundamentally changed—it was no longer a one-time delivery, but a continuously growing content system. It was at this stage that a problem, not readily apparent in the early days of the Web, began to emerge:performance.

In the era when "a website equals a collection of pages," performance wasn't a core concern. The number of pages was limited, the volume of access was predictable, and the update frequency was low. Even if each request was generated by the server in real-time, costs remained manageable. So-called "performance optimization" often simply involved switching to a faster server or removing a few images.

However, things changed drastically when websites evolved into content-centric systems. The number of articles continued to grow, and access points became more dispersed; the same piece of content might be accessed extensively at different times and repeatedly crawled by search engines. Meanwhile, most content remained highly stable after publication—it wasn't frequently modified, yet it was frequently accessed.

This change directly exposes a fact: for the vast majority of requests, the server is repeatedly performing the same task. Each access requires re-querying the database, reorganizing the content, reapplying the template, and regenerating the complete page. Logically, this isn't problematic, but from a system perspective, it's extremely inefficient. Therefore,Caching systems have emerged as a result.:

The introduction of caching is essentially a new abstraction: it separates "content generation" from "content distribution." When a page won't change in a short period, there's no reason for the system to regenerate it for every request. By temporarily storing the final result and reusing it next time, server load can be significantly reduced, while access speed can be greatly improved.

In modern websites, caching goes beyond simple page storage. Page caching, object caching, reverse proxy caching, and CDN edge caching are layered together to form the performance infrastructure of the modern web. They enable websites to maintain availability and responsiveness even as content volume and traffic increase dramatically.

Technically, caching seems like a simple optimization, but it subtly changes the way websites operate: content no longer relies entirely on real-time generation, but instead has a "static" presentation. This is hardly contradictory for most content, as it is inherently highly stable.

However, as website content begins to include dynamic interactive elements, such as comments, likes, login status, or personalized content, simple caching logic is no longer fully adequate. Caching only determines whether the result of the entire request is reusable, without distinguishing which parts of the content are stable and which parts may change frequently.

That is why,The costs of content abstraction are gradually becoming apparent.Websites can efficiently handle a large number of stable visits, but when dynamic interactions are involved, simply relying on caching is no longer sufficient. This is not a problem with plugins, nor is it an accidental phenomenon caused by misconfiguration; rather, it is a natural tension faced by content systems as they enter a phase of scaling and long-term operation.

5. Commentary, Real-time Performance, and Structural Tension

In the previous chapter, content-based websites achieved significant performance gains through caching systems—stable content was distributed efficiently, server load decreased significantly, and the website maintained good responsiveness even under large-scale access. From an engineering perspective, this is almost a flawless optimization path. However, the problem doesn't end there.

In most content-based websites, articles are not the only content. Comments, likes, replies, reading status, and user information, while taking up a small percentage of the page, naturally share a common characteristic:They require real-time performance.Users expect their comments to appear immediately after posting them; refreshing the page but not seeing any updates is often an unacceptable experience.

In WordPress's content semantics, comments are considered part of the post from the very beginning. They exist in conjunction with the post, share the same access point, and are usually output uniformly in the same page rendering process. From the perspective of the content model, this design itself is not problematic: posts are content, comments are also content, and together they constitute a complete content entity.

The real conflict arises after the caching system intervenes. Caching doesn't understand the difference between "articles" and "comments"; from its perspective, a URL corresponds to only one reusable response. As long as the cache is still valid, the system will directly return existing content, regardless of whether any parts of the page have changed.

Thus, a structural tension begins to emerge: the main body of an article tends to be highly stable, while comments are constantly changing; however, in a caching system, they are forced to share the same lifecycle. The same URL is either entirely valid or entirely invalid; caching cannot update only the comment section, nor can it express the semantics of "the content remains largely unchanged, but certain parts need to be refreshed in real time."

When traffic is low and caching strategies are conservative, this conflict is not obvious. However, when a website starts to rely on longer caching times to trade for performance, the problem becomes amplified: pages can be cached for a long time, but comments are forced to appear with a delay, or even require users to refresh repeatedly to see updates.

At this point, people often attribute the problem to plugin instability, complex caching configuration, or a "mis-tuned" strategy. However, from a higher, more abstract perspective, this is not a problem with a particular implementation detail, but rather...The inherent tension between the two system logicsContent systems emphasize structural integrity and long-term maintainability; caching systems emphasize stability and reuse efficiency. When strong real-time requirements are embedded in a model centered on stable content, conflicts are almost inevitable.

More importantly, this tension will not disappear completely with experience. As long as comments are still considered part of the overall page, a trade-off must be made between "performance" and "real-time": shortening the caching time results in performance degradation; extending the caching time impairs the interactive experience.

From this perspective, the commenting issue is not an isolated functional problem, but rather a boundary issue that inevitably emerges as content systems mature. It reminds us that when content is stored long-term, widely distributed, and highly dependent on caching,Not all information is suitable to remain in the same rendering model..

It is here that the website architecture begins to diverge, gradually splitting into two paths: one is to introduce more complex caching rules and invalidation strategies without changing the content model, so that the original system can carry more dynamic needs as much as possible (such as Cloudflare APO); the other is to rethink the boundary between content and interaction and further decompose the system.

And this is precisely the starting point for the next stage of architectural evolution.

6. Front-end and back-end separation: An evolution that is not rebellion

In the previous chapter, we saw that content systems gradually reveal structural tensions when faced with comments and real-time interactions. This tension does not stem from a specific implementation error, but rather is the result of the content model naturally evolving to a certain stage: when content is stored for a long time, widely distributed, and highly dependent on caching, the cost of continuing to cram all interactions into the same rendering process begins to rise rapidly.

As a result, the website architecture began to undergo a seemingly radical, but actually restrained, change:The system no longer attempts to solve all problems at a single level, but instead chooses to split responsibilities..

The first thing to be re-examined was not the content itself, but "how the content is presented." In the traditional CMS model, content storage, page generation, and user interaction are tightly bound together in a single request: the server is responsible for managing content, assembling pages, and handling comments and status changes simultaneously. This model is very efficient when the scale is small, but as complexity increases, it gradually becomes a limiting factor for the system's continued evolution.

Separation of front-end and back-endIt gradually took shape against this backdrop. It wasn't a rejection of WordPress or CMS, but rather a further abstraction built upon their success—After the content has been clearly modeled and reliably stored, the system begins to clearly distinguish between two types of roles: one is responsible for the content itself, and the other is responsible for the presentation and interaction of the content.

Under this division, the backend system continues to operate around content: how content is produced, how it is structured, how it is stored long-term, and how the relationships between different pieces of content maintain order. Meanwhile, the frontend gradually detaches itself from the role of "template rendering result," focusing instead on page organization, interaction rhythm, and changes in user state. The two are no longer coupled through the single form of "generating pages," but rather collaborate through explicit interfaces.

This is why content has begun to be extracted from the "complete page": it is no longer delivered directly as the final display result, but exists as a resource that can be independently accessed and combined. The page is no longer the sole destination of content; content can be reused repeatedly across different front-ends, devices, and display strategies without changing its storage method.

This change directly alleviated the previously recurring structural tensions. Stable content can continue to be cached freely, while real-time demand-driven elements such as comments, likes, and user status are dynamically loaded through independent requests. They are no longer forced to share the same cache lifecycle, nor do they need to compromise with each other.

From this perspective, the separation of front-end and back-end is not a revolution of "starting from scratch," but rather a natural division of labor after the system matures. When the content system is stable enough, it has the conditions to be separated and exist as a basic capability.

It was during this stage that website architectures began to diverge: some moved towards a completely headless architecture, some combined static generation with incremental updates, some moved rendering to edge nodes, and others retained the traditional CMS while only breaking down key interactions. The implementation paths differed, but the underlying motivations were remarkably consistent—Let stable content remain stable, and let changing elements have room to change.

The separation of front-end and back-end is not the end point for content systems, but rather a sign that they are beginning to acknowledge their own boundaries. When a system can proactively decompose itself, it often means that it has entered a more mature stage.

7. To clear the name of a misunderstood revolution

Looking back at the previous chapters, a fairly clear evolutionary path can be seen: the Web didn't suddenly become complex, and WordPress didn't become "heavy" overnight. Pages were abstracted into content entities, and content began to be stored long-term and repeatedly distributed; comments, permissions, caching, and interactions were continuously added—each step was a natural result that grew out of the process of solving real problems.

This is precisely why we frequently hear criticisms of WordPress today, calling it "too heavy," "bloated," and "not modern enough." These feelings often stem from real user experiences, but the problem isn't the criticism itself, but the premise of the comparison. Many discussions actually use current solutions designed for "minimalism," "single responsibility," and "complete front-end/back-end separation" to retrospectively examine a system born more than a decade ago with "long-term content management" as its core objective—this temporal misalignment makes the comparison inherently unequal.

If we draw an analogy with World of Warcraft's place in the history of MMO games, it might be easier to understand:

For many veteran online gamers, the significance of World of Warcraft goes far beyond its graphics, skill mechanics, or numerical system. It became a landmark of its era because it was the first game to systematically define the MMO genre.World-building, social relationships, and long-term content evolutionThe basic paradigm.

While today's games, powered by modern engines, with more sophisticated mechanics and faster pace, are indeed more "advanced" in many technical aspects, their existence does not negate the historical significance of World of Warcraft. On the contrary, it is precisely because that paradigm was fully validated that later makers had the space to simplify, optimize, and make choices.

The relationship between WordPress and modern web architecture is actually very similar.

When we say WordPress is "heavy," we often overlook one point: this heaviness is not the result of redundant design, but rather the culmination of ever-increasing real-world needs. It carries not only the functionality itself, but also a whole set of web experiences regarding how content exists, evolves, and is repeatedly used. It is precisely in the process of these experiences spilling over that the modern web architecture has gradually taken shape: content storage and evolution are still handled by CMS-like systems, while content retrieval and presentation are delegated to new middleware layers, or even moved to the edge of CDNs.

From this perspective, this is not an article defending WordPress, but rather a review of the evolution of the Web. WordPress is not perfect, nor is it suitable for all scenarios, but it did complete a decisive leap at a crucial historical juncture: transforming websites from mere collections of pages into truly content-centric, continuously growing systems.

Once this is understood, many debates naturally become meaningless. What remains is not "should we use WordPress?", but whether we realize that the seemingly self-evident web capabilities of today originate from the revolution that has already happened and continues to influence us.

Note: Strictly speaking, WordPress is not the world's first CMS. Before it, systems such as Drupal, PHP-Nuke, and Movable Type existed. However, its revolutionary nature lies not in technological innovation, but in the popularization of awareness—for the first time, ordinary users truly realized that a website is not just a collection of pages, but a content system that can be managed and continuously evolved over the long term.