Static site generator and content system mixed, which pages are suitable for pre-generation
Static site generator and enterprise content system mixed, which pages are suitable for advance generation——The criterion is whether this page will be frequently changed, or whether to recognize the visitor's identity.The generator compiles content into ready-made files during the build phase, requiring almost no computation when read, the official page describes it as a static site generator implemented in Go language, known for its speed, and the entire site can be rebuilt in a very short time;The cost is the need to rebuild and deploy each change. The content system places the cost at the request, in exchange for the ability to change at any time and return different results based on identity. Both types of tools occupy a section, and clear division of labor on the page allows for the benefits of both sides.
Each tool places its cost at which step
The route of pre-generation, the cost is concentrated in the construction period: once generated after writing and review, the read request hits the existing file, the server pressure is small, and one layer of runtime dependency is also eliminated. The dynamic content system route, the cost is分散 in each request: retrieve data, apply template, judge permission, write cache, the advantage is that it takes effect as soon as it is changed, no need to publish actions. It is more cost-effective to place pages with more reads and less writes in the first route, and pages with more writes and less reads are more convenient to place in the second route.
Page types suitable for pre-generation
| Page Type | Change frequency | Whether to recognize the visitor's identity | Where is it suitable to place |
|---|---|---|---|
| Help documents and manuals | Low | No | Pre-generation |
| Event landing page | In, according to the event cycle | No | Pre-generation |
| Archived information content | No longer modified | No | Pre-generation |
| Article list and column page | High | No | Dynamic side, relying on cache |
| Comments and messages | High | Is | Dynamic side |
| Forms and submission | High | Is | Dynamic side |
| Member-only visible content | in | Is | Dynamic side |
Documents, manuals, and archive text are typical of read-heavy, write-light scenarios: edited once, read thousands of times, and generated in advance to keep reading costs very low. Similarly, the landing page for the event remains mostly unchanged during the event period, and the number and structure of pages are controllable.
Not suitable for staticized page features
If only one condition is met, don't force it: need to return different content according to login identity; need visitors to write data; content changes in real time over time; the same address should return different results for multilingual or multistie sites. Comments, messages, form submissions, and text under member group fall under these conditions. Force them into the generation process, either move the write operation to a third party and return, or pack scripts dynamically in the page, the cost saved when reading will be added back in another form.
Address and release rhythm when mixed in use
The two systems are most likely to have problems with the address style and publishing time. On the address side, the dynamic side enables pseudo-static rules, writing the address form of the list page and the content page to be consistent with the generation side, unifying the path template under the same column to avoid the situation where the same content has two readable addresses. AnQiCMS's pseudo-static rules support customization, can be set separately by category, and after aligning this section, you can safely hand over the document content to the generation side.
On the release rhythm, scheduled release is responsible for making the content go online at a preset time. When mixed, it is necessary to distinguish between two triggers: dynamic side takes effect immediately, and the generation side still needs to wait for one build to be completed. Put the fixed build tasks every day after the intensive content release, or let the release action directly trigger incremental generation, so that the two timelines will not be out of sync. If the entire site can be rebuilt in a very short time, the risk after release is not great; for projects that take a long time to rebuild, incremental triggering is more suitable.
Align the address and rhythm, and retain a unified navigation source. Let the navigation settings be maintained by the dynamic side, and the generation side only reads the same structure. When the column name is changed or a new one is added, both sides change together without manual synchronization.
Common questions
How to correct typos in pre-generated pages?Follow the same publishing chain: make changes in the content system, trigger reconstruction, and then check the generated results. Making changes directly on the generated file will be overwritten by the next build.
Can the list page also be pre-generated?Yes, but it depends on the update frequency. High-frequency new content will cause frequent triggering of builds, and the benefits will be offset by the operation and maintenance costs; for most projects, it is more cost-effective to keep the list page on the dynamic side with caching.
Which side is suitable for a multilingual site?The page itself can be generated, but the language switching and the management of full-page translation remain in the content system, driven by the same structure on both sides to avoid the translation from being disconnected from the original text.
Will the mixed use increase the operation and maintenance burden?It will add another release chain and a set of address constraints. After clarifying the division of labor and aligning the address with the release time, the additional burden mainly falls on the construction monitoring, rather than daily editing.