Speeding Up Smart Passive Income

This is the first in an ongoing series of website performance reviews. I take a popular site, give it a performance shakedown, then report on what they’re doing well and what needs improvement.

The first site in this series is Smart Passive Income. This is Pat Flynn’s blog about running a web-based business focusing on passive income. He’s extremely transparent, posting exactly how and what he does along with monthly income reports. In his July report, Pat touched on how slow the site had gotten and how he’d started improving its performance. I’m keenly aware of how slow his site has been. I often read his articles at the gym using my iPhone 3G. While I’m used to the underwhelming browser speed on the 3G, SPI had gotten painfully slow. Some pages would take 15+ sec to load anything and would continue loading for minutes if I didn’t hit the stop button. His recent changes have improved this significantly but there’s still a lot that can be done. Let’s dig into it.

Gathering Information

The first step in reviewing a site’s performance is to gather quantitative data. We can watch a page load and think “damn that’s slow (or fast)” but that doesn’t give us anything to work with. My favorite tools for doing this are Zoompf and Pagetest. When used together they provide a great overview of a website’s performance and what needs to be improved.

Why Not YSlow, Page Speed, etc?

There are many other tools you can use to review your site’s performance. They’re great for a quick in-browser check or profiling something specific like Ajax performance but in this case they’re just not necessary. The data provided in Zoompf’s and Pagetest’s reports is comprehensive and using other tools would be redundant.

How Fast (Or Slow) Is Smart Passive Income?

Pat has done a great job at improving the site’s performance. Like most blogs SPI is run on WordPress. Out of the box WP lacks many basic optimization features every website should implement. Thankfully there are some great plugins that fix this problem. One of the best, if not the best, is W3 Total Cache. Every WP site should use this plugin. It adds advanced caching, minification, and CDN support. SPI is using W3 Total Cache but not all of the features are enabled but let’s not get ahead of ourselves.

One of the other things Pat added to SPI was a CDN. He’s using Amazon’s CloudFront service. While a CDN will often improve your site’s performance it isn’t a panacea. It can take effort to get your CDN setup correctly to optimize speed and caching. More on this later.

Pagetest: For The Browser We Love To Hate

Pagetest profiles a single page and the associated files. It generates a report covering server requests, settings, performance, and a lot more.

The first thing to note is the “First View” load time. This tells you how long it took to load the entire page including CSS, JavaScript, images, etc. SPI took 13.419 seconds to load. Although 13+ seconds is long this can be deceiving. The most important times are “First Byte” and “Start Render”, which can be found in the table at the top of Pagetest’s report.

First byte shows you how how long it took from requesting the page to data coming back to the browser. If this time is high it indicates you have server-side performance issues. SPI took 0.784s to first byte. This is about what you’d expect from a standard WP install without caching enabled. Since SPI is running W3 Total Cache this number should be much lower. On closer inspection I found that nearly half this time, 321ms, was from the DNS lookup. It may have been a hiccup but it might make sense to move smartpassiveincome.com’s DNS to a better service. The actual round-trip request took reasonable 432ms. Considering SPI is running on shared hosting this isn’t bad at all.

Render Me Tender

The start render time indicates how long it took for the browser to start showing the page to the user. It is absolutely crucial to get this number as low as possible. The longer a visitor sees a blank page the more likely they are to leave your site. I always try to keep the start render time under one second. SPI hit 3.934s. Ouch. Keep in mind this test was run using IE7. IE7 is slow. This page would have rendered faster had we used IE8 or a modern browser like Chrome. Still, if you aim to improve performance in IE7 you’ll know it will be faster in everything else. A (too) large percentage of people still use IE6 & IE7 so you need to consider these browsers.

Now we know our first goal: drop 3 seconds off of the start render time. But how?

Block This

Take a look at the waterfall chart. It shows all of the server requests the browser had to make to load the page. In this case there were 119 requests. Wowza! The green vertical line on the chart shows the start render time. In IE7’s case the CSS and JS files before this line prevented the page from loading. I counted 7 CSS and 6 JS files that blocked rendering plus Google Analytics that was loaded asynchronously (doesn’t block loading). These 13 blocking files are what caused the page to start loading so slowly. Luckily there’s a solution and Pat is already half way there. W3 Total Cache has an option called “Minify.” This will allow you to combine and minify CSS & JS files. It takes a little effort to setup but it’s well worth it.

The performance review page of the report has plenty to say about some basic things that can be improved. While there’s nothing wrong with looking this over I’m going to move on to Zoompf because it addresses the topic in much more depth.

Zoompf: Everything AND The Kitchen Sink

Zoompf’s report gives SPI a rank of 65.16 out of 100. Not bad but as already demonstrated by Pagetest there’s room for improvement. This report goes into plenty of detail on the 56 issues it found so I won’t go through them all. Instead I’ll touch on a few important ones I think are key to making the site super fast.

A CDN Without Caching? Say It Ain’t So!

One of the high priority items in this report is Images Without Caching Information. The server, in this case CloudFront CDN, can add headers to static files like CSS, JS, and images to keep them cached in the browser. When viewing subsequent pages these images are loaded from the visitor’s hard drive and no request is sent to the server. This significantly decreases load time. Based on a post Pat made about his traffic stats, most vistors to SPI spend a significant amount of time on the site and view multiple pages. Adding caching headers to static files will reduce bandwidth costs and improve user experience. It may even get users viewing additional pages since the site will feel so snappy.

The problem here is that CloudFront doesn’t add the necessary Expires header by default. You have to apply it to each file. Our favorite plugin W3 Total Cache comes to the rescue again. By enabling the Browser Cache option it will automatically tell CloudFront to add caching to all of the blog files it serves.

Sprites = Speed

Along with merging CSS and JS as covered in the Pagetest section there are additional requests that can be eliminated. All of the theme images can be merged together into a single image file called a sprite. Since the theme uses quite a few images this would eliminate a lot of overhead and make a noticeable difference in load time. One of the easiest ways to create a sprite is to use Steve Souders’ excellent tool SpriteMe. When run on a site this bookmarklet detects images, merges them, and provides the necessary CSS to make them work. Using SpriteMe is pretty straightforward and the FAQ on its site covers a lot of common issues.

Shared Hosting Isn’t The Problem

In his July report Pat had mentioned he was planning on moving to a VPS. Based on my site review I think this is unnecessary. It would lead to some improvements in page rendering time but with caching enabled it won’t make a significant difference at this point. The time and effort is better spent on the improvements outlined above.

Fewer Requests and Smaller Files Lead To Happier Visitors

By combining files to reduce server requests, adding caching, and minifying CSS and JS SPI’s performance can be improved dramatically. If Pat implements the changes I’ve outlined in this review I guarantee his site will be much faster and his vistors will be happier. I know I will.