Table of Contents

Last Update: May 2019.

Optimizing your website for speed can be a complex issue, especially for non-developers. A lot of guides and articles over-simplify by providing broad advice that isn’t applicable to every website and shouldn’t be taken at face value. Here’s a few commonly-spouted tips that need some clarification.

1. Your performance “grade” matters

When you use one of the popular speed testing tools such as Google PageSpeed Insights, GTMetrix, Pingdom etc your site is given a grade for its performance, along with some recommendations. Customers often feel that because they have a caching plugin they should be scoring almost perfect grades. Not only is this not the case, but it’s also a waste of time to chase a perfect grade.

The bottom line – the performance grade of your site does not matter!
The only metric that matters is the actual load time of your page.

Why your grade doesn’t matter

The primary reasons for having a faster site are:

  • To improve SEO
  • To improve user experience
  • To increase conversions

In none of these scenarios does your grade matter.

When the Googlebot visits your site, it does not know your grade as given by each of the speed testing tools. It only sees how fast your page loads.

What is a grade good for?

The grades and recommendations can be helpful in providing a guideline for best practices, and spotting any red flags or bottlenecks on your site. But the fact is, a higher grade does not equal a faster page load time. I’ve seen plenty of sites with high grades but slow speeds.

For example, this site has a load time of 30 seconds – clearly something is wrong, but the Pingdom grade is: 96/100:

good-grade---long-load-time

Additionally each tool you use will grade your site differently –  which is “right”? So don’t worry about chasing grades, just focus on the actual load time.

Sometimes the suggestions that are made are helping in improving load time but sometimes they will be hard to implement for little to no benefit.

A classic example of this is when Google PageSpeed suggests moving CSS and JS files to the footer. Some JS files can be moved to the footer, but others will break your site if you move them. Likewise, if you load your site without CSS styles, it will appear broken and provide a terrible user experience.

2. You need all types of caching

There are several different types of caching available and some articles will suggest that you need to implement them all – page caching, database caching, Memcached etc.

On a site without caching, when a visitor hits a page on your site, the server, via PHP has to gather and assemble from the database the various page components and content and send them back to the browser, on the fly. That takes quite a bit of time and effort.

By contrast, page caching (which is what WP Rocket and other plugins do) generates static HTML files of your content, which is faster to serve to your visitors than having PHP generate your pages from scratch every time.

So this means that when you have page caching and a visitor comes to your site, they are not even touching the database at all. So in many scenarios where you have page caching, you don’t need to cache the database as well. This is true for many websites.

There are some circumstances in which database caching may be necessary but they are likely to be not the average site. For example, if you have a highly dynamic site where page caching is not realistic, database caching would be helpful. The average blogger does not have to worry about that.

Some forms of caching are run at the server level so you may be restricted as to what you can do if you are on a shared or managed hosting platform – you’ll be at the mercy of your host. But page caching can be implemented via a WordPress plugin so it’s easy for the average site owner to implement.

3. You only need a caching plugin

A caching plugin is an invaluable tool in your kit for creating a speedy website.
(You can get WP Rocket now, and check by yourself the value it can provide to your site!)

But it shouldn’t be the only one. On a WordPress site there are many layers that can be optimized. Admittedly, some are easier than others for the layperson to optimize.

A caching plugin (when correctly configured) will always help, but it’s the final layer in creating a fast site. It can just be a band aid if your site is inefficient in general.

Other layers that need to be considered are:

Web hosting

This is the foundation so invest in great hosting! If your hosting is poor, you’re a little bit doomed and there will always be a ceiling on how fast your site will run. Awesome web hosting doesn’t have to be expensive.

We have a couple of hosts that we recommend (and as a WP Rocket customer you would be eligible for a discount) that won’t break the bank such as SiteGround or Kinsta. There are many great hosts out there – don’t just pick the cheapest, you will end up paying in other ways!

Your theme

The bulk of the code on your site is coming from your theme so an inefficiently coded theme will cripple you. This is an area that can be hard to fix if you are not a developer so in some cases it might be worth hiring one proficient in speed optimization to tweak your theme for performance.

(We tested some of the fastest free WordPress themes: check them out!)

Generally those “kitchen sink” type themes that include every feature under the sun, are going to come with a certain amount of weight – extra scripts being loaded in that you’re not actually using etc. If you have one of those themes, don’t activate all the available features (like 3 different sliders) unless you’re actually using them.

Your plugins

