Themeisle Docs

Appearance

Troubleshoot File Optimization and PageSpeed Verification ​

This guide covers common troubleshooting scenarios when using Super Page Cache Pro file optimization settings: Asset Manager exclusions not appearing in PageSpeed Insights, missing CSS minification controls, JS defer with no visible effect, confusing results when running SiteGround CDN alongside Cloudflare, and 404 errors for minified CSS or JS files after changing minification in another optimization plugin.

In this article

Verify Asset Manager changes before retesting PageSpeed ​

After disabling a script or style in the Asset Manager, the change will not be visible until you purge the page cache. PageSpeed Insights may also return a stale result if it reads a previously cached response. Follow these steps to confirm the change is active before retesting:

  1. In your WordPress dashboard, go to Super Page Cache > Dashboard and click Purge Everything.
  2. Open an incognito/private browser window.
  3. Open DevTools > Network.
  4. Reload the page you want to test.
  5. In the Network tab, search for the script or style URL you disabled (for example, the Google Maps API URL).
    • If the asset is absent from the request list, the exclusion rule is active.
    • If the asset still appears, check that the rule is saved and that you purged the correct cache layer.
  6. Click the main HTML document request and inspect its response headers. Confirm:
    • X-WP-CF-Super-Cache-Active: 1 — Super Page Cache served the page.
    • X-Wp-Spc-Disk-Cache: HIT — the disk cache was used.
    • CF-Cache-Status: HIT — Cloudflare served the response from its edge cache.
  7. Run the plugin's built-in Test Cache tool on the Dashboard to confirm caching is active.

📝 Note: If any header shows MISS or EXPIRED, reload the page once or twice to let Cloudflare populate its edge cache before retesting.

Once you have confirmed the asset change is active in the Network tab, you can run PageSpeed Insights for a reliable score.

📝 Note: PageSpeed Insights can return scores based on cached crawl data, particularly for recently changed pages. It is not an immediate real-time validation tool. After a cache purge, verify your changes are live using the browser Network tab first, then use PageSpeed Insights to measure the score impact.

CSS optimization expectations ​

Super Page Cache Pro includes Remove Unused CSS, which strips CSS rules that are not used on a given page. However, Super Page Cache Pro does not currently provide CSS minification or CSS grouping (combining multiple stylesheets into one file).

If you specifically need CSS minification or file combining, use a dedicated optimization plugin such as Autoptimize or Asset CleanUp. Be careful not to enable page caching in two plugins at the same time — keep page caching handled only by Super Page Cache.

📝 Info: Remove Unused CSS reduces CSS payload size by removing unused rules. CSS minification removes whitespace and comments from files. CSS grouping combines multiple files into one request. These are separate operations and require separate tools.

Why JS defer/delay may not change every script ​

Defer Javascript and Delay Javascript do not affect all scripts on every page. Certain script types are intentionally skipped:

  • Inline scripts (JavaScript written directly in the page HTML rather than loaded from a file) are not deferred or delayed by default.
  • Module scripts (type="module") are natively deferred by the browser and are not processed by the plugin.
  • Essential scripts — some third-party scripts, payment widgets, or anti-fraud libraries actively resist deferral and may revert to synchronous loading.
  • Scripts excluded via Exclude JS — any handles or URLs you add to the exclusion list are skipped intentionally.

If deferring or delaying JavaScript appears to make no visible difference in PageSpeed Insights, verify using the browser Network tab that JS files are actually being loaded deferred. If the change breaks menus, forms, carts, sliders, maps, or other interactive elements, use Exclude JS to exempt the affected scripts, or use Exclude Pages to disable JS optimization on specific URLs.

Fix broken layout, CSS, or JavaScript after enabling file optimization ​

Remove Unused CSS, Defer Javascript, and Delay Javascript are powerful optimizations, but they change how your styles and scripts are delivered. Remove Unused CSS serves only the styles it detects on each page and restores the rest on first interaction, so a style the analyzer misses can make the initial render look broken. Delay and Defer Javascript hold scripts back until later, so scripts an element needs immediately can stop working. The result can be broken layout, missing fonts or colors, or non-working menus, sliders, carts, forms, maps, or other interactive elements.

Because each feature affects different assets, enable them one at a time and check the site after each one. This makes it much easier to tell which feature caused a problem.

If your site breaks after enabling one or more of these features, follow this recovery workflow:

  1. Go to Super Page Cache → Settings → Files and turn off the optimization you most recently enabled (Remove Unused CSS, Delay Javascript, or Defer Javascript).
  2. Go to Super Page Cache → Dashboard and click Purge Everything.
  3. Open an incognito/private browser window and reload the page. Confirm the site looks and behaves correctly again. If it does, the feature you disabled caused the problem. If it does not, repeat steps 1–3 for the next feature.
  4. Re-enable that feature, then identify the specific asset or page that breaks. Open DevTools → Console to spot JavaScript errors, and DevTools → Network to find the CSS or JS file involved in the broken element.
  5. Add a targeted exclusion instead of leaving the whole feature off:
    • For broken styling, add the stylesheet to Exclude CSS, or add the page path to Exclude Pages under CSS Optimizations.
    • For broken scripts, add the script to Exclude JS, or add the page path to Exclude Pages under Javascript Optimizations.
  6. Click Purge Everything again, then reload the page in an incognito window to confirm both the breakage is fixed and the optimization is still applied elsewhere.

