function add_menu_with_notification_bubble() {
	$bubble = sprintf(
		' <span class="update-plugins"><span class="update-count">%d</span></span>',
		42 //bubble contents
	);
	add_dashboard_page(
		'Example Menu',
		'Example Menu' . $bubble,
		'read',
		'example-menu-item'
	);
}
add_action('admin_menu', 'add_menu_with_notification_bubble');

The resulting menu will look like this:

Security-wise, this is dangerous for two reasons:

• Most plugins are not designed to be accessed in this way and will simply crash. The error message, if any, can disclose sensitive information about your site.
• Most plugin developers don’t expect anyone to access the plugin .php files directly. Doing so may trigger a dangerous bug or vulnerability that they haven’t tested for.

While the chances of either happening are admittedly fairly slim, it doesn’t hurt to safe-guard your site from this type of attack. Luckily, disabling direct browser access plugin .php files is very easy. Just create a text file named “.htaccess” in your /wp-content/plugins directory and place this code in the file:

<FilesMatch "\.php$">
	Order deny,allow
	Deny from all
</FilesMatch>

Now anyone who tries to load a plugin PHP file in their browser will now get a “Forbidden” error.

A word of warning

This will break some plugins. While most plugins only need their CSS, JS and image files to be accessible via the web browser, a handful also rely on .php files being directly accessible (e.g. for AJAX or dynamically generated CSS).

If you find out that one of your plugins doesn’t work, create a .htaccess file in that plugin’s directory and place the following code in the file:

<FilesMatch "\.php$">
	Order deny,allow
	Allow from all
</FilesMatch>

This will re-enable browser access to .php files for just that directory.

Our transient will die naturally of old age once $expiration seconds have passed since we last ran set_transient()

What you might not know if you haven’t explored the source code of the transients API is that transients stored in the database* will not actually “die of old age”. Instead, a stale transient will stick around until someone tries to access it. Only then will WordPress notice that the transient has expired and delete it. If no-one ever attempts to read a stale transient – e.g. because the plugin that created it has been uninstalled – it will stay in your database forever.

* If you have a suitable caching plugin installed, transients can be stored in a fast in-memory cache like APC or Memcached instead of the database.

Fortunately, since the expiration time of each transient is also stored in the database, we can easily clean up stale transients with a little bit of SQL magic. Run the two queries below to delete all stale transients. You can use either phpMyAdmin or a plugin like WP-DBManager to execute SQL queries.

DELETE a, b
FROM
	wp_options a, wp_options b

WHERE
 a.option_name LIKE "_transient_%" AND
 a.option_name NOT LIKE "_transient_timeout_%" AND
 b.option_name = CONCAT(
		"_transient_timeout_",
		SUBSTRING(
			a.option_name,
			CHAR_LENGTH("_transient_") + 1
		)
	)
 AND b.option_value < UNIX_TIMESTAMP()

DELETE a, b
FROM
	wp_options a, wp_options b

WHERE
 a.option_name LIKE "_site_transient_%" AND
 a.option_name NOT LIKE "_site_transient_timeout_%" AND
 b.option_name = CONCAT(
		"_site_transient_timeout_",
		SUBSTRING(
			a.option_name,
			CHAR_LENGTH("_site_transient_") + 1
		)
	)
 AND b.option_value < UNIX_TIMESTAMP()

Note: Back up your database before running any of the plugins or queries presented below.

Delete inactive plugins and themes

Not only do inactive plugins and themes waste disk space, they also clutter your database with unused settings and other metadata. Remember: most plugins won’t delete their DB options and tables until you completely uninstall them. You will also continue to receive update notifications, which can be a distraction. Remove any plugins and themes you’re not using any more.

Delete orphaned DB options

As mentioned above, plugins should automatically clean up their database entries when you uninstall them. Unfortunately, not all of them do, which leads to some entries becoming “orphaned”. Use the Clean Options plugin to delete DB options left behind by those untidy plugins.

Delete orphaned database tables

First, use WP-DBManager to get a list of all tables in your database. Compare it to the list of WordPress core tables. Any table not on that list is part of a plugin. If you spot any tables that have been orphaned by uninstalled plugins, use the “drop” command to delete them.

Delete post revisions

The post revision feature can be useful, but it also tends to fill up your database pretty quickly since WordPress creates a new revision each time you edit a post. There are several ways to fix this problem.

