LiteSpeed Cache SEO Hostinger Singapore: Setup Guide 2026

Quick answer: LiteSpeed cache SEO Hostinger Singapore setups work because Hostinger’s servers actually run LiteSpeed, letting the free LiteSpeed Cache plugin activate true server-level caching. Configure cache TTL, exclude cart and checkout pages, enable WebP image optimisation, and test CSS/JS minification carefully to meaningfully improve Core Web Vitals for Singapore WordPress sites.

If you run a WordPress site on Hostinger in Singapore, someone has probably told you to just install LiteSpeed Cache and call it done. It’s not that simple, and treating it that way is one of the more common technical mistakes we see on small business sites. LiteSpeed Cache behaves very differently depending on what server it’s actually running on, and Hostinger’s use of LiteSpeed servers is exactly why the plugin is worth using there in the first place. This guide walks through the settings that actually matter: cache configuration, exclusions, image optimisation, minification risk, and database cleanup. For a broader look at how caching fits into your wider technical and on-page work, our full WordPress SEO guide covers the fundamentals, and if speed is your main concern right now, our WordPress page speed and SEO guide goes deeper into the specific metrics Google measures.

Why LiteSpeed Cache Behaves Differently on Hostinger

Most WordPress caching plugins do the same basic job everywhere: they generate a static copy of a page and serve it instead of rebuilding the page from scratch on every visit. LiteSpeed Cache can do that too, but its real advantage is server-level caching that only activates when the site is actually hosted on a LiteSpeed web server (either LiteSpeed Technologies’ commercial server software or the open source OpenLiteSpeed). On that kind of server, cached pages are served directly at the web server layer, before WordPress or PHP even loads, which is considerably faster than a plugin-only caching approach.

This is the part that trips people up. LiteSpeed Cache is a free plugin, and it will install and run on almost any WordPress host, including standard Apache or Nginx shared hosting. It just will not do the thing that makes it worth choosing over alternatives like WP Rocket or W3 Total Cache. On non-LiteSpeed hosting, the plugin falls back to a more limited, page-caching-only mode, and you lose the server-level advantage entirely. We recommend confirming your hosting stack before you build your whole speed strategy around this plugin, because installing it on the wrong server gives you the appearance of optimisation without the substance.

Hostinger is one of the more common hosts we see among Singapore SMEs precisely because its shared and WordPress hosting plans typically run on LiteSpeed servers. That pairing is part of why this specific combination tends to produce more consistent results than the same plugin on a generic host, and it is a good example of why technical SEO work needs to start with the hosting stack rather than the plugin list.

Confirming Your Hostinger Site Is Actually Running LiteSpeed

Before configuring anything, verify the server itself. Most Hostinger shared and WordPress hosting plans use LiteSpeed, but plan types do change over time, and if a site has been migrated, resold, or moved between hosting products, that assumption can quietly stop being true.

The most reliable check is inside the LiteSpeed Cache plugin itself. On the plugin’s Dashboard tab, look for a line confirming the “LiteSpeed Web Server” status. If it shows as detected, server-level caching is available to you. If it shows as not detected, the plugin will still function, but only in its reduced, page-caching mode, and several of the more advanced tabs will either be greyed out or simply will not do anything meaningful. You can also check this from the hosting side: Hostinger’s hPanel typically lists the web server type under your hosting plan details, and support can confirm it directly if you are unsure.

In our experience, this single check gets skipped constantly. When we audited Hostinger-hosted sites that had “already done” their caching setup, a fair number had never actually confirmed the server type, they had just assumed LiteSpeed was running because the plugin name matched the host’s marketing. If you’re not confident in your current technical setup at all, a proper technical SEO audit will catch this kind of gap along with the rest of your site’s infrastructure issues before it becomes a bigger problem.

Core Cache Settings: Enabling Cache and Setting TTL

Once you’ve confirmed LiteSpeed is running, head to the Cache tab in the plugin settings. The first toggle, “Enable Cache,” needs to be switched on for both the front end and (if relevant) the back end. This is the setting that actually starts generating and serving cached pages, and it’s surprising how many sites have the plugin installed with this left off entirely.

Next, look at the TTL (time to live) settings, sometimes labelled cache expiry. This controls how long a cached version of a page is kept before LiteSpeed regenerates it. The default public cache TTL is usually somewhere in the range of a few hours to a full day, and for most brochure-style SME sites that update infrequently, a longer TTL (12 to 24 hours) is perfectly reasonable. Sites that publish content often, like blogs or news pages, may want a shorter TTL so new posts appear promptly without needing a manual purge.

