Advanced LiteSpeed Cache Settings to Boost Your Core Web Vitals

LiteSpeed Cache is free, powerful, and installed on millions of WordPress sites. It’s also one of the easiest plugins to misconfigure. I’ve seen sites where turning on “every optimization” pushed the PageSpeed score up by ten points while breaking the mobile menu, the contact form and the checkout page at the same time.

After tuning LiteSpeed Cache across several content sites and a WooCommerce store, I’ve settled on a configuration that reliably improves Core Web Vitals without the breakage. This guide shares those exact settings, the order I turn them on, and how to test each step so nothing goes wrong silently.

Before changing anything, record your starting point. Run your homepage and a typical article through PageSpeed Insights and save the LCP, INP and CLS values. You can also compare results across testers in our roundup of free page speed test tools.

Core Web Vitals in 60 Seconds

Google measures page experience with three Core Web Vitals. Every setting in this guide targets at least one of them:

For the full definitions, Google’s Web Vitals overview is the official reference.

Before You Start: Three Things to Check

• Your server type. LiteSpeed Cache’s full-page caching only works on a LiteSpeed or OpenLiteSpeed web server, or through QUIC.cloud CDN. The optimization features (CSS, JS, images) work on any server. Many hosts, including Hostinger, run LiteSpeed by default.
• Remove other caching plugins. Running two page-cache plugins together causes conflicts. Keep one.
• Take a backup. Export your LiteSpeed settings under Toolbox → Import/Export before every major change, so you can roll back in seconds.

Step 1: Connect QUIC.cloud (Optional but Valuable)

Several of LiteSpeed’s best features — Unique CSS (UCSS), Critical CSS (CCSS), Viewport Images (VPI), Low-Quality Image Placeholders and image optimization — are generated on QUIC.cloud’s servers. Linking your site under General gives you a free monthly quota for these services.

You don’t have to use QUIC.cloud CDN to use these optimization services. I connect the account on every site and decide on the CDN separately.

Step 2: Cache Settings — The Foundation

Page caching has the single biggest effect on Time to First Byte (TTFB), which feeds directly into LCP. Get this right before touching anything else.

Cache Tab

• Enable Cache: ON
• Cache Logged-in Users: OFF for most blogs (turn ON only for membership sites with heavy logged-in traffic, and test carefully)
• Cache Commenters: ON
• Cache REST API: ON
• Cache Login Page: ON
• Cache Mobile: OFF if your theme is responsive. Turn it ON only if your theme serves different HTML to mobile devices.

TTL Tab

• Default Public Cache TTL: 604800 (one week) is a good default for content sites. LiteSpeed purges pages automatically when you update them, so a long TTL is safe.
• Default Front Page TTL: Lower it (for example, 3600) if your homepage shows frequently changing content.

Purge Tab

• Purge All on Upgrade: ON. Plugin and theme updates can change CSS and JS, so a full purge prevents broken layouts.
• Leave the automatic purge rules for related pages (home, categories, tags) on their defaults unless you have a specific reason.

Browser Tab

• Browser Cache: ON
• Browser Cache TTL: 31557600 (one year). Static files like images, CSS and fonts rarely change, and LiteSpeed versions its generated files.

Step 3: Object Cache — The Hidden INP and TTFB Booster

Page caching helps anonymous visitors. Object caching speeds up everything that can’t be page-cached: logged-in users, WooCommerce carts, admin screens, and uncached first visits. It stores database query results in memory.

• Ask your host whether Redis or Memcached is available, and enable it in your hosting panel first.
• In Cache → Object, turn Object Cache ON, select the method, and enter the host and port your provider gives you.
• Look for “Connection Test: Passed” before saving.

On WooCommerce stores, this is often the setting that makes the biggest difference to checkout speed. For product-page SEO beyond speed, see our WooCommerce SEO guide.

Step 4: Page Optimization — Where the Real Gains Are

This is where most sites either win big or break. My rule: enable one group at a time, then test the site on mobile before moving on.

CSS Settings

• CSS Minify: ON. Safe on almost every site.
• CSS Combine: ON, but test. On HTTP/2 or HTTP/3 the gain is modest; turn it OFF if anything looks wrong.
• Generate UCSS: ON (requires QUIC.cloud). It creates a stylesheet containing only the CSS each page actually uses — a large win for LCP on bloated themes and page builders.
• UCSS Inline: ON, so the reduced CSS loads with the HTML.
• Load CSS Asynchronously: ON, which generates Critical CSS so the above-the-fold area renders immediately.
• Font Display Optimization: Swap. Text appears immediately in a fallback font instead of staying invisible.