Delete all post revisions

You can use WP-Cleanfix or WP-Optimize to get rid of any and all post revisions.

Delete only old post revisions

In some cases you may want to clean out old revisions while leaving the most recent – and thus most likely to be useful – revisions intact. This SQL query will delete only post revisions created before March 1st, 2012:

DELETE a, b, c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE
	a.post_type = 'revision' AND
	a.post_date < '2012-03-1'

Use WP-DBManager or a similar plugin to run this query.

Limit the number of revisions per post

Add this line to your wp-config.php file to limit the number of revisions to 5 per post:

define('WP_POST_REVISIONS', 5);

Disable revisions

Add this line to your wp-config.php to completely disable post revisions:

define('WP_POST_REVISIONS', 0);

Note that this does not remove existing revisions. Use one of the other techniques discussed above to do that.

Delete spam comments

Even small blogs can receive thousands of spam comments per month. If left unchecked, all the spam will gradually accumulate in your database, potentially slowing down comment queries and hurting your site’s performance. Make sure to regularly clean out the spam by clicking the “Empty Spam” button in Comments -> Spam.

Bonus tip: I strongy recommend the NoSpamNX plugin to anyone receiving large amounts of spam. It’s a great “first line of defence” and can be configured to discard spam comments immediately instead of storing them in the database.

Delete pingbacks

If your comments table still takes up a lot of space even after you’ve deleted all spam comments, consider removing some or all the received pingbacks. While pingbacks can be useful as a way to be notified when someone mentions your content, old pingbacks lose their relevance quickly. Pingbacks are also frequently abused by spammers.

This query will delete all pingbacks received before March 1st, 2012:

DELETE FROM wp_comments
WHERE
   comment_type = 'pingback' AND
   comment_date < '2012-03-01';

Scan your site for malware

Check that your blog is free from malware and suspicious code by scanning it with Sucuri.net.

Find and fix broken links

Use Broken Link Checker to check your site for broken links, missing images, removed YouTube videos and similar issues.

Delete unused post and comment meta

Unused post meta keys are another kind of database cruft that can be left behind by long-since-uninstalled plugins and themes. You can use the WP CleanFix plugin I mentioned before or WP-Cleanup to remove them.

Alternatively, if you would prefer to do it without a plugin, the following SQL query will also remove all instances of the specified post meta key:

DELETE FROM wp_postmeta WHERE meta_key = 'unused meta-key-name';

And this query will do the same for the comment meta table:

DELETE FROM wp_commentmeta WHERE meta_key = 'unused-meta-key-name';

Finally, if you have a lot of registered users, you might also want to check for and remove unused user meta keys. Here’s a query to delete an unused piece of user metadata:

DELETE FROM wp_usermeta WHERE meta_key = 'unused-meta-key-name';

Also, see this tutorial for a more in-depth explanation of how to find and remove unused custom fields with phpMyAdmin.

Remove unused tags and categories

If you have a lot of unused tags or categories on your site, clean them up to reduce the database size and gain a little bit of performance. Both WP CleanFix and WP-Cleanup can help you get rid of unused tags.

Alternatively, this set of SQL queries will accomplish the same task (props to 4 Rapid Development):

DELETE FROM wp_terms WHERE term_id IN (SELECT term_id FROM wp_term_taxonomy WHERE COUNT = 0 );
DELETE FROM wp_term_taxonomy WHERE term_id NOT IN (SELECT term_id FROM wp_terms);
DELETE FROM wp_term_relationships WHERE term_taxonomy_id NOT IN (SELECT term_taxonomy_id FROM wp_term_taxonomy);

Remove unused shortcodes

If you’ve been blogging for a while, you’ve probably run into this problem: you uninstall a plugin or switch to a different theme, and now your site is full of shortcodes that no longer work. Obviously, going back and editing each post one-by-one is not going to work. You need a way to automatically remove the unused shortcodes.

Well, Search and Replace is just the ticket. It lets you search your posts for a piece of text and replace it something else.

Alternatively, here’s a query that will remove all instances of the specified [shortcode] from your posts (props to WPRecipes):

UPDATE wp_post SET post_content = replace(post_content, '[shortcode]', '' ) ;

Note that the above only works with self-closing shortcodes. For self-closing shortcodes like “[shortcode] content [/shortcode]” you’ll need to use regular expression search.