What to exclude ​

When you need to add an exclusion, start with the assets most likely to be affected:

  • CSS: theme or page-builder stylesheets, animation libraries, and CSS that is loaded conditionally by JavaScript.
  • JavaScript: slider, carousel, menu, cart, form, map, and other interactive scripts, plus third-party widgets.
  • Whole pages: pages with heavy dynamic content, custom JavaScript rendering, or third-party embeds that are hard to isolate to a single file.

For the full list of exclusion options, see CSS Optimizations.

When to exclude vs. disable the feature ​

  • Exclude the affected file or page when only a few assets or pages break. This keeps the optimization active everywhere else, so you keep most of the performance benefit.
  • Disable the feature when many assets or pages break, or when you cannot identify which asset is responsible. A site that is fast but broken is worse than a site that is slightly slower but correct.

📝 Note: PageSpeed scores may not improve immediately after enabling these features. Optimized CSS profiles are generated as pages are visited, and PageSpeed Insights can read cached crawl data. Purge the cache, confirm your changes are live in the browser Network tab, then retest. See the verification steps at the top of this guide.

Avoid conflicting CDN layers ​

Running SiteGround CDN and Cloudflare CDN (or Cloudflare page caching) at the same time creates a layered cache stack that can make purging and verification confusing. When both layers are active, a purge in Super Page Cache may clear one layer but not the other, so stale content can still be served and test results will be inconsistent.

Recommendations:

  • Choose one CDN layer: either Cloudflare (recommended if you use the Super Page Cache Cloudflare integration) or SiteGround CDN — not both.
  • The Super Page Cache > Settings > Third Party > SiteGround SuperCacher integration is specifically for server-cache purge synchronization with SiteGround's server-side cache. It is not required if you are already using Cloudflare for CDN delivery.
  • If you deliberately use both layers, you must manually purge each one separately and verify headers from each layer before drawing conclusions about cache behavior.

⚠️ Warning: Using SiteGround CDN and Cloudflare simultaneously can produce misleading headers during verification. For example, CF-Cache-Status: HIT may indicate Cloudflare served a response that SiteGround CDN had already cached, making it difficult to determine which layer actually delivered the page.

Fix 404 errors for CSS or JS files after changing minification ​

If your site suddenly loses styling, has broken scripts, or shows 404 or net::ERR_ABORTED 404 errors for minified CSS or JavaScript files in the browser DevTools > Network tab, the cause is usually stale cached HTML rather than a fault in Super Page Cache.

This commonly happens after you enable or disable CSS/JS minification in another optimization plugin, such as SiteGround Optimizer. When minification is toggled, the previously generated minified files are removed or served from new paths, but cached pages still reference the old file URLs. Until every cache layer is refreshed, visitors are served HTML that points to files that no longer exist.

On a typical SiteGround and Cloudflare setup, the stale HTML can be held in three places at once: the Cloudflare edge cache, the Super Page Cache disk cache, and the SiteGround server cache. Clearing only one of them leaves the others serving the broken references.

To fix it, purge every active cache layer, then verify:

  1. In your WordPress dashboard, go to Super Page Cache > Dashboard and click Purge Everything. This clears the plugin's disk cache and the Cloudflare cache it manages.
  2. Purge the SiteGround server cache separately, from SiteGround Optimizer or your SiteGround hosting dashboard. Purge Everything does not clear it unless you have enabled the SiteGround SuperCacher integration described in the note below.
  3. If you manage Cloudflare outside the plugin, purge the Cloudflare cache there as well.
  4. Open an incognito/private browser window, open DevTools > Network, and reload the page. Confirm that the CSS and JS requests now return 200 instead of 404.

📝 Note: Enabling Super Page Cache > Settings > Third Party > SiteGround SuperCacher synchronizes purges, so clearing the Super Page Cache cache also clears the SiteGround server cache. This reduces the chance of one layer serving stale HTML after an asset change.

⚠️ Important: Super Page Cache also detects SiteGround Optimizer and other caching or optimization plugins and shows a Multiple Caching Plugins Detected notice whenever one of them is active. This notice is based on the plugin being active, not on which of its features you have enabled, so it can appear even when you use SiteGround Optimizer only for asset optimization. Keep page caching handled by a single plugin, and purge every layer after changing minification or other optimization settings.

Was this helpful?