There are separate TTL fields for private cache, front page cache, and feed cache, and it’s worth setting each deliberately rather than leaving every field at its installed default. We’ve seen sites where the front page TTL was left far too short, meaning the homepage, usually the highest-traffic page on the site, was being rebuilt constantly instead of served from cache, which defeats much of the point of installing the plugin at all. If this level of configuration feels like more than you want to take on yourself, it’s the kind of task we fold into our ongoing technical work, and our pricing page outlines how that’s structured.

Excluding Logged-In Users and WooCommerce Pages From Caching

Not every page on your site should be cached, and getting this wrong causes real problems, not just missed opportunity. Under the Cache tab’s exclusion settings, you’ll find options to exclude specific URLs, cookies, or user roles from caching entirely.

Logged-in users, particularly site administrators and editors, should almost always be excluded from the public cache. Otherwise you risk one logged-in user’s session data, or a partially loaded admin bar, being served to a completely different visitor. If your site runs WooCommerce, this becomes even more important: cart, checkout, and my-account pages must be excluded from caching, because these pages need to reflect live, session-specific data (what’s actually in a customer’s cart, their order status, and so on). LiteSpeed Cache’s WooCommerce-specific settings typically handle much of this automatically once WooCommerce is detected, but it’s worth manually checking the exclusion list rather than assuming the defaults cover every page template your theme uses.

It’s also worth setting up purge rules so that cache clears automatically when relevant content changes, for example, purging the shop and category pages when a product’s stock status updates. Getting exclusions right protects the accuracy of your site as much as its speed, and for small business owners running lean WooCommerce stores on Hostinger, this is usually the setting most worth double-checking before launch.

The Image Optimisation Module and QUIC.cloud

LiteSpeed Cache includes a built-in image optimisation feature under its Image Optimization tab, and it’s one of the more useful parts of the plugin for Singapore SMEs who upload product photos or blog images without resizing or compressing them first. The feature works by sending images to QUIC.cloud, LiteSpeed’s own cloud service, which compresses them and can convert them to WebP, a more efficient image format that typically produces noticeably smaller file sizes than standard JPEG or PNG at a similar visual quality.

To use it, you request optimisation from within the plugin, QUIC.cloud processes the images in the background, and once complete, you pull the optimised versions back into your media library. The plugin can also be set to serve WebP versions automatically to browsers that support the format, while still serving the original to browsers that don’t. This matters for Core Web Vitals because unoptimised images are one of the most common causes of poor Largest Contentful Paint (LCP) scores, which measure how long the largest visible element on a page takes to load. Image optimisation is a routine part of technical speed work, and our case studies show where image work sits within a wider SEO programme alongside content, local and technical fixes.

Our beauty SEO case study shows why this step matters on image-heavy sites. A Dempsey Hill day spa’s website carried heavy ambience photography, and unoptimised images are the primary cause of mobile speed failures in that category. Compressing and lazy-loading the images was part of the schema and technical phase that lifted its mobile Lighthouse score from 46 to 74. The tool in your stack may differ, but the principle is the same.

QUIC.cloud does have usage limits on its free tier, so very image-heavy sites may need to pace optimisation requests or consider a paid QUIC.cloud tier, though we’d suggest starting with the free allowance and monitoring usage before committing to anything beyond it.

CSS and JS Minification: Where Sites Break

This is the section we’d ask you to slow down on. The Page Optimization tab includes settings to minify CSS and JavaScript (stripping out unnecessary spacing and characters to reduce file size) and to combine multiple CSS or JS files into fewer, larger files (reducing the number of separate requests a browser has to make). Both can meaningfully improve load times on paper.

In practice, combining and minifying CSS and JS is also the single most common way a LiteSpeed Cache setup breaks a site’s front-end layout. Some themes and plugins load CSS or JavaScript in a specific order that combination settings can disrupt, and a script that depends on another script loading first can silently fail once files are merged or reordered. The plugin’s critical CSS feature, which tries to identify and inline the CSS needed for above-the-fold content so the page renders visually complete faster, carries a similar risk: get the critical CSS generation wrong and you can end up with a flash of unstyled or oddly styled content on page load.

