How to Speed Up WordPress With LiteSpeed Cache: The Complete 2026 Setup Guide

A slow WordPress website quietly costs you visitors, search rankings, and sales every single day. When a page takes more than a few seconds to appear, most people simply leave, and Google notices that behaviour through its Core Web Vitals measurements. The good news is that one of the most powerful speed tools available for WordPress is completely free, and when it runs on the right kind of hosting, it can transform a sluggish site into one that loads almost instantly. That tool is LiteSpeed Cache.

This guide walks you through everything from installing the plugin to configuring key settings, connecting object caching to Redis, linking QUIC.cloud for advanced optimization, and fixing the problems that trip most people up. It is written for site owners and small business operators who are comfortable in the WordPress dashboard but are not developers. You do not need to touch code. You do need a little patience, because caching rewards careful setup over guesswork.

What LiteSpeed Cache actually is

LiteSpeed Cache, often shortened to LSCache or LSCWP, is a free WordPress plugin built by LiteSpeed Technologies. It is the most-installed dedicated caching plugin on WordPress.org, with more than 7 million active installations and a rating of 4.8 out of 5 from thousands of reviews. Those numbers matter because caching plugins can break a site when they are poorly built, and a tool trusted by that many people has been tested against nearly every theme and plugin combination imaginable.

At its heart, caching means storing a ready-made version of your content so your server does not have to build it from scratch every time someone visits. Think of a busy café. If the barista brewed a fresh pot for every single customer, the queue would stretch out the door. Instead, they brew ahead and pour on demand. Caching does the same thing for your website, and LiteSpeed Cache is unusually good at it because it can work at the server level rather than only inside WordPress.

Why the server underneath matters, and where N6 Cloud fits

Here is the single most important thing to understand before you begin, because it shapes everything else. LiteSpeed Cache reaches its full potential only when your website is hosted on a LiteSpeed or OpenLiteSpeed web server. On that kind of server, the plugin can control a true server-level page cache, which is far faster than the caching a plugin can do on its own. On an ordinary Apache or Nginx server, LiteSpeed Cache still works, but it runs in a limited mode and loses much of its advantage. Certain premium features, including Edge Side Includes for caching logged-in users, require either LiteSpeed Enterprise or an active QUIC.cloud connection.

This is exactly why the hosting you choose is not a detail you can ignore. N6 Cloud runs its Lightning plans on the LiteSpeed Web Server, which means the plugin can do its most powerful work rather than being held back. On the WordPress Hosting page, the Lightning Premium and Lightning Ultimate plans include the LiteSpeed Web Server and the LiteSpeed Cache for WordPress plugin, delivering up to 11 times the performance of Apache and up to 6 times that of Nginx, along with separate desktop and mobile caching, ESI support, and full HTTP/2 and HTTP/3. If you are on one of these plans, everything in this guide applies fully, including the server-level cache and the object cache steps further down.

If you would rather not manage the technical side yourself, Managed WordPress Hosting runs on the same Lightning platform, with the LiteSpeed Web Server, LSCWP caching, and Redis object caching all enabled by default on every plan, so much of what this guide covers is already switched on for you. Either way, if you are not sure what your site currently runs on, the N6 Cloud support team is available 24 hours a day, every day of the year, and can confirm it for you in a moment.

There is a Canadian angle worth mentioning, too. N6 Cloud operates from British Columbia, with Canadian data centres, so a fast cache paired with low latency serves Canadian visitors, and your data stays on Canadian soil under Canadian privacy law. Speed and data sovereignty are not usually offered together, and for many Canadian businesses, that combination is the deciding factor.

Before you start: a short checklist

A few minutes of preparation will save you a great deal of frustration later. First, confirm that your site is hosted on a LiteSpeed server, which is provided by every N6 Cloud Lightning plan and every Managed WordPress plan. Second, take a full backup of your website so you can roll back if a setting causes an unexpected display issue. Most caching problems are easy to undo, but a backup removes any worry. Third, and this step is the one people skip most often, record your current speed as a baseline.

