Site Speed Steps – A Detailed Guide To Taking Your WordPress Site From Slow To Go

Fast WordPress site speed scores…they’re like that magical brass ring that many bloggers dream of, but very few are able to obtain. This is especially true for WordPress (.org) bloggers.

You can certainly install the 2020 theme and just leave everything alone and you’ll achieve a 99 mobile and 99 desktop score on Google Page Speed Insights and an A score on a GTmetrix speed test. But then your blog would look like everyone else’s, have no branding, and would be pretty boring.

Would Google like it? Probably. Would your users? Probably not.

And therein lies the challenge.

As bloggers, we are always having to balance the wants of Google (because organic traffic is the BEST traffic) and the needs of our users. If we simply please Google (plain theme, no images, no plugins, no third-party scripts), we will get organic traffic, but our bounce rates will be high and our users likely won’t return.

If we just please our users (lots of images, plugins to make their lives and our lives easier, and some third-party scripts), the page speed will be slow and Google won’t reward us with organic traffic. And those visitors that do show up will wonder why this WordPress site is slow to load and will leave before they ever take the time to read the content.

It’s a puzzle. The good news is…I like puzzles.

The interesting thing about WordPress speed and the Google Page Speed puzzle is that it keeps changing. As Google adjusts its algorithm and page speed expectations along with it, we need to retest everything to make sure we are doing what Google asks. At the same time, we must balance not disrupting our user experience.

As an example, about 18 months ago I went through a massive page speed exercise. I spent the better part of a weekend (and about 20 pots of coffee) testing, changing, testing, changing, testing…you get the picture.

The problem I encountered was there wasn’t one good guide to speeding up a WordPress site. Instead, I spent a ton of time Googling searches like the following and sifting through tons of articles to find the tips that worked for me.

• Why is WordPress so slow?
• How do I conduct a WordPress speed analysis?
• Is my WordPress theme slow?
• How do I speed up my WordPress site?
• Do plugins slow down WordPress?
• Why is my WordPress site so slow?

And that was just a few that I can remember.

But…by the close of the weekend, I was pretty happy. I had crunched my images, implemented a CDN, and tuned my caching plugin so that my pages were loading in under 2 seconds according to the GTmetrix speed test. My Google Page Speed Insights scores were in the 80s for mobile and 90s for desktop.

NOTE: 3 seconds should be your goal when you are evaluating page load times. Anything beyond 3 seconds should have you considering why your pages are loading slowly.

I was humming along, content with my scores, until recently. But the fact of the matter was that while I had fixed up my site, there wasn’t a good WordPress speed guide out there.

Flash-forward about six month. Two different resources that I trust mentioned that my site seemed like it was loading more slowly.

To me, that was a bit of a slap in the face. I had spent a lot of time optimizing my site and making things run quickly. So, to tell me my site was slow sounded like more of a “them” problem, than a “me” problem.

The problem was this was definitely a “me” problem.

I jumped over to Google Page Speed Insights and ran some tests and…[Insert bad word here]…my site was running slow. How slow?

60 on mobile and 68 on desktop. Not to mention that it was taking about 6 seconds to load according to GTmetrix.

NOTE: Some folks have asked if the GTMetrix speed test is the same thing as the Gmetrix speed test or Gmetrix page speed test. The answer is yes, they are the same thing. Apparently folks are just forgetting to add in the extra “T” when searching.

Now some of you, who have never optimized a site before, might be thinking “that’s great compared to my 19 on mobile and 25 on desktop.”

You’re right. It is better. But it’s still not great.

I had already done an optimization and to see my scores plunge that far…well…embarrassed me a bit. Plus, a six-second wait for a page to load is not good. Three seconds is the best-practices target. Anything beyond that and people are ditching your site.

So, what changed? What was different from 18 months ago? There were a few things:

1) I had joined an ad network and was displaying ads on my site.
2) I was writing much longer posts with a lot more images
3) I had upgraded my hosting plan (which should have helped, not hurt)
4) I had made several changes to my site layout

All of these things, when combined, ended up hurting my scores. To be honest, I should have been tuning and optimizing monthly, or at least every three months, but I hadn’t….and it showed. It became clear that, just like content optimization, speed tuning for WordPress was going to have to become an ongoing process, not just for me but for anyone running on WordPress who wants organic traffic.

Since a definitive WordPress speed guide still didn’t exist, I figured I would run through the process again and this time document it so others could learn how to speed up a WordPress site.

So, that’s the background on how this project came to be and last weekend I decided it was time to do something about it.

The last time I optimized my site, I didn’t really document the changes and share them. This time, knowing there are a LOT of bloggers out there wondering “how do I improve my Google Page Speed Insights scores” and “how do I speed up my WordPress blog load times”, I figured I would document the process for others to benefit from.

How much should you fret about page speed and tests like Google Page Speed Insights and GTmetrix?

This is a bit of a loaded question and the answer depends.

I would argue that quality and consistency of content is more important than page speed. If you don’t have content that people want to read, then what’s the point of a fast server or a site that loads quickly?

With that in mind, if you are a beginning blogger who doesn’t have a lot of content, then I wouldn’t spend a lot of time fretting about your site speed. Instead, I would encourage you to focus on building a content creation process and publishing a lot of content that is meaningful to your audience.

If, however, you are an established blogger who has a content creation process and is consistently working to improve your site, then it might be time to work on your page speed and testing scores. If your page speeds are in the 70s and 80s consistently, then I wouldn’t spend a lot of time on tuning.

The key for established bloggers, though, is making sure that you are tuning both for desktop AND mobile. Google has clearly signaled that mobile user experience is going to be part of their algorithm in the future, so if your site speed is slow on mobile and your Google Page Speed Insights mobile scores aren’t in the 70’s or above, don’t ignore that.

If your scores are below 70s on desktop and mobile and you have time to dedicate to testing, then I would recommend running through a site speed exercise. It’s going to help your user experience and Google has indicated that it values site speed, so it’s probably worth working to get those scores into the 80s or 90s.

If you think a tuning exercise is right for you, then read on.  

Before we get started, a few disclaimers

PLEASE READ THESE…they are important.

The importance of a testing site

First and foremost, my goal in creating this process was to show anyone, regardless of their technical aptitude, how to speed up their site. I figured the best way to do that was to just walk you through the exact process I followed and give you the steps to take.

Additionally, I wanted to do it in a manner that caused little-to-no downtime to a live site. My site is my business, so downtime means lost revenue.

To minimize downtime, my process was to build my site from the ground-up on a subdomain and then re-point my URL to that newly built site once testing was completed and I had reached my target scores.

If your hosting plan offers the ability to create staging sites, you could do that too. The key is that the process should not involve you tweaking and tuning your live site.

Messing with your live site is how outages happen. That’s how you get locked out of your admin console. That’s how you create the WordPress admin console white screen of death.

Basically, that’s how bad things happen and we are not going to do that.

My goal is to show you how to do this the safe way. If you choose to experiment on your live site, please be sure to take a backup before you make any changes. Also, please do not complain if your site goes down because you chose to experiment on your live site. If you choose to do that and honk it up, do not blame me.

Your site is different than mine, so your results may vary

Every WordPress site is different. Your theme, your layout, your images, your content length, your plugin selection, your ad partner…they are all different and they are ALL going to impact your site speed.

If you want my exact results, you would have to host on my provider, replicate my theme, my plugins, my content length (please don’t replicate my content), and my image sizing/compression.

That is not realistic. It would be kind of silly.

But because of that, your scores are going to vary from mine. You might score better, and I will be totally jealous. You might score worse and you will need to make some choices about whether your scores are okay or if you need to make changes.

My goal is to help you identify where those slowdowns are, which should help you make an educated decision about what to change and what to keep. I will even give some recommendations about alternative options that you can try.

Feedback is a good thing

I am not perfect. I am not an expert. I am not a guru. I have not thought of everything.

BUT, I do have more than a decade of experience building sites with WordPress. I have built dozens of WordPress sites ranging from small blogs to websites for billion-dollar corporations.

In other words, I have been around this block a time or two.

That said, I am open to suggestions and feedback. One of my favorite things about the WordPress community is that we support each other in our willingness to make the WordPress core and the supporting themes and plugins better.

So, with that in mind, if you have ideas on how I could have tested better or have an idea on how to improve something (different plugin, different service, etc.…) then definitely leave a comment.

I would love to give it a test.

Just reach out to me via my contact form on socmedsean.com and let me know what you think.

Some things you need to consider when it comes to speeding up your WordPress site

There are some key components that you need to think about when it comes to building a fast website. Here are the top elements that I will focus on throughout this testing process.

The quality of your hosting sets the pace

The first thing to consider is your host. In the motorcycle community, we have a saying that goes “If you have a $20 head, buy a $20 helmet.”

The same principle holds true when it comes to hosting. If you have a $5/month website then, by all means, host it on a $5/month host.

My site generates thousands of dollars in revenue each month, so I pay for a good host and a robust hosting package. I do not say that to brag. I say that as a matter of fact, to point out that your hosting quality (and corresponding cost) should reflect the quality of your site.

I will go through my recommendations for hosting later on, but you need to choose a host that both fits your budget AND offers good response times.

Without a good host, you are NEVER going to get a good site speed score.

Let me repeat that.

Without a good host, you are NEVER going to get a good site speed score.

You can have the fastest theme, the fewest, streamlined plugins, and have the best caching schema but if your hosting sucks…your scores will never reach their full potential.

A well-coded theme will keep you from ripping your hair out

The second important component is your WordPress theme. If you are on a great host, but are running a slow theme, then you are undoing all the great speed your host is providing.

Once again, you usually get what you pay for. If you want a great, fast-loading, well-supported theme you will likely need to pay for it.

There are some lightweight free themes out there, but I have watched too many free themes go unsupported by their developers over time. They just don’t have any incentive to keep them up to date and supported.

So, find a theme that is fast, well-supported, and has a track record for ongoing improvements.

Again, I will give my recommendations on themes later, as well.

More plugins lead to more bloat, which leads to a slower site

Third, you need to really consider what plugins you are running. In my currently optimized state, I only run 18 active plugins and that is fairly-heavy for my setup.

If you are running 30 or 40 different plugins, you need to seriously rethink their functionality. The more active plugins you run, the slower your site will run.

