Improve Page Speed For Google SEO In Actionable Ways

Improve Page Speed For Google SEO In Actionable Ways

Google announced that they will be including mobile page speed as a variable in their mobile search ranking considerations starting July of 2018 (The Google Speed Update). This is actually a small Google SEO update that has already likely been impacting results prior to its official announcement. Google says the update will only impact a very small portion of “slow” sites, but it begs the question, “If I improve page speed, will Google rank me higher?”

This is something publishers have been hearing from Google and other major players in the online ecosystem for a while now.
Faster, faster, faster. Mobile, mobile, mobile. This supports platform initiatives in emerging markets, like India, where web speed is a much bigger issue than it is in countries like the U.S.
Here’s the problem.
Most webmasters do not have very good knowledge of how to actually measure site speed (ex. Google Page Speed Tools is not a good way), improve their overall website page speed, or understand which improvements to those metrics offer real benefits to visitors and their Google search rankings.
Luckily, I have a lot of information on all of those topics that I’ll share below.

Why does mobile page speed matter to Google?

Google has long been invested in mobile user experiences. They’ve been watching searcher behavior over the last decade shift from a desktop-oriented experience to a more mobile-oriented one.
This means they understand that their ecosystem — and value to their users — is dependant on them providing a good mobile experience; especially in emerging markets like India and Eastern Europe.

This has translated to initiatives that Google has instituted to encourage publishers to do the same. Think about it. If Google provides a great mobile experience, but the websites they provide to searchers via their search engine don’t, how will this ultimately affect Google’s flagship technology?
Over the years this has been instituted slowly. Sometimes in obvious ways, like the Mobile First Index, Mobile-Friendly Update, and aspects of RankBrain.
But, in other instances, Google has been rewarding publishers that have objectively delivered better mobile experiences to visitors for a while.
Quick Note: I have mentioned mobile experiences multiple times in this opening segway, but not mentioned website page speed once. There is a reason for this.

Understanding page speed and SEO up to this point?

While page speed does have a correlation to better user experiences (and higher ad revenues), it is actually just one factor in the equation (I’ll share Google’s data on this below). This is why Google has not directly used page speed as a ranking factor in mobile results for all of recorded history. It isn’t actually what they are concerned about.
Let me explain. If search visitors come to a page that loads in 5.6 seconds, which has an average bounce rate of 45%, an average pageviews per visit of 2.1 pages, and an average session duration of 2:45, Google may look at that experience and compare it to similar search results for the same query (FYI, Google is looking at other engaged behavior metrics other than these, but this is just for example).
If this site compares favorably in those UX metrics but loads 2.1 seconds slower than the rest, currently, Google has ignored the arbitrary record of page speed and still given the mobile experience ranking benefits to the publisher with the better objective behavior metrics.

Google has indicated that this is largely how it will continue. In fact, in their Speed Update announcement, they indicated that the update itself would only “affect the slowest mobile sites”. Potentially less than 1% of all mobile queries will be affected by this update.
Pages that provide the best objective experiences to visitors, and seem to provide the best answers to a searchers query, will ultimately still be what impacts search rankings the most.
What does that mean?
As indicated by Google at Pubtelligence last August, search factors like when searcher bounces back to the SERP after visiting a website and then click on a subsequent result are clearly something they are measuring and accounting for.

Additionally, Ilya Grigorik (Google Webmaster team) also seemed to indicate that when a searcher clicks on a search result and bounces back to SERP — prior to the page loading (even before the Google Analytics script loads)— that this is something that Google monitors closely; meaning if this is happening to people on your website that Google is likely to view this negatively.
The worst part about that is that if the Google Analytics script isn’t even loading prior to this kind of bounce, webmasters will have no record that the searcher clicked on their result and bounced back to the SERP before the page loaded. This is where page speed comes in.
Understanding what needs to load, how fast it needs to load, and what is important to load first, can offer some of the biggest payoffs to publishers. Both functionally, and in ranking instances with Google. Yet, most publishers do not understand to what degree they should actually be worried about their current page speed.
Since page speed is sort of an arbitrary measurement anyways, how do we know when it is actually factoring into visitor experiences and impacting visitor behavior (i.e. affecting rankings, causing faster bounces, impacting session duration)?
Which improvements in page speed offer SEO benefits?

