A quick search for “wordpress speedup” or “wordpress optimization“, however, reveals that we aren’t suffering from a dearth of information. On the contrary, many, many people have posted articles about their specific techniques and experiences (I’ve listed the best of these in the Related Articles section; you really should read them). This leads me to believe that most bloggers are either apathetic about their site performance or intimidated by the prospect of diving into something they know little about. I tend to think it’s probably the latter, so let’s see if we can make it a little less scary, eh?

Here at Cloud Four, we are big fans of the work done by the Yahoo! Exceptional Performance team to research and publish best practices for improving web performance. For us, the big finding was that most of the end-user response time — as much as 80% of the total page delivery time — occurs after the server has finished all its back-end work to create the page. Why such a long delay? Well, we’ve all been steadily increasing the number of Javascript, stylesheet, and image references on our fancy blog pages, and that means the browser has a lot of work to do before it can completely render the page for the reader. This finding is good news for most of us, since improving the page layout and rendering behavior are well within the skillset of almost anyone who can setup Wordpress and install plugins.

What You Should Do Right Now

Here’s the short answer: install a couple plugins, add a few lines to your .htaccess file, and reap the rewards. It is almost certainly guaranteed that you will see an immediate improvement in your site performance, shaving seconds off each page load and impressing your readers. If you truly want to know how and why all this stuff works, you’ll enjoy reading the related articles for more information and insight.

1. Use Firefox, Firebug, and YSlow to measure yourself

The Yahoo! team has published their 34 rules for speeding up your web site and a tool for evaluating web sites against those rules. Strictly speaking, you do not need to install these tools, but I think you will enjoy seeing your YSlow score move from where it is today (probably an “F”) to where it should be (at least a “B”). And joy of joys, your actual site performance will improve accordingly.

2. Enable GZIP compression

Add the following lines to your .htaccess file (the AddOutputFilterByType should all be on one line). This action tells the web server to compress files before sending them to the browser, resulting in reduced bandwidth and faster delivery to the browser. Adding compression is a very safe option.


<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml
</IfModule>


3. Add an Expires Header

Add the following lines to your .htaccess file. This action tells the web server to add an Expires header for files that are unlikely to change in the near future. The reader’s browser will then cache the files until the expiration date, not even bothering to check for a new, updated version in the meantime. Note that if you DO change any files with a far future expiration date you will need to change the file’s name, otherwise any browser with a cached version will fail to fetch your new version. You are most likely to experience this issue with CSS or Javascript files, so don’t say I didn’t warn you.

    <IfModule mod_expires.c>
      ExpiresActive on
      ExpiresByType image/gif "access plus 1 month"
      ExpiresByType image/jpeg "access plus 1 month"
      ExpiresByType image/png "access plus 1 month"
      ExpiresByType text/css "access plus 1 month"
      ExpiresByType application/javascript "access plus 1 month"
      ExpiresByType application/x-javascript "access plus 1 month"
    </IfModule>
  

If mod_expires is not available on your system, you can try this instead:

    <FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css)$">
      Header set Expires "Sun, 22 Apr 2018 01:10:54 GMT"
      Header set Cache-Control "max-age=315360000"
      Header unset Pragma
    </FilesMatch>
  

4. Disable ETags

Add the following line to your .htaccess file. This action tells the web server to remove ETags from the HTTP response. For most websites, removing ETags will not affect your performance at all, but it will increase your YSlow score. Removing ETags is a very safe option.

    FileETag none
  

5. Install the PHP Speedy Wordpress Plugin

The PHP Speedy Wordpress Plugin is a real gem, implementing several of the Yahoo! best practices: combining multiple files to reduce HTTP requests, minifying Javascript and CSS, compressing the files via GZIP compression, and adding far future Expires headers. You should configure PHP Speedy to minify everything, compress Javascript and CSS, and add far future expire headers for both Javascript and CSS. There is no reason to enable GZIP compression for the web page itself, since we are doing that via apache.

Since this plugin modifies the way your page references Javascript and CSS files, take some care to test your site after activating your configuration. PHP Speedy appears to preserve the load order of the files, which is the main thing I care about. And if necessary you can exclude specific files from this optimization step. Still, I recommend that you test like crazy on this one.

6. Install the WP Super Cache Plugin

The WP Super Cache Plugin helps performance by dramatically reducing the time it takes the server to deliver the initial HTML file for the page. There are other steps you can take to optimize your server-side performance, such as eliminating unnecessary plugins and optimizing your page templates, but while you’re thinking about all that, this one little action will make a world of difference. My one configuration note here is to go ahead and enable “Super Cache Compression.” This option is disabled by default, but I recommend that you enable it and just run a quick test to ensure the page is being delivered correctly.

You can verify that the cache is configured and working correctly by visiting the site as an anonymous user and viewing the page source. Compressed pages being served by the cache should by quite fast and the last three lines of the page file will look something like the following.

      <!-- Dynamic Page Served (once) in 1.422 seconds -->
      <!-- Cached page served by WP-Super-Cache -->
      <!-- Compression = gzip -->
  