To create a baseline, run your home page and one busy inner page through Google PageSpeed Insights and GTmetrix, and record the load time, Largest Contentful Paint, and Time To First Byte. Without a before-and-after picture, you will never know how much the plugin actually helped, and you will be tempted to keep flipping switches without evidence. With a baseline, you can measure each change and stop as soon as the results are good, which is the mark of a careful setup rather than an anxious one.

Step one: install and activate the plugin

Installing LiteSpeed Cache is the same as installing any other WordPress plugin. From your dashboard, open Plugins and choose Add New, then type LiteSpeed Cache into the search box. Look for the plugin published by LiteSpeed Technologies, click Install Now, and once it finishes, click Activate. A new LiteSpeed Cache menu item will appear in your sidebar, and that is where every setting in this guide lives.

If your website is hosted with N6 Cloud on a LiteSpeed plan, the plugin will automatically detect the LiteSpeed server and switch on server-level caching straight away. You can confirm this by opening LiteSpeed Cache and checking the dashboard; it will show that the cache is active. From this point on, your pages are already being cached, and everything else you do is about making that cache smarter and adding extra layers of optimization.

Step two: connect QUIC.cloud first

It may feel odd to configure an external service before touching the main settings, but there is a good reason to link QUIC.cloud early. QUIC.cloud is LiteSpeed’s own content delivery network and online optimization service, and several of the most valuable features, including Critical CSS, Unique CSS, Viewport Images, and image compression, run on QUIC.cloud servers rather than on your own. If you connect it first, those features are ready to switch on when you reach them later, and you avoid backtracking.

To connect it, open LiteSpeed Cache and go to the General tab. Find the Online Services or QUIC.cloud section and click the button to enable QUIC.cloud services. The plugin will detect your server type and IP address, which takes a few moments. You will then be asked to create a QUIC.cloud account linked to your site by entering your email address and choosing a password. Check your inbox for a validation email from QUIC.cloud and click the activation link to confirm the account. Once that is done, your site is paired with QUIC.cloud and the advanced services become available. You do not need to enable the CDN yet; we will return to that near the end once the rest of the configuration is in place.

Step three: the General settings

The General tab controls how the plugin behaves at a broad level, and most of its options can be left at their sensible defaults. A few are worth understanding.

The Automatically Upgrade option lets the plugin update itself when a new version is released. Leaving this off and updating manually is the safer choice for a business site because you can update after a quick backup, rather than being caught by surprise by a change.

Guest Mode and Guest Optimization deserve attention. Guest Mode serves a lightweight, pre-optimized version of your pages to brand new visitors so their very first impression loads quickly, which is the moment that shapes bounce rate. Guest Optimization goes further by applying advanced optimizations, such as Unique CSS and Critical CSS, to the first view using QUIC.cloud. Guest Optimization is powerful but can occasionally cause a brief style shift for first-time visitors if your theme is fussy, so switch it on, then test your site as a logged-out visitor to make sure everything still looks right.

The Notifications option simply allows LiteSpeed to display plugin news, and you can configure it to your preferences without affecting performance. Once you have reviewed these, save your changes before moving on.

Step four: the Cache tab, setting by setting

The Cache tab is the core of the plugin, and understanding each toggle here is what separates a site that flies from one that mysteriously misbehaves. Take these one at a time.

Enable Cache is the master switch. It must be on. On an N6 LiteSpeed plan, this enables the server-level page cache, which stores the finished HTML of your pages and serves it in a fraction of the time it would take PHP to rebuild them.

Cache Logged-in Users stores a private cache for signed-in users. For a simple blog or brochure site, this can be on, but if you run a membership area or a shop, leave the finer control to Edge Side Includes, which we cover shortly. When in doubt, keep it off and rely on ESI.

Cache Commenters handles visitors who have left a comment and are therefore in a slightly different state. Leaving it on is fine for most sites and keeps their experience quick.