Delete commenter’s user agent

For each comment your blog receives, WordPress also stores the comment author’s user agent (basically, the web browser fingerprint) along with the rest of the comment. This can be handy for advanced users, but most bloggers will never need this information. You can shrink your database a bit by removing the user agent records.

Run this query to remove the user agent information from your database (props to RSA Blog):

UPDATE wp_comments SET comment_agent = '';

Delete unused images

Free up some disk space by deleting images not attached to any post or page. Go to Media -> Library -> Unattached, select all items, choose “Delete Permanently” from the “Bulk Action” drop-down and click “Apply”.

Another option is to use Upload Janitor or WP CleanFix to automate the process.

Optimize database tables

It’s good practice to optimize your tables regularly. Database optimization helps keep site performance steady and is especially useful after you’ve just made large change to the DB (like cleaning up all post revisions and unused meta keys). You can use WP-DBManager to schedule automatic DB optimization. WP-Optimize also includes the database optimization feature, but does not support scheduling.

Resources

For reference, here’s a list of all plugins mentioned in this post (in alphabetical order):

• Broken Link Checker – scan your site for broken links.
• Clean Options – detect and remove orphaned DB options.
• NoSpamNX – block spam comments.
• Search and Replace - find & replace text in your posts, comments, etc.
• Search Regex – find & replace with regular expression support.
• Upload Janitor – find and delete unused images.
• WP CleanFix – delete post revisions, unused meta, and much more.
• WP-Cleanup – delete revisions, unused tags, post meta, etc.
• WP-DBManager – manage and optimize your database.
• WP-Optimize – remove revisions, auto-draft posts, optimize tables, etc.

Final note: As you may have noticed, many of the “clean up” plugins – WP-Cleanup, WP-CleanFix, and so on – have a very similar feature set. So which should you use? Overall, WP CleanFix seems to be the most comprehensive solution, so I would recommend that one.

a href=”http://wordpress.org/extend/plugins/broken-link-checker/”

An update notification for a theme not hosted on wordpress.org

Download

• Client library (requires PHP 5 and WP 3.0 or later)
• Example theme
• Example metadata file

License

This library is licensed under the GPLand is distributed free of charge. If you find it useful, consider making a donation. Commercial licensing (e.g. for projects that can’t use an open-source license) is available upon request.

Quick-Start Guide

There are two things you will need to do:

1. Create a publicly accessible “metadata file” that describes the latest version of your theme.
2. Add the update checker to your theme and tell it where to find that file.

First, the metadata file. Open your favourite text editor and copy the following JSON code into a new file:

{
  "version" : "2.0",
  "details_url" : "http://example.com/example-theme/details.html",
  "download_url" : "http://examle.com/example-theme/example-theme.zip"
}

Replace the placeholder values with your own data. As you can probably guess, version is the version number of your theme. details_url specifies the page that the user will see if they click the “View version 1.2.3 details” link in an update notification. Set this field to your “What’s New In Version 1.2.3″ page or the theme homepage. Finally, download_url is the URL where the latest version of the theme can be downloaded. This field is optional. If you leave it out, the user will still get an update notification when a new version comes out, but there will be no “update automatically” link. They’ll have to download and install the update manually.

Upload the metadata file to your website. You can use any directory and file name you like; just remember that the file URL should be accessible from wherever someone might install your theme.

Next, lets add the update checker library to you theme. Copy the “theme-updates” directory from the client library to your theme. Then add the following to your functions.php:

//Initialize the update checker.
require 'theme-updates/theme-update-checker.php';
$example_update_checker = new ThemeUpdateChecker(
    'example-theme',
    'http://example.com/example-theme/info.json'
);

Again, replace the placeholders with your own settings. The first argument should be the name of your theme’s directory. For example, if your theme lives in /wp-content/themes/my-theme/, use “my-theme” here. The second argument should be the URL of the metadata file you just created.

Congratulations, your theme now supports automatic updates :) The update checker will automatically query the metadata file every 12 hours, checking to see if a new version is available. If it finds one, it will display a standard theme update notification on the Dashboard. Your users will be able to install the new version with a single click.

The ThemeUpdateChecker class

Class constructorThe library is configured by passing a number of arguments to the ThemeUpdateChecker constructor. They are, in order :