The widely repeated advice to “just turn on all the optimisation settings” ignores how much this varies by theme and plugin combination. We recommend enabling these settings one at a time, not all at once, and checking the site on desktop and mobile after each change, including pages with forms, sliders, and any custom page builder elements. If something breaks, you can usually exclude the specific problem file from combination rather than abandoning the setting entirely. Testing thoroughly here takes real time, which is exactly why a lot of site owners either skip these settings altogether (leaving speed gains on the table) or turn everything on and never notice the layout issue until a customer complains.

Database Optimisation: Cleaning Up the Backend

The Database tab in LiteSpeed Cache is often overlooked entirely, but a bloated WordPress database can slow down both the admin area and, indirectly, front-end performance. Over months or years, a typical WordPress installation accumulates post revisions (saved drafts of every edit you’ve ever made), expired transients (temporary cached data many plugins generate), spam and trashed comments, and orphaned metadata from plugins you may no longer even use.

The Database tab lets you clean each of these categories individually: revisions, drafts, trashed posts, spam comments, trashed comments, and expired or all transients. There’s also an option to optimise database tables directly, which can reduce overhead built up from repeated inserts and deletes. It’s worth backing up your database before a large first cleanup, particularly if you’ve never run this kind of optimisation before and don’t know how much old data has built up.

We found, when reviewing WordPress sites that had been running for several years without any database maintenance, that revision cleanup alone often removed a large volume of unnecessary database rows. This doesn’t usually produce a dramatic, single-number speed improvement on its own, but it keeps the database lean, which matters more as a site grows and adds more products, posts, or forms over time. Setting a scheduled cleanup (weekly or monthly, depending on how active the site is) is more sustainable than relying on remembering to do it manually, and it belongs on any ongoing technical maintenance checklist. You can read more about our team on our about page.

Realistic Core Web Vitals Gains to Expect

It’s worth being honest about what a properly configured LiteSpeed Cache setup can and can’t do. Core Web Vitals (Google’s set of metrics measuring loading speed, interactivity, and visual stability) respond well to server-level caching, image optimisation, and reduced file sizes, and many Hostinger-hosted sites see meaningful improvement in Largest Contentful Paint after a proper setup, particularly if images were previously unoptimised. Total Blocking Time and Interaction to Next Paint can also improve when JS is minified and combined sensibly, since the browser has less script to parse and execute.

That said, LiteSpeed Cache is not a substitute for good site architecture, a reasonably lightweight theme, or a hosting plan with enough resources for your traffic level. A site built on a heavy page builder with dozens of unnecessary plugins will still load slowly even with every LiteSpeed Cache setting enabled correctly, it will just be somewhat less slow than before. We’d frame the realistic range as: meaningful, often visible improvement for sites that were previously unoptimised, and more modest, incremental gains for sites that already had reasonable performance before you started. Below is a quick reference for what to configure in each main tab.

Getting the Sequence Right

The order you work through these settings in matters almost as much as the settings themselves. Confirm the server type first, since nothing else in this guide is worth doing if LiteSpeed isn’t actually running. Then enable core caching and set sensible exclusions, so you have a stable baseline before introducing anything riskier. Only after that baseline is confirmed working should you move into image optimisation, then minification and combination (tested one setting at a time), then database cleanup as ongoing maintenance rather than a one-off task. This whole sequence is a good example of the kind of structured process we bring to every project, which you can see summarised on our homepage.

Our clients who’ve had the smoothest results are the ones who resisted the urge to enable everything in one sitting and then walk away. A caching setup that’s checked once at launch and never revisited tends to drift out of step with the site anyway, new plugins get added, new page templates get built, and settings that worked fine six months ago can start causing subtle issues nobody notices until organic traffic or conversion rates quietly dip. Treating this as a one-time task, rather than something to periodically revisit, is a big part of why so many “already optimised” sites we look into turn out not to be.

Field notes: In our law firm SEO case study, a Tanjong Pagar general practice firm started with a mobile Lighthouse score of 52/100. The month 1 technical audit lifted it to 81/100 through image compression, deferring render-blocking JS and font loading optimisation, the same levers LiteSpeed Cache gives you control over. Default settings rarely deliver this on their own; each setting has to be reviewed and tested.

Frequently Asked Questions

Does LiteSpeed Cache work if my site is not hosted on Hostinger?

Yes, it will install and run on most WordPress hosts, but it only unlocks its full server-level caching advantage on a genuine LiteSpeed or OpenLiteSpeed server. On hosts running standard Apache or Nginx, the plugin falls back to a more limited page-caching mode. It still works as a basic caching plugin in that case, but you lose the deeper performance benefit that makes LiteSpeed Cache worth choosing specifically, so it’s worth confirming your host’s server type before relying on it as your main speed solution.