Cache REST API stores responses from WordPress’s internal data interface, which many themes and plugins use behind the scenes. Keeping this on is generally beneficial and rarely causes trouble.

Cache Login Page caches your wp-login screen. This is safe and reduces load from bots hammering the login, so it can stay on.

Cache Favicon and Cache PHP Resources are minor options that cache small supporting files. They are safe to leave on and help shave a little extra time.

Cache Mobile matters if your theme serves entirely different HTML to phones rather than simply resizing with CSS. Most modern responsive themes do not need it, but if you use a separate mobile theme or an AMP setup, turn it on so mobile visitors are not served the desktop cache. Be aware that enabling it roughly doubles the number of cached copies stored, since the plugin keeps a separate version for mobile.

Below these switches, you will find TTL settings, which stand for Time To Live and decide how long a cached page is kept before it is rebuilt. The defaults, typically around one week for public pages, suit most sites well. A shorter TTL means fresher pages at the cost of rebuilding more often, while a longer one yields better performance for content that rarely changes. Unless you have a specific reason, the defaults are a solid choice.

Finally, the Purge settings control when cached pages are automatically cleared, for example, when you publish a post or update a page. The defaults are well-judged and ensure visitors always see current content, so there is little reason to change them unless you have a particular need.

Step five: object cache with Redis, the full walkthrough

Page caching handles pages that look the same to everyone, but it cannot help with the constant stream of database queries WordPress makes while building a page, such as fetching options, user sessions, and query results. On a busy site, especially a shop or membership site, those repeated queries add up and slow everything down. Object caching solves this by storing the answers to those database queries in fast memory so they do not have to be looked up repeatedly. LiteSpeed Cache supports Redis, Memcached, and its own LSMCD for this purpose, and Redis is a reliable, widely supported default. For a typical WordPress site, the performance difference between the options is small, so Redis is a sensible pick.

Diagram comparing how a WordPress page cache stores finished HTML while an object cache stores database query results, showing that the two work best together

One thing worth knowing first: if you are on N6 Cloud Managed WordPress Hosting, Redis object caching is already enabled by default on every plan, so you can read this section to understand what it does and then simply confirm it is active rather than setting it up from scratch. If you are on a Lightning plan under WordPress Hosting, the steps below walk you through enabling it yourself.

On N6 Cloud LiteSpeed hosting, Redis is configured through a fast local socket rather than a network host and port, which is both quicker and simpler because there is no network hop involved. The steps below reflect that socket-based approach, so you can ignore any guide that tells you to type in a host address and a port number.

Enable the PHP Redis extension in cPanel

This is the step that catches almost everyone, because without it WordPress cannot talk to Redis at all and the connection silently fails. Log in to cPanel and open the Select PHP Version tool in the Software section. Move to the Extensions view, find the entry named redis, and tick its box to enable it. Save the change. Your site now has the software bridge it needs to use Redis.

Enable your Redis instance through the LiteSpeed cPanel plugin

N6 Cloud provides Redis through the LiteSpeed cPanel plugin, which uses a feature called LiteSpeed Redis Cache Manager. Rather than a single shared Redis service, this gives every cPanel account its own dedicated, isolated Redis instance stored in your home directory, which is both faster and more secure in a caged CloudLinux environment. Because the instance is per-user and sandboxed, it is reached through a local UNIX socket rather than a network host and port.

Open the LiteSpeed Redis Cache Manager in your cPanel dashboard and ensure your instance is enabled. On N6 Cloud’s CloudLinux servers, the socket for your instance lives inside your account at /tmp/redis.sock, where yourusername is your own cPanel account name. Make a note of that exact path, because you will paste it into WordPress in the next step. Remember that, because this is a socket, there is no hostname or port to record. One convenient detail worth noting is that the LiteSpeed cPanel plugin integrates directly with the LiteSpeed Cache plugin for WordPress, so in many cases, enabling your Redis instance will configure WordPress on the WordPress side automatically. Even when it does, it is worth confirming the settings below to ensure you understand what is switched on. If you cannot find the Redis section in your cPanel, open a support ticket and the N6 Cloud team will enable your instance and confirm the socket path for your account.

