Country Baskets Website Health Check
It’s a pity we didn’t meet Country Baskets director before they embarked on their new website design. When they came to the Glasgow Website Designer, they had already been over-charged for careless, low quality coding. The director could see that something wasn’t right as the pages were taking way too long to load. Something was fundamentally wrong and a quick health check was required. GWD were called in and quickly employed.
These days, site speed is one of the first and most important aspects of a website as Google is looking to rank sites which provide a good (fast) user experience to its customers. From a Google perspective, if your site takes longer than five seconds to load then it will be ranked lower in search results. It’s a very important factor and it’s just as important as good, unique content. If a website loads slowly it means there’s sloppy coding in the background and Google will definitely penalise a site for this. It’s a red flag to Google bots that the site is not giving that ‘good user experience’ they seek.
We looked at several areas and we discovered quite a lot of obvious mistakes which were causing the lag. When their developers addressed the issues below, the home page and product page load speeds increased dramatically. We discovered some very concerning issues and much of it was very basic. Looking at the fundamentals, it really beggars belief when we learned how much they paid for their new website.Based on some simple analysis, here are the main areas of immediate concern:
- Incorrect Use of H Tags
- Expiry Dates For Static Resources
- Combine all JS and CSS Files into One
- Compress Images Across Website
- Load JS In Footer
- Server Side Compression
- Server Side Compilation
- Magento Inherant Issues:
Incorrect Use of H Tags
We took a quick look at CB source code. Something we always look at when we analyse a website is the H1 and H2 tags on the home page. Usually what we see when we look at these tags are signs that the site has been built without any consideration for search engine optimisation. Most coders don’t know anything about SEO and they will admit that if asked. It’s a fundamental mistake with most websites. The developers consider SEO to be something that you can just tag on at the end. What they should realise is that SEO is the foundation and all other aspects of the site should be designed around good tags and good search engine structure. What good is a website that doesn’t harness the full potential of search engines? Isn’t this the main objective after all? To be found in search results?
We were sorry to report that Country Baskets H1 tag was “country baskets” and their H2 tags are “Welcome…..”, “Inspiring Creativity“, ”Christmas is here”, “Brown”, “Home Page”. The H1 tag is the first thing that Google looks at when it lands on any page. Google looks at the H1 tag and asks, “what is this site all about”? The H1 tag should be the main keyword phrase and the H2 tags should be sub-headings that define then main features. H1 and H2 tags must be utilised to communicate to search engines, sort like the title of a book and it’s chapters. Unfortunately, CB developers were using them as CSS styling to control the fonts. Big mistake, very elementary and very costly to CB and their business. We are great fans of analogies and it’s like building a house with no foundation.
So, why were their H1 and H2 tags being used as CSS styling shortcuts? Because most developers know nothing about SEO and they use H tags to make fonts look nice. Is this unforgivable? Definitely!!
As with JS, css files must be minified before uploading to any website server. We had to ensure it used less bandwidth to download. Here are the list of CSS files that needed minified versions:
Expiry Date For Static Resources (enable browser caching)
All static resources such as images, CSS and JS files need to have an expiry date set to some time in the future. This stops browsers from constantly requesting the same resource until that expiry date is reached. These static resources will then be cached by the browser and it will not be flushed from browser memory until the expiry date. Below are the static resources that required an expiry date:
We had to combine all of the JS files into one file so that there was only one request for all the JS files. This helped dramatically and an instant improvement in the site loading speed was apparent. Here are the list of JS files that had to be combined:
As with JS above, we had to combine all the CSS files into one to reduce the number http requests for any page (hence reducing the site loading speed). Here are the list of CSS files that had to be combined:
Compress Images Across Website
CB had images on their website which were not compressed. This was pretty alarming as it’s just unacceptable for tiny thumbnails images to be 498kb! As a general rule of thumb, no image should be greater than 50kb on a website as it will dramatically slow down your load speed. This is really elementary and it was hard to believe that a professional developer would not notice this, especially since the client was complaining about load speed. We were really astonished by this. It was no wonder the homepage was taking thirty seconds to load when tiny images were 600kb!! It felt like the site was produced by someone who know nothing about websites. Here are the images that required compression (all just on the home page alone):
We had to load the new, combined and minified JS files in the footer. Originally, these were loading all over the header and body part of the website which was slowing down the load time for other (visible) elements in the page. Basically, JS requests were blocking other resources until it was fully downloaded to the client side (browser). It’s always best to load JS in the footer of the web page so that everything else loads first and it does not block any of the other static resources (more elementary stuff here).
Server Side Compression
In addition to above fixes, we had to ensure they were using gzip to compress all of the static resources which in turn reduced the amount of time it took to download to the client. They were not using gzip so something was seriously wrong with these developers. Using gzip reduced their site loading time considerably.
Server Side Compilation
With access to the back end of the site and a communication line with their host, we confirmed some settings and enabled compilations in the server side and in admin side which increased the server performance. We did this by compiling the php files and going to:
System -> Tools -> Compilation
Magento Inherent Issues
Magento doesn’t have a good reputation for speed, yet it’s usually the first choice for medium to large developers. This is because it has a fantastic set of tools, so from a development point of view it is very slick with tons of built in features to make life easy for them. From the clients perspective the downside is that it can be inherently slow. If Magento is not configured and tweaked correctly and if your sever isn’t configured to handle it then you will experience some lag. It’s a common problem and one that we have encountered on a few occasions now.
In conclusion, there were some really very simple fixes for their website load speed. We could list more such as non-use of image sprites, the over use of inline CSS and sloppy html markup. However, we really had to address the basics, above. Overall site speed was reduced right down to less than five seconds (faster than the Google recommendations). This is a good example of how our basic website health check can improve an existing website, dramatically.
Learn How Glasgow Website Designers Can Health Check your Website
Call: 0845 643 9323
Quote Request: Tell us about your website requirements.