How I Shaved 10 Seconds Off Page Load Time

Do you wish your site loaded quicker?

We all want our site to load as quick as possible for our users convenience and to keep Googlebot happy.

My friend Janet’s new site was dead slow when she asked me to take a look. Here’s how I spent about a couple of hours to get a WordPress site to load in about 2 seconds. When I started in was regularly taking over 10 seconds, sometimes hitting 20 seconds.

healthvuepartners.com pingdom

The Big Problems

There are a few places a website slows down, but often the most expensive piece of the equation for WordPress is the database connections. Another common problem is adding/using widgets that need to make even more expensive database calls.

Very close behind database lag is common requests to the web server. For every item on your page, a request originates, the browser says “Oh, look here’s an where I need an image of a kitten… hey web server do you have that? You do? Great, please send it to me here in the browser so I can display it.”

For the homepage of the site I was working with, there were about 44 requests including:

  • 7 CSS requests
  • 19 javascript libraries
  • 6 images
  • 18 CSS images

That’s not unusual for a good looking WordPress theme, and the images and javascript were not dragging down the speed of the page.

What I did notice was one specific css file that was taking 4 or 5 seconds to respond every single page request. It was the css file from their MailChimp plugin:

http://www.example.com/?mcsf_action=main_css&ver=3.9.1.

I took a minute to look at what that request was doing, and it was requesting a very small file to style their widget. But because every time I requested that css file it couldn’t be cached, and it took an additional database connection it was killing page load time. I searched to see if anyone had that problem, and sure enough, LimeCanvas did.

I ended up following those tips and that alone saved me 4 or 5 seconds – Hooray! Basically I moved the css to the main Theme CSS file so it was cacheable.

The last plugin thing I opted for was the WordPress Jetpack plugin – Photon. It uses the worldwide WordPress cloud to cache and serve your site images from their CDN. It’s not perfect, and lacks the ability to flush the cache, but it does help speed up image delivery.

Everyday Problems

The other problems can effect any site, not just WordPress sites. It has to do with optimizing as many things as you can to relieve the constant back and forth between the browser and the web server.

Caching

There are a lot of ways to cache content so that it is returned quicker to a visitor. For this site we used WP Super Cache, it generates html files that are served directly by Apache without processing comparatively heavy PHP scripts. This caching pulled back another second or two.

One of the other manual things I added was to enable browser caching by setting expiry dates on certain types of files via the .htaccess file – which I accessed via Yoast’s WordPress SEO Plugin.

I added the following lines that basically say if you are looking for a jpg image and you have already requested it in the past year, check your browser cache for it first:

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
</IfModule>
## EXPIRES CACHING ##

The advantage to setting those is that those requests no longer need to be made to the web server. See all the 304 server codes below? Those all mean that those items were already downloaded recently, so no need to fetch them again.

Network tab in Chrome browser

The best part is that instead of 40+ requests to serve this page, we’re down to 8 or 9. That’s a huge savings, and that’s where another couple of seconds came from.

I also added in some cache-control info to the .htacess file:

# images can live for 60 days
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=5184000, public"
</FilesMatch>

# text can live 2 days
<FilesMatch "\.(xml|txt)$">
Header set Cache-Control "max-age=172800, public, must-revalidate"
</FilesMatch>

# html files can live for 2 hours
<FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=7200, must-revalidate"
</FilesMatch>

Last but certainly not least is compressing files. Compressing files before sending them to the browser saves time, so any file possible, we GZip before pushing it to the browser.

Update

I noticed later that a request for the non-canonicalized site (without the www) was still crazy slow… back down the rabbit hole. The good news this time was I was sitting next to the Curagami CTO Jarrod Swart.

It turns out if you made a request for the homepage without www (http://healthvuepartners.com) it set off a chain reaction as follows…

  • Ask the web server for the page
  • Sees in the .htaccess file that it should check the cached file set
  • Checks the cache for that file – it doesn’t exist
  • Now back to WordPress to create that page on the fly…
  • WordPress has to make a request to the database, where it realizes the url to serve from is www.healthvuepartners.com
  • Return headers for the 301 redirect
  • Redirects and serve the www version of the homepage

It’s that time where the request has to return to the WordPress database where everything grinds to a halt. To overcome that I added a redirect right into the .htaccess file to canonicalize the request first thing:

#Redirect to www version of site
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^healthvuepartners.com
RewriteRule (.*) http://www.healthvuepartners.com/$1 [R=301,L]
</IfModule>

That simple change dropped the page load from 5+ seconds to under 1 second.

Web Hosting

In most cases your web hosting company is impacting your ability to serve your site as fast as possible. I have been using TigerTech (affiliate link) for the past 5 or 6 years and I love them! They don’t overload their shared servers and offer excellent customer service. They’re not dirt cheap, but they are less than $10/month.

If you’re having any trouble with your site being slow and need someone to take a look, let me know!

Is your online world on fire?

We all run into trouble from time to time. I'm working with a group of Internet Marketing Geniuses that are dedicated to helping you put out the fire and get control back as soon as possible.

No long contracts. No maintenance fees. Just a 100% Money Back Guarantee.

90 Day Maximum, 60 days more likely.

Comments

  1. Brilliant – As usual Phil. I love your detailed description of the issues and process for resolving them. You are smart and generous man!

  2. You can do more with this test: http://media4x.com/test/

    • Thanks Sergo, I hadn’t seen that one before.

      I also like a couple others, but any of them are a good place to start, what really matters is that you occasionally test your site to see what’s slowing it down.

  3. Good speed is crucial for SERP ranking. Great resources, Phil these need to be part of every website now.

  4. 40% of people abandon a website that takes more than 3 seconds to load. :(

  5. Great piece man, I appreciate the .htaccess examples. A good host is also important! I’ll have to check out those tiger guys you mentioned. I’ve had great luck with Synthesis for very important sites too but lots of $$$.

    Do you have any advice for “Time to first byte” on WP setups? I think Cutts said it’s one of the more important aspects they look ati. It’s easy to check here http://www.bytecheck.com/ and if you’re under .4 you’re generally good, but most of my sites are waaay over that.

    • I saw that piece from Matt as well, but he’s also said a few times that if your site is already in the “good” range, getting it to blazing won’t have a ranking impact – it’s more the other direction having a negative impact. I take all of the speed stuff to have a pretty wide spectrum. Even when Moz publishes articles like this one I’m not very moved.

      I’m sticking with, “slow kills” and once your “fast enough” additional effort doesn’t have much impact.

Leave a Reply

css.php