documentation

How cache.lat works, from install to technical detail

This guide covers what the plugin does step by step. For short answers, check the FAQ.

1. Installation and activation

Upload the cache-lat-client folder to /wp-content/plugins/ (or install it from the zip in WordPress's plugin screen) and activate it. On activation, the plugin creates its cache folder, installs its rules in .htaccess, and checks whether another full-page caching plugin is active. Nothing is registered against the cache.lat server at that point — that only happens once you open the "cache.lat" menu in your dashboard and confirm the detected domain.

The free plan doesn't require an email or password: the site is identified by its domain. If you later buy a license, you activate it with the site key and activation key you receive by email from TuNegocioEnLinea.net.

2. Generating and updating the cache

From the panel you choose which pages to cache (free plan: up to 10) or "whole site" with exclusions (with a license). The "Generate/update cache" button starts a job that processes pages in batches: the server fetches several pages in parallel and adjusts the batch size based on how fast your own site responds. Speed is the same with or without a license: what changes is how many pages you can cache.

The progress bar shows pages processed, an estimated time, and, once finished, the average time per page — useful for spotting whether your hosting itself is responding slowly, independent of cache.lat.

If you close the tab midway, the job keeps moving forward on the server alone (chained to WP-Cron) and resumes the progress bar if you reopen the panel. There's also an "Abort" button to cancel a job in progress: whatever was already generated is kept.

3. Automatic content freshness

cache.lat detects content changes and acts differently depending on scope:

• Targeted changes (publishing, editing, unpublishing or deleting a post/page/product, a stock change, an approved comment, a category change): the affected static file is instantly cleared and regenerated, without touching the rest of the site.
• Site-wide changes (menu, theme, customizer, widgets): the whole site is marked for regeneration, without deleting what already exists first (so the site isn't left without cache while it regenerates).
• Scheduled refresh: optional, every 6h, 12h, 24h, 7 days, or monthly, via WP-Cron, in short steps to avoid long waits on large sites.

4. Image optimization (AVIF/WebP)

From the panel you can convert your media library to AVIF or WebP (automatic format, or forced to one of the two, with quality control). It uses Imagick or GD, whichever your hosting has available; a new file is kept only if it's smaller than the original, and both the original file and every size WordPress generates (thumbnail, medium, large...) are converted.

In the generated HTML, images with an available AVIF/WebP version are rewritten to <picture> with each format under its own URL — so it doesn't depend on the browser or a CDN in front of your site respecting Accept-header negotiation, which many CDNs ignore in practice.

Images always stay on your own server; they're never uploaded to cache.lat's infrastructure.

5. Page optimization

Configurable from the panel, applied while generating each page (at no cost to your hosting — it's done on the cache.lat server before saving the final HTML):

• Lazy-loading of images and iframes, respecting the main visible image on load (it's not lazy-loaded, to avoid hurting perceived speed).
• font-display: swap and preconnect for Google Fonts, so text doesn't stay invisible while fonts load.
• Deferred JavaScript, always excluding jQuery, WooCommerce, payment gateways and reCAPTCHA (so checkout and forms don't break).
• Conservative HTML minification: only collapses whitespace between tags, never touches comments or the contents of <script>/<style>/<pre>.
• CSS combining and minification (off by default, opt-in): only joins consecutive stylesheets in the HTML that share the same origin and media attribute; if one fails to fetch, that batch is left untouched.
• Compression: each page is also saved as .gz and .br (Brotli) if the server supports it, serving the best variant based on what the browser accepts.

6. The .htaccess file

cache.lat installs its own block in your WordPress .htaccess to serve the static HTML instead of executing PHP, respecting: non-GET requests, admin session cookies (it never shows the cache to a logged-in user), and the bypass headers the engine itself uses when regenerating. The panel has "Repair .htaccess" (with an automatic backup of the previous file) and "Check permissions" buttons, and runs both diagnostics automatically after every generation.

7. Compatibility with other caching plugins

cache.lat detects whether you have another full-page caching plugin active (LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, WP Fastest Cache, SiteGround Optimizer, Breeze, Cache Enabler, Comet Cache, Swift Performance, WP-Optimize, Hummingbird) on activation and on every panel load. If it finds one, it shows a notice and switches to "safe mode": it keeps generating and serving the static HTML, but turns off its own font, JS, minification and image optimizations to avoid mixing two different manipulations on the same page. Your preferences stay saved and resume on their own once only one caching plugin remains active.

8. Plans and licenses

The plugin is always free; a license only removes the 10-page-per-site limit and enables "whole site" mode with exclusions. There are two types: WordPress (no WooCommerce) and Advanced (with WooCommerce — shop, products and categories); the license decides it, the plugin is the same. It lasts one year from activation on a site, not from purchase. Selling and managing licenses is exclusive to TuNegocioEnLinea.net — see pricing and our refund policy.

9. What never gets cached

Cart, checkout, "My account", and any page viewed with an admin session cookie are always excluded from generation, with no exceptions and no configuration needed.

10. Using a CDN (Cloudflare, bunny.net and others)

cache.lat is compatible with a CDN or proxy in front of your site. It works because the static HTML is served by your own hosting's Apache, without PHP; a CDN only forwards or caches those responses. AVIF/WebP images are rewritten to <picture> (they do not depend on the Accept header) and the .br/.gz files travel with their Content-Encoding, so a CDN does not break them. The plugin's calls to cache.lat do not go through your site's CDN. There are three points worth taking care of:

1. Keep the CDN from caching the HTML. To generate each page, cache.lat requests it from your site with the X-TNL-Bypass: 1 header to receive the live version, and a CDN does not understand that header: if it has a copy at the edge, the engine builds the cache from an old copy and pages "do not update". The static HTML goes out with Cache-Control: public, max-age=3600, must-revalidate, so a CDN that honors the origin (bunny.net does by default) may keep it for up to an hour. Cloudflare does not cache HTML by default, except with "Cache Everything" or APO. Recommended: let the CDN serve only images, CSS, JS and fonts; the HTML already comes from your hosting without PHP, so caching it at the edge adds almost nothing.
2. Keep the CDN from blocking the cache.lat engine. The engine is a server with no browser (User-Agent CacheLat-Generator). With Bot Fight Mode, a JavaScript challenge or WAF rules, the CDN may hand it a verification page instead of your page and generation fails with a 403 or 503. Create a rule that allows that User-Agent (or the cache.lat server IP) and skips the challenges.
3. Keep any cache rule from reaching dynamic pages. With "Cache Everything" and cookies ignored, a CDN could cache the WooCommerce cart, checkout or account; and if it ignores the query string, serve the same page for searches and "add to cart". The plugin already avoids this at the origin, but a misconfigured CDN breaks it from the outside: exclude wp-admin, cart, checkout, my-account and every URL with a query string (except utm_*), and respect the WooCommerce cookies.

Cloudflare: turn off Rocket Loader (it clashes with the plugin's deferred JS) and do not combine cache.lat with APO (Automatic Platform Optimization), which is another full-page HTML cache. The CDN's image optimizations, such as Polish or Mirage, break nothing but repeat the plugin's work. bunny.net: set up the pull zone for images and static resources; if the HTML goes through it, lower its TTL or turn its cache off; the image Optimizer is optional and redundant with AVIF/WebP.

What cache.lat does not do today: it does not purge the CDN when it regenerates or purges the cache (the edge copy updates when its TTL expires) and it does not detect whether a CDN sits in front of your site.

11. Support

For technical questions about the plugin, check this documentation and the FAQ first. For purchases, billing or license support, contact TuNegocioEnLinea.net directly.