What’s new in LiteSpeed Cache 3 for WordPress?

LiteSpeed Cache is a popular tool that offers high performance cache management and has a number of functions to optimize code generated by WordPress. For several months now, a new version of the plugin has been developed and the progress of work can be tracked by viewing the github repository or downloading the beta version and testing it personally.

In this article, I will try to present the most important changes and functions, which will most probably appear in version 3.0 – based on the analysis of version 3.0 RC3. If you believe the log entries – publication of the final version 3.0 is scheduled for 1 April 2020, but I assume that this is not a final date.

If you don’t know what LiteSpeed Cache is and what functionalities it offers, I invite you to read previous article about it first:

The best caching plugin for WordPress

You can also track the LiteSpeed Cache tag for WordPress on my blog, where entries related to this plugin appear.

Connecting QUIC.cloud and LiteSpeed Cache together

The first striking thing (apart from the refreshed user interface) is a clear attempt to combine and monetize two LiteSpeed services – a free add-on to WordPress and a semi-free (but aiming at a premium service) QUIC cloud.

After starting LiteSpeed Cache 3, we will be asked to set up an account and generate an API key for free through the QUIC.cloud backend (available at the temporary address my.preview.quic.cloud), which will allow us to use the plug-in functionality that requires the use of external servers from LiteSpeed Technologies.

So far, QUIC.cloud has been only an experimental CDN service in the early stages of development. However, it seems that it was decided to combine resources responsible for Critical CSS generation and image optimization via LiteSpeed Cache plug-in with CDN services.

After generating the API key and going to the dashboard of the QUIC.cloud service, we will see a summary of the usage of particular functionalities offered by QUIC.cloud servers, and thus being part of the LiteSpeed Cache for WordPress.

The same data can also be seen in the dashboard of the LiteSpeed Cache plug-in.

The data is split into sections:

• Optional CDN (whose configuration still leaves a lot to be desired, comparing the process to, for example, Cloudflare integration, which is fabulously simple – especially for hosts using the Cloudflare API)
• Image optimization
• Critical CSS generation
• Generating Low Quality Image Placeholder

The dashboard offers us the possibility to display details regarding the usage of each service separately and thus allows us to draw some insights on possible future costs of using the LiteSpeed Cache in WordPress.

Image optimization

It seems that image optimization will still be free, but the speed of image processing by LiteSpeed servers will depend on the current load and the possibility to use a limited, fast queue. The use of this queue will be paid in credits, which are voluntary, and 2000 units are offered for start up, which refresh every month.

What does it mean in practice – so far it is not known – probably the details will be revealed with the publication of the final version of LiteSpeed Cache version 3, and the costs will dynamically evolve with the growth of users and infrastructure expansion.

Critical CSS

The situation is slightly different with generating a critical CSS, i.e. styles for the views the user will see on the screen before he starts scrolling the page (the LiteSpeed Cache plugin places such styles in the page header when the rest of the CSS style is loaded asynchronously). The QUIC.cloud service in cooperation with the LiteSpeed Cache plugin allows you to generate a critical CSS using credits – in this case, however, there are no standard and fast queues – either there are credits that allow the server to work, or there are no credits and you need to buy them to use this optimization method.

Low Quality Image Placeholder

LQIP is a novelty in LiteSpeed Cache 3, extending already existing methods of image lazy loading. LQIP is based on displaying low quality substitute image when the final one is loaded in the background. Low quality thumbnails are generated by servers responsible for providing QUIC.cloud service and billing is based on available credits. So if we want to use a slightly more sophisticated method of lazy loading, more accessible for the recipients of our site, we will have to pay for it.

Credits

The cost of the credits is not very high at the moment. Several sets are provided for the start:

• 5 000 credits for 5 USD
• 12 000 credits for 10 USD
• 25 000 credits for 20 USD
• 130 000 credits for 100 USD

It is also worth noting that practically every QUIC.cloud service, both CDN and LiteSpeed Cache optimizations are available both for sites hosted on LiteSpeed servers and those using other technologies, e.g. Apache.

However, sites supported by LiteSpeed web servers receive additional packages of free credits for particular services.

Refreshed user interface

Although LiteSpeed Cache didn’t live to see a completely new interface, the changes are still very positive – especially when it comes to the arrangement of individual elements, so you don’t have to jump through the menu to find related settings.

First of all, the settings for image optimization parameters and the support of the optimization process are all in one place. The summary screen has also been refreshed, and instead of strange features in the form of clickable illustrations not entirely suggesting their clickability, normal buttons have been added.

It’s only surprising that the image optimization menu does not include the features responsible for lazy loading and displaying replacement images. The authors of LiteSpeed Cache decided that their place is in the “Page Optimization” tab.

The crawler screen was also redesigned. All settings are in one menu, while the preview allows us to quickly assess the state of indexing and cache generation.

Selected new features

In addition to the changes described above, several new options have been added to the plugin settings. Some of the existing ones have also been improved, and their reliability has been increased.

