Avoiding problems with missing images in WordPress
WordPress installations handle missing image files very inefficiently by default, running the entire WordPress script to build a custom “404 Page Not Found” page rather than simply letting Apache return an immediate default “404” response. Running the WordPress script when not necessary is a huge waste of processor time. For example, WordPress might be able to only process 8 requests per second for a missing image when WordPress generates a custom “404” page, but Apache can return process over 1,000 raw “404” responses per second. If your Web site contains references to missing files, this default WordPress behavior can be driving up your CPU usage unnecessarily. We’ve seen poorly-configured Web sites spend a significant portion of their CPU time processing missing images.
There are many sources of missing image file references. Themes and plugins can generate them. Your site may be missing a favicon.ico file. Some RSS news readers make a lot of requests for files named apple-touch-icon.png and apple-touch-icon-precomposed.png, which most Web sites do not have. Check your Web site’s analytics report (such as AWStats) or raw log files to see what image files are missing from your site.
If you’re a Tiger Technologies customer running WordPress, you already benefit from a global rule we implemented for missing favicon.ico files (as discussed in a previous blog post). We’ve also recently updated our WordPress Performance page with extra tips on returning faster “404” results for other missing files such as robots.txt and for all missing images.
on Saturday, July 2, 2011 at 2:25 pm (Pacific) Nico wrote:
The htaccess rules you suggest for serving 404 to all missing images (http://support.tigertech.net/wordpress-performance#don8217t-run-jmp) doesn’t work on MU installs. Well, it does work, but it also breaks the site.
A subsite refers to the theme files as website.com/subsite_name/wp-content/themes/… . WP then uses htaccess to remove the subsite from the URL, thus getting the correct path: website.com/wp-content/themes/…
Placing your htaccess rules before the wordpress redirections breaks the theme images, since website.com/subsite_name/wp-content/themes/… doesn’t exist. And these are links generated by WP tags so they are never on the /files/ format you mention. The /subsite_name images don’t exist, and the server serves a 404 before WP can get to it and fix it.
on Saturday, July 2, 2011 at 3:10 pm (Pacific) Robert Mathews wrote:
Nico writes:
>The htaccess rules you suggest for serving 404 to all missing images doesn’t work on MU installs.
Yikes! Nico, you’re right, and thanks for pointing this out. Our suggestion to put the rules “before the existing WordPress section” would indeed cause this problem with WPMU. Our apologies — the incorrect information was added to the page yesterday, based on testing with what turns out to be a non-standard .htaccess file a customer was using for WPMU.
We’ve updated the page to specify exactly where the rules need to be to work for WPMU. The same rules work; they just need to be in a very specific location for WPMU. And as a pleasant side-effect, putting them in that exact location means that one of the “RewriteCond” lines isn’t necessary, making it shorter and simpler.
Thanks again for pointing this out so we could fix it!
on Saturday, July 2, 2011 at 3:28 pm (Pacific) Nico wrote:
Ha, I think that customer was my client 🙂 I just spent a while going through the htaccess file and error logs trying to figure out what was causing some images to dissapear.
Thanks! I’ll try the updated fix.