• $theme –  The theme directory name, sometimes called the “slug”.
• $metadataUrl – The URL of the theme metadata file.
• $enableAutomaticChecking – Enable/disable automatic update checking. If set to FALSE, you’ll need to explicitly call the checkForUpdates method to, err, check for updates. Defaults to TRUE.

checkForUpdates()
Manually trigger an update check. This is useful if you want to do update checks on your own schedule. checkForUpdates has no parameters and does not return anything. If you want to actually retrieve the latest update, use requestUpdate instead.

requestUpdate()
Retrieve update information from the configured metadata URL. Returns either an instance of ThemeUpdate, or NULL if there is no newer version available or if there’s an error.

deleteStoredData()
The update checker stores various update-related bookkeeping data in a DB option. Call this method to delete that data. This is can be useful is your theme provides some kind of “uninstall” feature.

addQueryArgFilter($callback)
Register a callback for filtering query arguments. Whenever the update checker needs to retrieve the metadata file, it will first run each filter callback and attach the query arguments that they return to the metadata URL. This lets you pass arbitrary data to the server hosting the metadata. For example, commercial themes could use it to implement some kind of authorization scheme where only paying users get automatic updates.

The callback function will be passed an associative array of query arguments and should return a modified array. By default, the update checker will append the following query arguments to the URL:

• installed_version – the currently installed version of the theme.

This method takes one parameter – the callback function.

addHttpRequestArgFilter($callback)
Register a callback for filtering arguments passed to wp_remote_get. The callback function should take one argument – an associative array of arguments – and return a modified array or arguments. See the WP documentation for details about what arguments are available and how they work. This method takes one parameter – the callback function.

addResultFilter($callback)
Register a callback for filtering theme info retrieved from the metadata URL. The callback function should take two arguments. If a theme update was retrieved successfully, the first argument will be an instance of ThemeUpdate. Otherwise, it will be NULL. The second argument will be the corresponding return value of wp_remote_get (see WP docs for details). The callback function should return an instance of ThemeUpdate, or NULL. This method takes one parameter – the callback function.

The site is still in early beta, so some features may a little rough around the edges or just plain missing. Nevertheless, I encourage you to go check it out and let me know what you think. All feedback is welcome.

What already works

• Add/remove sites.
• Monitor multiple sites with one account.
• Automatic daily scans.
• Email notifications.

What doesn’t quite work

• The crawler that I use is slow to get going. Sometimes it can take ~30 minutes before any progress is visible.
• Redirects are currently not followed.
• There’s a fair amount of false positives. Luckily, most of them are temporary and don’t show up when using the “persistent” filter.
• The site could use some UX love.

Screenshots

I am starting a new WordPress blog, and no longer updating an old one. [...] How can I lock the installation of WordPress down so I don’t need to maintain it? I have seen someone suggest making a static version, which sounds like a lot of work.

The top-rated answer is very good, but overly complicated. It involves custom code and .htaccess modification. I think I can offer a simpler solution. Here’s how you can turn your blog into a static site:

1. Make a backup. Just in case.
2. Disable comments and any other dynamic features your blog may have, e.g. contact forms.
3. Install WP-SuperCache and set the cache expiry time to 604800 seconds (= one week).
4. Fire up Xenu’s Link Sleuth and tell it to crawl your entire site. This will make WP-SuperCache generate static HTML files for all of your pages.
5. Delete all .php files and drop the WordPress database.

With all PHP scripts deleted, “expired” cache entries will never be removed, so the server will keep serving the same cached pages forever. Congratulations, your site now static :)

Alas, the aforementioned SE thread is rather old, so if I posted my answer there, no-one would probably ever see it.

Over the last two months, I optimized this site to load almost 2x faster. After the optimization was complete, the amount of Google search traffic that it receives increased by a whopping 5 percent. Here are the specific numbers:

November 2010

• 4.5 seconds.
• 58 832 visits.

January 2011

• 2.2 seconds (-105%).
• 61 751 visits (+5%).

If I wasn’t deliberately looking for changes in my organic search traffic, I probably wouldn’t even had noticed! The upswing is so tiny it might as well be a random statistical aberration. In fact, there’s a good change that is all it is.

Either way, there is some value in this exercise – it provides an upper bound. If you speed up your site by 100%, you probably won’t see more than a 5% improvement in your search traffic. Underwhelming, that.

