Want to improve your website speed and boost your site rankings? Looking to improve your sites Core Web Vitals? Are you confused by all the conflicting information out there on how to speed up your wordpress site?
Many people in Facebook groups claim to be speed experts when, in reality, they’ve optimized two or three sites. I see so much nonsense advice shared in those groups that I usually close the browser, shaking my head.
The advice is terrible to the point where some could do real damage to legitimate money making sites and businesses.
This is why I’ve put together this in-depth guide on Website Speed Optimization…
My team and I have optimized over 4000 sites since we started offering speed optimization as a separate service under our WPSpeedFix.com brand.
That’s a pretty decent sample size.
In this post, you will learn in detail the state of site speed optimization and where things stand today. You will find out how to speed up a website and, by the end, I’m hoping that you have some new insights you won’t find anywhere else on the web.
You will get a bunch of insights around site speed that will help you make improvements that shift the needle in a meaningful way.
Read on, to find out more…
Table Of Contents
- Where To Start
- What Is Page Speed or Site Speed?
- How Site Speed ACTUALLY Impacts SEO
- Google Pagespeed Insights – Interpreting Reports
- Site Speed Jargon You Should Know
- The Theory of Constraints – Putting Page Speed Optimization in Perspective
- Simple Site Speed Optimization Checklist (Getting To FAST)
- Advanced Website Speed Optimization Checklist (Getting To “As Fast As Possible”)
- Nitropack & Other Optimization SaaS Solutions
Where To Start
You’ll see action steps throughout this post and I’ll link to various resources around the web. I’ve written this with as little fluff as possible and a way that each section can be digested and you can run through the action items quickly and easily for that section.
I’ve also included audio in various sections as an easier way to digest this info as it can be somewhat technical at times.As a starting point, run your site through our free site speed test at https://sitespeedbot.com
It’ll take 60 seconds and will give you an initial baseline to start with plus will provide you with insights you probably won’t have seen before. Run it a few times and also from multiple locations so you get a good baseline average to start you off.
You can track the history at https://app.sitespeedbot.com/domain/YOURDOMAIN.COM
What Is Page Speed or Site Speed?
Page Speed or Site Speed are essentially the same thing and refer to how fast a web page loads. Now, this is not to be confused with Google Pagespeed Insights or Pagespeed Score which is Google’s site speed test and it’s own scoring system for the speed at which a page loads.
Site speed is one of the big things in SEO right now, even more so with Google rolling out the Core Web Vitals metrics which has made speed metrics more visible in Google Search Console.
This video outlines everything you need to know about Core Web Vitals:
There’s lots of different tools for measuring the speed of a webpage and several different timings that measure speed. We’ll get into the specifics of what the different metrics mean and which are actually important further down in this article…
Also, regardless of what terminology you use, one key thing most people miss when looking at the speed of their site is that the speed of all pages matter, not just the homepage!
How Site Speed ACTUALLY Impacts SEO
This is probably the real reason why you’re here and reading this, right? You want better Google rankings and more organic traffic.
But first, let me address a myth…
Anywhere you see SEO advice dispensed these days, you’ll see it’s just a given fact that faster websites rank better.
About half the inquiries we get at WPSpeedFix look something like the screenshots below.
Someone will ask us for help with their site speed because they want “better SEO.”
The frustrating thing with a lot of these inquiries is that most of them have crappy on-page SEO: missing title tags, meta descriptions, and so forth with even crappier content with next to no keyword-content matching.
Speed probably won’t make a dent overall if your SEO sucks!
You will learn about why this is and how the theory of constraints can help you make more money in a few sections below…
Below, I address the real reason why faster websites rank better and how you can improve your site speed and rankings.
Here are the three ways “site speed” will help your SEO.
I put site speed in quotes because technically, two of these problems aren’t site-speed factors and more a case of poor website speed being a symptom of these problems.
1. Uptime and reliability
Uptime of your website and reliability is probably the most important one of the three here and often the most overlooked. People go wrong on this one all the time in site speed land.
The uptime and reliability of your site and hosting provider REALLY matters. This makes logical sense when you think about it for a minute – downtime is essentially zero speed; therefore, we should probably start our speed optimization process by making sure we have as little downtime as possible.
When I see people talking about site speed improving rankings, it’s most often when they move from a bad host to a good host. They then see their speed improve, see their rankings, organic traffic and conversions improve and determine that speed is clearly better for SEO.
What’s actually happened is they’ve improved their site’s reliability, and Google can now crawl it without getting frequent DNS errors or intermittent downtime in the form of 502 and 504 errors.
Most of the cases where there’s a clear organic traffic and rankings improvement after speed optimization work, it’s due to the site’s reliability being improved in some meaningful way, not because the site is faster.
Secondary to that, the other most common reason is that canonical issues with http and https versions of the site or www and non-www were fixed as part of their WordPress speed optimization work which arguably should have been fixed if technical or onpage SEO work was done on the site.
So based on this insight here’s some simple action items we can take to improve website reliability:
Get uptime monitoring setup for your site
…And if you’re highly monetized, monitor the top 5-10 pages. Uptimerobot.com has a free plan that checks on 5-minute intervals, so there are zero excuses not to get this setup. We use the paid plan, which checks at 1-minute intervals, and it’s still dirt cheap.
If you want to really throw cash at this, Uptrends.com would be the next level again.
Use good hosting close to your primary target market.
Every day we see people using Bluehost, Hostgator, Godaddy, and other garbage low-quality web hosts and often in the US when the target market is in Europe or Australia. A high quality host is the absolute minimum bar to entry here – WPX hosting is good quality, dirt cheap, and one of the best hosting for affiliate marketing.
If you’re running a site that needs more processing power, eg Woocommerce, then Cloudways is typically the hosting we recommend.
If you want to get super technical, Gridpane, Runcloud, or Wordops coupled with a VPS from Vultr, Linode, AWS, or Google will allow you even more granular control over your hosting. These combos will enable you to squeeze every last drop of performance from your site.
That said, you should probably work on your SEO instead of messing around with servers – refer to the theory of constraints section further below.
DNS hosting speed and quality really matters.
It’s possible to have good quality web hosting but still be using shitty DNS hosting. This will have a massive impact on your site’s overall reliability.
DNS hosting turns your www.domain.com into an IP address so the browser can find your web server and connect to it. The first thing the browser does when you type in an address is to do a DNS lookup.
The speed of this lookup is critical and hugely overlooked. Slow DNS hosting can take 0.5-2 seconds to answer a query, which means your site takes 0.5-2 seconds to load regardless of how good your hosting is.
Because DNS performance is so overlooked, our speed test tool SiteSpeedBot checks DNS hosting speed as one of it’s metrics.
A common mistake we see all the time is using the default DNS hosting provided by your domain registrar.
Don’t make this mistake!
The worst performing DNS hosting we see is typically run by IT support companies trying to squeeze a few bucks out of their clients and charging for this service. If you do client work you’ll probably see this more often than not.
Backup your site and ideally use two backup systems.
Over the lifetime of a site, data loss is almost inevitable, and often that means downtime. You can minimize downtime by having a quality backup solution in place you can quickly restore from.
For WordPress, you always use two backups, one provided by the host and then I recommend you use BlogVault on top of that.
Security, patching, and site maintenance
Security, patching, and site maintenance are all important and are intertwined with reliability. Make sure you’re doing plugin updates and patch updates on a regular basis. For any service you’re spending a reasonable amount of money on it’s also worth checking in a few times a year to see if they’re offering new features that you’re not taking advantage of.
For example Cloudflare release new features a couple of times a year that are often switched off by default.
For security and firewall, we use a combo of Cloudflare and the free version of Wordfence. The paid $20/month version of Cloudflare has a quality firewall built in and is worth it if you’re well monetized.
We typically add some custom Cloudflare rules into our sites that will boost both performance and security. Check out this post for details.
2. Page Weights or Page Sizes
The size of the pages (page weight) on your site matters, but I rarely see it talked about. People will brag about having a site that loads in under 2 seconds but you look at their speed report screenshots and the page is 5mb in size…regardless of how fast a tool says your page is, a 5mb page is going to load slowly.
We discovered how important the page size across an entire site is for SEO by accident. At the time, we had a couple of our SEO agency client sites that were stuck. We couldn’t move their rankings no matter what we threw at them.
Around the same time we had a similar customer come to us at WPSpeedFix wanting speed optimization. The rankings of their site had been stuck and they wouldn’t budge so they figured they’d get the speed improved to see if that would solve the problem.
We ran their site through some tools and saw that most of their pages were 10mb+ in size, definitely a problem from a speed perspective. They had no lazy loading and hadn’t done any image compression. By the time we’d implemented these practices and optimized the site, most of these pages were 1-3mb in size.
Within a week or so, they saw rankings improve dramatically. In my mind, it was too big an improvement in too short a time to be purely because the raw speed had improved. I had a hunch that the page size reduction might be the reason for the dramatic shift in rank, so we had a look at our two stuck agency sites.
Long story short, they had similar page size issues that we resolved, and the rankings soon recovered.
Implement Lazy Loading
On today’s web you really need lazy loading for images, Youtube videos and iframes to minimize page size. We generally use WP Rocket’s lazy load plugin (free) or the lazy load that’s part of their paid plugin.
The lazy load library this plugin uses is excellent and they have some simple code you can add to your functions.php to exclude specific image filenames or image classes from lazy loading.
Autoptimize has a decent lazy load feature as well but the library it uses (lazysizes) doesn’t perform as well as the one WP Rocket uses in most cases.
Reduce The File Size Of Images
Using the webp image format is a really simple way to reduce image sizes and overall page size. There’s lot of different ways to implement this, we tend to use Shortpixel as well as the image compression in the paid version of Cloudflare.
We prefer to use a plugin that does the optimization once versus a CDN or service that does it. The CDN is essentially doing the optimization on the fly which can be slower and less effective.
If you’re dealing with a non-WordPress site or site that can’t use Shortpixel, the $20/month version of Cloudflare has image optimization built into it.
Use JPGs instead of PNGs where possible.
Many of the problems we see with page sizes is because content writers have downloaded images from Canva, which suggests you use PNGs by default. This leads to a scenario where you have a bunch of 0.5mb+ PNG images on a page that would have been 0.1mb as JPGs
Shortpixel has a PNG to JPG conversion method to fix this, however, it can be buggy at times. This plugin also works well but can be clunky on sites with a considerable number of images.
Size images appropriately.
Like the PNG issue above, we commonly see sites where the image size or resolution is huge compared to their placement on the site. Using a 5000-pixel wide image in a section where the image is 500 pixels means the image file will be 5-10x larger than it needs to be.
The approach we take here is to fix this on important pages manually and then use the bulk resize feature in Shortpixel to bring images across the site down to a maximum resolution.
Run pages through a speed test tool
Speaking of content writers, include a step in your publishing process where you have the writer run the page through a speed test tool once it’s published to check the page size. Many page size issues could easily be avoided if this happened when each page was published.
If you want to go the next level up here, Cloudinary has an amazing image audit tool that will analyze a page in detail. We tend to find it’s 30% too optimistic but still useful for determining where the fat on a page is coming from.
Assess any third-party code
Third-party code can be a big contributor to a pages size.
3. CRUX Data and User Experience
CRUX stands for Chrome User Experience Report. It’s data pulled from the browsers of millions of Google Chrome users.
Google is using Google Chrome User Experience (CRUX) data in its Core Web Vitals scoring and in Google Search Console. This is the data that they are using in their algorithm as it relates to site speed. It’s probably also the way they’re rolling user engagement metrics into their algorithm.
A lot of effort is wasted regardless because people are typically focussing on the wrong elements, such as overall load time versus how the user experiences the website. The new Core Web Vitals go a long way towards addressing this.
Core Web Vitals has a 28-30 day cycle time
Core Web Vitals data is processed on a monthly cycle. If you have a Core Web Vitals speed error in Google Search Console it’ll take 28 days to review. The CRUX reports we’ll talk about in a moment process data from Google Bigquery monthly with data available on the second Tuesday of the month.
My guess is this means any change you make to site speed that improves engagement metrics will likely have a 30 day lag time before it potentially could impact the SERPs.
Lab Data (or Synthetic Testing) vs Field Data (or Real World Data or Real User Monitoring (RUM) )
An ESSENTIAL concept to understand with site speed is the difference between lab data (or synthetic testing) versus field data.
Lab Data/Synthetic Testing is what a speed test will report back. GTMetrix, SiteSpeedBot, Pagespeed Insights, Lighthouse, and every other test tool is doing a synthetic test. It’s emulating a real user and giving you the speed results based on its testing methodology.
Field Data/Real World Data/RUM is the actual speed in the real world as the user experiences it. CRUX data is field data, and data from RUM (Real User Monitoring) tools like Uptrends is real world data, i.e. it records the actual speed of the page when the user visits the page.
What we care about is speed in the real world because that’s what matters. This is why you can have a site that scores 100 in Pagespeed Insights yet still feels slow. Likewise, a lightning-fast site can potentially have a low speed test score.
We’ll dig into this a bit in the next section, for now one chunky action step for you – setup a CRUX speed report for your website at this link: https://g.co/chromeuxdash
This report will give you a breakdown of Google’s field data about your site speed and how users in the real world are experiencing your page loads.
However, you’ll only be able to generate this report if your site has a reasonable level of traffic.
Google Pagespeed Insights – Interpreting Reports
Let’s talk about Google Pagespeed Insights (PSI). We spoke about CRUX reports and lab data versus field data already, so by now, I hope you’re starting to understand why a 100 score in Pagespeed Insights isn’t the holy grail.
Below, I will share some important things you probably don’t know about PSI and why they matter…
Google Pagespeed Insights is testing from the US
This means that if your site is hosted in Europe, Asia or Australia, it will be slower in the US and thus get a lower PSI score.
If you want to get an accurate Pagespeed score internationally, then try using the Lighthouse Report in Webpagetest.org (see screenshot below) or run it on your local machine using Chrome by following these instructions.
Mobile Pagespeed is testing a slow connection and CPU limited device!
The reason why your mobile score is lower than your desktop is that Google is emulating a 1.6mb/second internet connection (slow!) and a Nexus 5 device (a 5+ year-old device) with a 4x CPU slowdown (25% CPU power).
That is a super slow device, so unless your site has been built from the ground up on a lightning-fast theme to achieve a high mobile score, you’ll probably struggle to get past a 50 or 60 score.
When looking at mobile speed, make sure you also consider the percentage of mobile users visiting your site.
Our WPSpeedFix website is well overdue for a rebuild and is built on a slow theme. Right now, the site has a desktop PSI score that floats between 90-100 (depending on whether we’re experimenting with speed stuff on the site), and a mobile score of 40-80.
Apart from the regular questions asking why we don’t have a 100 score, I’m not bothered by the mobile score because mobile visitors are typically only 10% of total traffic.
Your Pagespeed Insights score isn’t a fixed score!
The score is not fixed! Your PSI score changes depending on your page’s speed AND it also varies depending on the Lighthouse version used.
The current version of Lighthouse v6 was released in June 2020 and scores sites much more aggressively than the previous v5. A website that got a 100 score on v5 would typically see a 70 score on v6
This calculator will show you exactly how the scores are calculated from the speed timings.
All pages matter
Just because you get a 100 score on the homepage doesn’t mean your inner pages are fast. Screaming Frog is probably the quickest way to see the PSI score for each page on your site.
Here’s a couple of articles on the Screaming Frog website that’ll explain how to use it to get Pagespeed scores and CRUX data across the site.
Simple-ish getting started guide: SEO Spider Configuration
Super technical Core Web Vitals guide: How To Audit Core Web Vitals
CRUX data/field data is more important
Like we talked about already, the field data or CRUX data Google has on your site is more important than the PSI score as it’s the actual speed of the page, not just lab data.
Site Speed Jargon You Should Know
There are some terminology and concepts you need to have a basic understanding of to maximize site speed. Here are the important metrics, what they mean, and which we focus on:
TTFB – Time To First Byte
TTFB is the point at which the web server responds to you and starts sending data. Smaller is always better here.
Typically we want to see this consistently at 0.1-0.2 seconds in the country the site is hosted in and 0.2-0.5 seconds internationally. Any higher than this on a consistent basis means you have some work to do.
Page Weight / Page Size
We talked about this already; Page Weight is the Page Size. We want this as small as possible, however, for key pages, 3mb is the absolute maximum you want to be at.
Onload Time / Document Complete / Load Time
Onload Time (also called Document Complete or Load Time) is when the processing of the page is finished, the core files like images and CSS have finished downloading, and the browser fires the document-complete event.
Broadly, in WordPress this is when the core of the site has loaded, but the third party files have not yet finished. Lower is always better here, but we typically want to see this somewhere between 1.5-2.5 seconds.
Onload Time is the metric that Pingdom’s speed test tool uses (they call it Load Time), BUT Pingdom will often incorrectly report the timing because it’s not rendering the page as a normal browser would.
You’ll see most speed optimization content and sites use Pingdom’s timings in their screenshot examples because of this underreporting. It makes them look good! (Yeah, we do it too)
GTMetrix can be set to use Onload Time and SiteSpeedBot.com displays Onload Time as one of its 6 key metrics.
Onload Time is probably the one to focus on if you have an ad driven site as the ad network code will blow the fully loaded time out substantially.
Fully Loaded Time
Fully Loaded Time is what GTMetrix uses by default and is probably what people refer to as their load time. This number is the time at which the complete document event has fired, AND there’s be no network activity for 2+ seconds
We used this timing in the past, but it’s no longer a great overall metric as a single piece of code from a remarketing pixel can substantially blow out this timing.
Lowest is always best here. A site with a moderate amount of marketing and analytics code would typically see this somewhere in the range of 0.5-2 seconds higher than the load time/document complete timing.
Number Of Requests
Number Of Requests is broadly the number of files that download on the page – lower is always better here and under 50 is ideal. If you have any ad code or using something like Easy AZON you’re going to see this number be quite high.
FCP – First Contentful Paint
First Contentful Paint is the time at which the first part of the page starts to render. The visitors effectively see the page start loading at this time. Lower is always best here, and typically anything under 1 second is fast.
LCP – Largest Contentful Paint
Largest Contentful Paint is roughly the end of the render, not exactly, but close enough. It’s when the largest part of the page above the fold has finished rendering, and the user perceives the site to have mostly finished loading. We want this under 4 seconds but ideally as close to the FCP time as possible. A fast site would achieve a LCP within 1 second.
CLS – Cumulative Layout Shift
CLS is a new metric that attempts to measure how stable the page’s layout is during the loading and render process.
You’ve probably experienced this yourself where you head to a site, go to click on something, and a banner bar loads or the layout changes slightly, and you have to adjust where you’re clicking. That’s a layout shift and a bad user experience.
Google’s target for CLS is under 0.1
You’ll have seen this term around if you’ve done any speed testing, e.g. “Avoid Render Blocking Resources” or similar.
The way it’s phrased is poor and implies something is broken or incorrectly setup but that’s not the case.
In simple terms, render blocking means the site render can’t continue until the browser processes a file.
No Jquery equals a faster site.
CSS is another render-blocking resource, and your page can’t render appropriately without processing CSS.
You may have noticed from time to time some sites have a FOUC (Flash Of Unstyled Content) where the site appears broken for 0.5-1 second while it’s loading. This is because someone has deferred the CSS or fiddled with the CSS in some way to solve the “Avoid render blocking resources” recommendation in a speed test tool and, in the process, partially broke the site render.
In general, the fewer render-blocking resources your site has and the smaller they are, the fastest the site will render. I.e. A lower FCP and LCP time.
Total Blocking Time
Total Blocking Time is a measure of responsiveness. It is the time between the FCP time (when the site starts to render) and the Time To Interactive (TTI), which is when the site responds to user inputs.
It’s a measure of the time difference between when users see the page loading and when they can interact and use it.
Speed Index is a synthetic metric and is a broad measure of load time. You’ll see it in Google Pagespeed Insights. It’s roughly equivalent to Fully Loaded Time.
We prefer to focus on the other metrics as the Speed Index Timing isn’t as tangible as FCP, LCP and load time.
Async and Defer
Async and Defer are two ways to optimize this. There’s a screenshot below from this excellent article that explains in more detail:
Most JS snippets from 3rd party marketing tools use an Async tag, which is not optimal for speed. Changing this to Defer or adding a Defer tag will help speed up our site render.
The WP Rocket also has a defer function, which can make a huge difference to speed.
The Theory of Constraints – Putting Page Speed Optimization in Perspective
I see people spend days and days on speed optimization chasing that 100 score in Pagespeed Insights because they think this will make their site magically rank at the top of Google.
Speed optimization is important, but just like everything else in SEO, it alone won’t give you magical Google ranking. Obsessing over site speed is flawed thinking.
I want to introduce you to a mental model or framework called “The Theory Of Constraints,” which explains why this is the case. Understanding this mental model in detail will help you make a bunch more money with less time and effort!
Once your site speed is fast, getting to as fast as humanly possible will probably only generate marginally better returns in rankings, traffic and conversions. This is because the “constraint” is no longer speed. It’s something else like on page SEO or content or your conversion elements.
Below, is a snippet from Taylor Pearson’s fantastic article that explains this in detail. It’s well worth a read.
Simple Site Speed Optimization Checklist (Getting To FAST)
Let’s dive a bit deeper and get into more specific action items. Here’s how we approach going from slow to fast enough, and fast enough to be as fast as possible.
Many of these we’ve talked about, and you’ll be familiar. However, many like Instant Page, you’ll likely not have heard of.
- Use good hosting close to the bulk of your target market. WPX hosting for affiliate sites and Cloudways for sites needing more processing juice. If you’re using Nitropack (will discuss a few paragraphs down), then Cloudways is better as it’ll handle the beating Nitropack gives it.
If you want to push the envelope, run your own VPS with Wordops, Runcloud, or Gridpane sitting on top of it, running a pure Nginx server configuration (no Apache)
- Use good DNS hosting. Ideally either Cloudflare or if you don’t like Cloudflare, use Digital Ocean. Both are in the 10 top on https://dnsperf.com
- Update from HTTP to HTTPS. HTPS is important for security and SEO. In addition, by updating to HTTPS a browser can use the newer, faster HTTP2 protocol which speeds up how quickly files can download from a site.
Note: Bad hosting won’t have HTTP2 support. Our speed test tool https://sitespeedbot.com will probe for this support. Also, this newer protocol won’t work with HTTP://
- Set Up Caching. You can’t get WordPress to go fast without caching. WP Rocket is the way to go for the DIY-er and less technical person.If you’re using Cloudways, install Redis and use this Object Caching plugin too: https://wordpress.org/plugins/redis-cache/
If you have a high-end Woocommerce site, eg doing 50-100k uniques a day or a checkout every 30 seconds, then the paid version of this Redis plugin will make you go even faster.
- Set Up Lazy Loading. Lazy Loading is a must use. We use WP Rocket’s lazy-load (either in their free plugin or paid caching plugin) and occasionally Autoptimize’s lazy-load.
- Include Image Compression & Nextgen Image Optimization. We use Shortpixel. Here’s how we do it.
- Set Up A CDN. We typically use Cloudflare and even the free plan is lightning fast. Don’t use this if you’re on WPX, use their CDN instead as it does “edge caching” by default.The paid version of Cloudflare will give you a very good firewall and image optimization.
BunnyCDN is a good alternative if you can’t use Cloudflare. It’s cheap and does image optimization too.
- Install “Just in Time Preloading”. We use the plugin from https://instant.page. Just in Time Preloading preloads links on your site when you hover on them.There is a more aggressive alternative to this called Flying Pages – don’t use it.
It’s too aggressive and will often break your hosting as it will typically increase the load on your hosting by 5-10x. It’s aggressive nature often loads dozens of pages in the background on the user’s device too which can cause the device to slow down when they’re navigating the page or interacting with it.
- Use Newer PHP Versions. Use the highest PHP version your site supports. Newer PHP versions are faster than older versions, so PHP 7.3 is faster than 7.2 and so forth. There’s a free PHP Compatibility plugin from WPEngine (can be used on any site) that’ll run a PHP compatibility check.
If it raises any flags, go and check manually with the theme or plugin provider to confirm they support the PHP version you want to use.
- Install A Firewall. The free version of Wordfence has a great firewall in it and will filter a lot of the crap hitting your site. While it does chew some CPU cycles to do its filtering and firewall, there’s an overall net gain as it will block scrapers, crawlers, and other garbage traffic that will chew up resources.
- Add Cloudflare Rules. Add these Cloudflare rules into your site. They will work on the free plan. They’ll block a lot of nonsense traffic hitting your site and, in some cases, will dramatically reduce CPU load as it will near eliminate brute force password attempts.
Advanced Website Speed Optimization Checklist (Getting To “As Fast As Possible”)
- Set Up Object Caching. This is a type of cache where database queries are stored. It will help a lot on Woocommerce sites or where sites are doing a lot of processing. Object caching can be set up to use Memcached or Redis. DO NOT use disk caching for this. It’ll slow you down.
Redis will be faster but Memcached is more widely available. I mentioned Redis in the last section around Cloudways but many other hosts support this too
If you have a VPS it will support Redis in most cases. However, it’s worth logging a support ticket and asking your host to support it.
- Preconnect, Preload, Prerender and Prefetch. These are “resource hints”, snippets of HTML that sit in the header of your site that tell the browser to do things in the background.
DNS prefetch does DNS lookups in advance before a file or resource is requested. As we talked about already, some DNS hosting can be slow, and this works around it. We typically don’t use this and use Preconnect instead, as that’s even faster.
Preconnect establishes a server connection in advance before a resource is requested. This can help speed up 3rd party code. Preconnect does the DNS Prefetch AND Preconnects to the server, so it’s doing more work in advance.
We use Autoptimize to add Preconnects, it’s on the Extras tabYou can automate this using this plugin…but I prefer to do it manually as it’s quite simple.
Here’s a short video that explains how to use this field and find slow third party resources that you should use preconnects on:
Preload can be used to change the order in which files on the page load. For example, we can speed up our FCP timing by preloading the logo file AND disabling the lazy load on it.
We typically use Autoptimize to add preload directives and, in some cases, use this plugin to just add preload code on the homepage to speed that up.
Here’s a short video that explains where to do this in Autoptimize:
Prefetch is what Instant.page uses to load pages in advance. Nothing manual required here. It’ll do all the work.
Prerender is a sneaky directive that will background load an entire page and dramatically speed up sites in some cases.
For example, if 80% of your visitors head to your homepage, then head to your top “best xyz” article, then you can add a prerender directive to the homepage that will background load the “best xyz” article.
However, only one prerender tag is supported per page.
In WordPress this plugin will dynamically work out which pages should be in the prerender tag and will dynamically insert them.
NOTE: This will blow out the reported load times in most speed test tools as the tool is loading two pages, the tested page, and the background loaded page. This doesn’t reflect the user experience in reality, so is OK (remember our synthetic test versus field data section).
- Use The Highest SQL Server Version WordPress and your hosting supports. This is probably only relevant on Cloudways or a VPS, but make sure you set up the highest possible SQL server version. Many default Cloudways installs are shit with SQL 5.5. Changing this to SQL 5.7 will make a noticeable dent on performance.
BACK UP YOUR STUFF BEFORE MESSING WITH THIS!
- Convert Your Database Tables to Innodb Storage Engine . SQL databases use two different storage engines, MyIsam and Innodb. Older WordPress installs and some hosts will set you up with MyIsam tables which will be slower than Innodb.
There are several differences between the two but in simple terms, MyIsam tables will lock a database table while it’s being written to. This means that on a busy site these database write operations start to queue and cause delays in processing which manifest as slower loading to the user.
Think of the database table as an Excel spreadsheet where if one person has it open, another person can’t make any edits.
Innodb tables only lock the row in the database table that’s being written to, so there’s little to no database queuing. It’s like using a shared Google Sheet that multiple users can work on at once.
Converting from MyIsam tables to Innodb tables can give you a solid speed boost particularly in the backend and on higher traffic sites.
For most affiliate sites, the database will be a few hundred megabytes at most, so we use a plugin called Servebolt Optimizer (https://wordpress.org/plugins/servebolt-optimizer/ ) to do the conversion. If your database is over 1 GB in size, you might need to run the convert operation a couple of times.
If the database is big, e.g. several GB, don’t do this during peak times, and probably not a good idea to do the conversion using this plugin as you’ll wind up knocking over the server for a reasonably long period of time. Better to do this at the database level itself in PHPMyAdmin and probably wise to get a developer to do this for you.
BACK UP YOUR STUFF BEFORE MESSING WITH THIS
- Set Up Edge Caching On A CDN. Edge caching is the reason why WPX scores so high on speed tests. It is also why Nitropack is fast – it does it too. In fact, WPX is a relatively average performing host without their WPX cloud enabled.
Edge caching is where a full copy of each page, including the HTML file, is stored on the CDN end-point or node. This can dramatically speed up how fast the page loads. It also takes the load off the hosting because the CDN node is doing most of the work.
The term end-point or node or edge location refers to the CDN server closest to the visitor. For example, Cloudflare has 200+ edge locations – here’s the list: https://www.cloudflare.com/network/
When we combine Edge Caching with Just In Time Preloading from the instant.page plugin, we dramatically speed up how fast our site loads. This is because the preload pulls pages into the local CDN node in advance.
Our SiteSpeedBot.com site is hosted in the US but because we’re using edge caching on Cloudflare, for me the site loads from the Cloudflare server in Sydney. This means it’s lightning fast because the data is coming from a local server.
At the end of 2020 Cloudflare released a new product for WordPress called APO which does edge caching out of the box. The cost is $5/month (previously only available on the $200/month plan) and will significantly speed up your site worldwide >> the cost is a no brainer!
More details here https://www.cloudflare.com/automatic-platform-optimization/wordpress/
- Consider Cloudflare Argo. Argo reduces latency by routing traffic over a private network outside of the internet. Consider it the difference between driving through a city during peak hour versus taking the tunnel that goes under the city. There’s less congestion in the tunnel.
For most sites, this probably is not worth paying for as our Instant.page plugin has effectively the same impact (reducing latency) on affiliate sites. If you’re highly monetized, have high traffic, and have a global audience, there may be a business case for it.
- Nitropack can be used to squeeze more juice out of a site. It’s effectively doing many of the things Cloudflare and WPRocket do but in a more automated fashion. I’m actually not a massive fan of Nitropack, as it’s not really faster than a well-optimized site. It also changes the URL of important assets like images to load off a nitrocdn.com image, which isn’t great for image SEO.
Nitropack & Other Optimization SaaS Solutions
OK so no speed optimization article would be complete without something about Nitropack. I get asked about it all the time and what my opinion of Nitropack is.
All these services are great tools and they will speed things up especially if you’ve done zero speed optimization.
These tools would have you believe that there’s some magical secret to getting a 100 score in Pagespeed Insights, but it’s not magic!
Site speed is really just a set of technical best practices. All these tools do is check the boxes for a number of optimizations, many of which you can do manually as one time optimization or are already provided with your hosting or a cheaper to do with a plugin.
Doubling up on some types of optimizations can actually cause your overall site speed to drop so it’s important that you understand what these tools are doing. Most of them do some variation of these functions:
- Edge Caching or Page Caching on the CDN nodes (Cloudflare’s new APO service does this, WPX’s “Cloud” also does this out of the box)
- Image Optimization – compressing images, webp injection and adaptive image resizing (you’ll usually get the best result doing this once with a plugin like Shortpixel)
- Minification (which is vastly overrated in terms of speed impact so not a big deal)
- Gzip and Brotli compression (your host should have this too)
- HTTP2 protocol support (your host should have this)
- Deferring JS (we prefer to use WP Rocket or Autoptimize for this)
- Delaying JS (we use WP Rocket “delay JS” feature and/or Google Tag Manager)
- CSS optimization
These are some of the big win items when it comes to speed. Edge caching, in particular, is an important optimization for Core Web Vitals BUT again, don’t double-up as you’ll usually end up going backwards. Also important to understand that there’s still a lot of optimizations these tools can’t cover.
For example, some important optimizations that these tools can’t do or problems they can’t fix:
- Make up for garbage or unreliable hosting
- Fix HUGE pages, if your content writers have uploaded MASSIVE images, no amount of compression or fiddling with lazy load is going to fix that
- Fix 404 errors and other broken code
- Fix issues related to what’s on the page. E.g. If you have a Youtube embed above the fold on a page that page is most likely going to have a poor LCP time and fail the Core Web Vitals test, the solution is usually to adjust the content and move the video below the fold.
- Disabling animations and transition effects.9% of animations and transition effects are bad for speed as the animation fires after the content loads so the visitor sees the content later. Many also cause CLS issues.For example, if your fade in happens over 0.5-0.8 seconds (typical fadein time) the visitor has to wait another 0.8 seconds to see that content. In effect, the site is 0.8 seconds slower for them.
So broadly, my advice would be to optimize manually or at the site level first and then determine what gaps still need to be filled that you could use CDN tools to fix.
I’m not particularly fond of Nitropack as it’s expensive and doesn’t do anything particularly great for the extra spend over, say Cloudflare’s $20/month plan with APO enabled, Argo added on and used with WP Rocket.
Being anal about SEO, I don’t like that the images load off their nitrocdn hostname instead of my own hostname as this is going to have a small negative impact on image SEO which is something that’s usually important on my sites.
If you DO use Nitropack, make sure you use the Just In Time preload library from https://instant.page (either the plugin or embed code).
Just In Time preloading gets a significant boost when Edge Caching. Your visitors will get a significantly faster experience browsing the site and you’d see some improvement in Core Web Vitals.
If you have a reasonable volume of repeat visitors Speedkit would be worth a look over Nitropack. One of it’s sneaky tricks is to use service workers (a small piece of software that sits in your browser and does things in the background) to accelerate the site. This will dramatically speed up repeat visits.
With any of these tools make sure you’re using the Core Web Vitals data to determine whether they’re a gain for the site. All these tools will show big improvements in Pagespeed Scores BUT behave very differently in reality and Core Web Vitals is actually what counts!
We’ve covered a ton of ground in this article and I’ve dumped a lot on you in this post so let’s recap some of the key takeaways:
- Reliability beats speed so make sure you’re using good hosting (WPX or Cloudways) and uptime monitoring (Uptimerobot.com).
- Backup your stuff, use two backups! (Hosting backup + Blogvault).
- The speed of all your pages matter as well as the page sizes. Screaming Frog is a simple way to check page sizes sitewide .
- Add a speed test step into your content publishing process so you don’t end up with a bunch of content that has huge images and is inadvertently screwing up your SEO .
- Field data or real world speed is what actually matters so wise to monitor this with our CRUX dashboard reports and a tool like Uptrends.
…also, remember the theory of constraints. Site speed is important but make sure you’re not neglecting other important areas of your SEO!
We’re constantly updating our SiteSpeedBot.com speed test tool with new optimizations and insights we’ve discovered and developed so check back regularly.
If you need help with your speed optimization, head to WPSpeedFix.com and request a free site speed audit and we can advise what’s achievable in terms of site speed.
Got Questions or Comments?
Join the discussion here on Facebook.