Some functionalities breaks when active

I’ve spent many hours over multiple days using WP Super Cache and trying to resolve a persistent issue on my WordPress + WooCommerce site where the front-end becomes unstable specifically when any page caching is enabled for anonymous/incognito visitors, and I’m at the point where I need a developer-level diagnosis of the root cause. Without caching, everything behaves normally. With caching enabled, the site intermittently renders UI in an incorrect state and various elements break or duplicate, and the behavior is hard to stabilize even after repeated cache purges.

The most visible symptom is that the theme’s off-canvas/mobile panel (the drawer that is normally only used for mobile navigation) sometimes appears open/visible on desktop for logged-out/incognito visitors. When this happens, the panel shows the same mobile navigation content that should only appear after tapping the hamburger icon on mobile. This “panel-open” state can persist while navigating between pages, and sometimes it gradually “self-corrects” after multiple reloads, but it’s not consistent. Importantly, this problem happens primarily for anonymous/incognito visitors; when I’m logged into wp-admin, the issue often does not appear, which strongly suggests a caching-related difference in script execution order, asset delivery, or initial state.

At the same time, other front-end components become unreliable when caching is enabled: category grids shift/corrupt, category pages sometimes lose their filter UI entirely, and in other cases the filter or grid UI appears to be duplicated or re-initialized multiple times while navigating. It feels like JavaScript-based components are being initialized twice (or being initialized on partially styled markup), leading to layout drift, missing elements, or duplicated UI. These issues tend to appear more frequently after moving across multiple category pages and then back/forward, again primarily in incognito/anonymous mode.

I have tested multiple caching approaches and the same pattern persists whenever anonymous page caching is active. I tried the host’s built-in caching controls, then Cache Enabler, then W3 Total Cache, and then WP Super Cache. With W3 Total Cache, enabling Minify/Combine (JS/CSS) made the UI corruption worse, so I disabled Minify and any lazy/delay/defer features and kept only basic page cache + browser cache. With WP Super Cache, I enabled caching for anonymous visitors, disabled caching for logged-in users, set rejected URLs for WooCommerce-sensitive pages (cart/checkout/account), and configured it to avoid caching URLs with GET parameters. Even with conservative settings, the “off-canvas visible on desktop” and “filter/grid corruption” symptoms still occur as soon as caching is enabled.

I also previously changed WooCommerce settings that seemed to affect caching behavior (notably disabling WooCommerce’s order attribution/source tracking feature that sets attribution cookies), and I repeatedly purged caches and flushed permalinks. Additionally, some of the functionality that often misbehaves (especially parts of the header/menu behavior and some UI behavior) is implemented using Code Snippets (custom snippets injected into the site rather than coming directly from the theme or a single plugin), which may be contributing to inconsistent initialization depending on whether the request is cached or not.

I want to be clear that I’m looking for a complete and technically correct solution to make the site compatible with page caching. Suggestions like “just don’t cache the homepage” or “don’t cache category pages” are not acceptable as a real fix, because those are some of the most important pages for performance and SEO; disabling caching there would defeat the purpose and significantly impact site speed. I need to understand why the site behaves differently under cached anonymous responses.

Right now, the current failure mode is primarily on mobile: the intended mobile navigation (provided by Superfly Menu) does not load/activate, and instead the site falls back to the theme’s mobile menu, and additionally the category filter (coming from a separate plugin) does not appear on mobile. If I change configuration to try to force the “correct” Superfly Menu behavior to appear on mobile, the issue flips to the other side: the desktop experience becomes unstable again, with Superfly Menu content appearing on the left as if it were in mobile mode and sometimes looking like it is always open. This “trade-off” strongly suggests a state/initialization problem (possibly related to cached HTML vs. deferred assets, conditional loading of scripts by device detection, or JS executing twice or out of order).

• This topic was modified 2 months, 1 week ago by willpardo.