GTmetrix reports in the real world

Site speed is all the rage

You may have noticed that site speed has become a popular topic of discussion lately. It’s something I’ve written about before and still something that’s an integral component of a great website. One of the tools I mentioned in my previous article was GTmetrix, a site-speed measurement tool that incorporates measurements from Google Page Speed recommendations and YSlow, both based in a letter-based scoring system (A being fast, F being slow).

Generally speaking, GTmetrix scores represent a “blue sky” scenario, meaning the aesthetic of the site was designed purely for speed and does not take into account other business interests. It’s not hard to achieve a great score on a simple personal website, however, on a complex site with a robust Content Management System, large media files, and multiple plug-ins, it becomes significantly more difficult. Most projects are built upon existing frameworks or code libraries that decrease development time – but they’re not as lean as a custom solution. Unfortunately, a custom solution is not always suitable for time and budget constraints in the real world.

Site speed is made up of many complex technical issues, and this article is not intended to address everything in detail. Rather this is a very general overview of some of the common issues I’ve seen in the context of lowering speed scores during our QA process.

Here are a few reasons why your score may not be accurate:

Plugins

To extend the capability of CMSs (boy did we have a good debate about how to punctuate that!) and customize it to clients’ needs, plugins are regularly used to speed up the development process and meet budgetary constraints.

Unfortunately plugins don’t usually put their JavaScript at the bottom of the page, and some inject unoptimized code into certain areas (even if they are a very useful plugin). This reduces your grade in GTmetrix. Unless you have the budget for your developers to custom build or modify all plugins used, this is something you have to live with. Basically it’s a trade-off between development time and the site-speed score.

Images

With the increasing popularity of responsive design, and designs that incorporate large image in backgrounds, it is not always possible to serve up scaled images. This will hurt your speed score, but the goal is to strike a balance between visually stimulating sites and less visual (but somewhat faster) sites.

Furthermore it’s not always possible to specify image dimensions in HTML when creating a responsive layout. This will hurt your speed score, but you have a site that optimally displays for all screen sizes.

CSS

Plugins often come with built in CSS that’s not used on all the pages of your site. If GTmetrix detects unused CSS, it will negatively affect your speed score. This impact on the speed of your site is trivial – but it hurts your score.

Efficient CSS selectors

With the increasing popularity of CSS preprocessors like SASS or LESS (development tools that help the maintainability and organization of stylesheets), the code output is compressed, lean, and fast. However according to GTMetrix parameters, the code is not optimized – so the score will not likely fare much better than a D. It will likely be an F on complex sites. Even the creators of GTMetrix get an F on this one. So there you go.

JavaScript

Defer Parsing of JavaScript

There are different thoughts on this, but genrally deferring parsing means that you don’t use JavaScript until the user interacts with an element on the screen. This could slow down the interactive experience, albeit not by much.

What is commonly done is to put as much JavaScript as possible at the bottom of the page. This means the contents of the page can load without waiting for JavaScript to load. The JavaScript is loaded last, thereby not affecting the page content. And it’s ready when the user goes to interact with an element on the page that requires JavaScript.

An appropriate metaphor here would be waiting in line at a cash register. If you don’t have your money out until you reach the cashier (deferring) then you slow down the checkout process, whereas if you have your money ready when you reach the cashier, the process is faster.

CMS

User generated content

While steps can be taken to make sure user generated content such as images are compressed properly, this may not always be the case. There may be injected code from photo galleries, or images that didn’t get compressed as well as they could’ve been.

Global Code

There will be code that applies to the whole site – but may not necessarily be used on the page that is being speed tested. If GTmetrix detects unused code, it will hurt the speed score. However it’s better to have fewer HTTP Requests – then cache that code for later use – then have minimal unused code on every unique page.

Conclusion

GTmetrix is a great tool to measure speed, and the proper use of the GTmetrix reports can help you shave off page load time. There are a lot of factors in the website and application development process – business, aesthetic, technology – that affect the feasibility of implementing its recommendations at face value. Although GTMetrix is a helpful indicator of what can be done to improve speed, every recommendation cannot be generalized to every project.