I must confess to have slightly struggled with the title of this blog post, as I didn’t wish to be responsible for encouraging unnecessary complaints and animosity between clients and web designers!
However, I have all to often witnessed situations where a web design company (or web designer) will not be implementing recognised ‘best practice’ (either through a lack of skills, or out of sheer laziness), and will conveniently ‘hide’ behind the belief that a client is highly unlikely to spot poor architectural design!
Well, here’s the truth – you don’t need to be a technical web expert to spot some basic poor development practices.
Indeed, if you can use a browser, and have a basic understanding of how a webpage works, then you can easily learn a few tips, that will help you challenge your designer / developer.
What this post will not cover
Just to clarify; this is not intended to be a deep-dive technical article on the inner workings of speed, performance and optimisation in modern web design (for that, there are plenty of other resources and gurus to be found on the internet, with far greater expertise than me).
This post will primarily focus on:
- Page size and loading speed.
- Optimisation / placement of components and scripts on a webpage.
Why only these?
Aside from not wishing to provide bedtime reading material for potential visitors, IMHO, I believe these basic factors are a good tell-tale benchmark as to whether a developer has good or poor understanding of modern web design architecture; it could also have a significant bearing on how Google will rank your website in search results (Google now use site speed in web search ranking).
One final point before we start – don’t be too critical!
Most organisations nowadays, require the ability to update website content themselves – enter the CMS (Content Management System). The CMS is excellent on so many levels, but it does have the problem of needing to be ‘all things to all people’ – as such, even with the best software engineers and designers in the world, you will almost certainly end up with a system that carries an element of ‘bloat’.
Unfortunately, it’s a bit of a trade off; flexibility verses efficiency. However, it still shouldn’t be used as an excuse for poor design architecture. The goal, is to aim for perfection with the understanding that this is not always going to be achievable – be questioning, but also realistic.
(There is an assumption that very basic web design protocols are already in place (correct use of Headers, Keywords and Meta Tags etc) – if your web designer isn’t implementing these, then you may as well give up now )
Ok, let’s get to the meat!
- If you haven’t done so already; go download, and install Google Chrome from here.
- Once installed, go and grab the Chrome version of YSlow from here.
It’s worth noting that there are alternative options to these developer tools for other browsers (e.g. Internet Explorer and Firefox etc) – but at the time of posting, I think it is fair to state, that the Chrome Dev Tools are currently recognised as the better choice.
You should pretty much now have all you need to analyse your website in detail.
Page size and loading speed
It stands to reason that if your page size if too large (in file size), then it is going to take a lot longer to download and display, clearly having a negative impact on your customers (as well as your search ranking).
Ok – open up Chrome, visit your website and then click on the ‘YSlow’ icon which you should see located at the top right hand side of your Chrome browser window.
You will then be presented with the ‘YSlow’ dashboard – similar to the below screen shot.
Click the yellow ‘Run Test’ button.
After a brief delay (status indicated by a progress bar), you will be presented will an array of information on the YSlow Grade tab (this tab also includes a general overall webpage grading score; you are ideally aiming for an ‘A’ grade here).
However, leaving the Grade tab alone, if you click on the Statistics tab – you will be presented with two pie charts, visually detailing the size of your web page.
One of these pie charts will be the initial page size, whereas the other will be the cached page size – which basically means the page size after someone re-visits your website (this should be significantly less than the initial page size – if it isn’t, then your web developer needs to investigate the ‘caching’ options of the website).
Real world example:
The below screen shot was taken from a website that initially had huge performance loading issues. You will note that the page size (total weight) is nearly 2MB, and the cached page is much smaller at 600K - (I should mention that this had previously been significantly worse, weighing in with a 5MB initial page load; alas, I no longer have a screen shot of the initial check).
This test was enough to present a justified concern to the company. It’s still quite large, but arguably acceptable for a CMS – or not?
The below screen shot was taken from my own website – which I’m not claiming to be a masterpiece by any means, but purely as a reference point, you can see the initial page load is only 412K and the cached page size (remember, that’s the one that gets loaded again after an initial visit) is actually 0.0K!
Incidentally, it also scored a Grade A, which I was quite chuffed about!
Before we leave Page Size – it’s worth noting that HTTP Requests are also very important. If you view an HTTP Request as a ‘trip’ to the server, then the more ‘trips’ you have to make, the more work the browser has to do, the more power it consumes (this can even drain batteries on mobile devices), the slower the page loads – well, you get the idea!
So you need to keep your HTTP Requests to as few as possible. Again, look at the charts above for HTTP Requests – I think you will agree, there is quite a difference
(Disclaimer: please be advised that the above website stats are not a scientific ‘like with like’ comparison, but do serve a purpose for blog demonstration)
Optimisation and placement of scripts
This secondary test is arguably slightly more involved than the page size inspection, but can still be very easily performed, using the magic of Chrome developer tools.
Ok – open up Chrome, press the ‘F12’ key on your keyboard and visit (or refresh) your website - you should then be presented with the Chrome Developer Tools, similar to the below screen shot.
Be under no illusion – options for the Chrome Dev Tools are vast, and I would encourage you to investigate them further – however, for now, we are just looking at individual elements being loaded onto the page.
This initial view shows you individual items being loaded by your website; indeed you may recognised some of the pictures. It also provides you will a useful ‘Timeline’ indicator, detailing how long each element is taking to load!
In another real world example, here I spotted a jQuery script being loaded onto the webpage twice (for no logical reason) – a small, but nevertheless poor mistake - again, this was enough to present a justified concern to the company, who surprise, surprise, removed the duplicate!
This obviously makes the download page size smaller, but also reduces those all important HTTP Requests!
Quick note on page blocking
A final, but important point to mention, is the placement of scripts.
However, my goal wasn’t to write an exhaustive article about poor web design in it’s entirety, but simply to encourage the layperson, to look at their website with a more ‘technical’ eye and have the confidence to question legitimate poor practice; and where relevant, challenge their web designer!