A WooCommerce store that runs perfectly with ten simultaneous visitors can go down with fifty. It's usually not the hosting's fault alone: it's almost always configuration decisions that nobody reviewed. These are the mistakes that repeat most often when traffic rises (a campaign, a Black Friday, a viral link).
1. Caching everything, even what you shouldn't
The first reflex is "enable caching on everything." In WooCommerce that breaks things: the cart, the checkout, and the customer account are personalized content and can't be served as the same file for everyone. If you see carts showing another person's products or prices that don't update, the cause is almost always a badly done exclusion.
- Exclude from the cache
/cart/,/checkout/, and/my-account/(with your site's slugs). - Respect the
woocommerce_cart_hashandwoocommerce_items_in_cartcookies: they indicate that this visitor has an active session. - Cache without fear the catalog, categories, blog, and home page, which are the bulk of the traffic.
2. Cart fragments that trigger AJAX requests
The famous ?wc-ajax=get_refreshed_fragments runs on every page to update the mini-cart. It's a request that bypasses the cache and reaches PHP and the database. With a lot of traffic, thousands of those requests are enough to overwhelm a shared hosting. If your theme doesn't need a mini-cart, disable the fragments; if it does need it, make sure it only loads when there are products in the cart.
3. Bloated database
WooCommerce sessions, expired transients, and product revisions pile up. A wp_options table with a lot of autoloaded data makes every request slower, cached or not. Check periodically:
- How many MB of autoloaded options are loaded on every page.
- Expired sessions and transients that were never cleaned up.
- Uninstalled plugins that left their tables and options behind.
4. Heavy queries in the admin and cron
WP-Cron is triggered by visits. During a traffic spike, tasks like syncing inventory, sending emails, or regenerating reports can run several times in parallel and compete with the customers who are buying. If you can, disable cron on visits and schedule it with a real server cron every few minutes.
5. Unoptimized images on product pages
A product page with six 3 MB photos weighs more than the entire rest of the site combined. It's the easiest mistake to fix and the one that impacts LCP (Core Web Vitals) the most on mobile. Upload images at the actual size they're displayed and in a modern format like WebP.
Where serving static HTML helps
For all public content (catalog, categories, blog, informational pages), serving a static HTML file prevents PHP and MySQL from working on every visit. That way the server's resources stay free for what is truly dynamic: cart and checkout. You can see how it works on cache.lat's how it works page and what requirements it asks for in the technical data.
Checklist before a campaign
- Test the full purchase flow in a private window, with the cache active.
- Confirm that cart, checkout, and my account are excluded.
- Check the database size and the autoload options.
- Move cron to a real server cron.
- Optimize the images of the products you're going to promote.
- Watch CPU and PHP process usage during a moderate load test.
If you have doubts about how caching fits into your store, the full documentation is a good starting point, and the TNL team answers questions on their contact page.
vaya revisando mi instalacion veo que no le he dado mantenimiento a la db podrian recomendar un plugin porque cache.lat no lo hace o si?
Carlos ya hemos integrado esa funcionalidad, espero puedas descargarte la última versión, y pruebes las últimas funcionalidades
creo que ha evolucionado y han entregado una nueva version deberia de funcionar
Es correcto José hemos agregado más funciones gracias por ser parte de nuestra comunidad
De hecho hoy he revisado y han integrado la limpieza de db , pueden probarlo o instalar la última versión del plugin , de nada
Tienes razón hemos agregado esa funcionalidad y un servicio de supervisión de rendimiento