How page caching works
OptiWave saves a ready-to-serve HTML copy of a public page. Eligible anonymous requests can receive that copy without rebuilding the page on every visit.
- Server rules: Apache, Nginx, or LiteSpeed can serve a valid file directly when the required rules are installed.
- PHP drop-in: requests that reach PHP can be served before WordPress fully loads.
- WordPress: uncached or excluded requests continue through normal rendering.
Which layer handles a request depends on your host and the request. A cache hit reduces server work; it does not guarantee a particular load time.
Choose when pages rebuild
Open OptiWave → Cache and find Cache Lifespan (Automatic Rebuild). The default is 10 hours; other choices are 24 hours, 7 days, and 30 days.
Publishing or updating content invalidates affected cached pages. Use a shorter interval if content also changes outside normal post updates. WordPress cron must run for scheduled rebuilding to make progress.
Separate mobile cache
Separate Cache for Mobile is off by default. Keep it off for responsive themes that send the same HTML to every device. Turn it on only when your theme sends different page markup to phones.
OptiWave then stores desktop and mobile versions separately:
wp-content/cache/optiwave/example.com/about/index.html
wp-content/cache/optiwave/example.com/about/index-mobile.htmlKeep personal pages out of shared cache
Keep Bypass for Logged-in Users enabled while testing. OptiWave also protects requests with recognized login, password, and shopping-session cookies.
Use Exclude Pages from Cache for additional private or dynamic paths, one per line. For example:
/members/*
/booking-confirmation/*Use Bypass Cache for Cookies for custom personalization cookies. When WooCommerce is active at activation, its cart, checkout, and account paths are added to the exclusions. Check custom store paths yourself.
Cache pages with query parameters
Separate Cache for Query Parameters accepts exact parameter names, one per line. It is empty by default. Add a name such as lang only when its value changes the public page content and is safe to share.
Recognized tracking parameters can reuse an existing clean-page cache. Unknown or sensitive parameters bypass caching. A configured name takes precedence over tracking normalization and produces separate cache versions for its values.
Preload or refresh?
| Dashboard action | Use it when |
|---|---|
| Start Preloading | You want to generate ready pages without clearing the existing cache. |
| Purge & Preload All | You need to clear old local pages and rebuild them; connected Cloudflare invalidation also applies. |
The preload queue runs in bounded background batches. If it stalls, check its failure details, WordPress cron, and whether your host or firewall allows the site's own requests.
Check a cache hit
Open a public page in a private window, then reload it after preload completes. In the browser's Network panel, select the page document and look for X-OptiWave-Cache: HIT. MISS indicates a request handled without a ready cache.
Nginx direct serving can report X-OptiWave-Source: Nginx; the PHP drop-in reports PHP. Proxies can alter headers, so confirm your hosting setup if they are missing. Logged-in pages, excluded URLs, and personalized requests are expected to bypass shared cache.
See the page cache screen
