Having a site that loads fast is the holy grail of web site owners. It’s the stuff of legends but we have faith that fast sites are attainable. In this post we hope to point you in the right direction to speeding up your site in a variety of manners which should be included in your processes for creating your content, managing your sites, server setups, and in code development.

Why is it Important?

Page load times are a “probable influence” on organic rankings according to Google. While you might demonstrate a correlation between particular speed metrics and search ranking, you can’t outright PROVE a causality relationship, since other unmeasurable factors are still at play. For all intents and our purposes though, speed matters to Google rankings, and for one very good reason – fast loading sites are enjoyable sites.

Speed matters for End Users

Google wants each search result to be a good experience for their users. So while relevant content is the most important factor for page rankings, the speed at which a user gets their webpage on screen IS critical for the experience to be pleasurable, and that is a factor that Goolge considers for page rank too. The problem is that sites with a lot of content may be great experiences and some sites with little content may be a pile of dung – pure size and speed can’t be the sole determining factor in optimal site speed. Optimization is the buzzword here. Do your best at optimizing that page load time and Google and your users will reward you.

Google is pretty mum on what it is actually ranking in terms of site speed (some suspect it’s the “time to first byte” loading speed) regardless, speed IS a consideration you should take seriously for many reasons including page ranking, customer experience and better conversion rates.

What’s this “Page Load Time” stuff?

Think of page load time as the complete journey. From the server assembling and fulfilling the requests to the networks that deliver it, to finally popping up on your screen where you can interact with the page. Let’s use a family going on a trip as our analogy for determining page load time:

• The server gets the page ready to deliver and figures out how to deliver it (planning your trip and getting the kids into the car),
• How often you’re making those deliveries (how many trips you need to make).
• How much you’re delivering (how many passengers and cargo),
• How fast its delivered (speed bumps and the speed limits on the road),

Optimizing each of these factors is ideal for page load time (and for the family). To confuse matters when people say”page load time” for a website, they may mean one of two measurements: “document complete” time or “fully rendered” time. Google might not distinguish between the two for page rankings but users certainly do. People want to get on with it, and will start to interact with a page before it’s completely on the screen. For our purposes we’re primarily going to focus on “document complete” as the page load time. “Fully rendered” has factors such as the browser being used and the users computer which we have no control over.

Now, page load time is measured in milliseconds. That’s a thousandth of a second. Humans can detect problems at 100 milliseconds. That’s right, above 1/10 of a second we start to notice (relative to expectations of course). Anything below that 1/10 of a second is deemed as instantaneous by our brains (kids response time is measured in days but expectation time is 1/100 of a second which may explain some parental frustration).

Interesting fact: Usain Bolt’s reaction time out of the starting blocks in the 100-meter final in Rio was 0.155 of a second and he wasn’t the fastest starter! He was 7th of 8 runners. He won his races in the first twenty meters of the run, decimating everyone with his phenomenal ability to get to top speed faster than anyone else in the world. Try to beat his reaction time here.

So fast response time matters but page load time is like the full hundred meters. Response time is one factor among many.

So let’s Start with the Content

Now a picture is worth a 1,000 words and impacts load time just as much. As good as WordPress is at developing thumbnails and as good as the plugin SmushIt or WordPress is at compressing them on the fly, always START with the smallest possible image that is the largest you need (upsizing is bad for image quality, just trust me on that). That’s in terms of pixel dimensions or physical dimensions. Just keep in mind, images are the single worst site element for dragging page load time down, so let’s begin our speed journey there.

Get the Physical Size Right

Don’t take a 300X300 pixel image and stretch it to 2000X2000 pixels. Conversely, don’t use a 300X300 pixel image when all you need are 30X30 pixels.

Take this icon. I saved it at 1081 X 1081 pixels and am presenting it at 300 X 300 pixels. What a waste! Yes, WordPress gives me some auto-generated thumbnail options that are closer to the size I wanted, 500X500 pixels to be precise, but even if I use the 500 pixel thumbnail image and drag and shrink it down to 300 pixels, I’m still loading up the 500 pixel image, apx. 30% waste in load time for this image. And the original, which I’ll never use, is taking up server space!

PRO TIP: Start with as close to the correct physical pixel size image as you need, every time, for massive page load time savings.

Use the Right File Format for the Image

You’r a lot about different file formats, people get pretty emotional about this topic. Be a Vulcan, don’t let emotions rule your decisions. Each file format has their own benefits when it comes to how many kilobytes you want to shave off the image.

GIF: no matter how you pronounce it, this format is much better at handling large non-gradient images. Like logos and icons – that have solid blocks of colour. It also supports transparent pixels, so you don’t have to use a PNG for that.

JPG: great for photos. You can also save them using different levels of file compression (which results in image degradation). I always compress till I can notice, than back off a bit. PRO TIP: I use 8 as my default in Photoshop and go from there.

PNG: great for photos that need transparency, not so great with big blocks of colour, you’ll get a slightly larger PNG than you would a GIF in that case. PNG’s are great, but only use them if you have a need for transparency, otherwise JPG compresses the file much better.

Tests with Flat Colour Images

Use Excerpts

Do you have a page that shows the first chunk of bunch of your posts? Consider crafting excerpts. When that page is formed it has to process those pages, grab the first bit of each, assemble it and present it. If you have excerpts, that same page quickly grabs the excerpt, and only the excerpt, and knows exactly how to use it. Not a big problem for actual content delivery time, but the process to get that page ready to show is sped up considerably by crafted excerpts.

Lots of Comments?

