OLS – Single Site

Category: Web Performance

Making sites faster, from the server to the browser.

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

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