Results!

By using these techniques, and by adding a bit of image optimization and consolidation, we have seen dramatic performance improvements for the sites we’ve optimized. Typical page loading times have dropped from 5-10 seconds to one second (or less for pages cached by WP Super Cache).

Without sacrificing any page functionality or quality, we have been able to:

• reduce the empty cache total size by 50% or more
• reduce the empty cache HTTP requests by 50% or more
• reduce the primed cache total size by 90% (!)
• reduce the primed cache HTTP requests to as few as 1 or 2 requests (!)

Where Next?

Well this first part was certainly easy: edit one file (.htaccess) and install two Wordpress plugins. These simple steps have probably provided some immediate relief for your readers, and that’s a good thing. From here, I would strongly suggest you review the related articles for other front-end improvements, such as optimizing images and using sprites to reduce the number CSS images on your site. There’s quite a bit more you can do without becoming a programmer or system administrator.

If you do have administrative access to your server, however, you can also begin experimenting with ideas to improve the back-end server performance. You might consider installing a PHP accelerator, such as eAccelerator, to speedup PHP script execution. Or you might want to expend some effort tuning MySQL for your site. For most people, however, these advanced topics are beyond their skill and training, or are simply unavailable in their current hosting environment.

If you decide try any of the techniques in this article, I’d like to hear about your experience, and about what you think you’ll try next.

Good luck!

Related Articles

• 38 Ways To Optimize And Speed Up Your WordPress Blog , April, 2008
• 20 Tips and Tricks To Speed-Up Your Wordpress Blog, August, 2008
• Tips To Get A Good YSlow Rating, May, 2008
• How-To: Optimize Your Site For Speed, April, 2008
• WordPress Optimization Guide, November, 2008
• Quick Tips For Wordpress Speed Up, March, 2008
• Wordpress Performance: Why My Site Is So Much Faster Than Yours, April, 2007
• Yahoo! Best Practices for Speeding Up Your Web Site

Wordpress Plugins You Need

• WP Super Cache
• PHP Speedy WP 0.4.7 (Works with WP2.6)

Resources

• Firebug Extension For Firefox
• YSlow Add-on For Firebug
• Pingdom Full Page Test
• Web Page Analyzer From Website Optimization
• CSS Sprite Generator From Website Performance
• CSS Sprite Generator
• eAccelerator

Leaving politics aside for the moment, it’s a pretty impressive display of what is possible using the iPhone and iPod Touch platform.

There are more details about the project at Lyza’s blog, Aileen’s blog and my own post on the topic.

You can see the earlier version of the presentation from May’s Web Visions event on Slideshare.

The application is currently only available for Blackberry users. You can download the application for free.

Early reviews of the application have been positive. The Silicon Valley Insider says that of all of the applications that newspapers have released that “Wall Street Journal’s Mobile Reader is easily our favorite to date.”

As the interface designers, nothing could please us more than hearing them say:

The software, available today, is one of those tools that makes instant sense the first time you get your hands on it.

The vast majority of the hard work on the application was done by FreeRange Communications. It is their branded RSS reader that the Wall Street Journal selected. FreeRange asked us to help with the user interface design to make the application feel more like the WSJ.

The people at FreeRange have been good friends to us. They helped start Mobile Portland with us, made a diving save on our mobile concurrency test, and have been generous community members. It’s great to see them launch such a significant customer and announce their Mobile Publishing Platform.

It’s wonderful to finally get to share something we’ve been excited about for months. Congratulations to FreeRange and the Wall Street Journal!

We’re going to be presenting our Mobile Concurrency Test and the initial results we’ve received.

More on how performance is connected to the environment in a moment, but first, the details on when and where:

Beer and Blog - Make Your Blog Load Fast & Save the Environment
Green Dragon Bistro & Brewpub
928 SE 9th Ave.
Portland, Oregon 97214
RSVP | Add to Calendar | Map

The Impact of Data Centers on the Environment

Everyone is aware that our ability to reduce our energy consumption is a key component to reducing the impact we have on the environment.

However, it wasn’t until I was asked to speak to the Storage Networking Industry Association (SNIA) at Storage Networking World last fall that I realized how important this is for those who run data centers.

At the time, I observed:

Several businesses are now being told that they cannot bring any more power into their data centers. The power company is simply refusing to provide them with more capacity.

In many cases, the cost of powering and cooling a data center exceed the costs of the hardware within two years.

The people in the storage industry get it. The SNIA has started the Green Storage Initiative to foster innovative ways of reducing power consumption in data centers.

The question is are those of us who are web developers doing our part? Sadly, no.

Web Site Gluttons

Web developers live insulated lives. We have broadband at our homes and our offices and it shows. We’ve stopped paying attention to the size of web pages.

Andrew King recently highlighted research showing that the average size of web pages has doubled since 2003. “Longer term statistics show that since 1995 the size of the average web page has increased by 22 times, and the number of objects per page has grown by 21.7 times.”