NOTE: Deactivated plugins are not loaded when each page of your site is loaded, so they will not hurt your page speeds. It is best practice, however, remove a plugin that you do not intend to use.

You will see the plugins I use in my testing worksheet, but you are going to need to determine the right plugin setup for your site. The good news is I am going to show you a process by which you can test and identify any plugins that might be slowing down your site.

If you identify a problem plugin, then you will need to either accept the site speed impact or find a suitable replacement. The other alternative is to ditch it completely. As you will see later on, I ditched a couple of my plugins during this testing.

Minification and combination leads to speed, but can also lead to problems

The fourth element we will work on is minification and combination of Cascading Style Sheets (CSS) and JavaScript. By combining and minifying those files, you can speed up your site considerably.

There are plugins that do this, and we will test a couple of them.

The key to successful minification and combination, though, is testing. One of the minification/combination plugins gave me the best speed scores but caused my site fonts to break.

Another fixed the font problem but gave me slower speeds and scores. In the end, I had to find the right combination that worked with my server, theme, and plugin combination.

You will have to do the same and I will give you some options to try.

Caching is the key to speed but only after everything else is optimized

Fifth in the process is caching. The more you cache your site, the faster it will run.

There are TONS of caching plugins and services out there and we will go through a few of them. Some are included with your host; others are free plugins or purchased plugins.

There are different types of caching, as well. Server caching, page caching, and content caching are all things you need to understand if you are going to reach the best scores possible.

Because there are different types of caching and a ton of plugins to choose from, you are going to have to find the magic combination for your site. I will show you my combination, as well as discuss some other options for you to try.

Set realistic expectations for your site and your scores

Finally, and MOST importantly, it is important for you to set realistic expectations about your scores. As you will see during this process, there was a point where I got my site to a 98 mobile and 99 desktop.

That wasn’t some stripped-down, initial install of WordPress with the Twenty Twenty theme installed.

This was my site with my chosen theme, my selected plugins, and most of my necessary functionality.

It was an amazing moment. I did a little dance. I ate some M&Ms to celebrate.

But then things went downhill.

Why? Because I added some new functionality in. Namely, I turned on the ads for my site.

My scores dropped. I was sad. I threw some M&Ms across the room.  

But then I took a breath…and got over it.

Since ads are my revenue source for my site, I just accepted that they were going to decrease my scores.

Because my wonderful ad partner sources ads from a variety of providers, it means that there are going to be several new server connections that my site is going to need to make.

More connections and more images on the site (ads), means that the site is going to load slower. There are a few ways to somewhat offset that, but lower scores are just a reality.

As a result, I had to accept that the scores for my ad-supported site weren’t going to remain at 98 mobile and 99 desktop. I accepted and reset my expectations.

After cooling down a bit, I set a new target for my scores. Mobile is the hardest to score for because Google Page Speed Insights simulates accessing the site on a 3G network. That means, by definition, that your site is automatically going to score lower on mobile than desktop.

As a result, I determined that I wanted to get at least a 95 on desktop and an 80 on mobile. I know…I know…I started at 98 and 99 and I am settling for 80 and 95 because I also want to make money.

NOTE: If you are running an eCommerce site using plugins like WooCommerce, do not expect to get stellar page scores. eCommerce sites tend to be very image heavy and make a lot of database connections to get product data. Because of this, they tend to run a bit more slowly than an average blog. That’s not to say that there aren’t ways to make eCommerce sites fast, but they generally require a lot of technical expertise.

Accepting a slightly lower page score is also okay because Google Page Speed Insights isn’t the only metric you should be using to measure your site. In fact, the more important metric you should be using is load time and we will use a different tool to test that.

To measure your page speed load times, we are going to use a test called GTmetrix. It’s a very well-respected test (that’s also free) and will help you test your load times and find any bottlenecks that might be slowing you down.

After testing my site on GTmetrix, which you will learn about below, I was back to eating M&Ms instead of throwing them.

Are you ready? Are you REALLY ready?

This is not a quick process, but it also isn’t a really long process, either.

It took me four days, on-and-off, to finish my testing and configuration. I was testing and documenting and testing and documenting….so it took me quite a while longer than it should take you.

For you, it could take a full day. Or, if you go through it slowly, it might take you a few days.

The good news is you can go at your own pace because you will be working on separate copy of your site, instead of a live site. See why that separate site is so important?

TIP: I highly recommend that you do not publish new content to your live site while you are going through this process. If you choose to, be aware that you will also need to enter it into your new site once it goes live. Just make your life easier and focus on the testing rather than new content.

Okay, if you are ready to get going, grab your coffee, tea, or caffeine of choice and let’s get rolling.

Testing your current live site and familiarizing yourself with the tools

The first step in determining the status of your current site is to understand the current test scores. I’m assuming that you’re reading this blog post because you’re not happy with your scores.

Some of you, however, might not have ever tested your site. That changes now.

The testing tools

For the purposes of this exercise, we are going to us two tools. Google Page Speed Insights (GPSI) and GMetrix Site Speed Testing (GMetrix).

GPSI is going to help us understand the mobile and desktop scores that Google has indicted are important and could be impacting our organic search rankings.

A good Google Page Speed Insights score for your WordPress thing can be a difficult thing to accomplish.

GTmetrix, is going to help us understand the actual load times for our test page and will also help us identify some of the slow-loading components that might be causing issues.

GTmetrix site scores can help you understand how quickly your pages load.

The adjustment tools

The tools we are going to use to make changes to the site are cPanel, the user interface for most hosts and the WordPress admin console.

Using cPanel, we will create a new instance of WordPress and a subdomain that allows us to access and configure the site. We will also use cPanel to set up services like Cloudflare, if it is included with your hosting plan.

The cPanel tools will allow us to create a fresh install of a WordPress site.

Using the WordPress admin console, we’ll add a theme and plugins, we’ll configure all the settings, we’ll import your content to your testing site, and we’ll adjust all the settings that will get us the speed we desire.

If your hosting plan does not include a Content Delivery Network (CDN) like Cloudflare, then you will also need to be comfortable creating and configuring a Cloudflare account.

Cloudflare is an example of a CDN, which you can use to make your pages load more quickly.

It’s not scary and is pretty straight-forward.

The tracking tools

One of the most powerful parts of this process is the tracking process. We are going to use an Excel spreadsheet that allows us to track each individual change and the impact it makes on the site.

The spreadsheet will allow you to track each of your different configurations and make notes about the outcomes.

It will show you an average score of your tests, giving you an understanding of whether the change you made either helped or hurt your page speeds and scores. With that information, you should be able to make data-driven decisions about changes to your site.

The testing process

This is really important. REALLY important.

The way we test needs to be consistent and needs to consider how servers work and how the tools we use to test work.

For example, when I talk to WordPress users who complain about slow GPSI scores, I usually ask them how many times they test each page. 99% of the time, the answer is “once.”

The problem is a single test of a page using GPSI is not going to give you an accurate reflection of your page speed.

Here’s why:

• The first time you run the GPSI test, it is likely that GPSI is going to call an un-cached version of your page. This is going to be the slowest test of your site because an un-cached page is always going to be slower than a cached page. When GPSI makes that first, un-cached page call, your server is going to likely add the page to its server cache.
• The second time you run the GPSI test, it is going to receive and test the cached version of that page. I would bet that your second test is always going to be better than the performance of your first test. By the time GPSI is done testing the second time, it’s likely that your page is going to be cached by the server, any caching plugin you have installed, and any CDN you have installed.
• The third time you run the GPSI test, you are going to get an actual cached test which is likely more reflective of what your users are going to see. During the testing process, this is the first entry you are going to add to your spreadsheet in the “Mobile Score 1” and the “Desktop Score 1”.
• The fourth time you run the test, you are going to add the scores to your spreadsheet in the “Mobile Score 2” and the “Desktop Score 2” fields.
• After the fifth, and final run of the test, you are going to add the scores to your spreadsheet in the “Mobile Score 3” and the “Desktop Score 3” fields. Once those final entries are added, you will see that the “Average Mobile” and “Average Desktop” entries in the spreadsheet will autofill.

Yes, you read that correctly. You are going to run the GPSI test five times for each change you make. This is going to give you a true reflection of your GPSI scores.

So, your process for running a single round of testing using GPSI will be:

• Test 1 – throwaway test
• Wait 30 seconds
• Test 2 – throwaway test
• Wait 30 seconds
• Test 3 – Record in your spreadsheet as test #1
• Wait 30 seconds
• Test 4 – Record in your spreadsheet as test #2
• Wait 30 seconds
• Test 5 – Record in your spreadsheet as test #3
• Analyze the average of the three tests to determine the positive or negative impact of the change

GMetrix, on the other hand, is only going to be used a couple times throughout the process.

First, you are going to use it benchmark your current site. Then, you will run it at the end of the process to ensure that your site is loading within the expected time parameters.

Considering why your site might be slow and forming a working theory

Since my last round of testing, about eighteen months ago, I hadn’t made a ton of changes to my site structure. The theme was the same, my host was the same, and I hadn’t changed many plugins.

As I mentioned earlier, adding an ad partner was a sizeable change. The other thing that I thought might be causing the issue was what I call “WordPress bloat”.

The way I describe “WordPress bloat” is similar to the way your phone gets slower the longer you have it. The more text messages you send, the more apps you install/uninstall, the more call logs you have, the slower your phone gets. Right?

The best way to get that “new phone” feeling is to do a hard reset.

Well, I initially installed WordPress for socmedsean.com in 2009 and I have update and updated and updated over the years. I have added and removed plugins, I have made code changes, I have added a lot of content.

My theory is 10+ years of changes are resulting in WordPress bloat. A combination of leftover folders/files on the server and a ton of abandoned tables in the database. The result is a slower site.

Again, a working theory, so I figured a fresh install of WordPress couldn’t hurt anything. If anything, it might give me another 10 years before I have to do a hard reset again.

Now that you know my working theory, what is yours?

Why is your WordPress site slow? You might take a few minutes to consider where those issues might be. Here are some reasons your WordPress site might have slow page load speeds:

• Your site is hosted on a cheap, discount hosting service
• You haven’t ever optimized your WordPress site
• Your theme might be slowing down your WordPress site (free themes, especially)
• You have too many WordPress plugins installed
• You have never installed a caching plugin or service
• You don’t have a Content Delivery Network like Cloudflare installed
• You have plugins that are resource hungry
• You are using features that connect to third-party websites like an ad partner, a social sharing plugin, or even embedding Instagram photos and YouTube videos.

