Hostinger runs on LiteSpeed Web Server and ships with the LiteSpeed Cache plugin pre-installed on most WordPress plans, but the default install leaves several cache layers switched off in hPanel. This guide walks through enabling every layer that actually moves your page load time, then shows how to verify LiteSpeed Cache is serving your site from cache and how to fix the issues that trip people up most often.
Prerequisites
You will need an active Hostinger web hosting plan (Premium and above ship with LiteSpeed Web Server), a WordPress site installed on that plan, and admin access to both hPanel and the WordPress dashboard. If you have not set up your site yet, work through how to set up Hostinger first, then come back here once WordPress is live.
Step 1: Check Whether LiteSpeed Cache Is Already Active
Hostinger auto-installs the LiteSpeed Cache plugin (LSCWP) on WordPress sites created through hPanel, so before you change anything, check the current state. In the WordPress admin, open Plugins and look for LiteSpeed Cache in the active list. If it is there, the plugin side is handled. If it is missing (this happens on sites migrated in from another host), install it from the WordPress.org plugin directory and activate it.
Next, open LiteSpeed Cache > Cache in the WordPress sidebar and confirm that Enable LiteSpeed Cache is set to ON. If it is already ON, the site is caching at the plugin level, but the server-side toggles in hPanel may still be off. Continue to Step 2.
Step 2: Turn On Cache Controls in hPanel
Server-side cache is controlled from hPanel, not from WordPress. Log in to hPanel, open Websites, pick the site you want to speed up, and use the sidebar to go to WordPress > Overview. Scroll to the Core section. You will see three switches worth attention:
- Cache: the primary page cache. Toggle this ON. It tells LSWS to store fully-rendered HTML for guest visitors so PHP is skipped on subsequent requests.
- Object cache: caches WordPress database query results in memory via LiteSpeed Memcached (LSMCD). Toggle ON if the switch is available. On the entry Premium plan it may be greyed out; Business and Cloud plans expose it.
- Automatic updates: unrelated to cache but worth leaving ON so the LSCWP plugin stays current with LiteSpeed server releases.
Changes take effect immediately. There is no need to restart anything from the hPanel side.
Step 3: Configure the LSCWP Plugin
Back in the WordPress admin, open LiteSpeed Cache > Cache. The defaults are conservative, so bump the following:
- Cache tab: Enable LiteSpeed Cache ON, Cache Logged-in Users OFF unless you run a membership site, Cache Commenters ON, Cache REST API ON, Cache Login Page ON, Cache favicon.ico ON, Cache PHP Resources ON.
- TTL tab: default values are fine for most sites (Default Public Cache TTL 604800, Default Private Cache TTL 1800). Leave them unless you are debugging.
- Purge tab: enable Purge All On Upgrade and add "All pages" to Auto Purge Rules For Publish/Update so cached pages refresh when you push new content.
- Browser tab: enable Browser Cache and set Browser Cache TTL to 31557600 (one year) for standard sites.
Click Save Changes at the top of each tab as you go. LSCWP applies settings per tab, not globally.
Step 4: Verify LiteSpeed Cache Is Actually Serving
Enabling switches is not the same as caching. To confirm the server is returning cached responses, run a quick header check from your terminal:
curl -I https://yourdomain.com/Look for an x-litespeed-cache header in the response. Values you may see:
- hit: the page was served from cache. This is what you want.
- miss: the page was rendered fresh and stored. Run the command a second time; you should see a hit on the follow-up request.
- no cache: something is excluding this URL from caching. Check the LSCWP Excludes tab and any conflicting plugin (WP Rocket, W3 Total Cache) that may be intercepting.
If the header is missing entirely, LSWS is not caching for this domain. That usually points to a plugin-side setting that has not saved, or a CDN in front of the site returning its own headers before LiteSpeed can respond. Purge from LiteSpeed Cache > Toolbox > Purge All and retest.
Step 5: Handle WooCommerce and Membership Cache Rules
Guest pages cache cleanly. Cart, checkout, account, and admin pages must not cache the same way, or visitors will see stale sessions. LSCWP already excludes the standard WooCommerce endpoints by default, but if you use custom checkout URLs, add them under Cache > Excludes > Do Not Cache URIs. For membership sites (MemberPress, LearnDash), set Cache Logged-in Users to ON only if the plan is Business or higher (Object Cache is required to make logged-in cache safe) and add role-based excludes for any role that sees personalized content.
Common Issues and Fixes
Changes to a page are not showing on the front end
The old cached HTML is still being served. Purge it from LiteSpeed Cache > Toolbox > Purge All. If content still lags, check whether Cloudflare or another proxy is in front of the site; you may need to purge there too.
Object Cache toggle is greyed out in hPanel
Object Cache (LSMCD) is a Business plan feature and above. If you are on the entry Premium plan, the switch is disabled by design. Upgrading to the Business plan exposes it, or you can stick with page cache alone; sites without heavy database queries do not miss it much.
PageSpeed score is still low after enabling cache
Caching fixes TTFB and repeat-visit speed but does nothing for images, unused CSS, or blocking JavaScript. If PageSpeed Insights still flags LCP or CLS after enabling cache, the fix is in image optimization and script deferral rather than more caching. LSCWP has image and CSS tabs that handle both, and the broader picture on Hostinger is covered in the Hostinger WordPress Optimization Guide, which walks through the rest of the speed stack once cache is running.
WordPress admin feels slower after enabling LSCWP
The plugin runs its own crawler and image optimization queue in the background. If the admin is sluggish, open LiteSpeed Cache > Crawler and set the crawler to run less frequently, or disable it entirely if you do not need proactive cache warming.
QUIC.cloud CDN and Cloudflare conflict
If you turn on both QUIC.cloud (LiteSpeed's own CDN, integrated in LSCWP) and Cloudflare with full caching enabled, dynamic content can serve stale. The safe pattern on Hostinger is one dynamic-content cache layer at a time: use QUIC.cloud for dynamic caching and set Cloudflare to cache static assets only, or vice versa. If you want to run Hostinger's own built-in CDN alongside cache instead, see how to enable Hostinger CDN on WordPress for the hPanel toggle path.
