The New Leaf Journal, like much of the internet, is powered by WordPress. Unlike much of the internet, however, I work to ensure that The New Leaf Journal is usable for the small minority of internet users who disable JavaScript. While I doubt that this matters to most of our visitors, it was kindly praised in one review of our site. One compromise I have made in the name of ensuring that our site works for users who block scripts is not using lazy loading for images. WordPress comes with built-in lazy loading functionality (I believe it is on by default), and the theme we use has built in intersection observer lazy loading functionality. I took some time to test both with scripts blocked and found that both had issues, so I opted to use neither. For whatever it is worth, I have not noticed any difference in site performance with lazy loading – which may make sense in our case since The New Leaf Journal is light and does not feature many images.
One thing that I do use to enhance our site performance is a WordPress plugin called WP Super Cache. This, unlike lazy loading, does have a strong positive effect on our site’s performance. It was more or less absolutely necessary when The New Leaf Journal existed on Bluehost’s cheap shared hosting plan. In theory, I could get away with no plugin-based caching on our Hetzner VPS server, but performance would suffer (especially under load). Despite some early New Leaf Journal caching trauma back in 2020 (the problem is always caching), I am comfortable with WordPress Super Cache and have adopted an aggressive configuration after moving from Bluehost to Hetzner (my current caching posture would not have agreed with the limited computing resources we had on Bluehost). I enabled preloading, which sends WP Super Cache to cache every article on site every 12 hours. This means that users will almost always hit cached versions of our articles, even seldom-visited articles – a configuration that proved helpful when we received a Hacker News page view avalanche back in August 2022.
However, while I have not had any serious caching issues since 2020, my current configuration did lead to two interesting issues with disabling preloading.
First, back in January, I switched to the child theme version of our WordPress theme, BunnyPress (theme as of April 4, 2023). Without getting too far into the weeds, people use “child themes” so that they can modify their WordPress theme’s behavior and have those modifications persist after theme updates. I disabled lazy loading during the switch. For this reason, I was surprised when The New Leaf Journal was not loading quite right with scripts blocked. I checked GTmetrix, a speed testing site, and found that it was flagging us for an overly-aggressive lazy loading posture. I tried enabling and then disabling lazy loading, but that did not resolve the issue. It then occurred to me that perhaps I should try flushing WP Super Cache. As I noted, WP Super Cache rebuilds its cache every 12 hours, so I rarely ever flush it manually. However, in light of the fact that changing settings was not fixing the lazy loading issue, I figured that something was stuck in the cache. I flushed the cache and then found that the issue was resolved.
Second, I updated from WordPress version 6.1 to 6.2 just the other day. The upgrade worked with no noticeable issues. Moreover, I did not see any lazy loading issue. I ran a test on our homepage in GTmetrix for reasons entirely unrelated to lazy loading and saw that our homepage appeared to have intersection observer lazy loading enabled. Strange, it was still disabled in our theme. It appears that something in the WordPress update from version 6.1 to 6.2 caused a minor issue. Again, I flushed our WP Super Cache cache and checked again. The script was no longer being loaded.
There is a valuable lesson here: Even if you think you have no caching issues, the problem is always caching.
(Fortunately this problem is very minor compared to the June 2020 issue wherein Bluehost’s server-side caching served an old version of our homepage that had been cached by our previous caching plugin.)