Category: WordPress

  • Web: is my site on a LiteSpeed server? (Finding out from Firefox)

    Being on a LiteSpeed server, you can possibly use the LiteSpeed Cache.

    The following is by my understanding.

    Once a site gets busy, for instance a WordPress site, a cache can make the difference between the site being slow versus normal.

    On my oldest WordPress site, which went up in 2012, I have always used LiteSpeed Cache, except for a couple of interruptions during updates. When I had to run the site without it, I really noticed how much slower it loaded. On that site, LiteSpeed Cache is the only plugin I use. (See my post from June 5, 2026 for some background thoughts about plugins.)

    So, LiteSpeed Cache is a plugin that I like. However, as I understand, in order to use the LiteSpeed cache, one needs to be hosted on a LiteSpeed server. (Perhaps that’s a slight oversimplification, but likely good enough for a starter’s perspective.) How does one discover if they are?

    Here’s how I did so on Firefox:

    1. On a page from the site, right-click on a non-active part. From the drop-down, click Inspect.
    2. On the new pane that appears, find Network and click on it.
    3. Reload the page. A bunch of resources will be listed as they load.
    4. Click on any of the resources. A new pane will appear; on it, find Headers and click it.
    5. Underneath the Headers title, find Response Headers and scroll down. An entry like server: LiteSpeed indicates that, indeed, the site is on a LiteSpeed server.

    There are many potential directions to follow from this post. One motivation for finding if one’s on the LiteSpeed server is to discover whether using the LiteSpeed Cache is a possibility, perhaps even as a plugin if the site is WordPress.

    For follow-up I intend to mention corresponding directions relevant to Chrome and related browsers.

    Source:

    docs.litespeedtech.com

    w3.org

    -JS

  • WordPress: Plugins: another let-down

    WordPress: Plugins, continued…

    The following is my take.

    I start about WordPress plugins in my post from June 2, 2026. I typically run a cache one, and sometimes that’s it.

    I thought about doing a post today about a plugin to make backups. Backups are important to safeguard content from errors, malfunctions, etc. Before doing any manual update, making a backup is likely a good idea. That’s what I do, anyway.

    So, I had a plugin installed which I was going to use to do a backup, then report about it.

    The plugin crashed: it just remained stuck at 0 percent completion. When I clicked the “Stop” button in its menu, I got a message back saying the process couldn’t be stopped.

    I logged into the server and stopped the plugin from there. Next, I deactivated, then deleted the plugin.

    I never keep plugins around that don’t stop when I click “Stop.”

    A plugin isn’t needed to make a backup of a WordPress site; a backup can be created manually. However, some plugins, assuming they work, might make it more convenient.

    Not in this case, apparently:)

    -JS

  • Computer constructs: caches, part 0

    What is a cache? What are some types of them?

    The following is my understanding about caches.

    In French, cacher means “to hide.” However, in woods-person terms, “to hide” and “to store” are closely related, because storing food means hiding it from foragers. Hence, a cache is, functionally, a place to store stuff.

    In computer terms, a cache typically means a place where results are stored so the CPU doesn’t have to figure them out again. Rather, said responses can just be brought from storage immediately. Cache storage needs to be fast in order to effectively save time.

    Types of caches have evolved. They may be classified on how fast they are to retrieve from, as well as by what they store. In the web world, for instance, page caches store pre-built pages that are called for often. Object caches store answers to database queries, for instance, that are often requested. Opcode caches store parts of computer programs that are run often. In each case, the code has been refined into a finished solution, or closer to one, so the CPU doesn’t have to start from scratch to respond to a request.

    On a website that delivers complex content, such as a WordPress site might become, all three of the caches described above might be used. Typically, without a cache, the content may be delivered noticeably slower compared to when a cache is used. At high levels, caches can be calibrated to be even more efficient.

    Source:

    php.net: OPcache

    gxmediagy.com: “OPcache, Object Cache, and Page Cache: The Three Layers That Make Websites Feel Instant”

    -JS

  • WordPress: Plugins, part 0

    What one veteran WordPress user thinks about plugins, part zero.

    The following is my understanding, opinion, etc.

    I’ve been using WordPress since 2012. It’s a great platform. AI tells me that, as of today, around 43 percent of the web runs on WordPress.

    At surface level, WordPress is easy to load up and post from. Next, some users want to manage their content, enhance how it’s displayed, reorganize it, etc. Often, that’s where plugins come into play.

    I recall learning about plugins and using a few in my early days. They seemed great – one would load a plugin, then get access to surprisingly convenient utility.

    In my case, there were two such plugins, each offering something I could have done myself but only after a lot of programming. Both plugins were free, and offered such utility with minimal effort. I really enjoyed using them.

    One crashed fairly early on – it just stopped working. It didn’t seem to make much of a mess, nor did it affect many posts. What it did, I admit, seemed too good to be true. When it stopped working, I just continued without it.

    The other plugin was key for several in-depth posts. When it broke, it made a mess, since it was a presentation plugin. Once it failed to encode the content meant for it, the raw code was exposed. While it all seemed harmless enough, it was unsightly and made those posts useless. I stopped using that plugin, or any like it.

    Both that plugin, and the one that broke earlier, were free. Paid ones might have more and better support. However, I think a user would have to be quite attached to a plugin to keep using it after its breakage crashed their site.

    Nowadays, I typically use a cache plugin (more about that later), and sometimes nothing else. I’ve even had a cache break on me, giving an error message where my site should have been displayed – not fun, but I recovered from it.

    That said, many WordPress users seem to depend on and celebrate all kinds of plugins. WordPress is PHP-based, so the potential utility of a plugin is virtually unlimited.

    I plan to continue about WordPress plugins.

    -JS