Page Speed is Not Just for SEO Yet More Important than Ever for SEO
In nearly every audit I perform, I find a 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.
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 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
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.
A good hosting environment doesn’t force that process. So go run a test through WebPageTest.org 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 retrieving Gravatar “default image” images.
5. Unused Script Code
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 InternetLiveStats.com, 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.
TWELVE BILLION SEARCHES.
Let’s be generous though. Let’s say it’s only one-tenth of one percent.
That’s still 1.2 billion searches.
ONE POINT TWO BILLION SEARCHES. EACH YEAR.
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
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. This means an entire sector of sites, and an entire sector of society, are going to be left out of that process.
User Experience on websites 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 to cause a large number of visitors to abandon the site.
If you go to Google’s Mobile Speed Testing Tool, (Powered by WebPageTest.org 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.