OLS – Multi Site

Blog

  • 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.

  • Hardening Your WordPress Site: Security Basics

    Hardening Your WordPress Site: Security Basics

    Most WordPress sites are not compromised by some exotic zero-day. They are compromised through weak passwords, outdated plugins, and file permissions that are far more generous than they need to be. The good news is that the same handful of basic measures stops the overwhelming majority of real-world attacks.

    Start with accounts. Every administrator should use a long, unique password and two-factor authentication. Delete the default “admin” username if it still exists, and limit the number of accounts that hold the administrator role to the few people who genuinely need it. An editor cannot install a malicious plugin; an administrator can.

    Lock Down Accounts First

    Next, keep everything updated. The vast majority of hacked sites were running a plugin with a known, already-patched vulnerability. Enable automatic updates for minor core releases and for plugins you trust, and make a habit of removing plugins you no longer use rather than leaving them deactivated but present on disk.

    Finally, tighten the filesystem. Files should be 644, directories 755, and wp-config.php can be locked down further still. Disabling file editing from the dashboard with DISALLOW_FILE_EDIT means that even if an account is taken over, the attacker cannot paste PHP straight into your theme. None of this is glamorous, but security rarely is.

  • 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.

  • Understanding Core Web Vitals and Why They Matter

    Understanding Core Web Vitals and Why They Matter

    Core Web Vitals are the three metrics Google uses to quantify the experience of loading a page: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. They replaced a pile of vaguer “page speed” signals with something measurable from real users in the field, and because they feed into search ranking, they are worth understanding properly rather than chasing a green score in a lab tool.

    Largest Contentful Paint measures when the biggest element above the fold finishes rendering, usually a hero image or a headline. Anything under 2.5 seconds is considered good. The usual culprits behind a slow LCP are an unoptimised hero image, render-blocking CSS, and a slow server response, in roughly that order.

    The Three Metrics in Practice

    Interaction to Next Paint looks at how quickly the page responds when a user taps or clicks. It is dominated by long JavaScript tasks blocking the main thread, which is why trimming third-party scripts often helps more than any image work. Cumulative Layout Shift, meanwhile, punishes content that jumps around as the page loads, the classic example being an image without width and height attributes pushing text down once it arrives.

    The practical takeaway is that these three metrics pull in different directions and you cannot optimise them with a single switch. Lazy-loading images helps LCP and bandwidth but can hurt CLS if dimensions are missing. Deferring scripts helps INP but can delay interactivity if done carelessly. Measure with field data, change one thing at a time, and re-measure.

  • 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.

  • Hello world!

    Welcome to WordPress. This is your first post. Edit or delete it, then start writing!