To set up LiteSpeed Cache for WordPress, first confirm your host runs a LiteSpeed web server, install the LiteSpeed Cache plugin, switch on page caching and measure, then add CSS, JavaScript and image optimisation one setting at a time while testing forms and checkout after each change. The page cache is the big win, and the optimisation settings are where sites break.
I use this stack, WordPress on Bricks with LiteSpeed, for the go.procol.ai ad landing pages I built at Procol. Ad landing pages are a good test of a cache setup: paid traffic arrives in bursts, mostly on phones, and every visitor who waits is a click you paid for and lost.
Why use LiteSpeed Cache instead of another caching plugin?
Because on a LiteSpeed server it caches at the server level. Most caching plugins write pages to files that PHP or a server rule then serves. LiteSpeed Cache tells the web server itself which pages to store, and the server answers repeat visits without starting WordPress at all. Many shared and cloud hosts, Hostinger among them, run LiteSpeed web servers, so the plugin is often the natural choice there.
On other servers I use other tools. Ravens Ait uses WP Rocket for caching and has a reported PageSpeed score of 94 or higher. The right plugin is the one that matches your server.
Which LiteSpeed Cache settings should you start with?
| Setting | Start with | Why |
|---|---|---|
| Page cache | On | The main speed gain on a LiteSpeed server |
| Cache logged-in users | Off | Logged-in pages are personal and change often |
| Browser cache | On | Returning visitors reuse static files |
| CSS and JS minify | On, then test | Usually safe, small gain |
| CSS and JS combine | Off at first | Most likely to break layouts or scripts |
| Load JS deferred or delayed | Test carefully | Can break sliders, popups, forms and tracking |
| Lazy load images | On, except the hero | Saves bytes below the first screen |
| Image optimisation | Optional | Uses QUIC.cloud; fine if you do not already optimise at upload |
| Object cache | Only if the host provides Redis or Memcached | Speeds up database-heavy admin and shop pages |
| Crawler | Off unless the host allows it | Warms the cache, but uses server resources |
In what order should you switch settings on?
Do not switch everything on at once
If you enable ten optimisations and the menu stops working, you do not know which one did it. Change one setting, purge, test, then move on.
What should you exclude from the cache?
Anything that is different for each visitor.
- Cart, checkout and My Account. The plugin recognises WooCommerce and handles these, but confirm it with a real test order.
- Pages that vary by country or currency. If you show content by location, as my Geo Targeting for Bricks Builder plugin does, those pages must not be served from one shared cached copy. See how to show different content by country in Bricks Builder.
- Pages with one-time tokens, such as some booking or payment forms.
- Preview and staging URLs.
Why test forms after every caching change?
Because cache layers can break forms without any visible error. On two client sites, Samko Holdings and Crowne Plaza London Kingston, a GoDaddy cache layer swallowed form submissions. The form looked fine and the visitor saw a thank-you message, but nothing arrived. Upgrading PHP from 8.0 to 8.3 fixed both. That was not LiteSpeed, but the lesson applies to any cache: when submissions vanish, check the caching layer before the form plugin.
On campaign landing pages this matters more than speed scores. A fast page with a broken form is worse than a slow page that works.
How do you set it up step by step?
- 1
Check the server
Ask your host or look for a LiteSpeed server response header. Without it, use the plugin only for optimisation, or choose another cache.
- 2
Remove other caches
Uninstall other page cache plugins and clear their leftover files.
- 3
Measure
Run PageSpeed Insights on the homepage and two key landing pages on mobile and save the reports.
- 4
Enable page cache
Leave logged-in caching off. Purge, then test forms, login and checkout.
- 5
Add optimisation slowly
Minify first, then lazy load with the hero excluded, then try combine or defer one at a time.
- 6
Set purge rules
Make sure editing a page, post or product purges that page and its listings.
- 7
Export the settings
Save the working configuration so you can restore or reuse it.
What if the site is still slow?
Then caching is not the bottleneck. Heavy builders, oversized images and third-party scripts slow the parts a cache cannot fix, such as the browser's work after the HTML arrives. Start with how to fix Core Web Vitals on a WordPress site, and if the site runs on Elementor, how to speed up an Elementor site.
I set up caching as part of my technical SEO and Core Web Vitals service. Send me the URL and your host, and I will reply with the settings I would start with.
