WordPress Hosting & Plugins
Making WordPress Fast and Secure: A Performance and Plugin Checklist
WordPress is only ever as fast and safe as what runs it. Here is the practical checklist we apply to every WordPress site we host — what to cache, what to secure, and which plugins earn their place versus the ones the platform makes redundant.
WordPress is only as good as what runs it
WordPress powers a large share of the web because it is flexible, but that flexibility is also how it gets slow and insecure: a default install queries the database dozens of times per page, broadcasts its version and stack to anyone who looks, and invites you to stack plugins until performance and attack surface both quietly balloon. None of that is a flaw in WordPress so much as a consequence of running it on infrastructure that does nothing to help.
The good news is that the same handful of decisions fix most of it, and they are decisions about the stack rather than the content. Cache aggressively at the right layer, keep the database out of the hot path, run the few plugins that genuinely earn their place, keep everything patched, and isolate the site so a problem stays contained. This post is that checklist, in the order we apply it to every WordPress site on the platform.
Cache at the server, not just in a plugin
The biggest single lever on WordPress speed is not running WordPress at all for most visits. A standard request boots WordPress, runs your plugins and queries the database before it sends a byte; a full-page cache serves the finished page straight from the web server on the next hit, skipping that entire boot. Where that cache lives matters: a caching plugin sits inside PHP, so PHP still starts before the cache can answer, whereas a server-level cache answers earlier in the request and holds pages in a form the server can flush instantly.
Every WordPress site we host runs on LiteSpeed Enterprise with server-level LSCache, and our own cache plugin wires WordPress to it correctly out of the box — pre-installed and auto-updated, so it is one less thing to configure or keep current. On a non-LiteSpeed origin the same plugin simply emits no full-page headers and stays out of the way while the object cache keeps working, so a migrated site is never left half-configured. The practical rule for your own checklist: one full-page cache, at the server, and do not stack a second caching plugin on top of it — they fight.
The object cache and the database
Not every request can be a static page. Logged-in sessions, the admin, search, carts and any personalised fragment have to run PHP, and for those the goal shifts from skipping the application to skipping the database. A per-site object cache — Redis, in our case — holds the results of repeated database reads in memory, so the same options, transients and lookups are not queried against the database on every hit. The effect shows up exactly where full-page cache cannot help: a faster admin, faster carts, and far lower database load under traffic.
The word that matters is per-site. A shared object cache means one busy or badly-written site can evict everyone else's cached data and starve the database for its neighbours; a dedicated per-site cache, paired with per-site database limits, keeps that blast radius contained. On your checklist, treat a persistent object cache as non-optional for any site with logged-in users or a store, and be wary of hosting where it is shared across tenants.
The plugins worth running — and the ones the platform replaces
Every plugin you add is code that runs on requests and a door someone might one day walk through, so the honest goal is the fewest plugins that do the most. A good host removes the need for a whole category of them: with server-level caching, a managed object cache and platform backups, you do not need a caching plugin, a separate object-cache plugin, or a backup plugin — those jobs are done better below WordPress, and running them on top just adds conflict and overhead.
What is left worth running is the small set that adds genuine capability: the plugins your site actually needs for its function, and — on our platform — the two repo-grade plugins we build and ship with every site. Our cache plugin connects WordPress to the server cache and handles smart purging so an edit clears only the pages it should. Our footprint plugin strips the tells a default WordPress install broadcasts — the version and generator tag, discovery endpoints, XML-RPC, pingbacks and the powered-by header — on every deploy, so a plugin or theme update cannot quietly put them back. Both are built to WordPress.org plugin-directory standards, are free, and update themselves.
Keeping WordPress secure and current
Most WordPress compromises are not clever; they are old. An out-of-date core, theme or plugin with a known, published vulnerability is the overwhelmingly common way sites get hit, which makes staying current the highest-value security work there is — and the most tedious, which is why it gets skipped. Managed hosting should take it off your plate: patching the stack beneath WordPress, and making core and plugin updates safe to apply by giving you a staging copy to test them on and a backup to roll back to.
On top of currency, expect the boundaries to be enforced for you: malware scanning on by default so an infection is caught rather than discovered by a visitor, isolation so one compromised site cannot reach another, DDoS protection at the edge, and TLS everywhere with certificates renewed automatically. None of that replaces basic hygiene — strong credentials, least-privilege access, removing plugins you no longer use — but it means the infrastructure is not the weak link. On your checklist, the question for any host is simple: is security the default, or a bundle you buy?
WooCommerce and the pages you must never cache
A store is where aggressive caching earns its biggest win and does its worst damage if it is naive. The catalogue, product and category pages are the highest-traffic, most cacheable pages you have, and serving them from full-page cache is the single best thing you can do for a store's speed. But cart, checkout and account pages are personal and must never be served from a shared cache — do that and a shopper sees someone else's basket, which is both a broken store and a privacy failure.
The way to have both is to cache the page and punch holes for the live parts. Edge Side Includes render the cart fragment, mini-cart totals and account state per request while the rest of the page is served from cache, and cart, checkout, my-account and any nonce or session pages are excluded by default. Freshness is handled by smart auto-purge that fires when a product, price or order changes, so a stale price never lingers. If you run WooCommerce, this is the part of the checklist to get exactly right: fast storefront from cache, live cart per user, nothing personal ever cached.
Frequently asked questions
Do I still need a caching plugin like WP Rocket?
No. Full-page caching is handled at the web server by LiteSpeed's LSCache, our own cache plugin wires WordPress to it and handles smart purging, and a per-site Redis object cache sits behind it. Adding a second full-page caching plugin on top typically fights the server-level cache rather than helping, so it is neither needed nor recommended.
Which plugins does the platform make unnecessary?
Caching plugins, separate object-cache plugins and backup plugins are all redundant here, because those jobs are done below WordPress — server-level caching, a managed per-site object cache and platform backups. Removing them reduces conflicts and attack surface. What remains worth running is the plugins your site genuinely needs for its function, plus our two free cache and footprint plugins, which ship pre-installed.
Will caching break my WooCommerce cart or logged-in pages?
No. Cart, checkout, my-account and any nonce or session pages are excluded from cache by default, and Edge Side Includes keep the cart fragment and totals live on otherwise-cached pages. Shoppers always see their own basket and a working checkout while the storefront still loads from cache, and smart auto-purge clears affected pages when a product, price or order changes.
How do you keep WordPress secure without me managing it?
We patch the stack beneath WordPress, make core and plugin updates safe to apply with staging and one-click restore, run malware scanning and DDoS protection on by default, isolate each site so one compromise cannot spread, and issue and renew TLS certificates automatically. That removes the infrastructure as the weak link; basic hygiene like strong credentials and removing unused plugins is still on you.
Related
Try it free for 7 days
Spin up your first sites free for 7 days — no card. Moving an existing site or network? Your first migration is on us.
Start free