Page Speed For and Beyond Google Mobile Ranking

Page Speed is Not Just for SEO Yet More Important than Ever for SEO

Nearly every audit I perform, I find weakness in page speeds. Twenty, thirty or forty second average load times.

Even when I audit a site and find the “30 day average” is under five seconds for most pages, the moment I dig in to look at individual page trends for 30 or sixty days, I often find some “mostly fast” pages are in the ten, fifteen or twenty five second range one or a few days a week or month.

Intermittent Page Speed Issues Revealed in Google Analytics

Scale that out. If thirty % of your site’s pages are slow a few days a month, and that’s involving a few hundred or several thousand visitors for those days, how many of them are getting those slow speeds?

SEO is far beyond the only thing that matters. Every visitor, from every referrer source, or even direct, who encounters a slow page, is potentially going to abandon the site.

And yes, even intermittent speed problems matter if you care about success.

While you can use a tool like Google Page Speed Insights, or Chrome Dev Tools to find ways to improve speeds, those tools are far from complete in their speed bottleneck issue identification, and far from complete in their recommendations.

WebPageTest, GTMetrix and other tools can help of course. Yet NONE of them cover some issues that need to be addressed if you want to properly resolve speed issues.

Sure, you can see “compress images” or “eliminate render-blocking, among other things. And that’s all important. Yet there’s much more that can be done.

Page Speed Improvements Beyond The Typical Tools

Rather than going through the GPSI list, I’m going beyond those.

Here then, are the top factors I find consistently over time, for page speed improvements not directly listed or mentioned in most speed tools:

Hosting Provider Forced Delays

1. OCSP Lookup

A fairly recent phenomena — a number of hosting configs are forcing OCSP certificate lookup verification through an off-server network. Just this week I saw one go through GoDaddy servers, and one go through Symantec servers.

Neither site I found this happening on, is being hosted on EITHER of those platforms.

And before the first byte is even downloaded, one and a half to two or more seconds have been lost to that process. It’s outrageous.

First Process in page load is a hosting system SSL certificate check, delaying page load.

A good hosting environment doesn’t force that process.  So go run a test through then go to the “Details” report.  Look at the first or first couple of processes for your home page.  Do they look odd? Out of place? Those could very well be a host certificate verification process being forced into the sequence.

If your own home page HTML retrieval in that test isn’t listed as the very first process, that’s a problem that needs to be resolved.

2. PHP Version

While we’re talking about hosting — check the PHP version on whatever host you’re using. Many hosts are stuck in PHP 5.6 instead of 7 — where PHP 7 has major speed improvements.

Be careful though — in some edge-case scenarios, upgrading to PHP 7 can cause other problems so be sure that won’t happen if you switch.  And if it will cause problems, figure those out and resolve them so you can switch.

Excessive File Weight and Process Delays

Strip out every single excess process that can’t be justified as necessary for revenue. I see sites with hundreds of individual elements at the code level for a single page.

1. Font Excess

There is no justification for five or eight font files, and most especially get those fonts stored locally. Run away from Google’s own GStatic font server.

And do you really need that one font where the file size of that font is 150 kilobytes? Honestly — aesthetic opinions often kill page speed needlessly. So look for similar fonts that weigh much less. Or just strip out fonts entirely and go with system fonts.  Or put them on your own site server.

2. Asset Hosting Location Matters

In fact, locally host (or host on your own CDN setup) as many assets as possible — fonts, images, scripts, whatever — too many sites pull assets from other networks and the delay in processing adds up significantly.

3. Tracking Pixel Insanity

No, a site doesn’t need 27 tracking pixels (see above where you need to justify every single asset being used or called).

4. Gravatar Nonsense.

While we’re at it, for cryin out loud, turn off Gravatar on WP blog systems. Forcing a page process to run back and forth to Gravatar for every single comment is nonsense, and I’ve seen pages grind to a snail’s pace loading while all that is going on. And the more comments a blog post has, the more time wasted retreiving Gravatar “default image” images.

5. Unused Script Code

What? the site has JavaScript files that by themselves are 250kb? Yeah, I bet half the code in those scripts isn’t even being used on that site.

6. Abusive Design Assets

No, a site doesn’t need fifteen CSS files.

7. Image Sizes — Pixel Dimensions Matter

Are all of the images on the site already sized dimensionally for their specific space needs? Or are you taking an image that’s 1000 pixels wide, down into a 200 pixel wide space?

So make sure those images are sized properly for dimensions before you compress them for weight.

Going Beyond Google Mobile Speed Ranking Considerations

I’m going to wrap up with a mini-rant. I don’t care if improving speed isn’t going to help the overwhelming majority of sites from an SEO perspective.

Let’s talk about perspective. Google reps claim the upcoming mobile speed impact update will only impact a small percentage of searches.

According to, there are 1.2 trillion searches a year. Some estimates around the web put it at over two trillion at this point.