Configure the object cache in WordPress

Return to your WordPress dashboard and open LiteSpeed Cache, then Cache, then the Object tab. Work through it as follows.

Set Object Cache to on. This is the master switch for the whole feature.

Set the method to Redis, since that is the service you enabled in cPanel.

For the connection, paste the socket path from your LiteSpeed Redis instance in the Host field. On N6 Cloud CloudLinux accounts, it looks like /tmp/redis.sock. Set the Port to 0 because a socket connection does not use a port, and the zero tells the plugin to use the socket instead. This single detail is where the socket-based approach differs from ordinary setups, and getting it right is what makes the connection succeed on N6 Cloud’s WordPress Hosting servers.

Set the Default Object Lifetime (TTL) for stored items to around 360 seconds. A relatively short lifetime avoids serving stale data while still removing the bulk of repeated database work.

Set the Redis Database ID. If this is the only site using your Redis instance, leave it at 0. If you run several WordPress sites under the same hosting account and Redis instance, give each one a different number from 0 to 7 so they do not overwrite one another’s data. This small step prevents two sites from colliding in shared memory, which is a subtle problem that is hard to diagnose after the fact.

Leave Global Groups and Do Not Cache Groups at their defaults unless you have specific guidance for a plugin, and keep Persistent Connection on, which keeps the link to Redis open for better performance.

Save and verify

Click Save Changes. If everything is correct, the plugin will run a quick check and display a message that reads “Connection Test Passed,” confirming that WordPress is now storing its database queries in Redis. If it instead reports a failure, the cause is almost always one of three things: the PHP redis extension was not enabled, the socket path was pasted incorrectly, or two sites share the same database ID. Re-check those in order, and the test will pass. 

Step six: Browser caching, storing static files on the visitor’s device

So far, every kind of caching we have set up lives on the server. Browser caching is different because it stores files on the visitor’s own computer or phone. When someone loads your site, their browser downloads static files such as your logo, stylesheets, scripts, fonts, and favicon. Browser caching tells their browser to keep local copies of those files for a set period, so that when they move to the next page or return the next day, those files load instantly from their own device instead of being downloaded from your server again. This makes repeat visits and page-to-page navigation feel noticeably faster, and it reduces the number of requests hitting your server.

You control this from LiteSpeed Cache, then Cache, then the Browser tab. There are only two settings, and both are easy to understand.

Browser Cache is the on-and-off switch. Turn it on. When enabled, LiteSpeed adds the appropriate Cache-Control and Expires headers to your static files, which instruct visitors’ browsers how long to retain them. 

Browser Cache TTL sets how long, in seconds, a browser should keep those files before checking for a fresh copy. The default is 31557600 seconds (1 year), which is Google’s recommended value for static assets. A long period is safe because whenever you change a file, LiteSpeed updates its version marker, so browsers know to fetch the new version rather than serving a stale one. If you run a site whose design assets change very frequently, you can lower this, but for most sites, the one-year default is exactly right.

It is worth being clear about what browser caching does not do. It does not replace your page cache or object cache, and it will not help a brand-new visitor who has never downloaded your files before. Its value lies entirely in speeding up repeat visits and page transitions, which is why it works best alongside the server-side caching you have already configured rather than replacing it.

Step seven: ESI, WooCommerce, and caching logged-in users

Ordinary page caching struggles with content that changes from one visitor to the next, such as a shopping cart showing different items or a My Account page. This is where Edge Side Includes, known as ESI, becomes valuable, and it is a feature most general guides skip even though shop owners search for it constantly. ESI lets you serve a page from cache while punching holes in it for the small dynamic pieces, which are then filled in separately. The bulk of the page is cached and fast, while the personal parts stay live and correct. On N6 Cloud Lightning servers, this works because ESI is supported through the LiteSpeed server and QUIC.cloud.