Source: http://www.websiteoptimization.com/speed/tweak/average-web-page/

In addition to the size of web pages, few sites are optimized to ensure that browsers cache the files and don’t request the same files repeatedly.

Steve Souders recently conducted a thought experiment on how much CO2 would be saved by optimizing the Wikipedia home page. He used the CO2stats.com estimate that “three minutes on a Web site generates three grams of CO2 - roughly equal to the amount one person generates by breathing for 4.5 minutes.”

Steve estimated that the optimization could save “5,000 kilowatt-hours per year or approximately 500-1000 pounds of CO2 emissions.”

Why Now?

I’ve been interested in web optimization for ever since it saved my prior company tens of thousands of dollars a few years ago. I’ve been speaking on the topic whenever possible and trying to help web developers understand how much benefit they can get by optimizing their pages and how easy it is to do.

A couple of weeks ago, I finally watched An Inconvenient Truth. At the conclusion of the film I started thinking about what more I could do. I’m getting a bike ready to use for my commute to work. I’m reducing the energy I use. I’m contemplating a vegetarian diet.

And I’ve redoubled my commitment to getting web developers to take site performance seriously. It saves money, improves the experience for your customers, and it’s easy to do.

Most importantly, if you care about global warming, optimizing your site is a moral imperative.

So come join us tomorrow at the Green Dragon to make your blog faster and reduce the energy it consumes.

The presentation was entitled Going Fast on the Mobile Web. Included in the presentation is the first results from our Mobile Browser concurrency test and some of the conclusions we’ve been drawing from the test results.

The response from people who attended the session was positive:

Alsymer: Really enjoyed @grigs’ optimizing mobile session … most useful of all the sessions I’ve been to so far at WebVisions=

davemerwin:@grigs needs to do a workshop next year

mfriesen: @grigs mobile session was excellent. Much useful knowledge.

buchino: mobile web presentation was great… cloudfour.com guy (@grigs) knows a lot.

I was extremely pleased to hear that people enjoyed the presentation. I’ve been attending Web Visions for years and have seen both good and bad sessions. I was determined to make sure no one walked out of the room without learning something.

(As an aside, how wonderful is it to have feedback via Twitter for presenters to know what they’ve done right and what they need to improve on?)

Speaking at WebVisions alone would be remarkable, but something truly unexpected happened after the slides got posted online. They seemed to strike a cord with people. The presentation was selected as Slideshare’s Slides of the Day. It was featured on the O’Reilly Radar, Ajaxian and quite a few other sites.

A comment made during the presentation even made it to the top of Fast Company’s home page as their Big Idea of the Day.

To date, the slides have been viewed 9,598 times, downloaded 677 times, favorited by 69 people, and embedded on 47 web sites.

I’m very grateful and humbled by the attention the presentation has received. I’m most excited about the conversations that it has spurred. I’ve got much more to write about and share based on the conversations during Web Visions and after.

Thanks to everyone who attended the session or read the slides online. I appreciate you taking the time to take a look at what we’re doing and why we believe the mobile web is so important.

Here are the slides themselves:

| View | Upload your own

Last month’s presentation by Dietrich Ayala about Firefox for Mobile Devices also includes an audio recording of his presentation.

If you haven’t attended Web Visions before, we highly recommend it. It is a great conference at an exceptional price. This year’s keynote speaker, Jeffrey Veen, is one of our favorites. This is a must-attend conference.

As we neared release of the test, we found that a certain set of BlackBerry devices was exhibiting odd behavior. While the user would never see the four rows of images in our test, both the test and that apache logs would report that the images had been downloaded.

After several hours of trying to figure out how our code had gone astray, we were getting desperate. So John drove to a local AT&T store. He found a BlackBerry to test with and called the office so we could change the code while he tested in the store. That phone call was one for the ages.

We stripped every line of code out of our test page until we had simply the html, head, body, and img tag. And the image still wasn’t rendering.

Finally, we removed the height and width attributes from the image tag and it finally worked. But this made no sense because we had an image tag on the other pages that had the height and width set and was displaying properly.

Further testing revealed that a bug in the BlackBerry browser: it will not display images if the height and width are declared and either is 4 pixels or less. Our test images were 4 x 4 squares.

Yes, it is that specific. Less than five pixels and the browser will download the file, but the image will never render on the page. In fact, the rules for when the image will and when it won’t display are even more specific:

• If the image width and height are set to 5 pixels or greater, the image will render.
• If either the height or the width is not declared in the attributes, the image will render.
• If both the height and the width are declared in the attributes and either is 4 pixels or less, the image will not render.
• The original size of the image does not matter. The only thing that matter is the size of the image declared in the html attributes.

If you have a BlackBerry, we’ve provided a test page to demonstrate the bug.

We don’t know how often people are going to build web pages for BlackBerries with images less than 5 pixels on one side, but we do know that if you do, you better be careful how you code the page or no one will ever see your work. We’re also certain that if BlackBerry wants to compete on the mobile web, it is going have to improve its browser.