This graph includes information Google has been sharing for a while — and has recently emerged again since the announcement of the Google Speed Update. However, if we look closer at the data, we can actually see some pretty interesting insights.

For example, improving page load time from 16s to 8s — cutting it in half — seems to offer very few benefits. But, improving from 6s to 3s looks to drop the average bounce rate among typical mobile users by 80%.

The problem here is that many webmasters think that tools like Pingdom or Google Page Speed Insights are providing them good information to make these decisions, they aren’t. In many cases these tools are only looking at TTFB; which we’ve shown before to be a bad metric for page speed and SEO (more on this below).

According to Google, the reason for the Speed Update is not to reward faster sites, but rather to try to penalize the slowest “sites” on the web (whatever that means).  However, if we look at the data that exists out there about page speed, we can learn a little bit more about how it is affecting visitor behavior and mobile experiences.
AND…. being able to affect these things DOES offer some SEO benefits. So how do we use page speed to improve our objective UX metrics and increase Google search rankings?

First, we have to understand how to get an objective understanding of our current page speed. If we understand how quickly our content and important scripts are loading for actual visitors, we can use some of the industry data above to potentially make impactful changes to our web properties.
EXAMPLE of Benefits
For example, if I am able to learn that my current visitors typically see an average page load time of about  4 seconds, I know that improving site speed by even 1 second ( 25%) offers some potentially strong benefits to bounce rate.
If my page load speed is 3 seconds, that same 25% improvement offers significantly fewer benefits to bounce rate, statistically speaking.
Ultimately, this is how publishers have to approach these initiatives. Improving page speed does not always offer benefits.
In some circumstances, it offers big benefits, in others, it doesn’t. And, more often than not, the degree to which page speed is improved in these instances will ultimately determine the overall impact it will have on visitor experiences (which is ACTUALLY what is affecting SEO the MOST).

How do I measure page speed that matters?

I wrote a really in-depth article on accurately measuring website speed — and the dangers of using common tools and TTFB as a critical metric — in a previous blog. I won’t repeat everything in that article; however, I will provide some cliff notes, and give a little context to how TTFB, DOM, and other metrics relate to understanding page speed for the end user.
Understanding and measuring page speed… a brief summary:

• Page speed is not a static measurement that is the same for every user
• Opening your phone and accessing your site is probably the worse way to figure out if a website is fast or slow. Four different people across the globe could do this and have completely different experiences.
• Technologies like CDN’s help normalize page speed results across geo-locations

• Popular free online tools like Google Page Speed Insights and Pingdom do not offer accurate page speed or site speed assessments. Thinking that improving scores in these tools will ultimately make SEO better is not an accurate or a very effective strategy. Many use TTFB (time until first byte) as a core metric; which is not indicative of how quickly a visitor can access or interact with content (which is actually the most important factor in page load for visitor experiences).

• DOM interactive has been shown — in our research — and the research of others, like Staus Cake, to be one of the greatest predictors of actual user page load speed. This is actually the metric that Google Lighthouse spends a gross majority of its time helping developers optimize within Google Developer Tools.
• DOM Complete is another helpful metric that gives publishers a good idea of how long it takes for all of the code on the site to load.
• Common tools may show a slower loading speed when best practices like lazy-loading are implemented; however, these types of things actually make pages load faster for the visitor (i.e. content, ads, and important scripts load first). These kinds of implementations may cause lower scores in simple tools, but will actually result in much faster page load times for actual visitors (which is better measured using DOM interactive)

What is website page speed, exactly? Cut through the B.S.

Below, I’m going to share some advanced — and simplified tips — for getting, and improving, actual page speed scores; however, we need to start with understanding how your content, scripts, and hosts all influence these measurements (if you don’t understand this, you’re guessing in the dark).

