The Top 5 Things You HAVE to do to Speed Up WordPress

AJ @ WpFASTER Blog 3 Comments

There are a lot of “Make WordPress Faster” posts on the Web. And a lot of them are good. But we’ve distilled the things necessary — the “you ain’t got no choice, yo” sort of stuff — down to this Top 5. Do these and, by and large, the details of increasing your WordPress site’s speed take care of themselves.

There are a lot of “Make WordPress Faster” posts on the Web. And a lot of them are good. But we’ve distilled the things necessary — the “you ain’t got no choice, yo” sort of stuff — down to this Top 5. Do these and, by and large, the details of increasing your WordPress site’s speed take care of themselves.


#1 You HAVE to Get Your Hosting Right

separator


“…Imagine that bus again. Now imagine that bus stacked floor to ceiling with people, the bus driver has 18 people on her lap and there are at least 3 people hanging out of every window. THAT is the overwhelming majority of shared hosting…”
Hosting is a rite of passage for anyone that’s ever owned a website. For all intents and purposes, everyone starts out with crappy hosting and learns the hard way that $1.99 per month hosting isn’t going to cut the mustard. But what’s the deal? Why does it matter? Why is the performance of your WordPress property so affected by which company hosts it and what sort of hosting environment it is being served from?

As I like to say to my students, your website’s host is where your website lives. It is where everything that makes your WordPress installation what it is resides.

Now, if your website lives in a crowded area like a major metropolitan area, it’s going to find getting around to be quite slow and plodding, just like you would were you to live in a big city.

The analogy I’m making here is to that of shared hosting. And if you’re here reading this, there’s about a 75% chance that your WordPress site is not only on shared hosting of some kind, but on some of the worst shared hosting money can buy.

In a nut shell, shared hosting works like a queue; the person ahead of you in line gets on the bus first. In other words, the website that has had a request made to it before yours gets that request handled before yours. And the fact of the matter is that you’re paying a buck 99 per month for hosting because the server your WordPress site is on is absolutely stuffed with other websites.

Imagine that bus again. Now imagine that bus stacked floor to ceiling with people, the bus driver has 18 people on her lap and there are at least 3 people hanging out of every window. THAT is the overwhelming majority of shared hosting…

In an ideal world, everyone would of course have their WordPress website on a dedicated server (“dedicated” meaning that your site and only your site is on the server). Due to cost constraints, this is obviously not feasible.

So!

The answer, then, is to either go with an affordable VPS/Cloud Hosting solution, or, if that is not feasible, the best possible shared hosting you can get your hands on. For the former, we recommend and migrate our own clients to Siteground’s Cloud Hosting; for the latter, we recommend and migrate our own clients to Siteground’s “GoGeek” plan. If your site is not monetized in any way (i.e. is simply your blog, etc.), you can get away with Siteground’s “GrowBig” plan.


#2 You HAVE to Use PHP 7+ WITH Zend OpCache Configured With VERY Specific Values & Directivesseparator


“…if this flies straight over head of your experience level, don’t freak out. If you get your hosting right, optimal Zend OpCache configuration is taken care of for you by default….”
Wait… wut? I know, right? Don’t freak out. Put simply, PHP is the programming language in which WordPress is written. And it can be big, complex and wasteful. However, there has been a sea change with PHP; so much so that the versioning (the version number they stick to it) jumped from PHP 5.6 all the way to version 7 in one tremendous leap.

And the performance difference between PHP version 5.6 and version 7 is equally tremendous.

However…

The unleashing of the true supersonic power of PHP 7 lies in Zend OpCache, but what is that? Well, Zend OpCache provides faster PHP execution through opcode caching and optimization. It improves PHP performance by storing precompiled script bytecode in the shared memory. Translation: You want this.

Zend OpCache, properly configured, is so powerful that it can actually feel like full page caching is implemented for your site’s front end when there is none (particularly advantageous when full page caching is not possible for a page or pages on your site). Zend OpCache, properly configured, will provide a logged-in user experience that rivals your WordPress website’s front end when there is full page caching in play. How cool is that?

