Why Page Speed Matters & PageSpeed Insights Fails – A Developer’s Tale

Note: Check out our Ultimate Guide to page Speed for a top-to-bottom look at how you can improve page load times. You can also take a look at our page speed optimization services, if you’d rather we did the work.

At this point, anyone who browses, manages, and/or creates websites on the regular, should know that page speed matters. So.. everyone. It’s no surprise that we demand our information fast, like right meow. If this is a new concept, you are lagging far behind. I believe the majority of users understand this but are still figuring out how to accomplish it. In this post, I answer why page speed matters to me as a senior developer, why the entire scope of the web application should be addressed to garnish the full potential, and why Google PageSpeed Insights is a thorn in my side.

Why page speed matters — a developer’s perspective

A colleague of mine asked me why page speed matters from my perspective. My first reaction was, “Because I want a super-fast user experience on every site I visit, just like everyone else.” For me, and I’m sure most others, it’s an intuitive response. I haven’t run the scientific numbers on this, but I’m pretty sure that if you surveyed 1,000 random people on whether they wanted faster loading websites or slower loading websites, 100% would choose faster loading.

So, why aren’t more sites fast? I’m sure it is any combination of reasons. Lack of budget, resources, knowledge, and/or know how. Perhaps laziness. Maybe the company they hired isn’t looking out for them like they should. Hmm… maybe. That got me thinking because it makes way too much sense. As a developer, I’ve been through the process countless times. The big site application that takes months and months to plan, develop, test, and release — and when it’s done, there is that feeling of wiping your hands clean and moving on. Was page speed and optimization baked into the plan? Too many times it can be an after thought, and probably still is in much of the web dev world.

Not Portent’s web dev world, however. It’s been an important part of our process for years.

And the more I think about why page speed matters from my perspective, the more I reflect on that process and think, “because it matters to our clients.” Whether or not they’re aware of its importance when engaging our partnership, it is one of the core subjects analyzed and discussed as the foundation level of the marketing stack, and one of my principle responsibilities at Portent.

So, let’s hunt our prey. Hmm, seems a bit much. Sprint to our goals? Corny. I just wanted to tie in a cheetah for a post on page speed (because they are awesome) while we transition to take a closer look.

Look at the entire scope

Getting great page speed isn’t just about implementing a few one-off recommendations you found on Google PageSpeed Insights. In fact, PageSpeed Insights can be misleading and confusing (more on that later). You have to look at the entire scope of your application, from your hosting environment to the front-end output.

Potential is in the combination

Most of the site speed analysis tools out there today are only able to focus on the front-end, or output of your web application. They analyze the source code, the time it takes to load all assets, resource optimization potential, and others. They aren’t able to see your environment setup and its configuration — for good reason, because that would be a major security hole. Granted, some of the metric results from these tools (like latency and time to first byte) will show issues that are directly affected by the environment, but they can only go so far. Regardless, you will not see the full potential of your application’s loading speeds until you have addressed both environment and application optimizations.

Compare your website to a car. You can make all the cosmetic changes you want to make the vehicle (front-end output) look pretty, but if the engine (server stack) is sluggish, or isn’t getting enough fuel (bandwidth), the overall performance still suffers. The stack technologies carry a heavier importance. If your PHP (or Java, Python, Ruby, etc.) threads are taking 5+ seconds to process the request and output browser code, you’ve lost the battle already.

We strongly advocate looking at the entire scope of the application, but if you have to choose, put your money into the environment — it will go further and still allow for front-end optimizations to be made later and/or with less effort.

A rant on Google PageSpeed Insights

Recently, our dev team was sent some feedback about our site’s grade on Google PageSpeed Insights from a guest at a seminar Ian was presenting at. I did some digging and comparison with other tools and simply put.. got pretty annoyed.

I’ve spent a LOT of time optimizing our environment and application as a forward facing example of the product we can provide to our clients. I have made great improvements that consistently provide visitors with sub 1 second load times on all of our pages. First time, first page visitors may see load times from 1.5 – 2.5 seconds, but after that, it’s all sub 1.^[1]

However, if you ask PageSpeed Insights, we’re flunking. I don’t know who at Google came up with the scoring algorithm, but they can bite me.

webP detection

Blake and I recently implemented our lazy loading, responsive image solution on portent.com, which also includes webP support. webP is an image format developed by Google that employs lossless and lossy compression, reducing image sizes by approximately 25%.

Ironically, Google’s web-based PageSpeed grading system isn’t recognizing it:

Google’s PageSpeed Insights extension for Chrome, however, is — which is funny because it’s technically been deprecated:

And if we take a closer look at the HAR (HTTP Archive), webP images are being served where applicable:

Leverage browser caching

Often, your site is at the mercy of 3rd party analytics software. It’s a balance between using tools that help analyze and provide insights, and keeping bloat to a minimum. Google PageSpeed Insights is docking us for their own software. Perhaps they should consider putting an expiry date much further in the future.

Tiny minification improvements

I’d also like to know how much weight is put into the grading algorithm for 2% reductions in minification:

A combination of tools

It’s unfortunate how much weight gets put on that PageSpeed Insights grade. Clients refer to it. Potential customers look at it. It is a misrepresentation of how their site is really doing. I’m not saying it’s not helpful. Actually, let’s back up at tick — I don’t think the grading system is helpful. Analyzing the recommendations provided can be useful, but take it with a grain of salt and use other tools for your analysis!!

Look at tools that give a waterfall analysis, like Pingdom and Web Page Test. Use the browser console (ctrl+shift+j) and analyze the ‘Network’ tab. Combine the results and come up with a game plan for tackling the highest priority items, which are usually:

• leveraging browser cache
• optimizing images
• combining and minifying javascript and css

In Summary

Take site speed seriously because it affects your conversion rates. The market is getting more and more competitive — don’t think for a second that a potential customer won’t leave your site in search of a better competitor’s. Press your development team to make site speed a priority. If they avoid it or shrug off its importance, hire us, and I will personally analyze your current setup, design and implement your environment stack, and optimize your application so your site can reach its full site speed potential.

1. Results may vary for visitors outside of North America. ↩