cache.lat
A cache that serves static HTML is extremely fast, but it has a hidden cost: if you don't know when to clear it, your visitors see old prices, outdated texts, or a promo banner that already ended. Purging well is as important as caching well.
Why purging matters so much
When a page is saved as an HTML file, the server delivers it without executing PHP or querying the database. That's exactly what makes it fast, but it also means WordPress doesn't "find out" that you changed something until the copy is regenerated. Two opposite mistakes are common:
- Purging too little: you edit a page and the change doesn't appear. The client writes asking why they see the previous promo.
- Purging too much: you empty the entire site on every small change, and the next visitor to each URL pays the cost of full generation again.
What to invalidate depending on the change
You edited a post or page
The bare minimum is that URL. But think about where else that content appears: the homepage if it lists latest posts, the category page, the author archive, and the feed. If the title or the excerpt changed, those lists also became outdated.
You changed the menu, a widget, or the footer
These elements are on every page, so a change here does justify regenerating the entire site. It's the typical case where a full purge is correct.
You changed the theme, the CSS, or activated a plugin
A change in appearance or scripts affects the HTML of every URL. Purge everything and regenerate after verifying that the site looks good in "no cache" mode.
You updated prices or stock in a store
Product pages can be cached, but the cart, checkout, and user account should never be served from a static copy. When you change a price, purge the product and the categories where it appears.
A simple workflow
- Make the change in WordPress and review it in a private browser window.
- Purge only what's affected: the edited URL and the listings that show it.
- If you touched something global (menu, footer, theme), purge everything and let it regenerate.
- Verify that the new page is actually served as a static copy. If you want to review how to do it, we have a guide on how to check that your cache works.
Regenerate after purging
Purging leaves the URL without a copy until someone visits it. On a low-traffic site, that can mean the first visitor (or a search engine bot) gets the slow version. That's why it's best to regenerate important pages as soon as you purge, instead of waiting for the next visitor. In how cache.lat works we explain that you can purge or regenerate from the plugin panel, and that generation is requested in small batches with a progress bar.
Watch out for campaign URLs
Parameters like utm_*, fbclid, or gclid shouldn't create a different copy for each ad click. If your system treats each variant as a new page, the cache fills up with duplicates and your ads end up hitting PHP. We already covered this in our post about campaigns with UTM and cache.
Frequent mistakes
- Purging the entire site every time a comment or a minor post is published.
- Forgetting the browser cache or a CDN in front of the site: you purge in WordPress and still see the old version.
- Not testing with a user session different from the administrator's.
- Caching dynamic pages (cart, internal search, POST forms) by mistake.
Conclusion
The practical rule: purge the minimum when the change is local, purge everything when it's global, and regenerate right away what gets the most traffic. If you want to see the details of each plugin setting, the documentation is the best starting point, and if you have a particular case you can write to us from the TuNegocioEnLinea contact page.