The following description shows the changes that I managed to find in the plugin menu and initially test on a copy of my own page.

For full list of changes please refer to the log placed in github plugin repository.

Purge Stale

Before this feature was introduced, users had to wait for the page to be generated if the LiteSpeed Cache did not have the current version. After enabling this option the user will always see the last generated version of the page (even if it’s not the latest one) and the current version will be generated in the background. The description of this feature shows that it works similarly to the supercache in WP Super Cache.

Site administrators will therefore be able to decide whether it is more important to display always up-to-date data or rather the speed of loading the site without any downtime for users is paramount.

ESI Nonce

The ESI mechanism in the LiteSpeed Cache has been given an important update and has apparently learned how to convert nonce to ESI-compatible, which will increase LiteSpeed Cache compatibility with other plugins and themes. Using this window, we can provide nonce names that exist in our theme or plugin, which will allow us to convert nonce to ESI-compatible.

Font Display Optimization

For some time now, browsers have been offering support for the CSS font-display parameter, which regulates the behavior of fonts on a website when downloading them. Since version 3 LiteSpeed Cache allows you to add the font-display parameter in a variant of your choice for all the fonts present on the site as resources. The use of e.g. “swap” value allows for faster display of text on the page when the font has not yet been downloaded by the browser.

Load Inline JS

Earlier versions of LiteSpeed Cache allowed to load JavaScript resources with the defer parameter, which allows to display HTML content and avoid blocking the page content display by JavaScript code, which has not been processed yet. Now the defer parameter can also be used for JavaScript code placed directly in HTML (inline).

Lazy Load Image Parent Class Name Excludes

The lazy loading of images allows you to increase the perceived loading speed of your website. However, not all images need to be loaded with a delay (e.g. a logo in the header or other images that we are sure will always be displayed on the first screen). It may also happen that lazy loading supported by LiteSpeed Cache causes a conflict e.g. with existing plugins. In this case it’s useful to be able to filter selected images and exclude them from the lazy loading mechanism. LiteSpeed Cache version 3 introduces new filtering methods – based on the name of the image parent class (e.g. image container). So we can filter images based on their name, class name, parent class name and via URL.

Responsive Placeholder SVG

A replacement image is now generated from the SVG file. This file can use width, height, and color variables that will be dynamically replaced by real values when generating the image. In the previous version, we could only specify the color – SVG allows much more flexibility. Hypothetically, it is possible to generate SVG with a logo or animation, for example using SVGator. The plugin has also gained the ability to generate SVG-based replacement images using its own resources (locally), without using the QUIC.cloud infrastructure.

WordPress Image Quality Control

By default WordPress sets the compression level for generated JPG thumbnails at 82%. LiteSpeed Cache version 3 allows to change this parameter.

Low Quality Image Placeholder

Apart from simple and repeatable substitute images used during lazy loading we can use replacement images generated from source images, but being much smaller and blurry versions. This method is considered to be better for users because it suggests the content of the image during loading, although it must be admitted that the default quality settings make the LQIP thumbnails appear to be simply overlapping several gradients (the blurring is very high). However, LiteSpeed Cache gives us the possibility to change the LQIP quality threshold. It should be remembered that LQIP generation is done via QUIC.cloud infrastructure and is paid in credits. In case our account does not have free credits, a SVG replacement image will be displayed.

Heartbeat Control

LiteSpeed Cache version 3 allows you to change the parameters of heartbeat functionality built into WordPress. We can completely disable the heartbeat API or limit the frequency of queries, which may affect the server load for pages with very high traffic.

Summary

LiteSpeed Cache 3 introduces a number of features that will undoubtedly benefit all users of the plugin. The module becomes more readable and easier to use, and the mechanisms optimizing the page with each new version gain compatibility with the rich ecosystem of plugins and WordPress themes.

With the huge popularity and availability of extensive solutions for this popular content management system, optimization of the output code and serving pages from a fast cache seem essential.

At the same time, the new version of the plugin shows a clear direction in which LiteSpeed is heading. The plugin was originally developed as an interface to handle LiteSpeed server cache. Then there were functionalities to optimize the page’s output code as well as comprehensive image optimization. Finally, some of the features not requiring LiteSpeed server were made available for all WordPress users, which was to increase module’s reach and build awareness among users.

In the meantime, LiteSpeed Technologies has been working on its own CDN cloud – QUIC.cloud, which will eventually allow it to support all functionalities related to the generation and handling of cache typical for LiteSpeed servers, and additionally serve data from various nodes scattered around the world.

If the idea holds and proves to be reliable, QUIC.cloud will become a reasonable addition to many shared hosting services. I have the impression that the success of the project depends largely on the final costs of using the cloud. At the moment, this solution is constantly being tested, and credits easily accessible, it is difficult to predict how the costs will develop with the growth of infrastructure.

The solution is worth considering, if only because it is a much more complex service than an ordinary CDN serving images. QUIC.cloud may eventually allow to deliver complex pages supported by oversized CMS in a manner indistinguishable from simple and static HTML pages – available without any obstacles from around the world.