Attempting to dictate the rules of speed quality, Google made the mobile Internet worse. How did they shoot their own foot?
Well, it didn’t happen overnight. Google shot over and over again. Destructive repetition. Foot target.
Google’s speed misadventure began in 2010. They announced speed as a factor in ranking websites. But Google was vague how much speed would affect SEO. Nor would they tell which aspects of speed made a difference. Everyone got excited. Lots of wild guessing. And soon, a web myth emerged. Never spoken by Google but assumed by the herd: “Speed is now critical to good SEO.” A blatant lie people use to sell speed services, addons, plugins, themes, and books. Panic in the air.
The truth is “page speed” never made much difference at all. Not for SEO anyway. It did for UX. It’s bad user experience to keep visitors waiting – especially on mobile devices. Google even said relevant content and UX were more important. But many website owners and bloggers ignored or missed those important words.
How much load time does www.google.com take? Using WebPagetest.org (owned by Google) the result is: 2.196 seconds. The full-load time can vary from 1.270 to 2.204 seconds depending on test server location. That’s right seconds. What? That naked page only has a logo and a search field. Tell us more: 16 HTTP requests. 471k page weight. Time to First Byte is 593 milliseconds.
Improve Server Response Time: This rule triggers when PageSpeed Insights detects that your server response time is above 200 milliseconds. – Google.com
Google TTFB (Time to First Byte) is 593 milliseconds?! Surely that’s a mistake. Nope. Their TTFB alone is almost triple the 200-millisecond Google rule.
Google doesn’t even keep their own edict of 200-millisecond TTFB (server response time). Their homepage TTFB ranges from 369 to 774 milliseconds depending upon where in North America the test server is located. So results fluctuate and vary.
Faster TTFB size is a benchmark of a well-configured server application.
TTFB is server overhead. An unfortunate delay caused by mechanical or physical parameters. It has nothing to do with page content or web code. TTFB is mostly hardware dependent. It’s usually beyond your control. TTFB is the duration after calling for server assets until the arrival in the browser. Good TTFB is under 200 milliseconds. Bad TTFB is one second and up. Terrible is above 4 seconds. Yes. Some servers are just that rotten.
So TTFB is something you buy. You pay for it. Your host owns it – not you. You can’t build or code it into your WordPress website. In other words, the poorer you are, the worse your TTFB. The richer … well, you get the idea. So much for web equality and democracy.
Yet, TTFB is the only parameter Google uses to check your site speed in their secret algorithm. And it improves your ranking less than 0.5 percent.
READ more PagePipe: Fast sites don’t improve Google page rank
But, Google has the fastest servers in the world. Correct? Wouldn’t their TTFB be the best and faster than 593 milliseconds? I mean, our cheap GoDaddy hosting gets better than that. Why the difference? It’s Google’s SSL Certificate. Read more below how this causes speed delays.
PagePipe doesn’t use SSL certification. We don’t need it. We’ll save our 500 milliseconds. Sales transactions are managed securely and efficiently by PayPal. Yeah. We sell a downloadable ebook, Toxic WordPress.
Well, here’s another place Google shot themselves in the foot: Their HTTPS / SSL initiative in 2015. It wasn’t moving along like they wanted after a few years. So they again said, “SSL certification will not only affect security – it will now affect page ranking.” Everyone got excited again. People started adding this non-feature to their websites in droves. Did they all need it? No. Did it help SEO? No. Did it kill speed? YES!
HTTPS / SSL server handshaking creates an initial stall in making Internet connections. There’s a slow delay before anything starts to render on your visitor’s browser screen. This delay is measured in the Time-to-First-Byte information (aka TTFB).
What is the typical TTFB delay caused by SSL certificate handshaking? 500 milliseconds. That’s 25 percent of a 2-second performance budget.
Learn about the gory details of this silly blunder by Google:
READ more PagePipe: HTTPS / SSL and its negative impact on mobile speed.
Are we done bashing on Google and their weird speed policies and practices? Not yet. We want to mention Google AMP (Accelerated Mobile Pages).
In 2015, Google said articles served from its Internet network were four times faster. That’s right. But developers disagree. Engineering or “designing in” page optimization gives the same or even better results. That’s right. It appears Google has a hidden agenda not-so related to speed. That’s their mask.
READ more PagePipe: Why Google AMP is not the ultimate solution for mobile WordPress speed.
Are we done raking Google over the coals. No. We need to talk about Google PageSpeed Insights.
We don’t recommend Google’s PageSpeed Insight tools for mobile website benchmarking. Or even for desktop. We avoid this tool.
PageSpeed Insights is the worst speed test on the web. Why? It’s usually impossible for WordPress to pass this test. WordPress almost always has jQuery enqueued. That causes goofy warnings. But Google doesn’t use PageSpeed test scores in it’s ranking algorithm. They use TTFB (time to first byte). It’s a frustrating waste of time.
READ more PagePipe: Google PageSpeed Hypocrisy
We’re almost done! We must discuss Google Fonts and their impact on mobile speed:
External font scripts like Google Fonts slow down your site. We guarantee websafe fonts are faster. According to HTTP Archive, as of October 2016, web fonts (like Google Fonts) are just over 3 percent of an average page’s weight.
Disabling with Remove Google Fonts References plugin makes an average difference of only 53 milliseconds. But in the extreme, one theme had a 300 millisecond gain in speed. In some cases, there was no change in speed at all.
The difference in weight is anywhere from 60k to 300k. Again, it’s wasted mobile bandwidth.
Would we delete Google fonts and go with default browser fonts to save 300 milliseconds? You bet. When we’re working on getting under 2 seconds or even 1 second, that can make a big difference.
Again, there are times requesting Google Fonts will throw a 1-second delay. Why? We don’t know. Go ask Google. And, of course, the more fonts you call the slower things get. There’s a plugin that combines the Google font requests. Google WebFont Optimizer finds every Google Font request. It bulks them all together. Then your website only asks Google once for the fonts, instead of multiple times. Still, our preference is to delete Google Fonts completely.
OK. We’re finally done bashing on Google ruining speed. We may get blacklisted. It was worth it.
BONUS BASH – Google Analytics isn’t good for speed either. Read our article: How does Google Analytics affect mobile page speed?
Mobile WordPress Speed – without coding!