TIP: Embedding your Instagram feed into your site is a quick way to slow it down. It puts your site in a position where every time the page that shows the feed is loaded, your server needs to connect to the Instagram web service and download a bunch of photos. There are ways to speed it up, but if you are embedding third-party content into your site, you need to have it on your radar as a possible slowdown.

Even if you do not have a clue as to why your site is slow, that’s okay. You are going to learn a lot during this process and should be able to pinpoint where your speed bottlenecks are located.

Skills you are going to need throughout this process

Like I mentioned earlier, my goal is to make this process as easy to follow as possible. I want anyone, at any technical level, to be able to speed up their site. These are the skills you are going to need, though.

You need to be familiar with cPanel

cPanel is the hosting interface that many hosts use. If your host is not on cPanel, then you will need to work with your host directly to create a fresh install of WordPress within your hosting account that uses a subdomain of your primary domain.

TIP: A subdomain is simply a way to access files stored in a folder located on your server. So, the newsite.yourdomain.com subdomain will open whatever is installed in the /newsite/ folder. Since we’re going to install a fresh instance of WordPress in your subdomain folder, it allows us to access and configure a new version of your site without disrupting your live site.

NOTE: If you do not want to start with a fresh installation of WordPress and would rather just work on a copy of your site, that’s okay too. You can either use cPanel to create a staging instance of your site or you can work with your host to have them create a copy of your site in a test folder.

You need to be comfortable with the WordPress admin console

If you are not comfortable with installing themes, installing plugins, and configuring them then I would recommend you start by learning a bit more about WordPress before you start this process. There are some great YouTube tutorials out there, so take some time to learn about the WordPress admin console and how it works.

For the most part, everything we are going to do in the WordPress admin console is simply clicking buttons and checking boxes. We are not going to write any code, we are not going to do anything that is too challenging, so do not be afraid to give it a try.

You need to understand what a subdomain or a staging site is

If your hosting offers the ability to easily create a staging site, then this step should be pretty easy. If your host or hosting plan does not include a staging environment, then you will need to create a subdomain for your site, where you will host the new version of your site.

A subdomain is basically a new URL that points to a folder on your server. So the subdomain of test1.yourdomain.com might point to the test1 folder on your server.

What the subdomain allows you to do is build a fresh installation of WordPress in a folder on your server that you can access via a browser. This install will allow you to configure and test the new WordPress install to run as fast as possible without ever interrupting your live website.

To create a subdomain, you can do it yourself within cPanel or you can work with your host to have them do it for you.

NOTE: As I detail out the process, I am going to show the process of creating a fresh install on a subdomain of your site. This is a process that everyone should be able to do. Some hosting plans do not offer staging sites, but if yours does and you want to create one and use it, that’s fine too.

TIP: If you run an eCommerce site or a membership site where users can create their own WordPress accounts, I highly recommend that you build a staging site, rather than rebuild your site from the ground up. The reason is because exporting users from one installation to another can be tricky. By creating a staging copy of your site, the user records are kept intact on your new site and do not require any migration.

You need to choose a “guinea pig” post

During this process, we are going to pick one specific post to test over-and-over. It is important that the post you choose is representative of the average length of content on your site. Do not pick your shortest blog post and do not choose your longest post. Find one that is of “average” length and represents the average content length of articles on your site.

In the next step, you will download the tracking spreadsheet and make your own copy. In cell B1 of the spreadsheet, you will see a space to enter the URL for your guinea pig post. I found this to be helpful because I could just copy and paste it from there throughout the process.

It will also be a handy reference in six months or so when I go through the process again and I can see how this page compares to the post I choose to test against in the future.

Downloading and understanding the tracking worksheet

By tracking every step in the worksheet, you are going to have a deeper understanding of how your host is performing, how your theme impacts your speed, and how each individual plugin might hurt your site speeds.

In the end, you will have a detailed picture of what changes were made throughout the entire process and get a clear understanding of any challenges facing your site with respect to speed.

The spreadsheet is designed to provide visual feedback that aligns directly with the GPSI tool. So, if your score is 49 or below, the cells in the sheet will have a red background. If your score is between 50 and 89, then the cells will turn orange. If your scores get to 90 or above, they will go green.

If you review what my spreadsheet looks like, you will see that my initial install was all green. Even after I installed my theme and most of my plugins, the scores stayed in the green.

After I installed my ad network plugin, that is when my scores started to falter. As I mentioned previously, that’s okay. I was able to go through and configure some caching to help address some of the issues. In the end, I had to accept the scores.

You can download a copy of my tracking spreadsheet here and you can download a fresh copy of the spreadsheet for your use here.

Setting the benchmarks with Google Page Speed Insights and GTmetrix test

Before you start changing anything, you need to get an understanding of where your scores stand before you even begin. Now that you have downloaded the spreadsheet and added the URL for your guinea pig post, you need to run that URL through the two tests.

The first test is the GPSI test. In a private browser or incognito browser, head to the following URL:

https://developers.google.com/speed/pagespeed/insights/

TIP: I prefer to run all my testing in a Firefox private browser window or a Chrome incognito browser. By doing this, I ensure that I am always looking at a fresh version of my page that is not stored in the browser cache. I recommend you do this as well.

Simply enter your URL into the field and click the “ANALYZE” button.

Use the Google Page Speed Insights testing tool to determine your site speed scores.

Take a Google Page Speed Insights test of a page and record how it performs. For me, I used this post:

https://www.socmedsean.com/step-by-step-guide-updating-and-optimizing-old-blog-posts-for-increased-traffic/

Follow the testing process that I outlined above for GPSI before you start recording the scores. Here is the process again, for your reference:

• Test 1 – throwaway test that you do not record
• Wait 30 seconds
• Test 2 – throwaway test that you do not record
• Wait 30 seconds
• Test 3 – Record as test #1 in your spreadsheet
• Wait 30 seconds
• Test 4 – Record as test #2 in your spreadsheet
• Wait 30 seconds
• Test 5 – Record as test #3 in your spreadsheet
• Analyze the average of the three tests to determine the positive or negative impact of the change

With your first round of scores entered, you will notice that the “Average Mobile Score” and “Average Desktop Score” fields were populated by a formula and are formatted accordingly.

If, for some reason, the values do not populate automatically, you might have removed the formula from the cells. Just download a fresh version of the spreadsheet and try again.

Next, you will want to run a GTmetrix analysis and record your page load time. To do that, head to this URL:

https://gtmetrix.com/

Enter your URL in the field and click the “Test your site” button.

Run a GTmetrix site speed test to see how your site performs.

After the test has run, you will see a score for your site and the key metric we are going to track, called “Fully Loaded Time”. Record this time in your tracking spreadsheet.

Your GTmetrix test results will help you understand how quickly your page loads. These were my results after completing the process. Before, my site was taking 6.2 seconds to load.

Once completed, the top of your spreadsheet should look something like this.

Your tracking spreadsheet should now have your initial values entered.

NOTE: Don’t worry if the spreadsheet has a lot of red in it. It will change as you add more scores to the fields. Hopefully, those fields will turn green.

Well done! You have taken the first step toward speeding up your site. From this point on, I will take you through each step to build a testing site, configure all the elements, and find/fix issues that are slowing down your site.

IMPORTANT: If you are going to create a staging copy of your site, rather than creating a fresh install, then you can go through the process of doing that right now.

Once you have created a copy of your site, you need to deactivate all your plugins, and then skip down to step 15. This will give you a basic WordPress site with your theme installed to start your testing with.

If you create a staging site and make adjustments and your scores still aren’t where you want them to be, then come back and walk through the entire process so you can find out what might be causing issues.

Step 1 – Create a subdomain on your server using cPanel

The first step in building your test site is to set up a subdomain using cPanel. Some basic hosting plans only allow for the use of a single domain, but they do offer the ability to create a subdomain, which is perfect for what you will need.

Remember, the goal is to create a subdomain like yoursite.yourdomain.com where you can install a new instance of WordPress, build it up, and test it as you go. This will ensure that you are not testing in your live site.

To create a subdomain using cPanel, just login to your hosting account’s cPanel interface and click the Subdomains icon.

Use cPanel to create a new subdomain that you can use for rebuilding and testing your site.

On the Subdomains page, enter the name of the subdomain that you want to use. In the long run, it doesn’t really matter what the subdomain is, just make sure it’s something that you will recognize if and when you ever need to access it via the file manager or FTP.

In other words, do not name it something like “test” or “temp”. Name it something that aligns with your site. In my case, I simply named it “socmedsean”. This means that my subdomain will be socmedsean.socmedsean.com.

Create your new subdomain so you can rebuild your site.

TIP: Be sure to choose https as your protocol since you are going to be using a Secure Sockets Layer (SSL) certificate to ensure site security. Google has indicated that it considers whether SSL is installed in its algorithm calculations, so you want to have SSL installed if organic traffic is your goal.

That means the system is going to create a new folder named “socmedsean” on my server and it is going to point all traffic to socmedsean.socmedsean.com to that the WordPress installation in that folder.

With your new subdomain created, you are ready for a fresh install of WordPress.

Step 2 – Install a fresh version of WordPress in the folder where the subdomain points

Fortunately, most cPanel installations make it easy to install WordPress through the use of the WordPress auto-installer.

Most hosts provide a WordPress installer as part of their cPanel dashboard.

NOTE: If your cPanel instance does not have the WordPress auto-installer, you’re going to have to install WordPress the manual way using FTP. You can find the steps on how to do that via this URL:
https://wordpress.org/support/article/how-to-install-wordpress/

From cPanel, click the WordPress auto-installer and then doing the following:

• Choose the latest version of WordPress to be installed
• Choose the subdomain that you just created as the installation URL. Be sure to leave the “In Directory” field empty.
• Type the site name that matches your current live site.
• Type the site description that matches your current live site.
• Choose an Admin Username and Password. You can make these match your current live site since you are eventually going to make this new instance your live site.
• Select the primary language for your site
• Choose to add in the Classic Editor if you use it
• Do not add plugins like the Loginizer or WordPress Starter plugins. These are extra plugins that will slow down your site, so there is no need to install them.
• Leave the Advanced settings alone
• Click the Install button and let the auto-installer work its magic