How do I check if my Hostinger plan is actually running LiteSpeed?

The quickest way is inside the LiteSpeed Cache plugin’s Dashboard tab, which shows whether “LiteSpeed Web Server” is detected on your account. You can also check hPanel, Hostinger’s account management area, where hosting plan details typically list the web server type. If you’re still unsure, Hostinger’s support team can confirm directly. Most Hostinger shared and WordPress hosting plans do run LiteSpeed, but it’s worth verifying rather than assuming, particularly on older or migrated accounts.

Will LiteSpeed Cache conflict with other caching plugins?

Yes, running two caching plugins at once is a common cause of unpredictable behaviour, including pages showing outdated content or layout glitches. Before installing LiteSpeed Cache, deactivate any other caching plugin such as WP Rocket, W3 Total Cache, or WP Super Cache, and clear any existing cached files. It’s also worth checking whether your host applies its own server-side caching layer separately, since stacking multiple caching systems without understanding how they interact tends to create more problems than it solves.

Should I enable CSS and JS combination for a WooCommerce store?

It can help, but WooCommerce stores tend to be more sensitive to combination settings because cart, checkout, and product pages often load specific scripts that need to run in a particular order. We’d suggest enabling combination gradually and testing the cart and checkout flow specifically after each change, not just the homepage. If checkout stops working correctly after a change, that setting is almost always the cause, and it’s better to exclude the affected files than leave a broken checkout live while you investigate.

Does the image optimisation feature in LiteSpeed Cache cost extra?

QUIC.cloud, the service behind LiteSpeed Cache’s image optimisation, offers a free usage tier that covers a reasonable number of image optimisation requests each month, which is enough for many small business sites. Very image-heavy sites, such as ecommerce stores with large catalogues, may exceed the free allowance and need to consider a paid QUIC.cloud plan. We’d recommend starting with the free tier, monitoring your usage inside the plugin, and only upgrading if you consistently run against the limit.

How often should I run database optimisation in LiteSpeed Cache?

For most small business sites, a monthly cleanup of revisions, transients, and spam comments is sufficient to keep the database from accumulating unnecessary bulk. Sites that publish content frequently, or run active WooCommerce stores with high order volumes, may benefit from a more frequent schedule, such as weekly. Always back up the database before a large first cleanup, especially if optimisation has never been run before, since there’s no way to know in advance how much old data has built up.

Can LiteSpeed Cache alone fix poor Core Web Vitals scores?

Not entirely. LiteSpeed Cache addresses caching, image compression, and file minification, which are meaningful contributors to Core Web Vitals, but it can’t fix a fundamentally heavy theme, excessive plugins, poor hosting resources for your traffic level, or bad page structure. Think of it as one important layer of a broader technical setup rather than a complete fix. Sites with genuinely serious Core Web Vitals problems usually need a wider technical review, not just a caching plugin adjustment.

What is the difference between LiteSpeed Cache and WP Rocket on Hostinger?

WP Rocket is a premium, plugin-only caching solution that works the same way regardless of server type. LiteSpeed Cache is free and, on Hostinger specifically, gains a server-level caching advantage that plugin-only tools can’t replicate, because it integrates directly with the LiteSpeed web server software itself. On a LiteSpeed host like Hostinger, LiteSpeed Cache is generally the stronger and more cost-effective choice; on a non-LiteSpeed host, the comparison changes and a plugin-only tool may perform more predictably.

Is it safe to enable all LiteSpeed Cache settings at once on a live site?

We wouldn’t recommend it. Several settings, particularly CSS/JS combination and critical CSS generation, carry a real risk of breaking page layout or functionality, and it’s much easier to diagnose an issue if you’ve changed one thing at a time. Enable core caching first, confirm the site behaves normally, then move through image optimisation, minification, and combination settings individually, checking the site after each one, ideally on a staging copy before touching a live production site.

Getting LiteSpeed Cache right on Hostinger isn’t a one-afternoon task if you want it done properly, but it’s also not something that requires deep technical expertise once you understand which settings carry risk and which are safe defaults. If your site sits within a specific industry vertical with its own technical quirks, our industry-specific SEO pages go into more detail on sector-level considerations. For a full picture of where your site currently stands, our SEO services overview outlines how we approach technical work for Singapore businesses. If you’d rather have someone check your current setup than work through it alone, you can reach out directly.