So Outside Technology Security CMS
AnQiCMS
Online Demonstration

Static files and dynamic pages are deployed together, where should the cache be placed?

📅 2026-11-01 👁️ 0

When static files and dynamic pages are deployed together, where should the cache be placed? The answer is to layer by resource type, not by the whole site switch. Static products such as images, attachments, scripts, and styles should be placed at the outermost layer, with a long expiration period;The list page and detail page belong to 'Content changes but changes slowly', placed in the middle layer, the validity period is set short and actively invalidates with the publishing action; the background management interface and API calls do not cache, otherwise, you can't see the changed content and the verification status is confused.The most common problem with mixed deployment sites is that these three layers are treated as one, either the entire site cache causes backend exceptions, or the entire site does not cache causing the source end to be overwhelmed.

Firstly, tier by resource type

Resource type Change frequency Cache location Expiry method
Images and attachments Essentially unchanged Outermost static resources Replace file name or extend the validity period
List page and detail page Changes with publication Middle page layer Proactively clear when published or revised
Site map and list Changes with new additions Do not cache for a long time Update immediately after regeneration
Background and interface Need real-time Do not cache Not applicable

In the static product layer, there is a category of objects that are easy to ignore: images automatically matched to titles. Once the images are matched according to the title content, the path is written into the article, which belongs to a typical long-term caching resource; conversely, if the image matching strategy is adjusted and different images are returned from the same address, the cache will mix old and new images, and in this case, it is the filename that needs to be changed instead of clearing the cache.

The scope of application of page caching

The page layer needs to solve the pressure of repeated rendering. The list page and the homepage have concentrated access and consistent content, after the cache hit, there is no need to reassemble repeatedly, and the page loading speed directly benefits; for the detail page, if it contains user-state elements (login status, content visible to permissions), the cache should be handled with caution, otherwise, the member content will be cached as publicly visible.

The setting of the validity period has two references: the rhythm of content updates, and whether the cache clearing action is reliable. When updates are slow and lack active invalidation means, setting a short validity period is the only remaining insurance; on the contrary, if the release and revision actions can trigger cache clearing for corresponding addresses, the validity period can be relaxed to reduce the number of origin hits.

Why does the background and interface not cache

The reasons for the two layers are different. The background is a write-intensive interface, and caching can cause 'data still displayed after saving', which has a high cost of troubleshooting and is usually excluded from the cache range. On the interface side, form submission, human verification, and login status all depend on real-time verification, and the cache returning old responses will make the verification process invalid.

The deployment method also plays a role here: The content system implemented in Go language has obvious differences in resource consumption, with memory consumption reduced by about 80% compared to PHP CMS, and there is also an official reference for the level of 5 million PV that a single machine can carry.This actually has an impact - the cost of dynamic rendering itself is not high, the value of the cache layer is more reflected in reducing repeated rendering and shortening response time, rather than 'not caching will not hold up'.Therefore, small sites can treat caching as an optional optimization, deciding whether to add a page layer based on traffic, while the static resource layer is almost always worth doing first.

The backup range follows the stratification.

The cache strategy affects the shape of the resource directory, and this layer should be considered when backing up. Backup and recovery support the backup and recovery of data along with static files, and attachments, generated images, and static products are all within the scope.

Common mistakes in mixed deployment sites are only backing up the database: after source site migration or abnormal recovery, the page structure and content are all there, but the images and static files are missing. There is a simple way to check if the backup is complete - restore it once in a new environment and check if the images, attachments, and static resources can be accessed normally.

Common questions

Can't the site-wide cache switch be used?It can be used, but you need to confirm the exclusion rules: the background path, interface path, and pages with user status must not be cached, otherwise there will be issues such as not updating after saving or leakage of member content.

Changed the article but the page is still showing old content?Check if the page layer cache has expired with the publishing action; if there is no expiration mechanism, shorten the validity period or actively clear the corresponding address at the time of publishing.

How long should the validity period of static resources be set?Resources that do not change can have a longer validity period, provided that the file name changes with the content. Resources that overwrite at the same address are not suitable for long validity periods because the cache does not automatically recognize that the content has changed.