IF you have a ton of comments on a blog post consider breaking them into pages. Text is small though, so you’d better have a LOT of comments to make this worthwhile as you’ll LOSE visitors for every additional click they have to make through your site. Find this under your DASHBOARD-> SETTINGS -> GENERAL

Caching

Caching is… well, bothersome, but necessary. A webpage on WordPress is made up of many parts that get assembled and presented to the viewer as the whole page. Fine and dandy, but if you have a lot of parts and calls to the server, this puts a strain on the server which slows down the page load time. Caching assembles and stores the final assembled page beforehand, and serves the complete page when the call is made to the server. No building it on the fly so it speeds up page load time.

It’s great for the front end but I’ve run into so many issues with the back end that it makes me debate it’s worth for small business sites. I’ve had it conflict with many other plugins, there are ongoing security issues with the most popular caching plugins, and I don’t believe small sites should bother with the hassle it may bring to your site.

Many speed site testing sites look for caching and knock down your rating for not having caching turned on, they presume that it’s always a good thing, which may not always be the case. Google doesn’t care. They measure speed, not how you get there, so try caching out carefully and intentionally and make your own judgements as to it’s worth. On pure speed, yes it’s a good thing, on hassles it brings your the administrator sorting out conflicts, maybe not so much.

I have a few sites running Comet Cache, it seems to be a pretty stable, simple, non-conflicting cache plugin. It also allows you to clean up your database occasionally. Which is also a also a good thing to do – purging all those revisions and trashed posts will make your database easier to deal with for the active pages and posts.

Browser Caching

On the other end of the equation, why should the browser be getting new elements each page view if your page elements don’t change often? Let the users browser pick up some of the heavy lifting by storing elements on their side and re-using them when needed for set amount of time (it’s good to reload old elements occasionally in case a change is missed).

You can configure your web server to set caching headers and apply them to all cacheable static resources. It’s pretty easy if you have access to the .htaccesss file, just add the code below and adjust as you see fit. There’s probably plugins that do this too but I haven’t bothered to look for them.

Expiry Headers

CDN

Content Delivery Networks is another way to speed up the delivery of your site’s resources. Essentially, it spreads your site out to other servers that are able to deliver faster speeds for specific types of content (images, live streaming, etc). And another benefit to using a CDN from @levi_mccormick on twitter pointed out to me:

One reason a CDN can speed up loading is allowing more simultaneous connections. Browsers limit connections per domain.

Again, this is best used for larger sites with thousands and thousands of page views where those milliseconds add up. It’s fairly easy to implement, but again, it does require some experience and can cause caching issues. It’s a way to prevent bottlenecks of high demand content as well. For small business sites, the speed increase is minimal and may not be worth your while to implement. Like most of these WordPress speed boost tips, you have to consider the effort to results ratio and decide if it’s worthwhile to you.

Read more about CDN on Wikipedia. Google, Amazon, and WordPress.com all offer some form of CDN. My only advice is to use CDN intentionally and watch for possible problems during implementation and down the line. Know what you’re doing or don’t do it at all.

Hosting

Your domain name provider and your site host play a large factor in how fast your site gets delivered. You can test this out with the Waterfall measurement found at https://gtmetrix.com/ which takes a look at how fast your host resolves your domain name and gets it pointed your your site (among many other measurements of what’s happening at your site).

AMP

AMP (or Accelerated Mobile Pages) is a protocol for speeding up mobile presentations of your site. If a large portion of your viewers are on mobile devices than you should absolutely implement AMP on your site. It essentially builds an instant loading cache version of your page that is screaming fast on mobile devices.

AMP consists of three parts: MP HTML is HTML with some restrictions for reliable performance and some extensions for building rich content beyond basic HTML. The AMP JS library ensures the fast rendering of AMP HTML pages (it does this by using best javascript practises for mobile and getting rid of the bad that may be on your site) . The Google AMP Cache can be used to serve cached AMP HTML pages (it’s a CDN for mobile pages, see above).

Tutorials on the technical can be found here.

As you can tell, Google is a huge promoter of AMP, believing mobile is the future. Google will penalize your rankings for NOT having AMP if your site is searched for on mobile. So this tip is almost mandatory if you like page rankings on mobile searches.

Full disclosure: I haven’t delved too deeply in AMP specs or manual implementation. I let this plugin take do the hard work for me. It generates the AMP cache files automatically and does what needs to be done.

GZIP Compression

Compressing things always ends up making them smaller and load faster. GZIP is a server side compression that sends smaller components to the brower that uncompresses them at the client side. Many cache plugins or minify plugins offer a way turn turn this on but but this speed boost might not work for you if your server does not have either mod_deflate or mod_gzip installed.

In cPanel you can turn gzip compression on via the Optimize Site panel.

Know the Plugin Hogs

Sometimes a simple little plugin can kill your site speed. Say for example, it conflicts with another plugin or is just a resource hog but how would you know? Install P3 Performance scanning plugin, test and then remove the big offending plugins. [UPDATE: this plugin hasn’t been updated in awhile and is reported to NOT to work, and even break, some sites running WP 4.7 – USE WITH CAUTION. I’m looking into altermatives].

For example, on one site I found out the plugin being using for 301 redirects was accounting for HALF of the entire sites plugin processing! Unacceptable, especially since other plugins offer the same service for much less load on your server. Of course if it’s a killer, must have, plugin that’s using up your resources, you may have to live with it.

Pre-Rendered Pages

This was brought up at the WordPress meetup where I presented the above information. I’m definitely going to look into it and I’ll let you know my thoughts on it in the future with an update to this blog post.

Have any awesome tips for speeding up a site? Let me know with a comment. This post is just to get the dialogue rolling!