Configure your new WordPress instance using the installer tool.

After a few minutes, you should have a fresh install of WordPress.

Step 3 – Configure your Secure Sockets Layer (SSL) certificate

As I mentioned earlier, you want to leverage SSL in your WordPress installation. The use of SSL protects both you and your visitors by encrypting any data that is sent between the browser and the server.

One of the nice things about hosting on Siteground is they automatically generate free Let’s Encrypt SSL certificates for all new subdomains.

To confirm that your new SSL certificate is active, just click the “Let’s Encrypt” icon from within cPanel.

If your host offers free Let’s Encrypt SSL certificates, check to ensure that one is installed for your subdomain.

On the Manage Let’s Encrypt Certificates page, you should see the listing of all the domains that have active SSL certificates within your cPanel instance. If your new subdomain is listed, you are ready to roll.

If your SSL certificate was installed for your subcomain, you should see it listed in the Let’s Encrypt certificate manager.

If your SSL certificate is not listed, then you simply need to scroll to the bottom of the page and choose your subdomain in the dropdown list, select the “Let’s Encrypt SSL” option, and click Install.

NOTE: If your host does not provide free SSL certificates with your hosting plan, you will need to work with them to acquire an SSL certificate that covers both your live domain and the subdomain. Just open a ticket through their help system and they should help you get it set up.

With your SSL certificate installed, you should now be able to access your new WordPress admin console at https://yoursubdomain.yourdomain.com/wp-admin

If, for some reason, your WordPress admin console is not available, the steps to troubleshoot are:

• Wait 15 minutes or so and try again. Sometimes, there is a delay in setting up your SSL certificate and this is the most frequent cause of issues with a new install.
• Make sure you are typing https:// at the beginning of your URL.
• Check your work. Make sure your subdomain is spelled correctly. Make sure your WordPress install did not fail. Confirm that your SSL certificate is showing as installed.
• If those do not work, open up a chat or support ticket with your host and ask them to help you check your work to get it running.

If you can login to the WordPress admin console for your new site, then you are ready to move on to the next step.

Step 4 – Configure the WordPress settings to match your live site

With a fresh install of WordPress ready to roll, the next step is to configure all the WordPress settings to match your current live site.

To configure your settings, just click Settings > General in the WordPress admin navigation. Go through all the settings and configure them to match your live site. The two exceptions are that you want to leave your WordPress Address (URL) and your Site Address (URL) set to your subdomain.

Configure your WordPress general settings so they match your live site.

TIP: Activities like these make having dual monitors handy. If you have dual monitors, you can make your life easy by opening your live site admin console on one monitor and your new site admin console on your second monitor. This will allow you to see the live site settings and quickly duplicate them in the new site.

CAUTION: If you have your live site admin console and your new site admin console open at the same time, be sure that all the changes you make are to the testing site. Do not accidentally make changes to your live site by accident.
Do not ask me how I know about this.

With the General settings configured, go through the Writing, Reading, Discussion, Media, and Permalinks settings to make sure they match your live site.

Step 5 – Install your WordPress theme and child theme

With your WordPress settings configured, the next step is to add your theme or framework and a child theme. You are using a theme or framework that leverages a child theme, right?

If your current theme does not have a child theme, I would be cautious about using it going forward. Having a child theme allows you to make changes to your site without running the risk of future updates to the theme over-writing your changes and breaking your site.

How do you know if your theme leverages a child theme? The best way is to research the info provided from the theme developer. If they use a child theme, they will generally indicate it in the features of their theme.

Some theme publishers, like StudioPress, refer to their parent themes as “Frameworks” and then their child themes are called themes. I know, it is a bit confusing but the parent > child relationship still exists within these frameworks.

Install your WordPress theme on your new testing site.

In my case, I use the Genesis framework and the Streamline theme.

To add your theme, you can do one of the following:

• If your theme is listed in the WordPress theme directory, just search for it, install it, and activate it.
• If you purchased your theme through a third-party site like StudioPress or Themeforest, download the theme from your account on their site and then upload and activate it.

The WordPress theme directory is a good place to start when looking for your theme files.

TIP: If you are using a child theme, be sure you activate the child theme, not the parent theme or framework.

TIP: It is a good idea to leave one of the basic WordPress themes, like Twenty Twenty installed so you can use it to test if something goes wrong with your site.  

Step 6 – Configure all the theme settings to match your current live site

This step is going to be unique to your theme and your site. Each theme has its own way of configuring the different settings that are available, like colors, menus, layout choice, etc.…

For me, the theme settings are accessed by selecting Genesis > Theme Settings in the WordPress menu. This menu item opens the Theme Settings page, where I can select different categories and make necessary adjustments.

Configure your theme settings so they match the configuration of your live site.

To complete this step, go through the process of replicating the theme settings for your current live site into your new test site. Again, this is much easier if you have a dual monitor setup where you can open the live site in one monitor and the new test site in the other monitor.

Once you have the theme settings configured, you should be able to open your new test site in a browser and it should look pretty much like your live site. The posts will not be there and elements like your sidebar widgets and footers will not be there, but the layout should look very similar.

You should be able to view a bare version of your site with just the theme installed.

With your new WordPress site set up and your theme installed and configured, you should now be ready to run your first round of baseline testing of your new site.

Step 7 – Run a GPSI test to baseline your install with just WordPress and the theme

Next, you are going to run a set of GPSI tests against the home page of your site. Since your guinea pig post has not been migrated yet, it is okay to just run this one against your home page or even against the “Hello World” post that comes with a fresh install of WordPress.

This is one of the most important tests you are going to perform throughout this process because it is going to tell you how your host and your theme perform without any content in your site.

For review, go through this process of testing and recording your scores in the spreadsheet:

• Test 1 – throwaway test that you do not record
• Wait 30 seconds
• Test 2 – throwaway test that you do not record
• Wait 30 seconds
• Test 3 – Record as test #1 in your spreadsheet
• Wait 30 seconds
• Test 4 – Record as test #2 in your spreadsheet
• Wait 30 seconds
• Test 5 – Record as test #3 in your spreadsheet
• Analyze the average of the three tests to determine the positive or negative impact of the change

Track your testing scores for your site with only the theme installed.

In my case, I am testing my Siteground hosting and my Genesis Streamline Pro theme. Since I’m scoring 99 mobile and 99 desktop, this is a good sign that my hosting is quick and my theme is performing well.

Any problems that come from here on out are caused by plugins and configuration. If you do not score in the mid-90s or above at this point, then your host or your theme (or both) are a problem. You need to stop at this point and get on a host and theme that will get you to 99 and 99.

I recommend Siteground and the Genesis framework. The combination of the two will get you good baseline scores to start.

To check out Siteground hosting, click this URL (this is an affiliate link):

https://www.socmedsean.com/siteground-hosting

To check out Genesis themes, click this URL (this is an affiliate link):

https://www.socmedsean.com/genesis-framework

If your scores are not in the upper 90s, the way to determine if your theme is causing the problem is just to switch to the Twenty Twenty theme and retest again. If your scores are not in the upper 90s on Twenty Twenty, then your host is a problem and you need to either contact them to find out why they are slow or consider switching hosts.

If your scores shoot up to the upper 90s after switching to the Twenty Twenty theme, then the probable bottleneck is your theme and you need to consider whether a faster theme would be better for your site and your traffic.

Assuming your scores are in the upper 90s, it is time to move on to the next step of bringing your content over to your new testing site.

Step 8 – Run an export of your pages from your current live site and import it into the testing site

To see how your new site performs with your content in it, the next step is to export your blog pages from your live WordPress site and then import those posts into your test site. Luckily, WordPress provides us with the tools, and a fairly easy process, to accomplish this.

In the WordPress admin console menu, choose Tools > Export to access the tool. From the choices, select Pages and ensure that all authors, and all statuses are selected. You can leave both the date ranges set at their default values of “Select” and the export process will export all your pages, regardless of publication date. Click “Download Export File” to kick off the process.

Use the WordPress export tool to create an XML file that contains your site pages.

Once the export process is completed, the browser will download an XML file to the “downloads” folder on your local machine.

TIP: Don’t be tempted into trying to migrate all your pages, posts, and media at the same time. If your site has a lot of content, the import process will fail. Just stick with migrating the different content types one at a time.

The next step is to import that XML file into your new testing site. To do this, switch over to your testing site and click Tools > Import in the WordPress admin menu. Before you can import your XML file, you need to install the WordPress Import plugin by clicking “Install Now”.

Once installed, click “Run Importer” to start the process of importing your pages.

From the Import WordPress page, click “Choose File” and point it to the XML file that was downloaded to your Downloads folder. Click the “Upload File and Import” button.

Use the WordPress import tool to migrate your pages to your new site.

In the next step, you will be asked which user the system should assign the imported pages to. Use the dropdown menu to assign the pages to your admin login or the user of your choice.

IMPORTANT: Also check the box to Download and import file attachments. This will bring over the various media files that are directly associated with each of the pages and add them to your new site media library.

In the WordPress import tool, assign a user and be sure to include the media files.

Finally, click “Submit” to kick-off the process.

NOTE: The reason we start with exporting and importing pages and not posts is most sites generally have fewer pages than posts. That means you can get a feeling for the export import process using an XML file that is relatively small.

When you follow this process for posts and, eventually, for your media files, there is a high likelihood that your XML files will be very large and the import process will timeout. I will address what to do when that happens in the following sections.

If this happens to occur while your pages are importing, then skim down a bit and read about what to do and then come back to this point.  

Once your pages are in place, you should be able to see them in your WordPress admin console by clicking the Pages menu item in the admin menu.

Confirm that all you pages were successfully imported into your site.

With the pages imported, then next step is to tackle importing your posts.

Step 9 – Run an export of your posts from your current live site and import it into the testing site

Exporting and importing your WordPress posts from your live site to the new site is the exact same process, except instead of selecting “Pages”, you are going to select “Posts”.

Using the WordPress export tool, create an XML file that contains all your posts.

 

Download the XML file using the WordPress export tool and then import the posts XML file into your new site by using the same import process.

IMPORTANT: Be sure to check the box to Download and import file attachments. This will bring over the various media files that are directly associated with each of the posts and add them to your new site media library.

