LiteSpeed Blog / Products / LiteSpeed Web Server / Happy Holidays – LiteSpeed Cache for WordPress (Beta) is Here!

Happy Holidays – LiteSpeed Cache for WordPress (Beta) is Here!

LiteSpeed Cache for WordPress

We are excited to announce the beta release of the much anticipated LiteSpeed Cache Plugin for WordPress, our holiday gift to you!

LiteSpeed Cache for WordPress (LSCWP) uses the LSCache plugin for WordPress to communicate with LiteSpeed Web Server and LSCache to statically cache your dynamic WordPress pages, greatly reducing page load time and server load. As development continues, we will be adding many more features – such as ESI support similar to what can be seen in LiteMage Cache for Magento.

Download LSCWP Plugin (Requires LSWS 5.0.10+)
LSCWP Installation Guide

As this is only a beta release, we are counting on the LiteSpeed community to help test the LSCWP plugin as we move closer to an official release. To provide us with any bug reports, feedback, or suggestions, email us at info@litespeedtech.com.

Happy Holidays from everyone at LiteSpeed!

Tags: wordpress

Categories:LiteSpeed Web Server , LSCache

Comments

Jong Wead May 17th, 2017
Hi, on occasion I see a 500 server error when I browse your website. Just a heads up, best wishes
Reply
Frank December 24th, 2015
How does this compare, functionally speaking, to existing WordPress caching solutions such as WP SuperCache?
Reply
- Stiv December 26th, 2015
  Let me explain.
  1. WordPress Cache Plugin like W3TC or WP-SuperCache (via rewrite as fastest solution)
  Scenario:
  – Plugin is generating html file based on plugin/user logic
  – Web server parse the request and based on that key is checking is file exist via mod_rewrite. If exist, page is returned as static html, else request is processed by php for generating html file for next request.
  Speed: very fast since server is serving static file. I only don`t like it because server is checking if file exist even for css, js requests.
  Flexible: very flexible, plugin have full control to determine if request should be saved as html file.
  Easy: Yes
  2. Litespeed WordPress Cache
  Scenario:
  – Plugin is sending extra headers based on plugin/user logic to response and Litespeed determine if page should be cached. This headers are not send to client browser.
  – Litespeed parse the request and based on that key is checking if cache exist. If exist, page is returned from cache, else request is processed by php for generating cache headers.
  Speed: very fast since request is served from LSCACHE.
  Flexible: very flexible, plugin have full control to determine if request should be cached.
  Easy: Yes
  3. Varnish Cache
  – Varnish is caching based on varnish configuration.
  – Varnish parse the request and based on that key is checking if cache exist. If exist, page is returned from cache, else request is forwarded to backend server as apache and after response from backend varnish is caching for next request.
  Speed: very fast since request is served from memory cache, but also file cache is fast.
  Flexible: very flexible with advanced options like removing cookies, headers etc..
  Easy: No
  Personally i like first solution because at this time is fastest caching solution and for example W3TC have also persistent object cache, minification, cdn support and so on. I don`t like Varnish because sometimes is hard to setup but i don`t like it more since cant process ssl and actually you have double layered architecture (web server + varnish).
  If i was Litespeed developer, i`ll make ultimate caching plugin witch will include:
  1. Rewrite LSCache just for wordpress, this will speed up min 10%. Eq: don`t check for private cache if exist when wordpress don`t use it.
  https://github.com/litespeedtech/openlitespeed/blob/master/src/modules/cache/cache.cpp#L412
  2. Removing cookies from static files. Easy job.
  3. Persistent object cache (Apcu, Memcached, Redis). Easy job since there are already open source proejcts.
  4. Html minification before cache at server level just before insert to cache. Easy job only with rewrite.
  5. Move all js to footer before cache at server level just before insert to cache. Easy job only with rewrite.
  6. Combine js/css before cache at server level just before insert to cache
  This need to have more control, but good example is like:
  /path/style.css
  /path/style2.css
  make has key for this paths
  remove from html
  insert /path/hash.css
  when user request /path/hash.css litespeed know with files are those
  7. Image optimization, progressive and also WebP
  8. Rewrite js/css/img url for cdn pull zone support at server level just before insert to cache. Easy job only with rewrite.
  9. Esi support but i dont thing this will be used by wordpress community since it need skills and wordpress already have persistent function cache.
  Then you can rename your product as “Full WordPress LiteCache Solution” 😀
  Since you made good way to communicate with wordpress (response headers) and since headers can contains complex data, you can make all this. Once done i bet it will speed up wordpress at MINIMUM 20% more requests and MINIMUM 50% faster user experience in rendering.
  There are 1000 questions, 1000 combinations and 1000 answers when we speed about wordpress speed but this was my 2 cents 🙂
  Reply
  - Lauren December 28th, 2015
    Stiv,
    Thanks for your insight. I’m glad that you have looked into the code of LSCache plugin.
    Right now, it is just a beginning to have the structure in place. As you can see, it’s much simpler than other PHP cache solution. As the cache is actually handled by LSWS.
    One important feature you missed, is the we have tag based cache management, and it is many-to-many mapping. So this is really powerful. For example, a post can have many tags associated, like P.postid, A.authorid, D.monthlyarchive, T.tagid. When you have a purge event, you can simply issue all the related tags you want to purge, there’s no need to find out what’s the original urls you need to purge. We just need to make sure that we capture all scenarios, tag a page proper, and capture all the purge events to purge properly. It does not require permalink, and support https.
    Private cache will not be checked, it’s configured through lsws – check private cache (disabled).
    For other stuff like html minify, object cache, there’re other plugins can do that. and LSCache plugin can work along with them, I don’t really feel the urgent need for that. Especially if only generated once and get purged upon updates. contents are served as gzipped by lsws.
    For ESI, I do see the great benefit, as lsws already supports it and has production level quality due to our successful launch of LiteMage. For example, you may have side bars with widgets showing popular articles, recent posts, which can be refreshed every 5 minutes, and your page itself can be an old post. Like you monthly archived pages can have public ttl of 1 month, and the sidebar will be in its ESI block and get updated every 5 minutes. But that does require change a little bit of your template code, so each site will be different. The impact can be huge.
    Currently many hosts are using LSCache for WP sites, using rewrite rules and cache for short time like 5 minutes. More info here. Why? I think they saw better performance and easier to use than W3TC or WP-SuperCache. With LSCache plugin, this will be even better, as we can set longer ttl, and only purge when needed.
    There’s a lot to do to enhance this plugin. This is just a good start for 2016.
    Lauren
    Reply