That said, Zend OpCache not properly configured can, at best, do nothing, and, at worst, actually slow your site down. Here is WpFASTER’s Zend OpCache configuration:

Again, if this flies straight over head of your experience level, don’t freak out. If you get your hosting right, optimal Zend OpCache configuration is taken care of for you by default.


#3 You HAVE to Get Caching Right and Implement it Wherever Possible

separator

 “…get and keep all of your WordPress site’s pages cached at all times and do so without one of your users having to hit the page first…”
Ahhhh caching. Page Caching, Memory Caching, Fragment Caching, OpCode Caching… Caching the cache. Caching the cache of the cache so you can cache the cache of the cache’s cache… I digress. Which type of caching your WordPress site needs is going to be relative to what it does and what it’s purpose is. But as a basic rule of thumb, there are two types of caching that are “must-haves”. The first is (Full) Page Caching:

Remember how I previously said that PHP can be big, complex and wasteful? Well, because of that, coupled with the fact that WordPress is a database-driven content management system, things can feel boggy for you and your website’s users even with Zend OpCache in play and optimally configured.

Enter Page Caching

Full Page Caching basically “freezes” your WordPress site’s pages and posts at a moment in time. That “photograph”, if you will, is then served to your users bypassing a lot of the more complicated and resource-intensive things WordPress has to do to otherwise serve the page your user has requested. Page Caching alone can make your website feel ten times faster than it is without it. So, as you can see, Page Caching should be implemented whenever and wherever possible.

“…Less is more when it comes to speed…”
But beware… because not all Page Caching solutions are equal. WpFASTER’s approach to Page Caching mirrors our approach to all WordPress optimization techniques: Less is more when it comes to speed. Generally speaking, what you want is the simplest possible solution without a tremendous amount of bells and whistles. So, what we want is the following. No more, no less. A Page Caching solution that:

  1. Caches pages!
  2. Keeps them cached automatically so that no one ever hits a “cold”, uncached page/post.

For this, we ourselves use and recommend Comet Cache Pro. Comet Cache Pro offers several features, but the one that really matters is the Auto Cache Engine. Use it. It will get — and keep — all of your WordPress site’s pages cached, keep them cached, and do so far more reliably and efficiently than other, superficially similar plugins:

Alas there are going to be some WordPress sites for which Full Page Caching is simply not possible — or not possible on all pages — generally due to the need for pages to remain dynamic. Forums, for example; checkout pages as another, if you are using WooCommerce.

Worry not. So long as you have everything I have already exampled in order, you have a means by which to mitigate the database-intensive nature of WordPress.

Enter Memory Caching (i.e. Memcached)

If it could be reduced to two things, WordPress is made of PHP and database queries. That’s overly reductive, of course, but play along.

WordPress does all manner of things that require it to communicate with your database first. If your database is big and densely populated, just as it is with the shared hosting analogy above, things are going to slow down and in extreme cases grind to a halt.

Memcached to the rescue!

While Memcached Memory Caching can also be leveraged to cache entire pages, it is generally used to speed up dynamic database-driven websites like your WordPress site by caching data and objects in RAM — or “Random Access Memory” — to reduce the number of times your database must be consulted or communicated with. If you have a WordPress site that is in any way dynamic, and the odds of that are precisely 99.9237365628763%, then Memory Caching is a must to reduce those calls to your database.

Here is WpFASTER’s Memcached Memory Caching configuration:

Once more, if this flies straight over head of your experience level, don’t freak out. If you get your hosting right, optimal Memory Caching configuration is taken care of for you by default.

I’m sensing a pattern here…

#4 You HAVE to Optimize and Properly Scale Your Images

separator


