Site Got Slower After Activating ForgeCache — Diagnostic Checklist

You activated ForgeCache expecting faster page loads, and instead TTFB went up, GTmetrix scores dropped, or visitors are complaining the site feels worse. Most of these reports trace to one of five layered causes — the cache isn’t actually serving, a managed host’s edge cache is intercepting before WordPress, a stacked second caching plugin is conflicting, you’re measuring a page type that ForgeCache deliberately doesn’t cache, or an upstream CDN is serving stale content. This doc walks each layer in order so you can identify the actual slow layer in under ten minutes.

The Five Causes In Order Of How Often We See Them

1. The page being measured isn’t cached by ForgeCache. Logged-in admin views, cart / checkout / account pages, search results, REST API endpoints, and any page with WooCommerce session cookies are excluded from page caching by design. Measure a page type that IS cached (e.g. the home page in incognito) before concluding.
2. A managed host is running its own edge cache (Kinsta, WP Engine, Pressable, Pantheon, SiteGround, Cloudways, Flywheel, GoDaddy Managed). ForgeCache writes pages to disk; the host’s edge cache serves a different (sometimes already-stale) copy. Wasted disk + cache-coherence confusion.
3. A second caching plugin is still active. WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache — ForgeCache will refuse to install its drop-in when it detects a foreign one. The result is that no cache plugin is actually working.
4. Critical CSS is taking 200–500ms to inline-render on every uncached page. If you enabled Critical CSS recently and it’s 50KB+, the inline-style block in <head> can make TTFB look worse on first paint.
5. An upstream CDN (Cloudflare etc.) is serving stale content from before you activated ForgeCache. Purge the CDN once after first activation.

Cause 1 — Is the Page Cache Actually Serving?

Before anything else, confirm ForgeCache is actually serving cached content on the page you’re measuring. ForgeCache exposes a response header that tells you definitively whether a request hit cache.

The diagnostic

Open an incognito / private browser window

This is critical — the page cache never serves logged-in users. If you’re measuring while logged into wp-admin in another tab on the same site, ForgeCache rightly bypasses cache for you. Test in incognito.

Visit your home page in incognito + check the Response Headers

DevTools → Network tab → reload the page → click the first request (the HTML document) → Headers tab → Response Headers. Look for:

X-ForgeCache: HIT — the page was served from disk cache. Fast path. If you’re still seeing slow TTFB, the issue is upstream (CDN / host edge cache) or in the cached HTML itself (Critical CSS too large, etc.).
X-ForgeCache: HIT (template_redirect) — cache hit, but via the slow path (the PHP-served fallback when the advanced-cache.php drop-in isn’t active). Indicates the drop-in installation failed or was overwritten. See cause 3.
No X-ForgeCache header at all — the page is not being page-cached. This is the most common slow-after-activation cause. Continue below to figure out why.

If no X-ForgeCache header: is the page on the exclusion list?

ForgeCache deliberately never page-caches: logged-in user views, POST requests, admin pages, AJAX endpoints, REST API endpoints, XML-RPC, feeds, robots.txt, favicon, trackback URLs, password-protected posts, 404 pages, search results, WooCommerce cart / checkout / account pages, any page with a WooCommerce or EDD cart cookie set, and pages where a known page builder editor query param is present (e.g. elementor-preview=). If the page you’re measuring matches any of those, the absence of a cache hit is by design.

If no X-ForgeCache header AND the page should be cacheable: enable debug mode

Add this to your wp-config.php file, near the top, just below the WP_DEBUG line:

define('FORGECACHE_DEBUG', true);

Reload the page in incognito and view source. With debug mode on, ForgeCache appends a HTML comment near the bottom of the page explaining what happened:  tells you the drop-in is missing; absence of any comment tells you the page didn’t go through ForgeCache’s output buffer at all (usually because something else is intercepting the request earlier — managed-host edge cache, a different caching plugin’s drop-in still in place, or an unrelated WP-level hook returning early). Remove the debug constant when finished — it adds an HTML comment to every page.

Cause 2 — Managed Host Edge Cache Conflict

If you’re on a managed WordPress host that operates its own page-cache layer (Kinsta, WP Engine, Pressable, Pantheon, SiteGround, Cloudways, Flywheel, GoDaddy Managed), running ForgeCache’s page cache on top creates two problems: wasted disk (ForgeCache writes pages that almost never serve because the host’s edge intercepts first), and cache-coherence confusion (when ForgeCache purges its disk cache on post save, the host’s edge has no idea and keeps serving stale content until its own TTL expires).

How ForgeCache tries to warn you

ForgeCache 2.1.16+ detects all eight of the managed-cache hosts above by their well-known constants and surfaces a dismissible admin notice on the ForgeCache dashboard. If you dismissed that notice without reading it (it’s easy to do), this is your reminder.

The fix — pick one of two paths

Path A: Turn off ForgeCache page caching, keep the optimization features

ForgeCache is more than page caching — it also handles minification, lazy load, Critical CSS, CDN integration, REST cache, image optimization, and the Page Optimizer. None of those overlap with what your managed host does at the edge. Disable page caching specifically: ForgeCache → Settings → Cache → Enable page caching → uncheck. Leave everything else on. You get all the asset-level wins without the conflict.

Path B: Disable your host’s edge cache, run ForgeCache exclusively

Some managed hosts let you disable their edge cache at the dashboard level (Kinsta’s “Cache” tab, Pantheon’s pantheon.yml config, etc.). If you want ForgeCache as the only page-cache layer, that’s a host-by-host setting — check your host’s docs. WP Engine and SiteGround typically don’t let you disable their edge cache, so Path A is the only option there.

Why ForgeCache doesn’t auto-disable on managed hosts

