Set up LiteSpeed Cache on Drupal

LiteSpeed has a built-in cache that Drupal can use to avoid repeated PHP executions for compatible content. The improvement depends on the site, the cacheable content and the hit rate.

The LiteSpeed Cache module connects Drupal's tags and purges to that cache. The website must use LiteSpeed or OpenLiteSpeed and the server must have the cache enabled; installing the module does not replace this requirement.

The 1.3 branch documented here requires Drupal 10.3 or Drupal 11. Check the stable version and its published requirements before installing it: do not downgrade Drupal or force Composer to get around a conflict.

1. Make a backup

Save a recoverable copy of the files and the database. If the website has sessions, forms or personalised content, make the change in a test environment first.

2. Install the module with Composer

From the project's root directory, run:

composer require 'drupal/lscache:^1.3'

Composer will select a compatible version within that branch. For other Drupal versions, use the command shown on the official project page.

3. Enable LiteSpeed Cache

Enable LiteSpeed Cache from Extend or with Drush:

vendor/bin/drush en lscache -y

Also add the required directives to the .htaccess in Drupal's root:

<IfModule LiteSpeed>
    CacheLookup public on
    php_flag output_buffering off
</IfModule>

Without both directives, the module may send its headers without LiteSpeed storing the responses. Drupal's status report checks this configuration. The module's other options are under Configuration > Development > LiteSpeed Cache.

4. Check that it works

Review Drupal's status report in case the module detects outstanding directives or server data.

Then open the website in a private window, visit a public page twice and check its response headers in the browser's developer tools. A later request for a compatible public page may show a LiteSpeed header with the status hit; the first may appear as miss while the cache is generated. Make sure you are looking at a request to the server, not a copy from the browser's memory.

If it always shows miss, check whether the page depends on a session, a cookie or personalised content. Also confirm that no other page cache is interfering.

Do not turn on public caching for pages with private or user-specific data without first checking how sessions behave.

Test invalidation and disable

Edit a test piece of content and check that the change appears on its related pages. Test search, forms, logging in and out, and two users with different permissions. Cache tags must reflect the real dependencies of custom modules.

If you need to remove it, purge the cache and uninstall the module using Drupal's procedure before removing the Composer package. Keep the other .htaccess rules. If the problem started when you added the directives, restore that change and check the status report and the error log.