I have almost 500 posts that I exported from my live site and my import process to the new site ran without any issues, bringing over all the images, as well.

If, however, you have more than 500 posts then it’s is possible that your server will timeout before the process is completed. At that point, you will see a scary 504 Gateway Timeout error that looks like the one in the image below.

If you see this scary 504 error when running your WordPress import, don’t panic.

Do not panic.

Just hit the refresh button and the import process will restart but will skip over all the posts that already exist in the system. Since it skips over those posts and media files, it should be able to complete the import on the next run.

If you still get a 504 Gateway Timeout error, just hit the refresh button again. Keep going until the process completes.

NOTE: During one import, I also received an error that said “Sorry, there has been an error. The file does not exist, please try again.” This just meant that the file had completed processing and when I clicked refresh again, I got a notice that all the items had been imported.

Once your posts are imported into the new site, you are ready to bring over all the remaining media assets.

Step 10 – Run an export of your media objects from your current live site and import it into the testing site

When you imported your posts, you brought over the media files that were associated with them. This process did not bring over every object in your media library.

First, you might have uploaded things like PDFs or Word docs that are not necessarily attached to a post. This means those files are part of your old site but have not been migrated to your new site.

Second, I found that the featured images associated with my posts did not display properly until I completed a full export and import of the media library from the live site to the testing site.

The easiest way for you to move them from the old site to the new site is to follow the same export import process, but this time choose the “Media” selection.

If your site has been around a while, you likely have a lot of images. Unfortunately, most servers are not configured to handle the bulk import of a ton of files during the import process. This means that a huge XML file containing all your images won’t upload completely and refreshing the import like we did for the posts runs the risk of the process never completing.

For this reason, I highly recommend you limit the size of your export files. For me, the trick was to export 1 year of media objects by using the date selector, and then running the export.

Use the WordPress export tool to create an XML file for your media library objects.

Once you have exported the file, head over to your testing site and run the import, just like you did with pages and posts.

For me, during the import the process would timeout and I would get the scary 504 error. I would just click the refresh button and the process would continue. Refreshing after getting the error once or twice resulted in a completion of the import.

NOTE: Do not worry, if WordPress tries to import an image that already exists in the media library. If it already exists in the library, it will just skip it and move on to the next one.

If your site is large and you have a lot of images to move, this process is going to take a while. It took me about an hour to export and import 1500 images from my live site to my new site. I broke them up into 11 XML files, each representing one year.

Just stick with it…it will be worth it.

Once your pages, posts, and media files are migrated, you are ready to do some testing.

Step 11 – Run a GPSI test of your WordPress install with all of your media, pages, and posts imported

With no plugins active on your site, but with your content in place, run through the GPSI testing process again and record the scores in your workbook. This time, you are going to test against your guinea pig post, since it is what you used to set your initial baseline of your live site.

Once again, the testing process is as follows:

• Test 1 – throwaway test that you do not record
• Wait 30 seconds
• Test 2 – throwaway test that you do not record
• Wait 30 seconds
• Test 3 – Record as test #1 in your spreadsheet
• Wait 30 seconds
• Test 4 – Record as test #2 in your spreadsheet
• Wait 30 seconds
• Test 5 – Record as test #3 in your spreadsheet
• Analyze the average of the three tests to determine the positive or negative impact of the change

For me, the scores remained stable at 98 mobile and 99 desktop. This tells me that adding my content and media files into the database did not hurt my site performance in any way.

Test your new WordPress site with your content included and track the scores.

Again, if your scores are not excellent, then it might be time to consider a new host or a new theme. Everything will get slower as you add in plugins and functionality.

With your content in place and tested, the next step in replicating your live site layout is to add in your navigation menus, footer, and sidebars.

Step 12 – Configure your navigation menus, footer widgets, and sidebar widgets to match your current live site

NOTE: Before we get started, I know you have not installed all your plugins yet so you might not be able to fully replicate your various widgets if they rely on a plugin. That’s ok. Just skip those elements for right now and build out as much as you can without the plugins.

DO NOT install or enable any plugins during this step.

For the most part, it would seem that navigation menus, footer links, and sidebar widgets would be a relatively innocuous group of content that wouldn’t really impact site speed. The reality is often untrue, though.

Quite often, bloggers will add footer content or sidebar content that they think enhances the site experience for users, but actually hurts page speed loading time. The most egregious of these types of content are “popular posts” content or “related posts”.

For a long time, I used a plugin that tracked post visits and then aggregated that data into my most popular posts and displayed them in my footer. My thinking was that Google would always have a way to find my most popular posts because they were displayed on every page in my site.

While this thinking might have worked way back in 2012, it is a terrible idea today for a few reasons.

The first is that Google does not need your help finding these posts. If they are truly popular posts, they likely have a lot of external links from other sites and internal links within your articles.

Because of that, Google has no problem finding them and doesn’t need any help from a popular posts plugin. In other words, it is just excess overhead on your server for no reason.

The second reason popular post plugins are a bad idea is because of the immense level of server resources these plugins often require just to run and maintain their data.

Each time a page is loaded, the page writes to the database to increment the number of times it has been viewed. Additionally, each time a page is loaded, a SQL query runs to look through all the pages in the table where the data is stored and sorts them by count.

This is a process that takes time and slows down each page.

The result is that every page on your site where popular posts are displayed are slowed down. If you have the popular posts widget installed in your footer, that means it loads every time a page loads.

Yep…a site-wide slowdown caused by one plugin and its widget.

As page speed became more important to Google, I decided to keep the popular posts functionality, but get rid of the plugin and just manually display links to my most popular posts, according to my Google Analytics account.

I created a Custom HTML widget in the footer and create simple HTML links to all my top 10 posts. This worked fine and improved my page load times, but I now consider this feature to be unnecessary. As a result, in this round of site enhancements I decided to scrap the widget altogether.

I share this story as an example of how a widget that can seem helpful can harm your site and, as a result, speed scores.

Some widgets that you should really consider ditching if you are serious about page speed would include:

• Popular post widgets
• Related posts widgets
• Tag clouds
• Social media widgets that load icons and images from other services
• Archive widgets
• Recent Comments widgets
• Any plugin that tries to aggregate your page-related data in the background and then display it on the front-end

With that in mind, go ahead and build out your menus, sidebars, and footers. Your menus are accessed under Appearance > Menus in the WordPress admin menu and widgets (sidebar and footer) are accessed under Appearance > Widgets.

Add any necessary widgets to your site to replicate your live site.

Once you have your menus and widgets configured, it is time for another round of GPSI testing to determine what negative impacts adding those elements might have had on your page scores.

Step 13 – Run a GPSI test of your install with your navigation menu, footer widgets, and sidebar widgets configured

With the menus and widgets in place, run through another round of testing. In my case, my menus hurt my mobile page speed scores, dropping them from 98 to 94.

Yep, simply adding menus to my site hurt my GPSI scores.

Adding the menus to my site dropped my mobile scores.

This did not cause me much concern, though, for two reasons.

The first reason is because menus are an important part of my site. I’m not going to remove them, so I just have to be okay with the benefit of having the menus helps offset the impact to my scores.

The second reason is because my caching, which has not been implemented yet, should help overcome the drops to my score. Since menus are a common element across every page in my site, my caching plugin should be able to load cached versions of the menus and bring those site scores back up.

Once you have recorded your testing scores, review the impacts and determine whether you need to make adjustments. The volume of navigation elements in your menus can certainly impact page load times. Because your nav menus are on every page, any negative impact from your menus will likely hurt every page in your site.

The easiest way to evaluate if your menus are causing issues is to count the total number of entries in your menu. For instance, in my top navigation menu I have a total of sixteen elements. All sixteen are loaded every time a page is loaded.

If you have a lot of sub menus and sub-sub menus, you need to understand that each of those elements is loaded on every single page. Even if the visitor never hovers over your menu, the elements still had to be loaded, which cost you an increase in your page load times.

I have seen WordPress menus that were seven across and three-levels deep. The total number of menu items were in excess of 40. That’s more than 40 items that have to loaded every time your page loads. The end-result is excessive page bloat that increases page loading time and hurts GPSI scores.

The same goes for widget elements like the archives widget. If you have been blogging for 10 years and have faithfully added a new post each week, then that is more than 520 blog posts. Good for you!!

However, each time you load up that “My Archives” widget, the server has to provide the code to the browser that has links to 120 different months (one link for every month in all of the 10 years). That’s 120 hyperlinks that are costing you an increase in page load times.

Ask yourself, are my visitors really clicking on the archives widget? Is the perceived value actually hurting your GPSI scores? If your users are not clicking it and it is hurting your scores, then ditch it.

Go through that type of exercise with every widget you add to your site. Try removing them and re-running your GPSI tests and see if you scores improve. If they do, consider removing the widget altogether.

The next step in continuing your testing is to ensure that your test site has all the style and code features that your current live site has.

Step 14 – Add any CSS or functions.php customizations

If you have customizations to your style sheet and/or functions.php this is where you copy those from your live site over to your test site. Be very careful if you don’t know what you are doing here.

NOTE: This is probably the most technical aspect of the process of building your test site. It involves copying/pasting any code from the custom CSS fields in your old theme and then doing the same with any custom code that you have added to your functions.php.

Making changes to your custom CSS or functions.php can completely hose your WordPress site.

If you aren’t aware of what custom CSS or functions in your functions.php file are, then just skip this section. If you know that customizations exist but you are uncomfortable with copying and pasting them, then work with your host to have them help.

Once you have all of the CSS and code from your functions.php copied to your new testing site, it’s time to run another test to see how those changes impacted your speed scores.

Step 15 – Run a GPSI test of your install to test your base install

NOTE: If you decided to go with creating a staging copy of your live site, instead of a fresh WordPress install, this is where you are joining the process. Be sure ALL of your plugins are deactivated. By doing this, you give yourself the ability to run some tests and see how the copy of your site performs.

Custom code can be a website killer. Poorly written database queries, code that uses deprecated functionality, and a host of other issues can cause problems with your site.

I once helped a client analyze her site and found that she had uploaded 15 different pinable images to each post and used a piece of custom CSS to hide 14 of them. This is a common practice for people who have a large Pinterest audience and want to continually satisfy Pinterest’s need for new content.

