Skip to main content

The Workflow Mistake

The most common performance optimization mistake is testing changes while caches are still serving old HTML/CSS/JS. You end up debugging the cache, not the site.

Why It Happens​

In a typical WordPress stack, multiple layers can cache or transform output:

  • CDN cache (Cloudflare)
  • page cache (LSCache)
  • PHP bytecode cache (OPcache)
  • browser cache

If you change a setting (like "delay JS"), you can easily be looking at a previous version from one of those layers.

The Fix (Make Testing Deterministic)​

You need a workflow where:

  • you can see your change immediately
  • you can roll back quickly
  • you can attribute cause and effect

A Cache-Safe Testing Loop​

one-change-loop.txt
1) Change ONE setting
2) Hard refresh and verify the change is present
3) Check layout and critical flows
4) Check console/network errors
5) Log the result
6) Keep or revert
caution

Do not change multiple settings at once. If something breaks, you lose attribution.

  1. Set up a safe testing environment (staging preferred).
  2. Capture a baseline on representative URLs.
  3. Make one change at a time, and log it.
  4. Re-enable cache layers one at a time and verify.
note

The goal is not "never purge cache". The goal is to purge intentionally, only when you need it, and to always know which layer you are testing.

One Tool Per Feature​

Pick a single owner per feature (page cache, CSS optimization, JS optimization). Duplicating the same feature across multiple plugins is one of the fastest paths to broken layouts and unpredictable results.

Checklist​

  • Staging exists or a safe test mode is defined.
  • Baseline captured before changes.
  • One-change loop followed.
  • A change log exists (what changed, why, and what happened).
  • Cache layers are re-enabled one at a time with verification.

What's Next​