Photo of cheetahs considering optimizing their Joomla site by James Temple used under CC Attribution 2.0. license. Flickr: https://www.flickr.com/photos/jamestemple/312324961/sizes/o/
When we build a website on a content management platform like Joomla, Drupal, or WordPress, we are taking advantage of a sophisticated web application and all the built-in functionality it offers. And, we have to accept that as consequence of using these applications we are adding to the functioning complexity of our website. This becomes increasingly so as we add extra functionality through third-party extensions, plug-ins and widgets!
The law of diminishing returns
The reason for losing some control over our code - and therefore the ability to completely optimize our site - is to do with time and money. It simply may not be cost effective to re-develop the CMS or the extension code to comply with some optimization rules just to get those final few points to reach 100%, and make Google PageSpeed very happy.
Perceived speed vs optimization rules
Even though our website may not have a 100% optimization mark from Google, we can console ourselves with the fact those final few points needed may not make the website any faster. And, this is what really matters for the users, that the website loads fast and they can navigate it quickly.
In fact, you can optimize a site to achieve a high mark but it may still take over 10 seconds to load the home page because the web hosts server takes 8.5 seconds to respond to the initial browser request. In this situation a user would not care how well the website conforms to optimization rules. They will not wait around. Compare this to a site that loads in just over 2 seconds but is 84% optimized.
This is not say that optimization is not essential, something nice to have but nothing to worry about. We think it is essential, particularly when optimization reduces the host and user bandwidth usage (especially relevant for mobile devices), as well as improving the overall performance of the site.
The reason behind the unexpected scenario mentioned above is that website benchmarking applications do not heavily penalize slow servers. For them, what really matters is what happens after the hosting server responds and the site files starts to load.
But, it is worth bearing in mind that we need to have a balance between user perception, adherence to guidelines, cost effectiveness, and the benefits we derive from using a CMS to build our site. We need to be pragmatic!
The rule sets used vary slightly between these benchmarks and each has its quirks: YSlow! is quite adamant that everyone should be using a Content Distribution Network (CDN) and will penalize heavily if they don't.
Google PageSpeed (GPS) has two sets of rules: for mobile devices and desktop. Mobile devices section also looks at usability, making GPS our standard benchmarking application.
GTmetrix uses Google PageSpeed and YSlow! but it seems to use a different rule set as we always get a higher mark on GTmetrix for both those benchmarks than if we test them individually.
However, GTmetrix and Pingdom provide a very useful waterfall chart showing the sequence of the files being loaded and how long each takes:
To provide examples for our discussion, we used Google PageSpeed and GTmetrix on the un-optimized KandyTech website. It is up to you or your client to decide which benchmark to use and stick to it!
In the second part of this series of blog posts we will be discussing the absolute basics of Joomla speed optimization.