Cookies that break the WordPress cache and how to detect them

You installed a caching plugin, ran the test, and the site is still slow. Often the cause is not the plugin configuration but something simpler: a cookie that tells the server "this visit is special, don't serve it from cache." Understanding which cookies break the cache saves you hours of diagnosis.

Why cookies affect the page cache

A page cache stores the already-generated HTML and delivers it to all visitors without running PHP or querying the database. That is only safe if the page is the same for everyone. When the browser sends certain cookies, the system assumes the content may be personalized (a cart, a logged-in user, a commenter) and skips the cache so as not to show one person another person's data.

The problem appears when an unnecessary cookie triggers that behavior for anonymous visitors who would actually see the same page.

The cookies that most often cause problems

• WordPress user sessions (wordpress_logged_in_*): it is correct that they skip the cache. But if you browse your own site while logged in, your speed tests do not represent what a visitor sees.
• Comment cookies (comment_author_*): they are stored when someone comments and can cause that person to stop receiving cached pages.
• WooCommerce cookies (woocommerce_items_in_cart, woocommerce_cart_hash): necessary for the cart, but they should only affect dynamic pages (cart, checkout, my account), not the entire site.
• Cookies from custom plugins: popups, A/B testing, geolocation, or affiliate programs that use PHP's session_start() and send a PHPSESSID cookie on every page.
• Campaign cookies: some marketing tools generate them server-side and make them reach every visit.

How to detect if a cookie is costing you the cache

1. Look at the response headers

Open the browser's developer tools, Network tab, and check the first request for the document. See if the server responds with a Set-Cookie header on a page that should be public. If the response from a public homepage tries to create a cookie, something on your site is generating sessions where it shouldn't.

2. Test in a private window

A private window brings no previous cookies. If the site responds fast in private mode and not in your normal browser, the culprit is a stored cookie. If it is slow in both, the problem is something else.

3. Deactivate plugins one by one in staging

If you suspect a plugin that opens PHP sessions, deactivate it in a test environment and compare the headers. It is the most direct way to find the culprit without touching production.

How to fix it

• Limit the scope: cart or session cookies should only act on the URLs that are truly dynamic.
• Replace what you don't need: if a plugin opens a PHP session on every page just for a minor feature, look for an alternative or load that feature via JavaScript.
• Move personalization to the browser: the "Hello, Ana" greeting or a cart counter can be requested via JavaScript after the page loads, so the base HTML remains the same for everyone.
• Review your cache exclusion rules: a list of cookies that "prevent cache" that is too broad is a frequent cause of low hit rates.

A different approach: static HTML

With a system that serves the page as a static file, the decision of what is cached and what isn't becomes much clearer, because each public URL is a file. If you are interested in how that approach works, you can read the explanation in how cache.lat works and the details on the technical data page. For configuration questions, the documentation is the best starting point.

Quick checklist

• Test your homepage in a private window and check whether there is a Set-Cookie.
• Identify which plugin creates each cookie you see.
• Exclude from cache only what is truly dynamic.
• Move personalization to JavaScript whenever possible.
• Repeat the test after each change, not at the end.

If your site is still not taking advantage of the cache and you can't find out why, write to us and we'll review it together.