Stop listening to those silly page speed scores and tests (if you don’t know what you’re doing)!!!

I wrote this guide to avoid reiterating myself over and over with naive clients. Hopefully, it also helps other developers/admins arguing with newbie clients over speed optimization. (It’s akin to people arguing with their doctor because of something they read on WebMD.)

Here is the definitive explanation why you need to stop being paranoid because of page scores. (And also stop arguing with developers and sys-admins who know more than you!

1. You don’t know how to read a speed test.

I’m willing to bet most people freaking out about speed scores aren’t even professional web-developers or programmers. There’s a reason why expensive tools and instruments in hospitals are only intended to be used by certified doctors. It’s because they know what they’re doing. They know which metrics to pay attention to and which ones to ignore. Why don’t they let some random person look at it? Because that random person wouldn’t know anything about how it works, what it’s measuring, and whether each result is bad or good. They’d simply panic and over-react to every visual/audio cue given out by the instrument!

Simple questions to know if you’re qualified to read a speed test:

• Do you know what TTFB is?
• Do you know what first paint is?
• Do you know which items are most important on the waterfall?
• How can you tell if CDN is helping or hurting your asset loads?
• What is HTTP/2, and what is its benefit?
• What determines if your images are compressed enough?
• Why should you ignore 3rd-party requests?
• How far should the speed test server be from your web server?

If you don’t understand any of this, you my friend are absolutely NOT qualified to read a speed test…and definitely not qualified to argue with your developer or speed consultant on which things should be optimized.

2. Speed tests encourage OPTIMIZING FOR SPEED SCORES rather than for USERS.

The #1 death trap of speed tests.

It’s that you end up optimizing your site for speed tests rather than for actual users. What a terrible choice to make! It’s the equivalent of writing content for SEO rather than writing content for humans. You would imagine it’s logically harmonious to appease both but it isn’t always the case in reality. Same goes for speed tests and user experience. What is “fast and useful” for a speed test crawler may not particularly be “fast and useful” for an actual human visitor.

This comes down to the simple fact that optimizing for users means delivering an INTENDED USER EXPERIENCE in the fastest load time possible. Whereas optimizing for speed tests means delivering as FEW ASSETS AS POSSIBLE in the fastest load time possible. This is why it gets so tricky. Creating a specific user experience requires loading many specific assets and in a specific load order. But the automated speed tests don’t know this, so they just simply recommend for you to chop out as many bytes and as many requests as possible. They don’t know (or can’t account for) the ones that you really need, or the ones that directly affect your user experience.

This is why speed consultants reiterate time and time again that you should be OPTIMIZING FOR USERS, and not for speed scores!

Simple question to know whether you value speed scores too highly: 

• Which do you prefer? Fast page-load and terrible page score OR slow page-load but great page score?
• Does it bother you if your competitor’s website loads slower than yours but has a higher page score?
• Do you really think it’s important to have 100/100 A+ page score?
• Do you really think having a high page score means your site is fast?

Believe it or not, there is very little correlation between high page score and page load time. Feel free to look up many popular websites out there and see for yourself.

3. Speed tests don’t account for specific website NEEDS.

Every site is different from another

Let’s say one car leaves the house carrying 50lbs of gear and another car leaves the house carrying 500lbs of gear. Is the second car really carrying too much weight? We don’t know! What if the first car was only going to the neighbors house and the second car is going camping? You see what I mean?

What if the test says your site images are too heavy compared to another site? Is that good or bad? Well, it depends! If your site is an ecommerce store or photography portfolio, you probably want bigger and higher-quality images! If your site is a simple text blog, then perhaps you’ll want smaller images.

You can’t have some silly automated tool judging these things when it doesn’t have any perspective on what your site is doing and how it’s different from other sites. It judges all sites to some (arbitrary) standard without accounting for each one’s specific needs. The idea is this…what may be “bad” for one site may actually be “good” or “intended” for another.

Examples of common speed test suggestions (and why they’re flawed):

• Combine CSS/JS to reduce requests – might actually slow down your page load and/or break your website design/function!
• Compress images more to save space – reduces your image quality and not recommended for sites that need high quality images!
• Lazy load images to speed up page load – can hurt ecommerce UX by hindering your visitor’s ability to fast-scroll! It needs to be said that DELAYED LOAD is slower than NORMAL LOAD!
• Slow total load time – that shouldn’t matter as users don’t need everything to load immediately, they only need the critical items or items near the top of the page!

4. Speed tests can’t tell you what affects your speed the most.

Speed tests often make a big deal out of things that don’t affect speed.

They simply give you a giant (and seemingly) comprehensive list of checklists and TO-DO’s. But they don’t tell you why those things matter. Many of the things being measured don’t actually affect your speed. They’re just random optimizations that may (or may not) improve user experience…how confusing!

Why are speed tests unable to tell you what’s important?

It’s because they’re completely automated and can’t judge things the way a human can (at least not yet). They don’t weigh metrics depending on the site. They don’t understand that image-related optimizations should have more weight on image-heavy sites. And that CSS-related optimizations should have more weight on CSS-heavy sites. They can’t account for this, so they weigh those metrics the same for every site.

• CSS being 500KB overweight vs images being 5KB overweight still minuses the same amount of points.
• 10 images being 1KB overweight each lowers your score more than your CSS having 30KB of empty spaces.

See what I mean? The tests are flawed! I haven’t explained every possible scenario where it does this and I’m not going to. I hope you save us both the time (and just trust me).

Speed tests don’t account for when (general) rules should be broken

For example, the stupid complaint about items not being browser-cached or having too short of an expiry times. YES! Some of those items are SUPPOSED to be like that. Some items are SUPPOSED to be uncacheable and have short expiry times to keep certain content always updated.

Render-blocking CSS – I’m gonna flip a car next time I see this complaint. CSS SHOULD be render-blocking. Do you guys know what happens when you don’t render-block with CSS?…you get FOUT/FOUC issues! Trust me. It’s on purpose!

5. Speed tests are flawed.

Yes, they are flawed and many users don’t even know! They make newbie users feel bad about things they can’t or shouldn’t change. I’ll list some examples below:

Outdated recommendations

Speed tests are still not properly accounting for modern day web-server technologies. I still see many recommendations that were faster with older web-server technology but actually slower with today’s web-server technology. Things like recommending GZIP when Brotli is being used (FYI: brotli is better than gzip), or recommending to reduce HTTP requests when HTTP/2 protocol allows for parallel requests!

Penalizing for 3rd-party requests

I absolutely hate when speed tests point out the slow load time, lack of cache expiry, or encoding for some externally-loaded request. These items are loaded from ANOTHER SERVER, from which you have no control. It ain’t your fault and speed tests should have a way of letting you know this. And just FYI, some externally loaded requests are not cached or otherwise “optimized” for a reason!

6. Almost all speed tests fail THE EYE TEST!

What is the eye test? It’s basically testing the site for yourself with your own eyes. If the site visually loads fast, you are fine! No need to worry about the “total load time” because those things loading in the background aren’t actually affecting your user experience. BOOM! Drop the mic!

The EYE TEST should be the very first page speed test you ever run. And then the next one should be using your browser’s developer tools function to see how fast everything loads in your actual browser. This is as close to real world times as you can get!

Tell me which site would you prefer to have…one that fully loads in 3 seconds…or one that fully loads in 6 seconds? (answer this before moving on)

• What if I told you the 3-second site is completely blank and doesn’t render until the 2.8sec mark, whereas the 6-second site appears instantly and then silently loads the less important stuff in the background?
• In case it isn’t obvious, I would pick the 6-second site every day of the week. And so too would all the big Fortune 500 companies…in fact, many of them take several seconds to fully load (despite visually-appearing almost immediately)!

This is the kind of shit I’m talking about. Many speed tests don’t account for this. And even when they do list important metrics like initial rendering times, naive users don’t know to look at that! All they care about is that stupid TOTAL LOAD TIME number (sometimes accompanied by some scary warning message).

7. Addressing common myths and rebuttals.

As always the case, clients come up with logical assumptions and questions:

“Having a fast loading site or high speed score is important for SEO.”

Not really. Unless your site is super duper slow, that saying is pretty much false; it’s not even a myth. You can verify it for yourself by researching the top 10 results for random keywords. It’s not uncommon to find top results taking 3-5 seconds to load (according to page speed tests).

With that said, having a fast website can improve user engagement and conversions and I do believe that helps SEO rankings somewhat. Regardless, speed is great for conversions!

“You cannot have a good/fast site without scoring an A on page scores!”

Says who? Try looking up many of the most popular sites you know and see what they score for yourself. Heck, try even Google’s web pages against their own GPI tool.

“If speed scores don’t matter, why do they exist?”

They exist as a helpful checklist for those that know how to read them. Some things matter, and some things don’t.

“Why is my competitor’s website faster and scores higher than mine?”

That could be due to many reasons. Many they have a faster webserver, or more efficient coding, or fewer plugins, or fewer assets loading, or fewer 3rd-party assets loading. Just because you installed a cache plugin or hired a speed optimization expert doesn’t guarantee your site will be better than your competitors.

“But the other day, I installed some other plugin or worked with another person who improved my site score to 100/100.”

Suit yourself. Yes, it’s possible to get 100/100 if you don’t care about anything other than the score, but you might inadvertently slow your page load or hinder your user experience in doing so. At the end of the day, those page score recommendations are simply RECOMMENDATIONS…they are not empiric instructions to follow for every scenario.

“I DON’T CARE WHAT YOU SAY! Make my site fast and with A+ 100/100 score!”

Sure. Just delete all your plugins, use a simple theme. Don’t have more than 10 images. Don’t use Google Analytics or Google webfonts.

“But those speed tests are so scary! How do I know which things to fix and how to fix them?”

It might help to take your time reading and learning how each one works. Maybe work as a web developer for a few years. Or you could hire someone with more experience than you.

Still want to optimize all by yourself?

• Read my guide – How to optimize for Google Pagespeed, Pingdom, and GTmetrix