The best way to truly understand what is accounting for differences in page load time (what’s loading slow, what’s loading fast) is to right click on your page, select Inspect Element, and then navigate to the Performance tab and select the reload icon.
This will allow you to observe your page load waterfall; meaning an exact accounting of how, when, and the process by which things are loading.

This information will give you an idea of the types of things that are actually attributing to the load time. Ever wonder why sometimes the page is faster than others? It could be that the Facebook sharing script that communicates directly with Facebook.com is slower this week than last.
Understanding how this works can keep you from going crazy wondering why things are faster or slower when nothing changes.

Here are a few things to look at:
Run the reload and then look at the waterfall (see image above). Look at different elements of your page, dig into the details, see what outliers exist, and understand why.
This information can help you actually diagnose — with certainty — what exactly is causing differences in page load time. Everything from your caching and host to the individual fonts on your pages.
I’ve seen strange fonts linked via plugins that caused major variances in page load time. It would be nice to notice this stuff, right?

watch the video walk-through here (above)

Tips for quickly measuring and improving page speed

Okay. So, maybe you’re like a lot of webmasters or publishers and are traditionally used to using tools like Page Speed Insights to measure your site’s speed. What can you do instead to account for things like DOM interactive and to get a better idea of how fast visitors are actually accessing content?

I mentioned Status Cake once above; as they have done some great research in this area, but they truly are one of the best tools for understanding backend monitoring (namely website speed).
Status Cake offers a free version of its technology and some affordable “premium” versions as well. If site speed is a major concern for you (which it may not need to be), I recommend leveraging tools like this to get a holistic and objective view of your actual page speeds.

It’s also worth mentioning that if you use the Ezoic platform (free to use) on your website, you can access DOM metrics and other advanced visitor behavior information in your User Experience reporting dashboard. This may offer some of the deepest insights available on how things like website speed and other variables that are impacting the mobile visitor experience metrics that ultimately affect SEO the most.

The tools on Ezoic actually allow webmasters to dig deeper into their site’s visitor data to understand the time between navigation clicks and the time it takes for the next page to load. This can help publishers keep visitors on the site longer if they discover that Navigation to Connect is slower than average between certain pages or for certain visitors.
By diagnosing where and why this is happening, you can improve the session duration of visitors.

Lastly, if you’re just looking for a quick lay of the land. While still not as good as true monitoring tools, WebPageTest.org offers a better view of overall website speed than most of the other free tools; although it is not a true monitoring tool.
It has been what I recommend to family and friends when asked about getting a general idea of page speed for a particular website.

What actions can I take right now to improve site speed?

I’m willing to bet that most people navigating to this article were looking for this part first. Hopefully, you now have an understanding of how to measure page speed, and to what degree you can expect improvements to positively (or neutrally) impact your mobile website search results.

First, I’ll start with the basic infrastructure stuff.

• If you don’t have a CDN set up and active on your website right now, this is absolutely the first step. CDNs help distribute your website faster all over the globe. We wrote a little more about them in this article. CDNs are often free and easy to implement (if you’re an Ezoic user, you can easily turn it on for your site if you haven’t already – instructions below).
• Next, implementing page load best practices like “lazy-loading” and caching can offer significant page load benefits.
• If your site is regularly updating content on multiple pages, you’ll want to make sure your cache is configured so that visitors are grabbing the latest version of your content; since the point of caching is to make sure they don’t have to reload all the same elements directly from the server every time.
• Lazy-loading can cause your site to score slower on certain page speed tools, but actually provides users and crawlers with a much faster experience; as the content and other important elements load first. This provides the visitor with a fast experience.

If you’re an Ezoic user, you can actually implement all of this and more relatively easy using the Ezoic platform. Instructions below.

Once integrated — and live — using Ezoic, simply navigate to the App Store and install the Caching App.

Once this is installed, turn on the Caching App. The application will give you some cache control settings, CDN access, and the ability to clear the cache if significant site updates occur.