Let’s say the “small percentage” John Mueller likes to use as his statement that’s potentially going to be impacted by the Google Mobile Ranking factor is “just” one percent.

That’s twelve billion searches will be impacted by that speed update each year.


Let’s be generous though. Let’s say it’s only one tenth of one percent.

That’s still 1.2 billion searches.


Anybody who ignores speed because “it’s a small percentage of searches” is not considering what that really means.

Mobile Speed — Way More than SEO

According to Google if your mobile speed is nine seconds, they estimate you will lose 29% of your visitors.

Let’s move beyond formulaic SEO. Formulaic SEO is never what matters most. User Experience matters most.

Formulaic SEO attempts to emulate that. Except formulaic SEO needs to go with averages and generalized cases.  Which means an entire sector of sites, and an entire sector of society, are going to be left out of that process.

User Experience on web sites isn’t just for those coming from Google organic results. It’s about visitors from everywhere.

Studies out there have shown that even a site that loads in 10 seconds (far below the old 20 second threshold for SEO on desktop), is likely causing a large number of visitors to abandon the site.

If you go to Google’s Newest Mobile Speed Testing Tool, (Powered by by the way, my go-to testing tool), you can see how many missed opportunities a site could very well be experiencing because that site isn’t lightning fast. Going from 10 seconds (not critical for SEO) down to six seconds or four seconds, can make an impact.

Yet there’s a reason Google pushes “one to three seconds” as the ideal range. It’s not all about SEO or Google resources. It’s because they have enough data to know the value for businesses, when site speeds are lightning fast.

While I don’t expect every site developer or manager or owner can expend the time to eek out every last drop of speed delay causes, I think it’s critical to go further than most people are willing to do, and will become more important as we move forward.

At least until every human being is connected to the web on lightning fast connections, every site is on a lightning fast server, and you can get away with fifteen megabyte page weights.

So if you want to maximize, or at least take logical, fiscally responsible steps to improve the quality of your site experience from a speed perspective,  it’s worth the effort.

Whether it’s because of Google’s new mobile speed ranking consideration or for all site visitors, I highly recommend you take the steps necessary to clean up the excess junk in your site’s code.  Even if you don’t see immediate increases in sales or goal conversions, it’s about sustainable quality.

Published by

Alan Bleiweiss

Alan Bleiweiss is a professional SEO consultant specializing in forensic audits, related consulting, client and agency training, and speaking to audiences of all sizes on all things SEO.

7 thoughts on “Page Speed For and Beyond Google Mobile Ranking”

  1. More great resources, Alan. I stopped reading when I finished #2 under Hosting Provider Forced Delays as it reminded me to check our company’s PHP version.

    I already verified the absence of OCSP Lookup in #1.

    But, we were still on PHP 5.6! So I ran a speed test through WebPagetest, GTmetrix and think with Google speed testing tools before I upgraded from 5.6 to 7.0.

    The results?

    with PHP 5.6 Load Time: 4.062s / First Byte: 0.405s
    with PHP 7.0 Load Time: 3.480s / First Byte: 0.226s

    with PHP 5.6 Fully Loaded Time: 9.5s
    with PHP 7.0 Fully Loaded Time: 5.7s

    think with Google remained at 4s with PHP 5.6 and PHP 7.0

    I just had share the results and thank you again for your reminder. Now I can continue reading the rest of your post! LOL

    1. Glad you found tests showed improvements just by upgrading to PHP 7! Not sure why the Think with Google speed remained the same. I need to experiment with that.

  2. Hi Alan,

    Can you recommend any tools to track avg. page load time over long periods of time for a large site? I’m not seeing any changes in Google Analytics site speed report when I add or remove Header Bidding library (prebid), which should make a huge difference.
    The trouble with pages with ads is that every pageview will have hundreds of different requests, and so one random test of a page request has no relevance since that combination of 100 requests is unique to that pageview.

    Thanks for the timely post.

    1. Aaron, you may be able to do this using an API with WPT API or with the GTMetrix API. I suggest experimenting with different connection emulator settings — mobile 3G is often a very good test for emulating the type of connections Google Analytics encounters when there are bottlenecks, for example.

  3. Thanks for the tips Alan, I thought the OCSP Lookup tip was especially useful. My website tends to load so slowly in the first couple seconds and it seems like a server issue. How would you go about solving this? I would love to know what you step by step process would be to solving this!

    1. Rezan,

      My step by step process for identifying specific areas for improvement involves anywhere from a few, to several hours of effort across several sequential steps. Even then, I don’t directly work on the changes because that involves changing, or replacing, or refining individual scripts, server configurations, images, style sheets and so forth, and my role is strategic consultant, not hands-on development or design.

  4. Thanks Alan for such an elaborate and insightful page speed article, I will update my web design website accordingly. Thanks for your SEO expertise. Keep up the good work.

Leave a Reply

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