When a WordPress site feels fast in incognito mode but noticeably slower in a regular browser or while logged in, the difference can point directly to a caching problem. In this case, the frontend was performing normally for uncached visitors, while backend requests and regular-browser sessions felt sluggish.
The investigation found two important factors: WordPress was loading a relatively heavy stack of 32 active plugins on backend requests, and a stale browser cookie was causing certain sessions to bypass cache entirely. Once the cookie-related cache bypass was fixed, regular browser loads were expected to perform more like incognito sessions.
Issue background
The site had recently migrated to a WP Cloud hosting environment under the client’s own account. After the migration, users reported that the site felt slower than usual, including when making updates in the WordPress admin area.
An activity review also showed several recent plugin updates, including WP Rocket and Yoast SEO, along with updates to Yoast Duplicate Post, a maintenance plugin, Advanced Custom Fields, Site Kit, TablePress, Popup Box, Schema, and Redirection. A Freshy Mailgun plugin had also recently been added and activated.
Those recent changes were worth reviewing because caching and SEO plugins can trigger background processing after updates. However, the task did not document any fatal PHP errors associated with the slowdown.
Diagnosis
The first technical review showed that the frontend was actually performing well for normal visitors, while WordPress admin and other backend requests were consistently slower.
One contributor was the size of the active plugin stack. The site was running 32 active plugins, and every backend request required WordPress to initialize that stack. That added server-side processing overhead and helped explain why the admin area felt heavier than the public-facing site.
The most useful diagnostic clue appeared when performance was compared across browser states. The site performed very well in incognito mode but still felt slow in a regular browser or logged-in session.
That difference strongly suggested that the issue was not primarily caused by page images or artwork. Instead, the investigation found that affected browsers were carrying a stale cookie that was bypassing the cache.
With cache bypassed, WordPress had to generate requests dynamically rather than serving the faster cached response. This made the site feel slow even though an incognito browser, which did not have the stale cookie, performed well.
Resolution steps
The documented troubleshooting process provides a useful workflow for similar WordPress performance problems:
- Compare incognito and regular-browser performance. If a site is fast in a private window but slow in a normal browser, cookies, sessions, or cache exclusions should become a priority in the investigation.
- Separate frontend and backend symptoms. In this case, public frontend performance was acceptable, while backend requests were consistently slower. That helped narrow the issue to server-side WordPress processing and caching behavior.
- Review the active plugin stack. The site was running 32 active plugins. A large plugin stack does not automatically mean a plugin is faulty, but it increases the amount of PHP and WordPress code that may need to initialize on uncached backend requests.
- Review recent plugin changes. Recent updates to WP Rocket, Yoast SEO, and other plugins were checked as possible contributing factors because update-related cache purges, preload operations, or background processing can temporarily affect performance.
- Check for browser-state cache bypasses. The key finding was a stale cookie in affected browser sessions. That cookie caused requests to bypass cache, which explained why regular sessions behaved differently from incognito sessions.
- Correct the stale-cookie behavior. Once the cache-bypassing cookie issue was fixed, regular browser loads could use the site’s cache normally again.
- Retest under the same conditions. After the fix, performance should be checked in both regular and incognito browser sessions to confirm that the discrepancy has been eliminated.
This type of testing is especially useful with WP Rocket or other WordPress caching systems because cache behavior can vary based on login state, cookies, and browser sessions.
Final outcome
The investigation confirmed that the WordPress backend carried additional overhead from a 32-plugin stack, but the browser-specific slowdown was traced to a stale cookie that bypassed cache. After that cookie behavior was corrected, regular browser sessions were expected to load as quickly as incognito sessions.
The broader troubleshooting lesson is simple: when a WordPress site is fast in incognito mode but slow in a normal browser, do not assume the problem is image size or frontend design. Compare caching behavior first. Cookies and session state can silently force otherwise cacheable requests through the full WordPress application stack.
If your WordPress site is fast for some visitors but slow for logged-in users or regular browser sessions, contact Freshy. Our WordPress team can investigate WP Rocket, cache bypasses, cookies, plugin overhead, and other server-side performance issues.