The problem is each time a visitor loads the page, all 15 items still load, even though 14 of them aren’t visible. The browser still must load them and that takes time and slows down each page. I use this process for my posts but limit it to two additional Pinterest images in order to give visitors who are sharing the page a few options to choose from.

In my case, the extra CSS and a couple of custom functions in my functions.php file did not impact my scores in any way. My results stayed at 94 for mobile and 99 on desktop.

Track your scores after adding any custom CSS or functions.

If you find that your scores dropped after adding custom CSS or functions, then go back and undo them and rerun your tests. If the scores rise back up, then it’s time to work with your host or a developer to determine what the code does, why it’s impacting your page speeds, and whether you want to continue using it.

Once you are comfortable moving forward, the next step is to apply some caching options to further enhance your scores.

Step 16 – Begin installing and testing the plugins that your site requires

This is going to be the most time-consuming part of the testing process because you need to install and configure each plugin, one-by-one, and then run and document the GPSI test.

Because any individual plugin can tank your site performance, it is important that you take the time to install, activate, and configure the plugin and then run through the GPSI testing process.

In the spreadsheet, I created rows for 15 different plugins. You can add more rows if you need them. As you can see in my spreadsheet, I documented the scores and impacts of installing and configuring each plugin.

You need to pay attention to any significant impacts to your site speed and evaluate why a particular plugin might be causing slowdowns.

For easy reference, the testing process is as follows:

• Test 1 – throwaway test that you do not record
• Wait 30 seconds
• Test 2 – throwaway test that you do not record
• Wait 30 seconds
• Test 3 – Record as test #1 in your spreadsheet
• Wait 30 seconds
• Test 4 – Record as test #2 in your spreadsheet
• Wait 30 seconds
• Test 5 – Record as test #3 in your spreadsheet
• Analyze the average of the three tests to determine the positive or negative impact of the change

Pay attention to any plugins that call third-party web services like Google Analytics, Facebook pixels, social sharing plugins that track shares, etc. Any time a plugin is calling a third-party web service, it is going to slow down your site while your pages wait for those web services to respond.

The more web services your site calls, the slower your site will get.

I’m not saying that you shouldn’t have a Google Analytics tag or a Facebook pixel tag. What I am saying is you should carefully monitor whether adding the plugins to add them will actually slow down your site.

For SocMedSean.com, I use a plugin called “Pixel Your Site” which seems to load both my Google Analytics and Facebook pixel without causing any negative speed impacts.

Document your plugin test results in your spreadsheet and see what your average test times look like. In this step, you are going to determine which of your plugins are doing the most damage to your GPSI scores.

Once you identify a plugin that is causing issues, re-evaluate whether you really need it and are willing to accept that it could be hurting your load times and maybe even your rankings.

Test every plugin and track the results in your testing spreadsheet. This will help you identify any poorly performing plugins.

NOTE: You’ll notice in my spreadsheet that I have three plugins that I marked for testing after my domain was pointed to this new WordPress instance. The reason for this is I really don’t want to install the Mediavine plugin, Yoast, and OneSignal because they are specifically configured for my live www.socmedsean.com domain.

This just means that I need to test them later in the process.

For now, I just moved them below the section of my testing spreadsheet where I make the new site live.

Depending on the results of your plugin testing, you may need to make some adjustments.

• If you found a plugin that significantly slows down your site, find a way to replace it or remove it altogether.
• If you found a plugin that only slightly slows down your site then you need to determine whether you want accept the slight speed loss and still keep the functionality.

In my case, Contact Form 7 for Mailchimp and the MashShare social sharing buttons are causing a slight drop in my page speed scores. Because both are important for driving traffic to my site, I am okay with keeping them.

I’m hoping I’ll get an additional boost in speed once I install and configure my caching configuration and gain the benefits from using server caching and a CDN. If I do, it should make up for the slight drop in speed that caused the page speed scores to drop.

NOTE: Do not proceed until you have site scores that you are relatively happy with. If you are in the 80s and 90s, then all is good and caching can help improve them more. If you are below that, I highly recommend you spend time determining what is causing the poor scores.

Step 17 – Install and configure your caching plugin

Caching is a good thing and it can do a lot to help improve your site speed scores. Most good hosts offer the ability to leverage server-based memory caching and a lot of hosts simply have it enabled for all their accounts. That means you don’t have to do anything to leverage it.

Others, like Siteground, offer a plugin that allows you to turn it on or off. In my case, I enabled “Memcache” using the SG Optimizer plugin.

But there is more to caching than just memory caching. Using a variety of different plugins, you can also leverage file-based caching which can also help with performance.

For me, Siteground also offers file-based caching through the SG Optimizer plugin. It’s built to be used with my host, so I decided to use it on this fresh install, rather than using WP Rocket which is what I am using on my live site.

I enabled all the caching options, but NOT the front-end optimization which is script and CSS file minification.

For Siteground customers, the SG Optimizer plugin provides caching capabilities.

There are a LOT of different caching plugins out there and I have tried six or seven different ones over the years in my attempts to speed up my site. In the end, the ones I trust and recommend are:

• SG Optimizer – If you are hosting on Siteground then I recommend starting here. The plugin has evolved significantly since its launch a few years ago and Siteground is always improving it. Previously, I could get better scores using WP Rocket, which is why I was using it on my live site. As you will see through my testing process, SG Optimizer beat out WP Rocket, so I decided to keep SG Optimizer. This is especially great because it is free and WP Rocket requires an annual subscription.
• WP Rocket – If you are not on Siteground, then I highly recommend you give WP Rocket a try. Sure, there are plenty of free caching plugins out there, but I have yet to find one that works as well as WP Rocket. The reason is WP Rocket not only builds a pre-cache index of your site, but it can minify and combine files, as well as generate critical CSS, all of which lead to faster page load times. One plugin does the job that another caching plugin + an minification plugin can do. Did I also mention that WP Rocket can perform database optimizations periodically, as well?
• W3 Total Cache – For a free option, I would recommend giving W3 Total Cache a try. In my previous tests, it provides some of the same features that WP Rocket provides, including caching a minification. There is also a pro version (costs extra) that adds additional features. The main reason I recommend WP Rocket over W3 Total Cache is the easy of use. I found WP Rocket to be a bit more intuitive and easier to tune. If you are on a budget, though, give W3TC a try.

With your preferred caching plugin installed, follow the configuration for your specific plugin to get everything up and running. At this time, though, I would recommend against turning on any minification and combination settings for CSS and JavaScript.

With minification and combination features disabled, you will be able to get a sense for how your caching plugin performs before you start minifying and combining files.

Step 18 – Run a GPSI test with your caching plugin installed

With caching turned on, run through the GPSI testing process again and see how your pages perform. Now that you have caching enabled via a plugin, it is important that you follow the process of testing each page five times and recording the last three.

Because you have caching installed now, the process for testing with GPSI has a couple more steps:

• Clear your caching plugin, either Siteground, WP Rocket, or W3 Total Cache
• Wait 30 seconds for the caches to purge
• Load your guinea pig post in your browser
• Test 1 – throwaway test that you do not record
• Wait 30 seconds
• Test 2 – throwaway test that you do not record
• Wait 30 seconds
• Test 3 – Record as test #1 in your spreadsheet
• Wait 30 seconds
• Test 4 – Record as test #2 in your spreadsheet
• Wait 30 seconds
• Test 5 – Record as test #3 in your spreadsheet
• Analyze the average of the three tests to determine the positive or negative impact of the change

My testing results increased to 94 on mobile and 99 for desktop.  

Track your test results in the spreadsheet after enabling your caching functionality.

This tells me that caching alone is not going to get me back all my few precious points on mobile. I also need to minify my HTML, CSS, and JavaScript files.

NOTE: Just because your scores did not improve with the caching plugin turned on doesn’t mean that it isn’t useful. Caching will help significantly with your GTmetrix score and will help decrease your page speed load times overall. The result will be a better user experience, which hopefully will lead to lower bounce rates and more long-term traffic.

The next step in the process is to go ahead and enable CSS and JavaScript minification and combination.

Step 19 – Install and configure your script minification plugin

I told you earlier that this process would not require any coding and, other than copying any custom code from your CSS and functions.php files, I’ve held to that promise. So, if you are worried that I’m using terms like JavaScript and minification, don’t worry. The plugins are going to do all the work.

To understand why we need to do this process, and why it’s so important to the site scores, you need to understand that each time you install a theme or plugin, it often includes its own CSS file and JavaScript functions to make everything work.

As a result, if you have one theme and 15 plugins installed, you likely have a bunch of different CSS and JavaScript files that did not come with the core WordPress installation. Many of those files have to load for each post or page to be rendered correctly, which means a lot of different calls to your server to get those files.

What the minification and combination process does is exactly what it says. First, it finds all the CSS and JavaScript files that your site is using, and it looks for ways to reduce and optimize the code (the minification process). Second, it combines all the code from the various files into one single file (the combination process).

The result is that your page simply has to make one server call for the combined and minified file, which results in quicker page speeds.

Some caching plugins like SG Optimizer, WP Rocket, and W3 Total Cache come with minification and combination features included. You just have to enable and configure them. Other caching plugins do not include the functionality and leave it up to a second plugin to perform that function.

Enable your minification and combination features in order to speed up your site.

If you are using one of the three caching plugins that I recommend, I suggest you start by trying the minification and combination feature that comes with the plugin. If it gives you good page speed scores, then great, stick with it.

If it does not help your page speed scores, I recommend disabling the minification and combination features in the caching plugin and trying Autoptimize as your minification/combination plugin.

TIP: Until recently, I was running WP Rocket and Autoptimize as my caching plugins of choice. As you will see in my test results, though, just using the recently enhanced combination and minification options within the SG Optimizer plugin gave me better scores. That means I could stick with SG Optimizer and remove Autoptimize, resulting in one fewer plugin to manage.

With your caching plugin of choice installed and the minification/combination features configured you will need to do a thorough test of the user experience of your site to make sure that the minification/combination process did not break anything.

Minifying and combining code can result in the disruption of the look and feel of your site, so test everything to make sure it is working as expected before you move on to the testing process.

TIP: If something does break, remember that we are using a testing site or a staging site, so don’t panic. Just go back and uncheck the various minification/combination settings one-by-one to determine which setting is causing the issue.

