A slow WordPress site costs you twice: visitors leave before the page loads, and Google’s page experience signals work against you. If your host runs LiteSpeed Web Server (many popular hosts do), the free LiteSpeed Cache plugin is one of the most effective tools available, because it caches at the server level rather than through PHP. But it has dozens of settings, and enabling everything at once is a common way to break layouts and forms. This guide gives you a safe setup, plus the improvements that matter beyond caching.
This article is part of our complete guide: How to Build a WordPress Website for Your Business (2026 Guide).
First, measure
Before changing anything, record a baseline for your homepage and two or three key pages:
- PageSpeed Insights: lab score plus real-user Core Web Vitals if available.
- Search Console Core Web Vitals report: real-user data grouped by URL type.
- Time to first byte (TTFB): how quickly the server responds. Slow TTFB points to hosting, PHP or database issues.
Write down LCP, INP, CLS and TTFB so you can see what each change achieves.
Step 1: Confirm you are on LiteSpeed
LiteSpeed Cache’s page caching only works on LiteSpeed or OpenLiteSpeed servers (or with QUIC.cloud CDN). Check with your host or look for the x-litespeed-cache response header. On other servers, use a different caching solution.
Step 2: Enable page caching (the biggest win)
In LiteSpeed Cache › Cache, enable caching for public pages. Leave “Cache Logged-in Users” off unless you understand the implications. Check that the response header shows x-litespeed-cache: hit on a second visit in a private window. Page caching typically reduces server response time dramatically.
Exclude dynamic pages
Make sure cart, checkout, account and form confirmation pages are excluded. WooCommerce exclusions are usually handled automatically, but check custom pages. Forms that use nonces may need special handling; test every form after enabling caching. On mivaq.com, we tested the contact form both logged in and as a visitor after caching was enabled.
Step 3: Purge rules
Configure automatic purging when content changes (enabled by default for posts and related archives). After changing theme settings, menus or global styles, purge all manually from the admin bar.
Step 4: Optimise images
Images are often the heaviest part of a page. Options:
- Use LiteSpeed’s image optimisation (through QUIC.cloud) to compress images and create WebP versions, or a dedicated image plugin.
- Enable lazy loading for images below the fold, but exclude the hero image (the LCP element), which should load immediately.
- Upload images at sensible sizes. A 5,000-pixel photo compressed is still wasteful when displayed at 1,200 pixels.
- Set width and height attributes to prevent layout shift (WordPress does this for images inserted normally).
Step 5: CSS and JavaScript settings (carefully)
This is where sites break. Enable one option at a time, purge, and test pages including menus, sliders, forms and mobile layout.
- CSS minify: usually safe.
- CSS combine: less useful with modern HTTP/2 and can cause issues; test before keeping it.
- Generate critical CSS / load CSS asynchronously: can improve LCP but may cause a flash of unstyled content. Test carefully.
- JS minify: usually safe.
- JS defer or delay: large gains for INP and LCP, but can break features that need scripts early. Exclude problem scripts (for example, jQuery if your theme depends on it inline).
- Remove unused CSS: powerful but riskier; test thoroughly.
Step 6: Object cache and database
If your host provides Redis or Memcached, enable object caching in LiteSpeed Cache. It speeds up the dashboard and dynamic pages. Use the database tools to clean old revisions, transients and spam comments, after a backup.
Step 7: Browser cache and CDN
Enable browser caching for static files. Consider QUIC.cloud or another CDN for visitors far from your server.
Beyond caching: the bigger wins
Reduce plugins
Every plugin can add scripts, styles and database queries. Remove anything you do not use. Replace heavy multi-purpose plugins with lighter options or small custom code where sensible. On our own builds, we avoid installing plugins for features a few lines of code can handle.
Choose a lightweight theme and builder setup
Lightweight themes such as Hello Elementor, GeneratePress or Astra start fast. With page builders, avoid stacking many widgets, sliders and animations on a single page. Use the builder’s performance features (such as loading assets only where needed).
Limit third-party scripts
Chat widgets, heatmaps, social embeds and multiple tracking pixels often cost more than everything else. Load them only where needed or after user interaction.
Fonts
Use one or two font families, preload the main one, and consider hosting fonts locally.
Hosting
If TTFB remains slow after caching, the host or plan may be underpowered. Check PHP version, server resources and whether the database is overloaded.
Fixing specific Core Web Vitals
- Poor LCP: preload or prioritise the hero image, do not lazy-load it, reduce render-blocking CSS, improve TTFB.
- Poor INP: reduce and delay JavaScript, remove heavy plugins, simplify interactive widgets.
- Poor CLS: set image and embed dimensions, avoid inserting banners above content, use font-display settings sensibly.
A safe testing routine after every change
Speed settings interact in unexpected ways, so build a short routine and follow it every time you change something. Purge the cache, then open the homepage, a service page, a blog post and the contact page in a private window. Check the menu on desktop and mobile, open any accordions or tabs, submit a test form, and, for stores, add a product to the cart and reach the checkout page. Run PageSpeed Insights again on one page and compare it with your baseline. If something broke, undo only the last change. This takes ten minutes and prevents the most common outcome of speed work: a faster site that quietly stopped sending enquiries.
When to call in help
If your Core Web Vitals stay poor after caching and image work, the cause is usually structural: a heavy theme, a page builder layout with dozens of nested sections, or plugins loading scripts on every page. Fixing those needs template-level changes rather than more settings.
Common LiteSpeed Cache mistakes
- Enabling every optimisation at once.
- Caching pages with personalised or form content.
- Lazy-loading the hero image.
- Running two caching plugins together.
- Not purging after design changes, then thinking changes did not save.
Speed and SEO
Speed is one of many ranking signals and rarely outweighs relevance, but it strongly affects conversions. We treat it as part of every build and redesign. See our technical SEO audit checklist and, for builder sites, Wix speed optimisation. Projects like Sip & Scoop and Vine Living show how performance and design can work together.
Related guides and services
- Technical SEO audit checklist: the 40-point technical checklist we use on every site.
- WordPress security checklist: the hardening steps we apply to every WordPress site.
- Rank Math vs Yoast: which WordPress SEO plugin suits your site.
- WordPress services: fast, secure WordPress builds and maintenance.
- Web design: conversion-focused websites that are built to rank.
Get expert help
We can configure LiteSpeed Cache safely, reduce plugin bloat, optimise images and improve your Core Web Vitals without breaking your design. Start with our WordPress services, browse real client results in our case studies, or contact us for a free, no-pressure review of your website.
Frequently asked questions
Does LiteSpeed Cache work on any host?
Page caching needs a LiteSpeed or OpenLiteSpeed server, or QUIC.cloud CDN. Some optimisation features work elsewhere.
Why did my site break after enabling LiteSpeed Cache?
Usually because of CSS/JS combine, defer or unused CSS settings. Disable them one at a time to find the cause.
Should I cache logged-in users?
Usually not, unless you have a membership site and understand the configuration.
Will caching fix a slow server?
It helps a lot, but very slow TTFB on uncached pages may still need better hosting.
