Documentation

Celeris stores each page as a file and lets the server return it, so a visitor gets HTML without WordPress being started. This page covers installing it, making it serve as early as possible, the settings that matter, and what to do when something looks wrong.

Install and activate

1. Download the archive from your account. It already carries your license key: nothing to paste afterwards.
2. Plugins › Add New › Upload Plugin, choose the archive, install, activate.
3. Open Celeris › Status. Four checks must be green. If one is not, click Repair the installation.
4. Measure. Celeris › Measurements fetches the same page twice, once through the cache and once bypassing everything.

Nothing runs without an active license: the cache and every optimisation stay off until a key is accepted. Your settings are kept meanwhile, so everything starts at once when the license is activated.

The four checks

• Drop-in installed. A small file, wp-content/advanced-cache.php, that answers before WordPress loads.
• WP_CACHE active. A line in wp-config.php telling WordPress to use that file.
• Server rules written. On Apache and LiteSpeed they go in .htaccess automatically; on nginx you paste one block yourself (below).
• Preloading. After a full purge, Celeris refills the cache instead of waiting for visitors.

Repair the installation rewrites all of them. It is safe to click at any time.

Serving before PHP

There are three places a cached page can be found, and the earlier the better: the web server, the PHP drop-in, or WordPress itself. Celeris uses the earliest one available.

Apache and LiteSpeed

Nothing to do. The rules are written to .htaccess on activation. On LiteSpeed, Celeris also switches off LiteSpeed’s own page cache: two caches on the same pages eventually serve a stale copy, and the one that purges with WordPress is the one to keep.

Nginx

Copy the block shown in Celeris › Server into your virtual host — on Plesk, Apache & nginx settings › Additional nginx directives — then reload nginx. Until you do, pages are served by the PHP drop-in, which is already fast; the server rules simply remove PHP from the path entirely.

The settings that matter

The Recommendations tab lists what is not enabled yet, in order of impact, with a one-click Enable on each card. If you would rather choose yourself, this is what each one does.

• Page cache. The one that changes everything. Everything else is a refinement.
• Preloading. Fills the cache from your sitemap after a purge, so the first visitor is not the one who pays for it.
• Used CSS. Removes the rules a page never uses. Large gain, and the setting most likely to need a safelist entry on builder-heavy sites.
• Critical CSS. Inlines what paints the first screen. See below.
• Defer / delay JavaScript. Deferring moves scripts after the page is built; delaying waits for the first interaction. Chat widgets and analytics belong in the second group.
• Images. WebP and AVIF conversion, loading on demand, missing dimensions added. The first image of a page is never deferred.
• Fonts. Google Fonts brought local, preloaded, with a visible fallback while they arrive.

Critical CSS

Knowing which rules paint the first screen requires laying the page out in a real browser — something most hosting plans cannot do. Celeris asks its own servers instead: they render your page at a phone and a laptop size and return the rules that matter. Only the resulting CSS comes back; your pages are never stored.

One measurement is made per template, not per page: your thousand articles need one render, not a thousand. A change of theme or a new plugin changes the stylesheets, and the measurement is redone on its own.

Expect a few minutes between switching it on and seeing it applied: pages are queued and processed in the background. wp celeris critical runs the queue immediately if you are in a hurry.

Exclusions

Some pages must always be built by WordPress. Celeris already refuses to cache carts, checkouts, accounts, the console and login pages, whatever your settings say, and never serves a cached page to a logged-in visitor.

For anything else, the quickest way is from the front end: open the page, then Celeris › Never cache this page in the admin bar. The exclusion is added and the page is removed from the cache in one click. Celeris › Exclusions holds the full list, one path per line, and also accepts cookies and user agents.

URL parameters

Tracking parameters such as utm_source are ignored: a visitor coming from an ad gets the same cached file as anyone else. Parameters that genuinely change the page — lang, currency — can be listed so each value gets its own cached copy. Any other parameter bypasses the cache, which is the safe default.

WooCommerce and shops

• Cart, checkout and account pages are never cached, and neither are the WooCommerce API endpoints.
• A visitor with something in their cart is served by WordPress, not from the cache.
• Security tokens inside cached pages are capped at ten hours, which avoids the “are you sure you want to do this?” error on forms.
• Prices that vary by country or by customer group should be excluded, or the page will show the first visitor’s price to everyone.

When a page breaks

A form says “are you sure you want to do this?” — a security token expired inside a cached page. Purge that page; if it comes back, exclude it from the admin bar.

The layout is broken after enabling used CSS — a builder writing class names in JavaScript. Add the missing selector to the safelist in Celeris › CSS and JavaScript, then purge. Celeris already refuses results that would remove too much, and says so in its log.

A script stopped working — it was delayed and expects to run immediately. Add it to the exclusions of the delay option; the list accepts a fragment of the file name.

Nothing seems cached — check Celeris › Status, then look at the error log at the bottom of that screen. Every background failure is recorded there in plain words.

When in doubt: Clear the whole cache, then Repair the installation. Neither can damage anything.

Multisite

Each site of a network keeps its own settings and its own cache. Purging one site never empties its neighbours, and the drop-in reads a configuration per host.

Command line

Useful when you run many sites, and in deployment scripts.

wp celeris purge                 # empty the cache
wp celeris purge --url=…         # one page only
wp celeris preload               # refill from the sitemap
wp celeris critical --max=10     # process the critical CSS queue
wp celeris status                # what is enabled, what is cached
wp celeris repair                # rewrite drop-in and server rules
wp celeris settings export --file=celeris.json
wp celeris settings import --file=celeris.json

The settings file carries no license key and no site identifier, so the same file can configure twenty sites.

License, seats and renewal

A license covers a number of sites: one for Starter, five for Pro, a hundred for Agency. Activating on one more than your plan allows is refused with a clear message; freeing a seat from your account is instant and can be undone.

Renewal reminders go out a month before, a week before, on the day and a week after. An expired license stops the cache but never touches your settings: renewing starts everything again as it was.

Uninstalling

Deleting the plugin from the Plugins screen removes everything it created: the cached files, the drop-in (restoring any previous one), the WP_CACHE line, the rules added to .htaccess, its settings, its scheduled tasks and its temporary data.

Your content, your theme and your other plugins are untouched. Deactivating without deleting stops the cache but keeps your settings for later.

Still stuck?

Support is included with every license. Write to us with your license key and the address of a page that misbehaves: those two things usually save a day of back and forth. We answer within one working day.