Performance and caching
The Performance page manages Webcore's server-side caching features for a WordPress site. Page caching and object caching solve different problems and can be enabled independently.
Webcore Page Cache
Webcore Page Cache stores eligible anonymous WordPress responses at Nginx. A cache hit can be returned before the request reaches Apache, PHP-FPM, WordPress or MariaDB.
The Panel lets you enable or disable page caching, choose a WordPress or WooCommerce profile, set the cache TTL and set a per-site maximum cache size.
Requests that bypass page cache
Correctness takes priority over hit rate. Webcore bypasses the page cache for POST requests, requests with query strings, sensitive WordPress endpoints, logged-in sessions, commenters and password-protected content.
The WooCommerce profile also protects cart, checkout and account responses and recognises commerce/session cookies that must not receive shared cached content.
Additional path prefixes and cookie names can be configured when an application has personalised routes that Webcore cannot identify automatically.
WordPress invalidation
A managed WordPress integration invalidates the Nginx page cache when relevant WordPress content or configuration changes. This reduces the need to purge the whole cache manually after ordinary publishing changes.
The Performance page reports whether that integration is installed.
Cache purge
Purge Page Cache removes the site's disposable Nginx cache. Without preload, the next eligible anonymous requests rebuild entries naturally.
A diagnostic response header reports the page-cache decision as X-Webcore-Cache: HIT, MISS or BYPASS.
Cache preload
Preload is optional. When enabled, Webcore can warm the homepage and same-host URLs discovered from WordPress sitemaps after a purge. The crawl runs as a background task and is bounded to 200 URLs.
The Panel shows live preload state, attempted URLs, warmed and failed counts, the current URL, and start/finish timestamps. A running preload can be stopped from the Performance page.
Avoid stacked full-page caches
The Panel detects active WordPress page-cache plugins and warns when another full-page cache is active. Avoid running two independent full-page caching layers for the same site.
A plugin may still be useful for features such as asset or image optimisation when those functions can be separated from its full-page cache.
Redis object cache
Redis object caching stores reusable WordPress object-cache data in the node-local managed Redis service. It is not a replacement for Nginx page caching: Redis reduces repeated application/database work when WordPress still executes, while Nginx page caching can avoid executing WordPress entirely for eligible anonymous requests.
Each enabled site receives isolated Redis credentials and a site-specific key namespace. Redis is not exposed publicly.
When enabled, Webcore installs/configures the WordPress Redis integration and object-cache drop-in. The Performance page reports node availability, connection state and integration state and provides a cache flush action.
Choosing a cache strategy
For a conventional public WordPress site, start with Webcore Page Cache. Add Redis object caching when the workload benefits from persistent WordPress object caching, particularly where many requests still reach PHP and the database.
For WooCommerce, membership, booking or other highly personalised applications, use the appropriate cache profile and add exclusions for application-specific personalised paths or cookies where necessary.