Contrary to popular belief it’s not the QUANTITY of plugins you have that counts, it’s the quality. It just takes one poorly-written plugin to bring your site to a grinding halt. Of course, you should be judicious in the plugins that you select and you should delete any that you’re not using.

Bottom line

If you put a rocket on a sports car and a rocket on a tank, the sports car will still go faster because it’s streamlined and built for speed. The same applies to your website.

Caching cannot fix poor code, it can only mitigate the effects to a certain extent. The better all the other components of your website are, the better and faster your site will be all around.

4. Less HTTP requests = faster website

A common guideline is that you should to reduce the number of HTTP requests your site has to make to the server in order to render the page. To a large extent this is true and as a general guideline, reducing the number of requests is a good practice. But as with everything, it’s a little more nuanced than that.

This commonly crops up regarding minification. Most minification tools take all your CSS files and put them together in one big file (concatenation). So if you originally had 8 CSS files on your site, you now have 1. So that’s just 1 HTTP request instead of 8. Better right?

Well, maybe, maybe not. Modern browsers are able to download multiple files at a time in parallel. So that means that it might be more efficient and faster for your browser to download several smaller files all at once, then one large file. The results will vary from site to site so you will have to test this for yourself.

HTTP/2 has been a game changer here.

Here is an illustration of how the number of requests is not the best indicator of efficiency.

On my test site I started with this – 43 requests and a 639 ms load time:
2 requests less, half the load time

By simply adding two, large unoptimized images to the page, I only add 2 http requests, but the load time doubles due to the page size:

2 extra requests, double load time

So you cannot focus on just one indicator but have to take a holistic approach to optimization.

5. A CDN is a must

This is another extremely common piece of advice that shouldn’t be taken at face value.

The point about CDNs is that ideally you want to serve assets (e.g. images, CSS files, JS files) to your visitor from the closest location to them as possible to reduce latency.

Latency is the time it takes for the server to send content to the user’s browser. The further away from the server the user is, the longer it takes to deliver those assets.

Imagine throwing a baseball to a teammate. The further away your teammate is, the longer it takes the ball to get to him/her. With a CDN, content is distributed amongst servers around the world so that it can be served from the closest point to the user and therefore the user sees it faster.

So a CDN really only makes sense if your audience is distributed internationally, otherwise it may be pointless and an unnecessary expense.

You also have to keep in mind that because a CDN is an external server, the browser has to do a DNS lookup to reach that external server and each lookup takes a little time (approx 200ms).

So you have to make sure that the speed gain you get from the CDN outweighs the DNS lookup and resolution time.

Speed optimization is definitely not a “one size fits all” process. It requires patience and sometimes trial and error to find the best solution for your site. Any tip or advice you come upon will have to be tested in your specific circumstance to see if it will work for you.

Header image courtesy Rami


Comments (16)

Glad to have all of that out of the way, thanks for debunking so many "theories" all at once, Lucy!

Question:
WPML just published an article about their upcoming version and how it has been optimised for object caching with W3TC. How will this effect WPML and WP Rocket? Is there something you will tackle too or are you already fully optimising for WPML?

I would like to hear more about this, because most of the client projects I do are using WPML and WP Rocket.

Thanks,
Piet

It's nice to read that sort of thing , some customers swear by the PageSpeed notes and it is sometimes difficult to make them understand that a better rating does not mean that the site will be faster ...

Wow, first blog post and you're already delivering the goods Lucy!

Thanks for this, you just cleared up a few things in my head about website speed, which had been confusing me for a while.

There's so much confusing stuff out there about what you should/shouldn't do etc, and I feel like this post makes a good, foundational place to start learning.

P.S. just an idea, but something like this might be good in a infographic.

Well said, site optimization is not one recipe that fits all.
I think the CDN can have value when your site is not hosted near your visitor location. It's common to see more EDGE locations than hosting locations. I also think the grading gives a good overview of how your pages are rendering but as you said it's not a substitute but a complement to the loadtime.

I am glad someone else than me shares this opinion. Well written! Thank you.

Awesome article and I totally agree on the page load thing. In a post I wrote rather recently, it is stated that people will leave a page after .1 seconds if nothing happens! You need to convert with speed.

Also, to further share your praises, sometimes caching is detrimental to content driven sites if not managed correctly -- displaying old content or the wrong content.

Good read! :)

You mentioned: " For example, if you have a highly dynamic site where page caching is not realistic, database caching would be helpful. The average blogger does not have to worry about that."