Watch out for: a brief “flash” of unstyled content, or sliders and menus that look broken until you scroll. If that happens, add the affected selectors to the UCSS allowlist or exclude that page type.

JavaScript Settings

• JS Minify: ON.
• JS Combine: Start with OFF. It’s the setting most likely to break things, and the benefit on modern protocols is small.
• Load JS Deferred: Choose Delayed for the biggest INP and Total Blocking Time improvement. Scripts load only after the first user interaction.

“Delayed” is the most powerful — and most dangerous — setting in the plugin. After enabling it, test every interactive element: mobile menu, search, sliders, forms, accordions, cookie banners and add-to-cart buttons. If something stops working, add its script to Page Optimization → Tuning → JS Deferred / Delayed Excludes rather than turning the whole feature off. jQuery is a common exclusion if your theme relies on it immediately.

HTML Settings

• HTML Minify: ON.
• DNS Prefetch / DNS Preconnect: Add domains you load resources from, such as fonts.gstatic.com or your CDN.
• Remove WordPress Emoji: ON. Removes a script almost nobody needs.
• Remove Query Strings: Optional; mainly cosmetic in modern setups.
• Load Google Fonts Asynchronously: ON, or better, host fonts locally through your theme.

Media Settings — Your LCP and CLS Toolkit

• Lazy Load Images: ON.
• Viewport Images (VPI): ON. This is crucial. It detects images visible on first load and excludes them from lazy loading, so your LCP image isn’t delayed.
• Lazy Load Iframes: ON. YouTube embeds are a frequent LCP and INP drag.
• Add Missing Sizes: ON. Adds width and height to images that lack them, reducing CLS.
• Responsive Placeholder: ON. Reserves space for images before they load.

A classic mistake is lazy-loading the hero image or featured image at the top of an article. That alone can add a full second to LCP. VPI fixes this automatically; if you don’t use QUIC.cloud, manually exclude your logo and featured image class from lazy loading.

Step 5: Image Optimization

Images are usually the largest element on the page, which makes them the LCP element on most blog posts.

• Under Image Optimization, send an optimization request to QUIC.cloud and pull the results.
• Turn ON next-generation image format replacement (WebP or AVIF) so supported browsers get smaller files.
• Keep “Optimize Original Images” OFF until you’ve confirmed you’re happy with the compression quality — or keep a backup of originals.
• Upload images at the size they’re actually displayed. No plugin can fully rescue a 4000-pixel image squeezed into an 800-pixel column.

Step 6: Guest Mode and Guest Optimization

Guest Mode serves a default cached page to first-time visitors right away, then loads the personalized version in the background. Guest Optimization applies more aggressive optimizations to that first view.

Both can produce impressive lab scores. However, I enable them only after everything else is stable, and I always compare field data in Search Console a few weeks later. A great Lighthouse score that doesn’t move real-user metrics isn’t a win.

Step 7: Database, Crawler and CDN

Database

• Clean post revisions, auto-drafts, spam comments and expired transients monthly.
• Limit stored revisions in your settings so the database doesn’t balloon again.

Crawler

• The crawler pre-warms the cache by visiting pages before real users do.
• Keep it OFF on shared hosting — many hosts disable it anyway because it uses significant server resources. Use it on a VPS or dedicated server where you control resources.

CDN

• QUIC.cloud CDN can cache full HTML pages at the edge, which helps visitors far from your server.
• If you already use another CDN, don’t stack two full-page caches on top of each other. Choose one layer for HTML caching.

Recommended Settings by Site Type

One configuration doesn’t fit every site. Here’s how I adjust the riskier settings depending on what the site does:

Why WooCommerce Needs Extra Care

Stores have dynamic elements — mini-carts, stock counts, prices in different currencies, logged-in account areas. That’s why I start stores on the safer “Deferred” JavaScript setting and only move to “Delayed” after testing the full purchase journey: product page, add to cart, cart, checkout, payment, and order confirmation. A small speed gain is never worth a lost sale.

Why Page Builders Benefit Most

Elementor, Divi and similar builders often load large global stylesheets on every page. UCSS strips that down to what each page actually uses, which is why builder-based sites frequently see the largest LCP improvements from this one setting.

Exclusions I Always Set

Good exclusions prevent most LiteSpeed problems before they happen. These are the ones I add on nearly every site:

• Cache excludes: cart, checkout, my-account and any page that shows user-specific content.
• Lazy load excludes: the site logo and the featured image class used above the fold (if VPI isn’t active).
• JS delayed excludes: scripts for the mobile menu, cookie consent banner, and any above-the-fold slider.
• UCSS allowlist: selectors for elements that appear only after interaction, such as dropdown menus, popups and modal windows.
• Sitemap URLs: exclude your XML sitemap from page caching, or use a short TTL, so new posts appear in it immediately.

