I have written previously on the fine art of preloading images without JavaScript using only CSS. These caching techniques have evolved in terms of effectiveness and accuracy, but may be improved further to allow for greater cross-browser functionality. In this post, I share a “CSS-only” preloading method that works better under a broader set of conditions.

Previous image-preloading techniques target all browsers, devices, and media types. Unfortunately, certain browsers do not load images that are hidden directly (via the <img> element) or indirectly (e.g., via the parent <div> element) using either display:none; or visibility:hidden;. Further problematic is the potential unintentional display of images on pages when presented via specifically designed print stylesheet.

Continue Reading

For the past several months and up until just recently, Perishable Press had been suffering from unpredictable episodes of the dreaded white screen of death. Although blank white screens happen to virtually all WordPress users now and then, certain configurations seem to trigger crashes more frequently than others. Here, I am referring to WordPress version 2.3.

In this case, the unpredictable crashes, inconsistent errors, and general instability began several months ago after I had completed my WordPress theme restoration project. Prior to that, I had removed all of my alternate themes and placed them on a subdomain. Meanwhile, after the themes had been removed, I decided to enable the default WordPress cache (don’t ask why). For the next month or so, before restoring my themes, my site performed exquisitely: uptime at 99% (on a shared server, no less), virtually no errors, and so on. Then, after restoring alternate theme functionality, the site began locking up and crashing multiple times each day. Here is a summary of the sequence of events (estimated time frames):

Continue Reading

NOTE: This post was written many months ago under the erroneous assumption that caching Mint’s JavaScript was a good idea (for Y-Slow compliance, performance, et al); however, after a brief chat with the man himself, Shaun Inman, I was quickly informed that this was a bad idea: caching Mint JavaScript files will cause Mint to stop functioning. But, for what it’s worth, and for the sake of retaining potentially useful information, I present the original article here for your amusement.. </note>

Recently, I spent some time addressing a few of the performance issues pointed out by Yahoo!’s very useful YSlow extension for Firebug. Working on performance tip #3, Add an Expires or a Cache-Control Header, I encountered some difficulty while trying to get the JavaScript used by Mint to cache as desired. Apparently, the HTAccess directives used to cache my other scripts do not effect the two PHP-generated JavaScript files used by Mint. Although I am not entirely certain, I suspect that these files are not being cached along with other scripts because the way in which they are called via query string parameter (Apache is far from perfect when it comes to dealing with anything associated with query strings). In any case, I really wanted to have these Mint scripts cached by the browser, so I ended up editing two files in the Mint core to make it work. For those of you struggling with the same dilemma, here’s how I did it..

Continue Reading

During the recent ASO server debacle, I raced frantically to restore functionality to Perishable Press. Along the way, one of the many tricks that I tried while trying to fix the dreaded “white screen of death” syndrome involved increasing the amount of PHP memory available to WordPress. This fix worked for me, but may not prove effective on every installation of WordPress. If you are unsure as to whether or not you need to increase your PHP memory, consult with your host concerning current available memory ¹ and overall compatibility with a localized increase. Note that if your blog is running fine, there is probably no need to employ this solution. I recommend this change only if you are experiencing PHP-related and/or PHP memory issues associated with any of the following:

Continue Reading

This trick isn’t guaranteed to prevent all WordPress-generated PHP memory errors, but it certainly seems to help reduce their overall occurrence. For some reason, after my host upgraded their servers to Apache 1.3.41, I began logging an extremely high number of fatal PHP “memory exhausted” errors resulting from the WordPress cache.php script. Here is an example of the countless errors that are generated:

Continue Reading

Recently, while attempting to optimize site performance, I found myself experimenting with various caching mechanisms currently available for WordPress. Specifically, I explored each of the following caching options:

• WP-Cache 2 [WordPress plugin]
• WP Super Cache [WordPress plugin]
• WordPress Object Cache [built-in caching mechanism]

While working with the two plugins, WP Cache 2 and Super Cache, I was pleased to discover crystal-clear instructions on each their respective sites. Having access to installation and usage information greatly facilitated the implementation of each of these caching techniques.

On the other hand, finding information about the default WordPress object cache proved virtually impossible. Finally, after locating some decent information, I was able to confirm my initial suspicions and subsequently decided to post a quick article outlining and describing this very straightforward caching method. Although enabling the WordPress cache turns out to be drop-dead easy, it is always good to be sure that you aren’t forgetting a step or otherwise overlooking some important aspect of the process.

Continue Reading