In my experience, combining files is usually where the problem occurs. However, combining files is also where some of the best speed optimizations happen, so you want to find a plugin that can effectively minify AND combine your files without breaking your site functionality.

TIP: If you run into any issues with your site not displaying properly when you turn on all the minification and combination settings, do not just turn them off and move on. Take time to identify the issue and resolve them. Minification and combination of scripts is one of the most effective ways to raise your GPSI scores and reduce your page speeds. If you do not have the skills, contact your host and see if they can help. If they cannot help, find a WordPress resource who can help out.

Once you have the minification and combination features working correctly and your site looks great, then move on to another round of testing.

Step 20 – Run a GPSI test with your minification plugin installed and configured

The next step is to run through your GPSI testing again and record the values. Remember to follow the testing procedure before you start entering values to the spreadsheet.

Because you have caching, minification, and combination installed now, the process for testing with GPSI is as follows:

• If you are using Autoptimize, clear your Autoptimize cache
• Clear your caching plugin, either Siteground, WP Rocket, or W3 Total Cache
• Wait 30 seconds for the caches to purge
• Load your guinea pig post in your browser
• Test 1 – throwaway test that you do not record
• Wait 30 seconds
• Test 2 – throwaway test that you do not record
• Wait 30 seconds
• Test 3 – Record as test #1 in your spreadsheet
• Wait 30 seconds
• Test 4 – Record as test #2 in your spreadsheet
• Wait 30 seconds
• Test 5 – Record as test #3 in your spreadsheet
• Analyze the average of the three tests to determine the positive or negative impact of the change

As you can see in my spreadsheet, I tried a variety of different caching/minification/combination options to see which worked best for me. Initially, I found that using the minification/combination tools in the SG Optimizer caused a styling issue where my body font did not load correctly. The speeds, however, were faster than any of the other combinations.

When I ran the Google Page Speed Insights with the minification and combination settings enabled my scores jumped back up to 97 on mobile and 100 on desktop.

Success! I gained back those lost points on mobile that occurred when I added my menus.

Track the results of minifying and combining CSS and JavaScript

Because of the positive results, I went with the SG Optimizer tool and identified a way to load my body font in a way that it displayed properly.

NOTE: You will also see in my spreadsheet that I ran a bunch of other tests. These were just to make sure that SG Optimizer was the best solution for my site. You can follow along and see how I tested different caching and minification plugins.

At this point, you should have most of your site functionality up and running, along with a page cache and minification/combination. The next step is to turn on lazy load to ensure that your images are not slowing down your site.

Step 21 – Enable image lazy load on your site

If you aren’t familiar with lazy load, it’s a process by which any images that would not be visible to the user when your site loads up (e.g. those they would have to scroll down to see) are not loaded until the user actually starts scrolling down.

As a result, your initial page loads faster and the images are only loaded when the user needs them. Faster load times lead to better GPSI scores, so it is a great solution for speeding up your site.

The only downside that can occur with lazy loading is if you have “pinable” images at the bottom of your post that you want your visitors to be able to pin without having to scroll all the way to the bottom of the post.

The trick to using lazy load and allowing for pinable images is to be able to tell the lazy load plugin to ignore images that have a specific CSS class assigned to them. Then, you assign the CSS class to those images.

Turn on lazy loading in order delay the loading of images that don’t need to be displayed immediately.

I detail this process, and how to accomplish it in the post at this URL:

https://www.socmedsean.com/pinable-images

Because lazy load functionality is included within the SG Optimizer plugin and provides the ability to exclude CSS classes, if you are on Siteground I would recommend sticking with it.

If you are not on Siteground, the A3 Lazy Load plugin performs really well and the instructions for configuring it are in the post mentioned above.

For my new site, I used the SG Optimizer lazy load settings and I configured it so my no-lazyload class is excluded from lazy loading. By doing that, I was able to eliminate the A3 Lazy Load plugin, removing one more plugin from my site.

Once you have your lazy load plugin configured, it’s on to another round of testing in GPSI

Step 22 – Run a GPSI test with lazy load enabled on your site

Run through the testing process, once again. Remember that from here on out you should be clearing your caches before you do any testing.

As you will see in my spreadsheet, after running the GPSI test again my new scores were 98 on mobile and 98 on desktop.

NOTE: If you are adding multiple “pinable” images to your posts and hiding them using CSS, then you need to be aware that GPSI and GTmetrix are always going to indicate that you need to defer offscreen images. This is because you are manually overriding the lazy load feature with your CSS class. Do not worry about it. If you are only adding a few images and you are optimizing them for speed, then it shouldn’t impact your load times too much.

Once you have lazy load running and your scores are where you want them to be, it is time to move on to ensuring that your Content Delivery Network (CDN) is installed and configured correctly.

Step 23 – Configure your CDN

You do have a CDN like Cloudflare, right? If you don’t know what a CDN is, it’s a good time to learn about them and implement one.

To understand how a CDN works and why it is beneficial to your site, you need to think about your site visitors. If your site has been around for a while and you get traffic from search engines, then your visitors likely come from different places in your country and maybe even from all around the world.

This can cause issues when your visitors are not located close to your server location.

For example, imagine that your host has placed your blog on a server located in Chicago, Illinois. When a visitor from St. Louis, Missouri visits your site, the distance the signals from your server have to travel are short because the cities are located close together. This means your pages are going to load more quickly for that user.

If a visitor from Paris, France visits your site, it is going to take longer for them to receive the electronic signals, which means your site is going to load more slowly for this visitor. Make sense?

A Content Delivery Network, or CDN, is a service that creates copies of your top blog pages and hosts them on servers that are distributed around the world. A CDN like Cloudflare periodically caches versions of your blog posts and their associated images and places them on their CDN servers located around the world.

Then, when a visitor visits your site, Cloudflare serves up the copy that is geographically closest to them. The result is faster load times for all your visitors because they are getting the content from the CDN server nearby. It also reduces the load on your primary Web server (the one in Chicago), a secondary benefit.

There are quite a few CDN options out there and they all have their pros and cons. Personally, I use Cloudflare because a free version of the CDN comes with my Siteground hosting. I upgraded to a paid version because the features and additional security are worth the extra fee.

Some of the more popular CDN services include:

• Cloudflare
• MaxCDN
• KeyCDN
• Jetpack

I am not going to get into the nuts and bolts of choosing and setting up a CDN at this time. If you do not have a CDN installed and configured, I would highly recommend giving Cloudflare a try and seeing if it helps your page scores and your load times.

On Siteground, and other hosts that offer Cloudflare services through the cPanel interface, the setup process takes about five minutes. For those who are on Siteground, here is the URL to a helpful article with the steps on how to set it up:

https://www.siteground.com/tutorials/cloudflare/enable/

If you are already using a CDN, then now is the time to go ahead and install and configure the necessary plugin to activate it. For me, the Cloudflare plugin is a quick install and is easy to configure.

NOTE: For most CDNs, the system covers both your top-level domain (e.g. socmedsean.com) and any subdomains (socmedsean.socmedsean.com), so there shouldn’t be any additional configuration to have your CDN cover your testing site. In my case, my socmedsean.socmedsean.com subdomain is covered by all the settings of Cloudflare for my socmedsean.com domain.

With the CDN installed and configured, you are ready to run some more testing.

Step 24 – Run a GPSI test with your CDN plugin installed and configured

To test the site with your CDN running, clear all your caches and then run through the testing procedure again. Plugins like WP Rocket also have an integration that will clear your Cloudflare cache, so if you are running WP Rocket, you might consider adding that integration.

If your caching plugin does not have direct integration, then you need to add a testing step where you clear your Cloudflare cache. Here is the process I recommend.

• If you are using Autoptimize, clear your Autoptimize cache
• Clear your caching plugin, either Siteground, WP Rocket, or W3 Total Cache
• Clear your CDN cache
• Wait 30 seconds for the caches to purge
• Load your guinea pig post in your browser
• Test 1 – throwaway test that you do not record
• Wait 30 seconds
• Test 2 – throwaway test that you do not record
• Wait 30 seconds
• Test 3 – Record as test #1 in your spreadsheet
• Wait 30 seconds
• Test 4 – Record as test #2 in your spreadsheet
• Wait 30 seconds
• Test 5 – Record as test #3 in your spreadsheet
• Analyze the average of the three tests to determine the positive or negative impact of the change

In my case, after configuring my CDN my average results were 95 on mobile and 99 on desktop. There was a small drop on mobile, but nothing that I am concerned with. The major benefit from using a CDN isn’t going to be reflected in the GPSI test scores, but in the GTmetrix page loading times.

Track the results of enabling lazy load on your new site.

With the CDN configured and tested, it is time to take a break from all the changes and think through the results of what you just accomplished.

Step 25 – Take a break and analyze the results

For me, by simply rebuilding my site on a fresh instance of WordPress and installing my plugins from scratch, I went from a 60 on mobile and 68 on desktop to a 95 on mobile and a 99 on desktop. I would say that was well worth the effort.

As I mentioned earlier, this process is similar to doing a hard reset on your phone, where you wipe the data and install everything again. When you do that, everything seems to run smoother and faster, right?

In this case, you just did a hard reset of your WordPress site and (hopefully) it is gaining you a significant boost in your page speed scores.

If, for some reason, you did not get the scores you needed, then maybe do some hard thinking about the following items:

• Is your host slowing down your WordPress site? Early testing should have helped you understand whether your host is providing you with the good baseline speeds that you want. If your host is not fast…nothing else will be.
• Is your theme slowing down your WordPress site? Your theme impacts every page that loads on your site. If it is slow, your site will be slow.
• Are your plugins slowing down your WordPress site? One-by-one you analyzed your plugins to find bottlenecks. Do everything you can to remove slow plugins. Also, get rid of things that might be neat, but are unnecessary. Analytics dashboards are something I don’t ever install since I can get everything I need directly from within Google Analytics.
• Is the lack of a CDN slowing down your WordPress site? If you aren’t using a CDN, you are missing out on some opportunity to improve speed scores. With Siteground, Cloudflare is included for free, so there isn’t any excuse not to use it.

Some or all of these elements might be what’s causing the problem. Before you commit to taking your testing site live, you need to be sure that you are happy with the scores.