What Kind of Improvement to Expect

Results vary by hosting, theme and plugins, so be wary of anyone promising exact numbers. In my experience, the pattern looks like this:

• Page caching produces the biggest drop in server response time, which lifts LCP across the whole site.
• UCSS and Critical CSS deliver noticeable LCP gains on theme- and builder-heavy pages.
• Delayed JS is usually responsible for most of the improvement in Total Blocking Time and INP.
• Missing sizes and placeholders often bring CLS into the “Good” range on their own.

If a site already uses a lightweight theme and few plugins, the gains will be smaller — simply because there’s less to fix. That’s a good problem to have.

My Recommended Order of Changes

1. Baseline test and settings export
2. Cache, TTL, Purge and Browser cache
3. Object cache
4. CSS minify, then UCSS and CCSS
5. Media: lazy load, VPI, missing sizes
6. JS minify, then Delayed JS (with careful testing)
7. Image optimization and next-gen formats
8. Guest Mode and Guest Optimization last

After each step: purge all cache, test in an incognito window on a real phone, and re-run PageSpeed Insights. If you’d like a structured way to track results alongside other technical issues, our SEO site audit guide includes a performance checklist.

Troubleshooting: When Something Breaks

• Layout looks broken: Turn off CSS Combine first, then UCSS. Purge and retest.
• Menu, slider or form stops working: Usually Delayed JS. Exclude the specific script rather than disabling the feature.
• Cart or checkout shows old data: Make sure cart, checkout and account pages are excluded from caching (WooCommerce usually handles this automatically, but check under Excludes).
• Changes not showing: Purge LiteSpeed, then purge your CDN, then test in incognito.
• Need to compare quickly: Add ?LSCWP_CTRL=before_optimize to a URL to view it without optimizations applied.

The official LiteSpeed Cache for WordPress documentation explains every option in detail and is worth bookmarking.

How to Measure Real Improvement

Lab tools like Lighthouse give instant feedback, but Google ranks on field data from real Chrome users. Here’s how I verify that changes actually worked:

• Check the Core Web Vitals report in Search Console. It updates on a rolling 28-day window, so give it about a month.
• Look at the “Discover what your real users are experiencing” section in PageSpeed Insights.
• Track groups of URLs, not single pages — Search Console groups similar pages together.

If you haven’t linked Search Console to your WordPress dashboard yet, our Search Console integration guide makes this monitoring much easier.

When Settings Aren’t Enough

LiteSpeed Cache can make a good setup great, but it can’t fix everything. If your TTFB is still slow on cached pages, or INP stays poor with Delayed JS on, look at:

• Hosting resources: Underpowered shared plans hit limits quickly. Compare options in our best WordPress hosting 2026 test.
• Heavy page builders and themes that load large amounts of CSS and JS on every page.
• Third-party scripts: ads, chat widgets, heatmaps and social embeds are often the biggest INP problems.
• Plugin count: Every active plugin adds potential overhead. Remove what you don’t use.

Frequently Asked Questions

Does LiteSpeed Cache work on Apache or Nginx hosting?

The optimization features (CSS, JS, images, lazy load) work on any server. Full-page caching requires a LiteSpeed or OpenLiteSpeed server, or QUIC.cloud CDN.

Is QUIC.cloud free?

QUIC.cloud offers a free monthly quota for services like UCSS, CCSS, VPI and image optimization, with paid credits available for larger sites. Check their current plans before relying on it for high volumes.

Which single setting improves INP the most?

Usually “Load JS Deferred” set to Delayed, because it stops non-essential scripts from blocking the main thread during load. Test it carefully.

Why is my PageSpeed score good but Search Console still shows “Poor”?

Search Console uses 28 days of real-user field data. Improvements take weeks to appear, and real visitors on slower phones and networks may have a different experience from a lab test.

Should I cache pages for logged-in users?

For most blogs, no. Only enable it for membership or community sites where logged-in traffic is high, and test personalized areas thoroughly.

Final Thoughts

The best LiteSpeed Cache configuration isn’t “everything ON.” It’s a solid caching foundation, a fast object cache, smart CSS handling, careful JavaScript delay, and images that load in the right order. Change one group at a time, test on a real phone, and confirm with field data.

Do that, and you’ll get faster pages without the hidden breakage that quietly hurts conversions. For more context on how speed fits into Google’s wider ranking picture, read Google’s guidance on page experience, and explore our list of 50 free SEO tools to keep testing as your site grows.