“…I don’t know about you, but I hate tedious, repetitive, mundane tasks; whenever and wherever possible, especially when it comes to optimization, I favor the automated solution so long as it produces a quality result…”
I want to put this into perspective for you. We — and the optimization community, more generally — consider a “big” page to be anything over 1MB (that’s 1 Megabyte). It is, unfortunately, not at all uncommon for us to take on optimization projects and/or see WordPress-powered websites with 8MB worth of images on a single page…

…Said differently, images alone in this example make the page 8 TIMES bigger than the average “big” page, weighing-in at 1MB. And that isn’t counting CSS, JavaScript, the HTML– nothing but the images!

That something is on the Internet does not mean that it does not have a very real weight to it. The heavier a thing is, the harder it is to move. It is no different with your WordPress site. Remember: Less is more when it comes to speed. And images are really low-hanging optimization fruit in that uncompressed and improperly scaled images carry a lot of unnecessary weight that forces your users to download unnecessary data. At it’s core, image optimization is nothing more than removing all of that unnecessary data, thereby making it weigh less, thereby getting the image to the user that requests it faster.

I don’t know about you, but I hate tedious, repetitive, mundane tasks; whenever and wherever possible, especially when it comes to optimization, I favor the automated solution so long as it produces a quality result. So, we at WpFASTER use the EWWW Image Optimizer Cloud for ourselves and for clients. The user interface and it’s tabs are pretty much self explanatory:

As indicated in the image, the EWWW Image Optimizer Cloud requires an API Key, which you can get here. No, it’s not free. For good or ill, free, high-quality, automated image compression for WordPress is long gone.

This tool will not, however, properly scale your WordPress site’s images, which is the second fundamental aspect of image optimization. As it is with the obese images discussed above, images that are scaled larger than they have to be present the same problem for obvious reasons: Cramming a 1920 x 1080 image into a 150 x 150 thumbnail is clearly adding unnecessary weight to your website.

How to solve? Google “image resizer” and have at it, all Page 1 results are equally effective.

#5 You HAVE to Eliminate as Many Render Blocking Resources as is Possibleseparator


“…Like it or not, the world’s gone full ADD. People are simply not going to wait very long at all for something to start happening on your page before they bounce…”
This is the Big Dog on Google’s PageSpeed Insights for a reason: It ALWAYS matters to real-world performance, whereas not all of the recommendations made by this tool (and others like it) ultimately do. Render blocking resources do exactly that: They keep something, anything, from happening on your page until the browser is done figuring out what they do, why they are there and exactly how they matter in the aggregate. Then and only then can the browser move on with the business of rendering your page.

Like it or not, the world’s gone full ADD. People are simply not going to wait very long at all for something to start happening on your page before they bounce. This is why the real-world performance metrics that matter the most are those that combine to form perceived speed. These metrics include:

  •  TTFB (Time to First Byte);
  •  Start Render Time;
  •  Time to Above-the-Fold Visual Completion;
  •  First Paint Time;
  •  domContentLoaded Time;
  •  Time to Interactivity; 
  •  And — Most Importantly — Google’s Speed Index.

The more render blocking resources your WordPress website has, the more these critical, user-experience-centered performance metrics — the actual metrics Google themselves use to determine your website’s performance and user experience — are negatively affected.

I’ll be perfectly frank here, however: Getting rid of render blocking resources for your WordPress site is not easy; it’s not even intermediate a lot of the time. You shouldn’t let that deter you from trying, however, as there are a couple of extremely well developed and well-thought-out tools available to help. In fact, these two plugins are staples for us, often serving as the foundation of any properly constructed WordPress performance architecture we devise for our clients. They are:

So there they are, folks! Get these 5 things out of the way and you are literally doing better than 90% of all other websites, WordPress or not.


atom small

Have a question or a comment? Let us know below!

Comments 3

  1. Hi ,, Sam
    we paid $800 dollar and upgrade the server already!
    but your team didn’t reply anything and not start the work.

    You’re teaching even online course, but how can you be so unresponsible???
    only can contact your team by email and why you didn’t reply it???????

Leave a Reply

Your email address will not be published. Required fields are marked *