And a couple of charts for you:

Site performance history from Google Webmaster Tools

Google Search traffic

Both charts overlaid

The overwhelming majority of visitors never leave a comment. Chances are, most don’t even scroll down to the comments section. So why waste their time and bandwidth by loading avatars that they’ll never see? A better option is to delay the loading of avatars until the user has scrolled far enough to actually see them.

I also promised to post the plugin that would allow you to implement this feature on your own WordPress site. So here it is.

Download

lazy-avatars.zip (3 KB)

Usage

1. Install and activate the plugin.
2. Open your comments.php find a line that looks like this:

   <?php wp_list_comments(); ?>

3. Add this line above the wp_list_comments call:

   <?php do_action('enable_lazy_avatars', true); ?>

This will enable the lazy-load feature for the avatar images in your comments section. If you want to use it everywhere on your site – e.g. in the sidebar or the admin panel – you can instead add the line from step #3  to your functions.php file.

The way it works is that the plugin replaces all avatar images with place-holder <div>’s.  Then it monitors the scrollbar position. When one of the place-holders comes into view, the plugin creates a new <img> tag inside the place-holder <div> and sets its “src” attribute to the original avatar URL.

With regards to styling, each place-holder has any CSS classes that the original avatar image had, plus two  more – “lazy-avatar” and “pending”. The “pending” class is removed once the avatar has been loaded. You can use this to apply a custom style to avatars that haven’t been loaded yet, e.g. a by adding a spinning “loading…” icon as the background image.

Compatibility

The plugin has been tested in the following environments:

• WordPress 3.0.4 and 3.1-RC2.
• Firefox 3.6, Opera 11,  Chrome 9 and Internet Explorer 9.

It will probably work fine in older versions of Firefox, Opera, Chrome and possibly Safari (not tested). However, it will not work in any version of Internet Explorer older than IE9. This is because old versions of IE don’t support the addEventListener method and the pageYOffset property.

If you’d like to write your own image lazy-loading script that is fully cross-browser compatible, take a look at jQuery’s scroll and scrollTop methods. There’s also an inView jQuery plugin that could simplify the task even further.

The plugin also uses custom data- attributes to store avatar image URLs. This is, strictly speaking, not a standards-compliant thing to do (except in HTML5), but I’ve found that it works well enough in practice.

Naturally, I couldn’t leave it that way. Optimization problems are among my favourites. So I set out to speed up my site as much as possible, and after a month of off-and-on optimization efforts I managed to get the average load time down from 4.6 seconds to 1.5 seconds. In this post I’ll summarize all the performance tricks and techniques I used to achieve that. They are loosely ordered from most widely applicable to most narrow/esoteric.

Here’s how my site performance graph looks now (click to enlarge):

You will undoubtedly notice that after reaching 1.5 seconds it gradually returns to 2.3. This was a calculated decision on my part, and I’ll discuss it after at the end of this post.

Combine and compress CSS files

Technically there is a number of ways to do this automatically. However, I was too lazy to do it “right”. Instead, I combined the files by hand and edited my theme’s header.php to include the combined CSS file instead of the default style sheet.

Resources

• PHP Speedy WP – automatically combine and compress CSS and JS. Warning: doesn’t play nice with CDNs.
• WP Minify plugin – like PHP Speedy WP, but more actively maintained and up-to-date.
• WP CSS plugin – gzip and minify CSS, automatically combine @import’ed files.
• CSS Compressor
• YUI Compressor
• Where did that CSS/JS come from?

Remove unused JavaScript

There was this one JS file that didn’t seem to actually do anything. After some investigation, I discovered that WP was including it because I had comment threading turned on. Since my theme doesn’t actually support comment threading, I simply disabled it in Settings -> Discussion. This got rid of the .js file.

Resources

• Where did that CSS/JS come from?
• How to find dead JavaScript code

Remove unused selectors

Small CSS =  faster downloads.

Resources

• Dust-Me Selectors – Firefox Add-on
• Deadweight – Ruby gem.
• CSS Redundancy Checker

Set far expires headers for static content

Far-future “Expires” headers allow browsers keep static content – e.g. CSS, JS and images – in their cache and avoid re-downloading the same files unnecessarily. It’s as simple as adding a couple of lines to your .htaccess:
# Far-future "Expires" header for static files
<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf)$">
ExpiresActive On
ExpiresDefault "access plus 8 weeks"
</FilesMatch>

