SQLite Cache

On first request to a given URL whole html code of a page is being stored in
the SQLite database. On next requests to the same page WordPress core will
not be loaded at all but the content of a page will be retrieved from the
the SQLite storage therefore duration of PHP execution decreases in dozen
of times.

Many sites on the same webserver may use common SQLite storage.
Compatible with WordPress Multisite. Requires PHP SQLite PDO.

In comparison with plugins generating static html pages this plugin does not
create multiple directories and html files but stores all generated pages
in one file. Moreover, many wordpress sites on the same webserver may use
common SQLite storage. Keeps 404, 301, 302, 304 HTTP statuses, optionally
supports ETag, Expires, Content-Length, Content-Type (with charset) headers.

As the cache script doesn’t load the WordPress core where does it save it’s settings?

To get the plugin working you need to define the SQLite storage location in
the index.php of the wordpress installation directory (note, not in wp-config.php
but index.php). Besides of the SQLite file, this directory contains general
settings file (compression setting) and a subfolder for per domain settings.
In the admin area (plugin setting page) and to remember after deactivation where
the cache located, litecache_path WordPress option is used.

How the plugin handles URLs with and without `www.` prefix?

The presence of www. prefix is defined in Settings – General.
The plugin stores with_www parameter in domains/yourdomain.ini file in the
cache directory and redirects requests correspondingly; these redirects are
being processed before cache usage.

Is it WordPress Multisite compatible?

Yes, but for subdomains mode only (blogname.example.com), not for
example.com/blogname. A superadmin of a multisite network has access to
the first setting form (cache location), blog admins have access to the
second form and purge form.