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 website speed testing and 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 website 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 website speed optimization and where things stand today. You will find out how to speed up a website performance 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 website speed optimization that will help you make improvements that shift the needle in a meaningful way.
Read on, to find out more…
Where To Start
You’ll see action steps throughout this post and I’ll link to various resources on website performance 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 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 web pages load. Now, this is not to be confused with Google Pagespeed Insights or Pagespeed Score which is Google’s speed test and it’s own scoring system for the speed at which a site 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 engines Console.
This video outlines everything you need to know about Core Web Vitals:
There’s lots of different tools for measuring website performance 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 website speed testing 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 content delivery network 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…
But first, before putting massive amounts of load time and effort into improving site speed, ask yourself:
Is your on-page SEO on point? If not, fix it up first using our on page SEO checklist.- But, if you do have solid on-page SEO, read on…
Below, I address the real reason why faster websites rank better and how you can improve your 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 inspeed 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 website speed optimization process by making sure we have as little downtime as possible.
When I see people talking about 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 website 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 performance:
Get uptime monitoring setup for your site
…And if you’re highly monetized, monitor the top 5-10 web 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 take this up a notch, services like Littlewarden.com and Domaincomet.com are useful for monitoring things that also impact uptime. eg SSL certificates and domain expiries.
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 website performance.
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.
We use Cloudflare for DNS hosting (it can be used with all other features off) as it’s consistently the fastest DNS worldwide as tested by DNSPerf.
Because DNS website 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 website performance and security. Check out this post for details.
2. Page Weights or Page Sizes
The size of the pages (web 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 web page is 5mb in size…regardless of how fast a tool says your web page is, a 5mb web page is going to load slowly.
We discovered how important web pages size across an entire site are 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 website 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.
Source: www.wpspeedfix.com
We ran their site through some tools and saw that most of their web 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 web page size issues that we resolved, and the rankings soon recovered.
Action items:
Implement Lazy Loading
On today’s web pages you really need lazy loading for images, YouTube videos and iframes to minimize web 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 page 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 web 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.
>> Here’s how we do it with Shortpixel.
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 web 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 web 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 web pages manually and then use the bulk resize feature in Shortpixel to bring images across the site down to a maximum resolution.
Run web 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 web page size. Many web page size issues could easily be avoided if this happened when each web 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 web page is coming from.
Assess any third-party code
Third-party code can be a big contributor to a pages size.
Here are some simple ways we combat this:
WP Rocket has released a new version of their plugin, which can pause JavaScript execution until the user interacts with the page. In some cases, this can be a useful way to lazy load third-party tools.- Alternatively, lazy load any live chat tools and things like FB messenger bots by moving them to Google Tag Manager and adding a 5-8 second delay into their trigger (use the timer trigger). This gets them out of the way of the page load but doesn’t impact their functionality.
- If you’re using an ad network like Adthrive or Mediavine, find out if they have website speed optimization features. Both these networks have website speed optimizations that fire the ads later in the load process and can lazy load ads, significantly reducing the impact ads have on speed.
- We often see tools like Hotjar and Luckyorange installed when no AB testing is happening, and nobody uses the data. This is a simple case of removing them. If you are using these tools, move them to Tag Manager, and use the Window Loaded trigger which then loads them last in the page load process. Doing this will speed up the site render.
- Turn off any theme, plugin or app features or remove them altogether. Many themes, apps, and plugins load a file for every feature you have enabled. Go through the feature settings of your themes, plugins and apps in detail and turn off stuff you’re not using. e.g. Turning off the Google Maps API can lead to significant reductions in page size
- The most effective way we’ve found to see the web page sizes across an entire site is to use Screaming Frog SEO Spider. Connect the Pagespeed API to Screaming Frog, run a sitewide crawl, and it’ll give you the total page size data under the Pagespeed tab.
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 engines 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.
This is the area that most people think of when looking at website speed optimizations to improve SEO. While this is important, if you ignore the other two areas (reliability and page sizes), any efforts here are likely wasted.
A lot of effort is wasted regardless because people are typically focussing on the wrong elements, such as overall web page load time versus how the user experiences the website speed. 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 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 web 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.
Action Items:
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 speed and how users in the real world are experiencing your web page loads.
However, you’ll only be able to generate this report if your site has a reasonable level of traffic.
More background on this report here.
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).
This means super slow mobile devices, 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 internet users visiting your site.
Our WPSpeedFix website is well overdue for a rebuild and is built on slow websites themes. 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 devices score because mobile internet users 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 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 pages servers respond 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 web page is finished, the core files like images and css files 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 delivery network 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 page 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 page 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 load 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 move the mouse just a few clicks to hit the target page. That’s a layout shift and a bad user experience.
Google’s target for CLS is under 0.1
Render Blocking
You’ll have seen this term around if you’ve done any website 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.
You’ll see the Jquery JavaScript library is commonly referred to as render-blocking. This is because most themes use Jquery, and this file is required to render the page. It’s also why themes like Generatepress and WPAstra promote the fact that sites can be built on them without Jquery.
No Jquery equals a faster site.
CSS is another render-blocking resource, and your page can’t render appropriately without processing css files.
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 files 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
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 page load time.
Async and Defer
You’ll see these used in relation to JaVascript and css files and render-blocking resources. By default, all JavaScript is render-blocking. If it doesn’t have an Async or Defer tag, the browser will stop processing the page render to download and execute the JavaScript. This slows down the page render considerably.
Async and Defer are two ways to optimize this. There’s a screenshot below from this excellent article that explains in more detail:
In a nutshell, to optimize JavaScript and css files , we ideally want it in the footer and want to use a Defer tag on it. This means it loads later in the loading process and gets it out of the way of the site render.
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.
One of the key functions of services like Cloudflare Rocket Loader and NitroPack is extracting the JavaScript and css files from a page and deferring it all.
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 website speed optimization chasing that 100 score in Pagespeed Insights because they think this will make their site magically rank at the top of Google.
Website peed optimization is important, but just like everything else in SEO, it alone won’t give you magical Google ranking. Obsessing over 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 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 delivery network 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.
“…. Theory of Constraints which states that any system with a goal has one limit and worrying about anything other than that limit is a waste of resources. Suppose a factory has an assembly line with three sections and two of those sections can produce 100 units per hour while the third can only produce 50 units per hour.
In that case, any investment outside of improving the third section won’t improve the outcome. Doubling the first two to have the capacity to produce two hundred units per hour while the third can only produce fifty, still only produces fifty units per hour.”
Taylor Pearson
taylorpearson.me
Simple Website 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 website 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.
- 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.
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.
- Install Google Tag Manager. Moving third party JavaScript to Tag Manager and using the trigger Window Loaded will have the code load AFTER the site has loaded. This is a simple way to stop JavaScript and css files from render-blocking.
- Defer JavaScript & Cloudflare Rocket Loader. Changing your JavaScript tags to Defer (vs Async) will speed them up. WP Rocket or Cloudflare Rocket Loader can do this. Be wary of doing this as it can break things. If you look in the Chrome dev tools it’ll usually throw warnings if it’s broken something.
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.
When the user hits the link for “best xyz” the page is fully loaded and cached in their browser. The only thing that needs to happen is JavaScript and css files need to be executed.
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 page load time 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 website 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 busy sites these database write operations start to queue and cause delays in processing which manifest as slow websites to the users.
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 web servers closest to the visitors. 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 web servers.
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.
Nitropack is probably the most well known in the affiliate/SEO community but there are several competitors including Pegasaas, Speedkit, Edgemesh and Cloudflare with their APO service.
All these services are great tools and they will speed things up especially if you’ve done zero website 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 speed to drop so it’s important that you understand what these tools are doing. Most of them do some variation of these functions:
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:
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!
Conclusion
We’ve covered a ton of ground about website speed optimization in this article and I’ve dumped a lot on you in this post so let’s recap some of the key takeaways:
…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 website speed optimization, head to WPSpeedFix.com and request a free speed audit and we can advise what’s achievable in terms of speed.
Got Questions or Comments?
Join the discussion here on Facebook.