If you run a shop, it is worth knowing that N6 Cloud’s WooCommerce Hosting is built on the same Lightning platform with LiteSpeed caching and Redis object caching tuned for stores, which is the combination that keeps a busy shop fast under load. LiteSpeed Cache recognizes WooCommerce automatically and applies sensible rules out of the box. The Cart, Checkout, and My Account pages are excluded from public caching, so a customer never sees someone else’s details, while the rest of your shop, including product and category pages, is cached and quick to load. The classic example of ESI at work is the mini-cart in your header. With ESI enabled, the product page around the mini-cart is served from the public cache, while the cart count and contents are populated privately for each shopper. This removes the need for a cart refresh request on every page load, which is a common cause of sluggish shops.

To review these options, navigate to the ESI tab. Keep Enable ESI on for a shop. Cache Admin Bar can stay on, which caches the logged-in admin bar as its own block. Cache Comment Form can stay on, keeping the review form live while the rest of the product page is cached. The ESI Nonces area lets you list security tokens that must always be served fresh; LiteSpeed already includes the common WooCommerce ones, and you only need to add entries here if a third-party plugin instructs you to. For most stores, the defaults are correct, and the value of this section is understanding what it does rather than making many changes.

Step eight: the Crawler

When a cached page reaches the end of its lifetime, it expires, and the next visitor has to wait while a fresh copy is built. The Crawler exists to prevent that wait by quietly visiting your pages in the background and refreshing them before real visitors arrive, so almost everyone lands on a page that is already cached. It is switched off by default because it uses server resources, and on shared plans, hosts sometimes limit it.

To use it, open LiteSpeed Cache, go to the Crawler section, then the settings tab, and set the general Crawler option to on. You can leave the Crawl Interval and the Server Load Limit at their defaults to begin with, and check back after a day to see how many pages it is keeping warm. The load limit is a safety valve that pauses the crawler if your server gets busy, so it does not compete with real visitors, which is why it is sensible to leave it in place.

The part that trips people up is telling the crawler which pages to visit, and that is what the Sitemap Settings control. The crawler cannot guess your important URLs on its own; it works from a sitemap, which is simply a list of the addresses on your site. Under the Crawler’s Sitemap Settings, you point it at that list.

The key field is Custom Sitemap. Here, enter the web address of your XML sitemap, which on most sites is generated by an SEO plugin such as Yoast or Rank Math and usually lives at a URL like https://yourdomain.com/sitemap.xml or https://yourdomain.com/sitemap_index.xml. Giving the crawler your real sitemap makes it more efficient, because it then focuses on keeping your actual pages warm rather than wandering into unimportant URLs. If you leave this blank, the crawler has nothing meaningful to work with, so this single field is what makes the whole feature useful.

On a smaller site, the Crawler makes little difference because pages are visited often enough to stay cached naturally, but on a large catalogue or a busy blog, it noticeably smooths out the occasional slow page. If you are on an N6 plan and want to run the Crawler aggressively, the support team can advise on the right interval and load settings for your traffic.

Step nine: Page Optimization, including CCSS, UCSS, and VPI

The Page Optimization area is where you trim the weight of your pages by cleaning up the code your theme and plugins produce. These settings can deliver large gains, but they are also the ones most likely to cause a visual glitch, so enable them in small groups and test after each change rather than switching everything on at once.

Under the CSS Settings and JS Settings tabs, you will find Minify, which strips out spaces and comments to make files smaller, and Combine, which merges many files into fewer requests. Minify is low risk and can usually stay on. Combine is more aggressive and occasionally clashes with a theme or plugin, so enable it, then check your pages carefully. There is also Load JS Deferred, which tells scripts to load after the page appears rather than blocking it, improving perceived speed. This helps most sites but can affect scripts that need to run immediately, so test interactive elements like sliders and forms after enabling it.

The most powerful optimizations live under the QUIC.cloud services and understanding what each one does remove the guesswork.