Is there some kind of decision tree to be used to determine if you fall in the highly dynamic site category? Any help and what doesn't make a site ripe for a page caching plugin would help. I can't seem to find something that's helpful out there on the web.

Now i got it.. The last part. Less HTTP request means more fastest website lunch.. Thanks :)

there is a http/2 ? wow, its about time and i hope it comes out fast because everything we have today almost runs off of very old technology. I really hope http/2 gets rid of the need for browser caching (if that relates, otherwise im a noob)

Nice post. I agree and have them in a book I've been putting together.

An addition in support, most modern browsers (including IE 11) also support SPDY which also mitigates several of the problems; in fact, minimizing files could eventually be a negative with SPDY and HTTP 2.0

Very helpful article, and thank you for this.

Hi,

Terrific article that explains things clearly.
The main problem I have with caching plugins is that they often break site code due to other plugins etc.

It is good that yours is fully supported but it is expensive given I have about 10 websites.

Dale.
http://www.thesmallbusinessmarketer.com

Hi all, AJ here,

I'm not trying to rain on the parade by any means, but many of the 'myths' you're trying to debunk are not myths at all. Further, you're actually perpetuating the myth that these things are myths (wat?).

Myth #1 About True Thing Being Called a Myth: "the performance grade of your site does not matter!"

Yes, it does. All other things being equal, the site that scores higher on PageSpeed Insights, in particular, will have verifiably superior, real, user-experience-centered performance metrics (what are those? stay tuned...).

Myth #2 About True Thing Being Called a Myth: "The only metric that matters is the actual load time of your page."

There are in reality several 'load time' metrics: The loadEvent; Fully Loaded; Page Load Time (PLT); Document Complete, A.K.A OnLoad (which is what most people are actually citing when referring to 'load time"). Which one are you actually referring to? Ah, but wait... it doesn't matter. Regardless of which of these is actually being referenced as regards load time, the assertion that 'load time' is the most important performance metric remains 100% false with any and all of them.

Indeed, 'load time' of any sort is quite nearly worthless, relative to the other, far more meaningful, user-experience-centered performance metrics that are responsible for how fast a website is *perceived* to be. These include:

1.) Time to First Byte
2.) Start Render Time
3.) Time to (Above-the-Fold) Visual Completion
4.) First Paint Time
5.) domContentLoaded Time
6.) Time to Interactivity
7.) A site's Speed Index

Some of the most basic evidence that load time is (generally speaking) an incidental has been around since at least 2001 with Christine Perfetti's & Lori Landesman's, "The Truth About Download Time". An excerpt:

"When people accomplish what they set out to do on a site, they *perceive* that site to be fast. […] About.com, rated slowest by our users, was actually the fastest site (average PLT: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average PLT: 36 seconds)."

In short, a site’s load time (and it doesn't matter which “load time” metric we are referring to) is 8th if not 9th in line when it comes to performance metrics importance.

Just like you, your users care about getting done as quickly as possible what they came to a website to do. Ergo, true optimization begins and ends with whether or not a site’s users *perceive* a website to be fast. Which is why Google is so adamant about prioritizing the optimization of above-the-fold content and why they so highly favor sites that have implemented Progressive Rendering. And yes, that's why when you get dinged on PageSpeed Insights for having render blocking CSS and .JS you should in fact be getting dinged. It's accurate because render blocking assets negatively affect UX (user experience).

And the bottom line is this: Load time, any load time, really only matters when it’s a user experience problem; and, if you're not optimizing those user-experience-centered performance metrics that are responsible for how fast your website is *perceived* to be… you are not optimizing at all.

There are further (gargantuan) problems with this article, but my wife just brought me a plate of nachos, so... I'll have to get back to you. Assuming this actually gets posted and stays posted, of course. :)

All the best - and be well,
AJ
Managing Partner
WpFASTER.org

Love your writing style, you tell it as it is!

Hi Lucy, Awesome share on Speed optimization of a website. Agree with you Content Delivery network (CDN) is must to improve page load time, Choosing a good web host, Optimizing images, Removing unnecessary plugins and themes are some of the factors help us to improve website speed

Great Post. This post helps me to choose WordPress platform for developing a website. Thanks for clarifying my doubt related to security of WordPress platform.

Latest Articles of Page speed and caching
Subscribe to Our Newsletter

Stay in the loop with the latest WordPress and web performance updates.
Straight to your inbox every two weeks.

Get a Faster Website
in a Few Clicks

Setup Takes 3 Minutes Flat
Get WP Rocket Now