Disable ETags

Again, just add this to your .htaccess:
# Disable ETags
FileETag none

Minify the HTML

Smaller page = faster page. I used the WPSCMin plugin for WP Super Cache to strip redundant whitespace from my pages and re-organize tags for better compressibility.

Resources

• WPSCMin
• WP Super Cache
• WP Minify

Use CloudFront CDN with origin pull

On the one hand, using a Content Delivery Network is a huge overkill for a small(ish) site like mine. On the other, it does improve performance for many visitors, and it helps with Reddit-proofing one’s site. It’s also ridiculously cheap – my CloudFront bill for December was around $1.30.

There are two ways to get your files into the CloudFront CDN. You can either upload them to Amazon S3 and give CloudFront the bucket name, or you can set up a “custom origin” distribution that makes the CDN automatically pull the required files from your server on an as-needed basis. I went with I went with the second option as the obviously easiest one.

Note, however, that the AWS CloudFront console lacks the ability to create custom origin distributions. You need to use a third-party tool like CloudBerry instead.

Resources

• Amazon CloudFront
• CloudBerry Explorer

Enable preload mode in WP-SuperCache

By default, WP-SuperCache caches a post when someone first visits it. So if a post is visited only rarely, it’s cache entry is likely to expire before someone visits it again, and the next visitor will need to wait for the post to be re-generated. With preload on, WP-SuperCache automatically pre-caches all posts. This ensures that even less popular pages are will have a cached version available and load quickly.

Resources

• Further explanation and discussion of the Preload mode

Convert theme images to CSS sprites

This reduces the number of HTTP requests the browser has to make to render the page. Ideally, there should be only one image that the browser has to load to render all the decorative elements on the page.

Resources

• A tutorial on CSS sprites
• CSS sprite generator
• SpriteMe – a popular choice.
• More sprite generators

Convert CSS sprites to data: URIs and embed them in the combined CSS file

And this reduces the number of HTTP requests even further. There are ways of automating data URI generation (see the “Resources” section), but I just put my sprites through an online converter and edited the style sheets by hand.

Note that data: URIs don’t work in IE 7 and IE 6, so be sure to provide a fall-back style sheet specifically for those despicable two.

Resources

• data URI scheme on Wikipedia
• Image to data URI converter
• CSSEmbed – a small utility that automates data URI conversion and embedding in CSS files.

Optimize popular content images

On this site, there are a couple of pages that get a lot more traffic than the rest.  By fine-tuning the images used on those pages to load as quickly as possible, I (hopefully) improved the first-visit experience for a significant fraction of this site’s visitors.

In practice, I uploaded the images to Smush-it, then ran the results through PNGCRUSH. For the trickier ones, I spent an hour or so playing with lossy compression options in Photoshop.

Resources

• Yahoo! Smush-it
• PNGCRUSH
• OptiPNG
• PNGOUT
• PunyPNG

Load AdSense asynchronously

AdSense ads are loaded synchronously. This means that when the browser encounters an AdSense ad, it will wait until the ad has completely finished downloading before continuing to load the rest of the page. This can slow down your site considerably.

There is, however, a hack that lets one load AdSense asynchronously – in parallel with other content. The details are extremely involved, so I’ll just give you an implementation example:

<div id="adsense_ad" style="width:336px;height:280px;"> </div>
<script type="text/javascript" src="path-to/writeCapture-1.0.5-nolib-min.js"></script>
<script type="text/javascript"><!--
	google_ad_client = "ca-pub-1234567890";
	google_ad_slot = "987654321";
	google_ad_width = 336;
	google_ad_height = 280;
	//Async AdSense
	writeCapture.html('#adsense_ad', '<scr'+'ipt type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"><'+'/script>');
//-->
</script>

Dire warning: While I believe that the AdSense ToS doesn’t explicitly forbid this technique, I also cannot claim that they allow it. Use at your own risk!

Resources

• writeCapture JS library
• writeCapture demo page

Remove unnecessary HTML

Lets face it, WordPress isn’t exactly thrifty with its markup. For example, it adds a whole slew of META and LINK tags to each page – a Windows Live Writer manifest, a shortlink, a “generator” tag displaying the WordPress version, three different types of feeds, and so on. Each of those tags has a purpose, but in practice only a few will be relevant for your site. You can save a Kb or two by removing the useless ones.

