Tag: caching

  • LiteSpeed Cache vs. Nginx FastCGI: A Real-World Comparison

    LiteSpeed Cache vs. Nginx FastCGI: A Real-World Comparison

    If you host WordPress yourself, two caching approaches dominate the conversation: LiteSpeed Cache running on OpenLiteSpeed, and Nginx with FastCGI cache in front of PHP-FPM. Both can serve a cached page in well under fifty milliseconds, so the interesting differences are not in raw speed but in how much work it takes to run them well.

    The LiteSpeed combination wins on integration. Because the cache lives inside the server and the plugin talks to it directly, cache purging is intelligent: publish a post and only the affected pages are invalidated. Object caching, image optimisation, and critical CSS are all configured from the same plugin, which is a real advantage if you would rather not assemble a stack by hand.

    Integration vs. Control

    Nginx FastCGI cache wins on transparency and ubiquity. There is no plugin coupling and no licensing question, just a well-understood configuration that has run half the internet for a decade. The trade-off is that purging is blunter, you typically clear the whole cache or rely on a helper plugin, and you assemble object caching and the rest yourself.

    Our verdict: if you want the most performance for the least configuration, OpenLiteSpeed with LiteSpeed Cache is hard to beat. If you value a vendor-neutral stack you fully control and you are comfortable on the command line, Nginx FastCGI remains an excellent, boring, dependable choice. There is no wrong answer here, only the one that matches how much you enjoy tuning servers.

  • A Practical Guide to WordPress Caching

    A Practical Guide to WordPress Caching

    Caching is the single highest-leverage change you can make to a WordPress site, and yet it is also the easiest to get subtly wrong. The goal is simple: avoid doing work twice. If a page does not change between two visitors, there is no reason to run PHP, query the database, and assemble the HTML all over again for the second one.

    There are really three layers worth knowing. Page caching stores the finished HTML so repeat requests skip PHP entirely. Object caching stores the results of expensive database queries in memory, using Redis or Memcached, which helps logged-in and dynamic pages that cannot be fully page-cached. Browser caching tells the visitor’s browser to keep static assets locally so they are not re-downloaded on every navigation.

    Know Your Layers

    A content delivery network sits on top of all of this. Rather than every request travelling to your origin server, a CDN serves cached copies from a location near the visitor. For a global audience this cuts hundreds of milliseconds off the connection before a single byte of HTML is sent.

    The mistake people make is enabling everything at once and then being unable to tell which layer broke when a price or a cart total goes stale. Turn them on one at a time, confirm the cache is actually being hit by reading the response headers, and set sensible exclusions for pages that must stay dynamic, such as checkout and account pages.

  • Getting Started with OpenLiteSpeed for WordPress

    Getting Started with OpenLiteSpeed for WordPress

    OpenLiteSpeed is the open-source edition of the LiteSpeed Web Server, and over the last few years it has become a genuinely popular choice for hosting WordPress. It speaks the same configuration concepts as Apache, ships with a clean admin console on port 7080, and includes an event-driven architecture that handles concurrent connections far more gracefully than a traditional prefork setup.

    If you are coming from an Apache or shared-hosting background, the first thing you will notice is that OpenLiteSpeed does not read .htaccess files the way Apache does by default. Rewrite rules still work, but they are evaluated through LiteSpeed’s own engine. For WordPress this matters mostly in one place: permalinks. Once you enable a rewrite rule for the document root, pretty permalinks behave exactly as you would expect.

    Why It Pairs Well With WordPress

    The real reason most people switch is caching. The bundled LiteSpeed Cache plugin talks directly to the server, which means full-page cache, object cache, and even edge-side includes are handled in C rather than in PHP. In practice that turns a 600ms uncached response into a sub-50ms cache hit without any third-party CDN in front of it.

    • Install PHP 8.3 and the LSAPI handler.
    • Point the virtual host document root at your WordPress directory.
    • Enable the rewrite rule so permalinks resolve.
    • Install the LiteSpeed Cache plugin and turn on full-page caching.

    None of these steps takes more than a few minutes, and the payoff is a stack that stays responsive under load. In the next few articles we will dig into each layer, starting with what actually happens on a cache hit.