I recently ran a little experiment with the Ezoic Caching App between two nearly identical blogs that I own.
I own two blogs that have the same CMS, same theme, and the same host. One of the blogs had the caching app installed and the other did not. I ran both through webpagetest.org to get a general idea of the difference.
Here’s my blog without the Ezoic caching app.

Here’s my nearly identical blog WITH the Ezoic caching app (which includes the use of a CDN).

It’s a very limited study and comparison. However, the load time of the blog without the Caching App was 5.54 seconds. The one with the Caching App was 2.9 seconds.
If you remember our chart from above, the bounce rate difference between 5 seconds and approx. 3 seconds was significant. The average improvement; according to that research suggests that this will decrease bounce rate by  2/3’s!
If my first blog had been 3 seconds and my second one been 2 seconds, the difference would have been much less significant.

Other actions to improve website speed: Images

Aside from infrastructure changes, there are several “on-page” improvements most publishers can make to improve website speed. Really, there are two big ones that standout: images and 3rd party scripts or plugins.

Optimizing images for the web is one of the easiest ways to improve the page speed for a particular landing page. Most webmasters and publishers think they are doing this well but probably are not.

If you rely on a plugin or 3rd party tool to optimize/shrink your image files, I can promise with almost 99% certainty, that your images are too big on many pages.

This is actually one of the few things that Google Page Speed Tools can help with. If you run your pages through the Google Page Speed Tool it will show “Optimize Images” in the suggestions summary for any images on a particular page that may be larger than optimal.
Find these images, and then refer to this article where I review the two best ways to shrink these images to speed up the load time for that particular page.

Quick summary of that article: Resize the image (no more than 1000px wide), then use Photoshop or Optimizilla (free online tool) to compress the image for web.

If you run multiple pages through the tool and find that you need to optimize images on most pages, just assume that this is a systemic site-wide issue. It would probably be worth it to take on the small project of resizing images on all of your top landing pages, or pages that are on the cusp of getting lots of Google traffic.

Other actions to improve website speed: Plugins and scripts

The other “on-page” optimization that can be done to improve page speed is to remove unnecessary or slow 3rd party JS (Javascript) and sluggish plugins. This is usually pretty easy (as you are just clipping something out).
Sometimes it can be hard to figure out what is worth keeping and what can be eliminated. To simplify, I’ll give you a good example of something I once removed that improved speed, visitor experience, and bounce rates on a website I managed.

I had a WordPress plugin installed called “Smooth Scroll”. It provided all visitors with the Apple Safari browser style of scrolling (smooth, not choppy). I really liked the way this looked.
Unfortunately, “smooth scroll” wasn’t smooth for everyone. It made the pages slower and often caused the scrolling to freeze for visitors in certain browsers. Once I removed the plugin, my site speed increased and my bounce rate dropped by 25% site-wide. I felt really dumb for keeping this installed for so long.

If you’re still not sure what scripts to keep and which ones to get rid of, Ezoic users can use the Script Tester app to run experiments that exclude the scripts for some users so that you can measure the difference it makes. This can help you decide if that brand new social sharing widget is actually worth keeping on your site or not.

What should I do next to ensure a fast mobile site?

Well, there’s a lot of information above to sort through. First, you’re going to want to understand that the Google Speed Update is likely to have a minimal impact on the vast majority of mobile sites.
Second, you’re going to want to make sure you comprehend WHEN improvements in page speed are likely to impact rankings and visitor experiences. This can save you a lot of time; as many publishers arbitrarily worry about page speed without any understanding of any of the benefits.
Third, you’re going to want to understand how to objectively measure page speed without relying on inaccurate tools (even Google’s). This seems daunting, but the resources above should make this pretty straightforward.
Lastly, use the information above to configure your website infrastructure and make on-page adjustments to make incremental improvements to your page speed. Some of these may be easier to implement than others.
Hopefully, this has helped you get your arms around this strangely popular topic. If you have further questions about page speed or website load time, leave them below and I’ll do my best to answer them.