I removed 7(!) useless tags by adding this code to my theme’s functions.php file:

function removeUselessMeta() {
	remove_action('wp_head', 'rsd_link');             //EditURI
	remove_action('wp_head', 'wlwmanifest_link');     //WLW Manifest
	remove_action('wp_head', 'wp_shortlink_wp_head'); //Shortlink

	//My theme already outputs a general feed autodiscovery tag, so no need for more.
	//Also disables comments feed autodiscovery (I doubt anyone really uses it).
	remove_action('wp_head', 'feed_links', 2);
	remove_action('wp_head', 'feed_links_extra', 3);

	//No, don't tell the whole world what version of WP I'm running.
	remove_action('wp_head', 'wp_generator');

	//Disable rel='start' and rel='index' link tags. They make no sense on a site that
	//doesn't contain multi-page/series posts.
	remove_action('wp_head', 'start_post_rel_link');
	remove_action('wp_head', 'index_rel_link');
}
add_action('init', 'removeUselessMeta');

You can trim away some more bytes by removing optional tags and optimizing your layout and CSS so that, for example, common class names are not repeated more often than necessary.

Resources

• Optimizing HTML
• List of optional closing tags

Cache the FeedBurner counter and convert it to PNG

A minor optimization to be sure, but it saves one DNS query and the PNG version of the feed counter is about half the size of the original GIF. Here’s the PHP script I use to create and display the cached image:

<?php
//Configuration
$feed_id = 'wshadowcom';
$bg_color = 'B9CFFF';
$fg_color = '330000';
$cache_duration = 3600*12;
$cache_filename = $feed_id . '-cached.png';

if ( !file_exists($cache_filename) || (time() - filemtime($cache_filename) > $cache_duration) ){
	//Retrieve the original badge
	$image_url = sprintf('http://feeds.feedburner.com/~fc/%s?bg=%s&fg=%s&anim=0', $feed_id, $bg_color, $fg_color);
	$image = imagecreatefromgif($image_url);

	//Save as PNG
	imagepng($image, $cache_filename, 9, PNG_NO_FILTER);

	//Cleanup
	imagedestroy($image);
}

//Output the resulting image
header('Content-type: image/png');
header('Content-Length: ' . filesize($cache_filename));
header('Cache-Control: max-age=' . $cache_duration);
readfile($cache_filename);
?>

Lazy-load avatars

The overwhelming majority of visitors never leave a comment. Chances are, most don’t even scroll down to the comments section. So why waste their time and bandwidth by loading avatars that they’ll never see? A better option is to delay the loading of avatars until the user has scrolled far enough to actually see them.

My implementation of this trick is too large to fit on this page, so I will leave it for a future post.

Resources

• scroll and mouse wheel events
• How to detect when an element scrolls into view – a starting point.
• jQuery “in view” plugin
• Adding elements to the DOM

Disable AdSense (if you can afford it)

Finally, I disabled my AdSense ads and left them off for several days to test the impact they have on the average page load time. Surprise, surprise: the load time went down almost by a whole second. This is the steep 800 ms dip you saw on the performance graph – from ~2.3 seconds to ~1.5. The gradual increase back to 2.3 is me deciding that $XX/day from AdSense is worth the performance hit and re-enabling ads.

I must admit I’m a bit miffed about these results. Consider: a single block of AdSense adds around 800 milliseconds to the page load time. By looking at the graph from Google Webmasters Tools, we can infer that Google sees a site as “fast” if it loads in around 1.5 seconds. So if you use AdSense and want your site to meet that speed criteria, everything else on your page must load in 700 milliseconds or less.

You’d have to do better a job at performance optimization than frickin’ Google did with AdSense.

Further Considerations

Here are a few things I considered but didn’t attempt either because of their tediousness or high costs:

• Clean up the theme even further. There’s still a fair bit of redundancy in the markup and CSS.
• Get a DNS anycast provider for my domain name.
• Switch from Google Analytics to a something that doesn’t use JavaScript (e.g. AWStats).
• Experiment with different CDNs.
• Set up a Varnish cache for WordPress.
• Get more points-of-presence around the world. I’ve noticed that with the current setup – one server in USA – the time it takes to download the page HTML alone varies greatly depending on where the client is located.