Critical CSS, or CCSS, gathers the small set of styles needed to display the top of the page, the part visitors see first, and places those styles directly in the page so it can render immediately while the rest of the stylesheet loads in the background. The benefit is that visitors see a properly styled page almost at once, with no flash of unstyled content. LiteSpeed generates and stores critical CSS separately for each content type, such as posts, pages, and products, and the work runs on QUIC.cloud servers rather than on yours.

Unique CSS, or UCSS, goes a step further by removing the styles a page never uses. Themes and plugins load large stylesheets that cover every possible situation, and most of that code is dead weight on any given page. UCSS builds a slimmed-down stylesheet containing only what each page actually needs, which shrinks file sizes and speeds up rendering. It works together with the Combine setting and is generated on QUIC.cloud. One caution: UCSS stores a separate file for each page, so a very large site needs sufficient storage for all of them, especially if Cache Mobile is on. For most sites, this is not an issue, but it is worth knowing.

Viewport Images, or VPI, deals with lazy loading. Lazy loading delays images until a visitor scrolls to them, which saves bandwidth, but if it delays the main image at the top of the page, it can hurt your Largest Contentful Paint score and make the page feel slow to appear. VPI solves this by having QUIC.cloud determine which images appear on the first screen a visitor sees and load them immediately, while everything below the fold still loads lazily. To use VPI, you must have Lazy Load Images enabled under Media Settings, as VPI is the refinement that determines which images to exempt from Lazy Load Images.

Under Media Settings, you will also find Lazy Load Images and Lazy Load Iframes, which defer off-screen media, and Low Quality Image Placeholders, or LQIP, which show a tiny blurred preview while the full image loads so the layout does not jump. Turning on lazy loading together with responsive placeholders and VPI gives you the bandwidth savings of lazy loading without the layout shift or the slow hero image it can otherwise cause.

Step ten: Image Optimization

Images are usually the heaviest part of a web page, so compressing them is one of the surest ways to speed up a site. LiteSpeed Cache handles this through QUIC.cloud, which does the processing so your own server is not burdened. Open LiteSpeed Cache and go to Image Optimization. You can send your existing images to be optimized, and enable automatic optimization so new uploads are compressed as they are added.

The most valuable option here is serving images in the modern WebP format, which is considerably smaller than traditional JPEG or PNG files while looking just as good. Enable WebP delivery, and the plugin will serve the lighter version to browsers that support it, which is nearly all of them, while keeping your originals safe. Because the heavy lifting runs on QUIC.cloud, this is one of the easiest large wins available, and it pairs naturally with the lazy loading and VPI settings from the previous step.

Step eleven: enable the QUIC.cloud CDN

A content delivery network stores copies of your site on servers around the world, so visitors are served from a location near them, reducing the distance data has to travel. QUIC.cloud is unusual because, unlike most CDNs that only cache static files like images and stylesheets, it can cache your dynamic HTML pages as well, extending the benefits of your cache far beyond your own server. Now that the rest of your configuration is in place, you can switch it on.

Open the LiteSpeed Cache Plugin, go to the CDN tab, and set QUIC.cloud CDN to on, and save your changes. Then open your QUIC.cloud dashboard. The site you linked earlier will be listed; select it and click Enable CDN. The final part is pointing your domain’s DNS towards QUIC.cloud so traffic flows through the network, which you can do through QUIC.cloud’s own DNS, through Cloudflare in proxy mode, or another supported method. After the DNS change, QUIC.cloud automatically verifies your domain and issues an SSL certificate. You can press Refresh Status to watch it complete. If DNS changes make you nervous, this is a good moment to contact N6 Cloud support, who can guide you through pointing your records correctly.

Bar chart showing typical improvements after configuring LiteSpeed Cache on a LiteSpeed server with QUIC.cloud, with page load time falling from 3.8 seconds to 1.1 seconds, Largest Contentful Paint from 3.1 to 0.9 seconds, and Time To First Byte from 680 to 140 milliseconds

Recommended safe settings at a glance

If you would like a quick reference while you work, the table below summarises the settings that matter most, along with a sensible starting value for each. Treat these as a safe baseline, then test your own site and adjust where needed.