Performance and Caching

Outcome

You will know which hosted controls affect performance and what each one changes for day-to-day site behavior. You will also understand the caching layers a visitor request passes through, so you know which one to invalidate when something looks stale.

How Caching Layers Stack

A hosted request can be answered at several layers before it ever reaches PHP. Understanding the stack saves time when a change does not appear: the answer is usually that a layer above is still serving the old response.

flowchart TB
  U[Visitor browser] --> CDN[CDN edge cache]
  CDN -->|miss| WP[WordPress/PHP]
  WP --> R[(Redis object cache)]
  WP --> DB[(MySQL)]

• The browser holds static assets and sometimes HTML.
• The CDN edge serves a copy of the response close to the visitor.
• WordPress executes PHP only on a cache miss.
• Redis caches expensive database lookups so PHP does less work per request.
• MySQL is the source of truth and is the slowest layer to hit.

Available Controls

Page cache

The page cache stores the rendered HTML for anonymous visitors at the edge. Most posts and pages are served from here. Authenticated users (logged into WordPress) bypass the page cache so they always see fresh content.

• Purge the page cache after a content change that has not appeared after a few minutes.
• Expect a short repopulation window after a purge while the edge re-warms.
• Pages with personalized output should be excluded from the page cache rather than purged repeatedly.

Object cache (Redis)

Redis object cache stores the results of database queries and WordPress internal lookups. It is enabled for supported hosted sites and is the largest single performance win for content-heavy or plugin-heavy installs.

• Object cache is per-site and persists across requests.
• Plugin updates, option changes, and user role changes invalidate the relevant keys automatically.
• If a plugin misbehaves after a change, flushing the object cache is a safe first step.

Browser/CDN

Browsers and the CDN both honor cache-control headers on static assets. Images, CSS, and JavaScript are versioned so updates do not require manual invalidation in most cases.

• Hard-refresh the browser (or test in a private window) when you suspect the local cache is the issue.
• The CDN does not serve cached HTML to logged-in users.
• Long max-age on assets is expected and is what makes repeat visits fast.

Other Performance Controls

• Heartbeat behavior, including throttling or disabling it where appropriate. The WordPress heartbeat drives autosave and admin notifications, so do not disable it during heavy editing sessions.
• Revision limits for stored post revisions. Lower the limit if the database is growing quickly because of long edit histories.
• Image upload resizing controls. Large source images can be downscaled on upload to reduce storage and improve gallery performance.
• Redis object cache enablement for supported hosted sites.

When To Adjust These Settings

Use performance controls when the site is consuming unnecessary editor activity, storing more revision history than you want, processing oversized uploads, or needs object-cache support for heavier workloads. Change one setting at a time and watch the site for a day before changing the next; that way you know which change moved the needle.

My change isn't appearing

Work down the stack: hard-refresh the browser, then check whether the page is being served from the CDN edge cache, then purge the page cache, and only then look for a deployment or content issue. Most “the change did not save” reports turn out to be a cached response somewhere between the visitor and WordPress.

What Success Looks Like

• Editors still have the functionality they need.
• The site behaves predictably after configuration changes.
• Cache behavior and expectations are clear to the team.

Related Troubleshooting

Use Hosted Troubleshooting if the site still appears stale after the expected changes should be live.