That would surprise users who explicitly want both layers (e.g. some agencies run ForgeCache for the asset features on hosts that don’t cache JSON / REST responses well). ForgeCache surfaces the situation with the dismissible notice and lets you decide.

Cause 3 — A Second Caching Plugin Is Still Active (or Was Recently)

ForgeCache 2.1.14+ refuses to install its wp-content/advanced-cache.php drop-in if a foreign one is already present — WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, etc. The activation error surfaces as an admin notice saying “Another caching plugin has installed wp-content/advanced-cache.php. Deactivate that plugin first, then re-activate ForgeCache.”

If you missed that notice OR deactivated the other plugin without uninstalling it, the foreign drop-in may still be in place — meaning ForgeCache’s settings UI works but no actual page-cache serving is happening on your site.

The diagnostic

Check the contents of wp-content/advanced-cache.php

Open wp-content/advanced-cache.php in your file manager / FTP / SSH. Read the first ~50 lines. Every major cache plugin tags its drop-in identifiably:

ForgeCache — comment block starting with ForgeCache Advanced Cache Drop-in
WP Rocket — WP_ROCKET_VERSION reference near the top
LiteSpeed Cache — LiteSpeed_Cache class reference
W3 Total Cache — w3tc / W3TC namespace
WP Super Cache — wp_super_cache namespace

If it’s NOT ForgeCache’s drop-in — remove it and reactivate ForgeCache

(1) Deactivate ForgeCache. (2) Delete wp-content/advanced-cache.php from your file manager. (3) In wp-config.php, look for the define('WP_CACHE', true); line — leave it if it’s there, ForgeCache will detect it. (4) Re-activate ForgeCache from WP Admin → Plugins. ForgeCache will install its own drop-in cleanly. (5) Test by checking for the X-ForgeCache: HIT header in incognito.

If it IS ForgeCache’s drop-in but the X-ForgeCache header is missing on cacheable pages

This is a different issue — the drop-in is installed but something is bypassing it. Most often a custom mu-plugin, a security plugin that disables certain HTTP routes, or PHP-FPM serving from opcache that hasn’t reloaded since you activated ForgeCache. Restart PHP-FPM (or reboot the host) and retest.

Cause 4 — Critical CSS Is Slowing Down First Paint

If you enabled Critical CSS recently and pasted a 50KB+ snippet, that snippet is now inlined in <head> on every uncached page. The HTML response is larger by exactly that amount, so TTFB on the first uncached request and the first paint timing both look worse than before.

On cached requests it’s less impactful (the cached HTML already includes the inlined CSS, served fast from disk), but on first request to a new page or any uncached page type the overhead is visible.

How to verify Critical CSS is the cause

WP Admin → ForgeCache → Settings → Optimization → check the Critical CSS field’s “Current size” display. If it’s > 20 KB, you’re paying that overhead on every first-paint. Either:

Regenerate a smaller Critical CSS. Most generator tools have a “mobile” / “simple” mode that produces 5–15KB instead of 50–100KB. The smaller version covers above-the-fold styles only.
Turn off Critical CSS entirely. Critical CSS is an aggressive Core Web Vitals optimization; if you don’t need the LCP improvement, run without it. The CSS will load via the normal stylesheets, paint will happen ~100ms later but TTFB stays clean.

Cause 5 — Upstream CDN Serving Stale Content

If your domain is fronted by Cloudflare (or any CDN that page-caches HTML), there’s a chance the CDN cached a version of your site from BEFORE you activated ForgeCache — including any HTML that was missing performance optimizations or had different markup. Your changes won’t be visible to visitors until the CDN’s TTL rolls over OR you purge it.

The fix

Once after first activation, purge your CDN cache. For Cloudflare specifically: dashboard → Caching → Configuration → Purge Everything. For BunnyCDN, the equivalent is in the pull zone settings panel. Other CDNs have a similar global-purge button.

If you’ve already connected Cloudflare to ForgeCache via the 2.1.18 integration, the Purge CDN cache now button at ForgeCache → Settings → Advanced → CDN Integration does the same thing one click. See Connecting Cloudflare to ForgeCache if you haven’t set up the integration yet.

Check the cf-cache-status header to see if Cloudflare is serving

In DevTools Response Headers, cf-cache-status: HIT means Cloudflare served from edge cache (likely stale if you just activated ForgeCache). MISS means Cloudflare asked your origin (where ForgeCache then ran). DYNAMIC means Cloudflare decided not to cache that URL (typical for logged-in / admin pages).

Still Stuck? Email Priority Support

If you’ve worked through all five causes and the site is still slower than before activation:

Email support@royalplugins.com with the diagnostic info below. Priority email support is included with your ForgeCache Pro license — typical response time is within 24 hours.

Information to include in your email

Your ForgeCache version + WordPress version + PHP version + hosting provider.
The X-ForgeCache header value from an incognito request to your home page (HIT, HIT (template_redirect), or missing).
Whether you saw the managed-host detection notice after activation (and whether you dismissed it).
The contents of wp-content/advanced-cache.php first 20 lines — we just need to see whose drop-in it is.
A list of active plugins from Plugins screen.
The specific page URL where slowness was observed + a before-vs-after measurement (PageSpeed Insights / GTmetrix / WebPageTest screenshots ideally).
Whether your domain is fronted by Cloudflare or another CDN, and whether you’ve purged it since activating ForgeCache.

Related ForgeCache docs

JS/CSS optimization broke my site — if the site is broken-but-not-slow rather than slow-but-functional.
WooCommerce caching issues — if the slowness is on a cart / checkout / account page (those are excluded by design).
Connecting Cloudflare to ForgeCache — the integration referenced in cause 5.
ForgeCache Documentation — back to the main support page.