NOTE: In preparation for some of the next steps, there is a possibility that your scores are going to drop as we proceed. If you are running a 95 and 99 and do not intend to add any additional plugins like browser push messaging plugins, chat plugins, or ad network plugins then your scores are probably going to stay where they are. If, however, you are planning on adding additional features that rely on third-party services, your scores are going to drop. Get comfortable with that. It is going to happen.

If you are good with where your scores are currently situated, let’s move on to the next step of testing your site.

Step 26 – Thoroughly check all the functionality of your site

The great thing about WordPress sites is they are all different. The variety of themes, plugins, and content make it so that we can customize all the elements of our site to meet our needs and those of our audience.

At this point, you have built a new version of your site from the ground up. What you need to do next is ensure that everything that your current live site does, your new site will do, too.

There are things that your current live site might have that your new site does not have configured yet. Things that could include:

• Setting up Google Analytics
• Setting up a Facebook pixel
• Setting up any opt-in forms
• Ensuring that your new site has your Google Search Console validation file in the root directory
• Ensuring that your new site has your Pinterest validation file in the root directory
• Setting up (or migrating) your contact forms so they work properly and send to the correct addresses
• Setting up any opt-in popups that you use on your site
• Configuring any plugins like download managers that track the usage of files you host on your site.

These are all things, and there are probably more, that you need to go through and ensure are applied to your new site. As I mentioned earlier, these features often rely on third party web services.

It bears repeating that the more services you rely on, the slower your site is going to run.

Some things that I would recommend doing after you go live would be things like:

• Adding in the code and sidebars for your ad provider
• Setting up the Yoast SEO plugin, since it is specifically configured to work with your live domain, not the subdomain that you set up.

So, go through and do a thorough test. Make sure everything seems to be working as expected. In my case, I chose to wait until after go-live to configure the following:

• Yoast SEO plugin
• OneSignal browser push messaging plugin
• Mediavine ad network plugin

I set these up once my socmedsean.com domain was pointing to the new site. You will need to determine if there some plugins that you want to hold off on until you go live.

Once you have testing the functionality of your site, it’s time to take it live.

Step 27 – Work with your host to point your live domain to the folder where your new WordPress site is located

In this step, you are going to take the necessary steps to point your domain traffic to your new, and hopefully faster site.

NOTE: During this process, you are going to take your new site live. If you aren’t ready for that, then do any work you need to and come back to this step. Once you go live, you can revert back to the old site, if necessary.

TIP: I would highly recommend that you open a ticket with your host on this one. Let them know that you built a new version of your site in a new folder and you would like to have them point the domain to that specific folder. It should take them a few minutes to do via chat or phone and all your traffic will now flow to your new site.

I would also recommend that you ask your host to create a brand new subdomain for you that points to your old site. So, if you old site was installed in a folder named “mysite” and your new site is located in a folder named “mynewsite” then make sure they create a new subdomain that points to the old folder so you can still access the old site.

I know that might seem a little complicated, so maybe if I explain how my site was setup it will help.

• For this exercise, my initial site was built in a folder called “home”
• My new site is built in a subfolder of home called “socmedsean”
• The subdomain socmedsean.socmedsean.com points to the “socmedsean” folder
• I created a subdomain oldsite.socmedsean.com that points to the “home” folder.
• Once the socmedsean.com is pointing to the “socmedsean” folder, then I can also access the old version of the site by going to oldsite.socmedsean.com.

NOTE: I have since removed the old files in the “home” folder so you can’t access it if you try.

I know that might be a little confusing, but if you provide this information to your host, they should understand the request:

Dear host – I recently rebuilt my site on a brand new install of WordPress. I created a subdomain called [add your subdomain here] where I built out the new site and now I would like to repoint my primary domain [type your domain name here] so it directs all traffic to that new folder. I would also like for you to create a new subdomain called oldsite.[yourdomain] that points to the old version of my site and allows me to access it, in case I need it in the future. Thank you for your assistance.

If you are technically adept and understand how to make changes to your .htaccess file, then you can do this process on your own by adding this code snippet to the top of your .htaccess file in your root directory:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain-name.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.domain-name.com$
RewriteCond %{REQUEST_URI} !folder/
RewriteRule (.*) /folder/$1 [L]

In order to make the code above work, you have to replace both instances of “domain-name.com” with your actual domain name. Then, you need to replace the “folder” with the name of your folder.

Since my domain name is socmedsean.com and my folder is called socmedsean, then my code looks like this:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^socmedsean.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.socmedsean.com$
RewriteCond %{REQUEST_URI} !socmedsean/
RewriteRule (.*) /folder/$1 [L]

Once you add that code to the .htaccess file in the root of your hosting account and save it, all traffic for your domain should be routed into the new folder where your new site is located.

NOTE: For those of you who created a staging site and tuned it, you likely have a process where you can promote your staging site to become your live production site. This is the point at which you will want to do that. PLEASE back up your production site before you do that, though, just in case you need to revert it back.

With your testing site now live, there is another step you need to take before everything is ready to go.

Step 28 – Run a search and replace for your subdomain within your WordPress database

Once your domain is pointed to your new site folder and you can access it, there is another step to take before you are fully up and running. In the WordPress database, many of the links are likely still pointing to your subdomain.

You don’t want this.

NOTE: If you built a staging site, you likely do not have to go through this process because the tool you used to promote your site from staging to production likely did this for you. It is, however, a good idea to run through the exercise, just to make sure.

Changing things in the database might sound scary, but the good news is there is a great plugin that can help you do it called Better Search Replace. Just install the plugin from the WordPress plugin directory and then use the tool to replace and links to your subdomain with your actual domain.

Install the Better Search Replace plugin to help correct your internal URLs

For me, I needed to replace all references of socmedsean.socmedsean.com with www.socmedsean.com.

Do a dry run first to see what changes would be made.

Replace your subdomain URLs with the proper URLs for your live site.

Once you are ready to make the change, uncheck the dry run checkbox and actually run the query to make the changes. At this point, all of the URL references to your subdomain will have been replaced with your live domain.

After you complete the process, you can deactivate and remove the plugin.

TIP: If you use a plugin for a short period of time, be sure to deactivate and then remove it. This keeps your site running faster than when unnecessary plugins are activated. The last thing you want to do is decrease your scores and increase your page load times because of plugins you aren’t even using.

Step 29 – With the optimized site live, finish any necessary configuration

At this point, with your new site live, you need to finish up the rest of the configuration. Do things like:

• Install and configure Yoast SEO or whatever SEO plugin you use.
• Install and configure any additional tools like OneSignal (browser push notifications)
• Install and configure any ad provider plugins and scripts so that your ads show on your site.

Basically, get everything up and running as it was on the previous site. Go through every possible user experience that your visitors might consider. Consider things like:

• Testing your opt-in forms
• Test to make sure Google analytics is reporting data
• Downloading any document, pdfs, etc. that you host on the site
• Test any popups that you use
• Test your contact form
• Test to make sure your images are pinable

As you install and configure any additional plugins, you need to go through the process of testing and documenting their impacts in your worksheet. You are likely going to see some site speed impacts, if they rely on third-party web services.

In my case, adding my ad network provider caused a drop in my scores from the 90s to the 80s on mobile. That one change made a pretty significant impact on my scores.

Adding advertisements to my WordPress site dropped my page speed scores, but I’m OK with it.

The question I had to ask myself is whether I would rather have scores in the 90s by removing my ad provider or earn money from my site and have my scores in the 80s and 90s. The answer led me to keep my ad network and accept the fact that I would have lower scores.  

NOTE: As you will see in my spreadsheet, I tried quite a few different caching, minification, and combination options to see if other plugins might result in better scores. The end-result was that the SG Optimizer plugin, combined with Cloudflare worked the best and got me the best scores.

Step 30 – Run a GPSI test to test with your fully configured site

With your site live and fully configured, you want to run one last round of GPSI tests. I would highly recommend you let your site “rest” for about 24 hours before you run this round of testing.

You probably want to take a break from your site right now, anyway…right?

For me, my final scores were at 82 mobile and 95 desktop. Both are significant increases over my previous scores, so I’m happy with them.

I also have a deeper understand of where my site slowdowns are occurring, so there aren’t any mysteries. This documented process that details how each plugin impacts site speed is worth the exercise to me.

The result of my site rebuild was a significant increase in site speed.

With your final GPSI test documented in your spreadsheet, there is still one more test you need to run.

Step 31 – Run a GTmetrix test on the new site to determine page speed

Early in the process, I mentioned that GPSI isn’t the only test that is important for measuring your site speed. We also ran a baseline test using the GTmetrix tool and documented the page load times.

To finish up the testing, you need to run one more test to see how quickly your pages are loading. To test your new site, using the GTmetrix tool, head to this URL:

https://gtmetrix.com/

Enter your URL in the field and click the “Test your site” button.

The site rebuild process cut my page load times in half.

Record your score in the worksheet at the bottom and compare them to your initial baseline speeds. Did you see an impact? I hope so!

My fully loaded time dropped from 6.2 seconds to 2.5 seconds, well below the 3 second target and shaving almost four seconds off my page load times.

You have done quite a bit of hard work to get to this point. Give yourself a pat on the back and take a moment to celebrate the progress you made.

Step 32 – Schedule your next site optimization

Unfortunately, your work isn’t over. As I mentioned at the start of this journey, my scores changed dramatically over six months’ time. This means that you and I both have to be diligent and continually test any changes that we make to our site.

To do this, I highly recommend you place a reminder on your calendar that repeats every three months and reminds you to run through both the GPSI and GTmetrix tests to ensure that your site is still performing as you expect.

Additionally, whenever you add plugins or adjust your theme, you also need to evaluate the impact. Luckily, by this time you should be a pro at understanding, evaluating, and documenting the changes.

Step 33 – Share your success with the world

It has likely taken you a lot of hard work and energy to get this point. It certainly took me a long while to document the journey in a way that I think is easy to follow. My plan is to update this process every year going forward and add/change any steps that need further exploration.

I would appreciate you letting other folks know about the process so they can reap the rewards of the speed enhancements we documented. Feel free to share this post with your friends or your social media audience and let them know whether the process helped.

As always, feel free to reach out to me with any questions I can answer via social media or via my contact form. As I said earlier, the goal is to improve this process, so if you have constructive criticism, just let me know.

Cheers!

–Sean

---

Share this post with a pin!