The answers, before you have to ask.

It should already be gone. Saving a product, category, information page, manufacturer, option, attribute or review in the OpenCart admin fires an event that hard-deletes that item's own cached page — every language, currency and device variant of it — and marks the rest of the cache stale so listings rebuild on the next visit. If you are still seeing the old page, paste the exact address into Purge URL in Nitro's Cache section; it reports how many cached files it removed. If it answers that the URL is not in the cache, what you are looking at is your browser's own copy, not Nitro's.

Writes that bypass the OpenCart admin fire no OpenCart event, so nothing tells Nitro to drop those pages. The cron picks them up instead: every run compares each product's date_modified against what it last saw and purges the pages of anything that changed, plus anything that was deleted, then re-warms them in the same run. If you have no cron entry yet, that is the fix — the Cron tab prints the command. Until it runs, Purge URL or Clear Cache does it by hand.

Nitro writes a minified copy beside each of your theme's .css and .js files and regenerates it as soon as the source file is newer, and the ?v= on the URL is a hash of the minified content — so an ordinary edit appears on its own. The exception is bundling: a bundle is named after its sources' URLs and file sizes, so an edit that leaves a file exactly the same length — changing #fff to #eee, for instance — reuses the existing bundle. Press Clear Cache: it deletes every *.nitro.css, *.nitro.js and bundle directory under catalog/view, and they are rebuilt on the next page view.

Clear Cache, in Nitro's admin. It returns immediately however large the cache is: the cache is renamed aside so the store is logically clear at once, and the files are deleted afterwards — a little on the way out, the rest by the cron. If you need the disk space back this minute, Clear Cache + Reclaim Disk does the deleting there and then, which can take minutes on a large cache. Either button clears cached pages, cached query results and the generated CSS and JS together.

Paste the full address into Purge URL in Nitro's Cache section. It removes every cached variant of that page — desktop, mobile and tablet — and tells you how many files it deleted, or that the URL was not cached at all. If you are already looking at the page on the storefront with the speed panel on, its Purge this page button does the same thing. From code it is one call: \Nitro\Page::purge($url).

Two lines, anywhere OpenCart's constants are defined:

require_once DIR_SYSTEM . 'library/nitro.php';
(new \Nitro())->flush();

That clears the page cache, the query cache and the generated CSS and JS. It is exactly what Nitro's own hook into Journal3's Clear Cache button runs, so it is a well-travelled path. Put it in a small PHP script and schedule that if you want a clear on a timer. Nitro's own cron entry deliberately never clears: it prunes what has expired, trims the cache to your size cap and warms it back up, which is what you want on a schedule almost every time.

Twenty-four hours by default, with per-route overrides seeded at install: specials one hour, the home page six, categories and products twelve, manufacturers twenty-four, information pages a week. On top of that, stale-while-revalidate is set to one hour, so a page past that point is still served instantly while it rebuilds in the background — a visitor never waits for a rebuild. Expiry is staggered across the last fifth of each page's lifetime, so a cache warmed in one pass does not all fall due at the same moment. Catalog edits clear pages immediately regardless of any of this.

Serve WebP is on in every profile, so it is almost certainly already running. It needs GD compiled with WebP support — the Diagnostics tab has a GD WebP row that says plainly whether your PHP has it, and the option quietly does nothing if it does not. When it is on, a .webp is written next to each resized image as pages are visited or warmed, and the image URL in the HTML is rewritten to it wherever the file exists — so it works on any server, with no .htaccess content negotiation. Changing Image Quality deletes the existing .webp copies so they regenerate at the new setting, leaving the thumbnails themselves alone.