History

Page speed has always mattered. Ever since the first web page was built, the size of the data that was sent to the browser has always had an impact on how the user interacted with and enjoyed/disliked the site.

Over time many things have had a direct impact on the bare HTML and images that are sent to the browser. There are compiled and ever expanding CSS files for design, external JS files and libraries for interaction, tracking scripts, marketing automation forms and libraries, external CDNs for images, as well as third party APIs for targeting user personalization.

What we see now in a modern website, is structure coming from the main website domain but many layers of tracking, social interaction, and marketing interaction coming from a multitude of external third party domains that drive up the overall cost (ie page weight/speed) of the page in the browser.

Here comes mobile

With the ubiquity of mobile device browsers came another explosion of additional CSS for mobile specific design code as well as interactive Javascript elements specifically tailored to the mobile user. Because of the limited mobile bandwidth this also had the additional consequence of Google and other search engines tailoring certain search results for speed.

Google has also tweaked their Google Page Speed Insights and LightHouse page speed projects to throttle the page being tested to simulate a 3G mobile network call (3.1 mbps) by default. This means that what Google is really testing is how a user with limited bandwidth is experiencing your site. This default bandwidth applies to both the desktop and mobile experience numbers in their report.

When the number is not the number

Everyone would like to score 100 on a page speed test for their site. What is not really known are the variables that make up how the test is run even before it starts to look at your site.

Here are just a few things that have an impact on your test that in most circumstances you are not in control of.

Where the test is being run FROM and where your site is located

If the test being run on your site is running on a server in Vancouver Canada and your site is on a server in Virginia the number may vary as the network deals with latency and hops over that distance as well as specific DNS issues related to each URL. Sometimes this distance is taken into account and sometimes it is not. Which is why it is good to get a range of numbers from different products and compare.

What throttling or “specified degradation” the test is using

Certain tests by default use throttling to simulate 3G or 4G networks or “Worst case scenarios” but may not give an accurate picture based on your actual browser analytics from the site. If your users are mainly desktop users with a fast connection, getting a site speed score based on a throttled 3G mobile user does not benefit your site speed understanding.

What site assets are under your control and what are not

A majority of site speed scoring downgrades are based on assets that are not in fact under your control. If you have already decided to use Twitter and Facebook integrations, forms from Marketo or other marketing automation as well as analytics from Google and other sources, you will find that these are in fact the main cause of your site speed scoring problems. What you can do is get a site speed score with these integrations and then get a site speed score with the URLs blacklisted to get an actual site speed score for comparison.

Trade offs

The fastest page will always be the one that has almost nothing in it to cause speed problems. But as with most things on your site, your speed score is a trade off between functionality, data, usability and business requirements and the performance costs that these entail.

If you use a CMS (content management system), this makes it easier for your employees to create and edit content, but it comes with some performance costs inherent in each different CMS platform. It requires diligence to mitigate these issues but they will never fully go away. Are they worth it? In our experience, Yes! But each organization has to make a business decision based on it’s own experience and use case.

Getting visibility into your site’s visitors and traffic is crucial to understanding and adapting your site’s content and offerings, but too much data from multiple sources and platforms can have unintended consequences for your site. Each new tracking script and tool should be tested and implemented with care and audited regularly. That great new A/B testing platform or heatmap tool seems like just the thing until you’re no longer paying attention to the data or the person who was, is no longer there and no one can remember why it’s on the site to begin with.

Own your page speed score. Each feature on your site has a corresponding page performance or engineering cost and some of these you can offset and some you cannot. You can get around certain page performance costs of a specific marketing automation platform by building your own custom API implementation but in doing so what you have gained in page speed you might have lost in ease of use, sustainability and development cycles. To some it may be worth it. To most it is not. So when you see that little ding in your page speed score because of certain corresponding features you can know that is a trade off you will gladly make for the business benefit it affords.

Conclusion

• Pay attention to your site’s speed score but temper that attention with a meaningful goal of improving your site’s performance based on the feature set and development environment that your site requires.
• Choose a page performance tool and test and annotate regularly. We recommend tools like GTmetrix.com, sitespeed.io or custom implementations like the command line version of sitespeed.io with Grafana.
• Train staff to be conscious of page speed. Most short term page speed problems revolve around image size and use around your site. SVGs are great, but sometimes an overly complex SVG is even worse than a simple image.
• Be skeptical of too many tracking scripts. These are the cause of most site’s long term site speed problems. It’s not just the one tracking script, it’s the three others that it loads as well as the associated assets requests and header cache settings.
• Audit your site’s usage of its tools and libraries regularly. There is almost always a better way to build, compile, load, and serve your sites content.
• Page speed is not a single time event to check off your list. When you build the site or when someone decides to visit Google PageSpeed, it is a constant and rigorous approach to your site development process.