Should the manifest file be cached?It is not recommended to cache long-term. The value of the site map and overview files lies in their ability to reflect new additions and changes in a timely manner, and caching will delay the exposure of updates to the crawling end.

Related articles

How should batch 301 redirects be arranged during the domain name and version update, and how long will it take for old links to recover from dropping收录

The batch 301 redirect for domain change or version update should first lock the new address structure, and then follow the mapping rules of 'priority for isomorphic migration, followed by structural changes, and merging and deleting as a last resort.' The recovery pace depends on whether the crawling and active push keep up: if the list is still the old address, the recovery will be significantly prolonged. Handle the four lines of site map, pseudo-static rules, old links in the text, and push together, which is usually counted by week rather than by day.

2026-11-01

Is the slow page loading the fault of the CMS? Let's first look at the two clues of memory and staticization.

How to segmentally locate the slow page load: the handling methods of the three chains of network and resources, query and connection, and template rendering are completely different. Before monitoring data is available, it is worth prioritizing two clues: whether the resident memory triggers page switching and cache failure, and whether the front-end has truly taken the static path. This article provides the order of segmental troubleshooting, the basis for judgment, and in what cases the problem is indeed in the system kernel rather than the configuration.

2026-11-01

What is the default database used by lightweight CMS, SQLite or MySQL, and where are the differences in operations?

The lightweight website system uses a single-file embedded library as the default option to allow the site to run directly after placing it in a directory; switching to an external database service brings concurrent writing and multi-end connections, at the cost of an additional process, account, and backup link. This article uses the third-party system criteria from the day to explain the specific differences in installation dependencies, backup recovery, concurrency, and migration between the two forms, as well as at what scale this choice begins to affect operations.

2026-11-01

After the server management panel issues an emergency update announcement, what should the operations and maintenance personnel do first?

After the emergency update announcement from the management panel, the operation and maintenance team should handle the situation in the following order: first extract the affected components and current version from the announcement, then confirm that there is a recoverable backup point, then update in the order of gray to full, and finally review the login, process, and external ports. This article explains the criteria for each step with the panel announcement as an example, and compares the differences in rollback methods between panel deployment and Docker deployment.

2026-11-01

What items need to be checked when switching hosts on the day of switching, and parsing, certificates, and email cannot be missed.

Check the access chain on the day of the host switch: whether the resolution points to the new host, whether the certificate is complete and available at the new address, whether the pseudo-static rules and 301 redirect are effective, and whether the form and interface can be written. Before the switch, lower the validity period of the resolution record and make a complete backup containing static files. After the switch, keep the old account for more than a week and observe the log and traffic distribution. The record of the email sending identity should also be checked separately.

2026-11-01

How to coordinate the scheduling of content in holidays, scheduled publishing, and pending publishing status

When scheduling holidays in advance, the scheduled release solves the timing point, and the draft status to be released solves the review progress. AnQiCMS divides documents into four states: formal, draft, scheduled release, and recycling bin. The draft link with preview parameters can be reviewed before release, and deletion is moved to the recycling bin instead of physical deletion. There is a fallback path if scheduling fails.

2026-11-01

Batch migrating old website articles, is it more stable to import using a compressed package or a table?

The old site articles are moved in bulk, the choice between ZIP compressed package import and Excel table import depends on whether there are attachments and field structure: The migration of image static files and graphics goes through the compressed package, while batch creation of articles goes through field mapping. AnQiCMS also provides the import/archive import interface, which supports querying whether the title already exists, and can be checked before repeated import.

2026-11-01

Migrating from a hosting website building platform to a self-built content system, how to arrange the migration sequence to avoid losing indexing

Migrating in a fixed sequence ensures not losing indexing: First export the content list and make a complete backup, then use ZIP compression packages or Excel spreadsheets to batch import content. When importing, check for duplicate titles to avoid repeated搬运, and finally, set up 301 redirect mappings for old addresses and observe for two weeks. This article provides the key operational points and verification methods for each step, covering the backup scope of data and static files and the usage standards of the import interface.

2026-11-01