On the introduction page, we looked briefly at http requests and how they can slow down your page. So let's examine a few simple things that we can do to optimize these. If you haven't read that page then perhaps it might be worth reviewing it before you read this one. Click here to read about pageload speed.
Before you go about making improvements to any pages, it is best to have a baseline for comparisons. It really doesn't matter which speed test site you use, as long as you use the same one for future tests. I personally find pingdom.com to be as good as anything.
What I want you to do, is to take a look at all the script tags that you have in the <head> section of your pages. The homepage in particular. Look for the ones that go off your website, as well as the ones that reference the support-files folder.
And then ask yourself this. "If this was to be moved to the bottom of my page, would it stop my page working correctly if it didn't load before the readable content?"
Another example is the EU cookie script. How many of you have placed this in the head section? Put that in the footer and it will still give you that cookie notice. But the usable portions of your page have now loaded just a little more quickly.
How I handled the image gallery on my homepage.
If you have visited the homepage,then you will have noticed that I have an image gallery on there. Click any of the thumbnails, and the gallery will open. That is a fairly standard form of showing a portfolio with any designer, and even though something like this will slow the page-load speed down, we can at least take steps to make it as quick as we can manage. Here is what I did...
There are 2 script tags required, plus a style-sheet. Firstly, the tag that calls jQuery onto my page is required to load before the actual gallery otherwise it won't work. So that has remained in the <head> section, but with the addition of the async property.
What is ASYNC?
To add this to any script or style-sheet tag, simply type async into the tag at the end. If you aren't sure whether this will affect the page, do test to ensure it works as it should. Note, that you must have a src attribute, not an href. That means it's only useful for http requests that are being made to a different website than your own.
The following are some of the most commonly used of the worst offenders. Many of them make multiple HTTP requests (Pinterest for example). Every bit of rich content needs to be weighed up. Does the user experience with them outweigh the performance hit? And if the answer is yes, I need this, then can we at least make them more efficient?
The following are in alphabetical order.
Adsense is actually reasonably efficient. And even if it wasn't we can't do a whole lot with their code to improve matters. However there is one tip that a lot of you won't know.
Have you noticed that when you generate an ad unit, you get the exact same script given to you as part of the code to paste into your page? It looks like this...
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
So if you use 3 Adsense blocks, then you are requesting the same script 3 times. In fact you only need it once per page. One request versus 3, multiplied by however many pages you use Adsense on. That's a lot of extra requests that aren't necessary.
I have seen websites that simply will not load because something is wrong with their Amazon code. The page stops loading while the code is retrieved, and when it can't be downloaded, the page display is incomplete. It will remain that way until either Amazon fix things up at their end, or you remove their code.
I can only give you 2 bits of advice regarding Amazon (or Shareasale, or any other company that uses the same type of widgets to display their products).
The first would be, try to use in text links if possible. Apart from the performance gains, they convert better anyway, so a double win for you!
And the second is to use <iframe> if it's available. That way, if the Amazon doesn't display, only the iframe will be blank, not your whole page.
AddThis (and the closely related ShareThis) will often to be the biggest drag on your webpage performance. They are seriously bad, and people tend to go overboard with them. Not content with a simple set of buttons, they start adding more and more widgets. the "related content" for example.
My best advice is unless you absolutely feel you need the extra tracking and data logs that AddThis provides in their dashboard, get rid of it and just use the SBI equivalent! That is far more lightweight and efficient although it doesn't have as many fancy options and choices. But really, what more do you need than to give people an easy way to share your content on their favorite Social Media site?
Talking of which, some people are particularly prone to overdoing buttons and links to Social sites. It's not uncommon to see at least 3-4 ways to communicate with Facebook on a page, several twitters, multiple pinit buttons, Google +1 buttons and widgets, all topped off with the SBI "Socialize It!" which is often just a duplication of the buttons already on the page. It's overkill, it's unnecessary, and it is possibly the single biggest factor when it comes to a slow pageload speed.
I have worked on clients websites that have had over 150 HTTP requests from every page, just to social media. That is ridiculous. But here's the funny thing about it. After stripping down the pages and removing the unnecessary duplication, not only did the performance increase significantly, so did the shares to Social Media, even though there were less buttons.
How many Facebook Like buttons do you have on each page? Go ahead, count them.
1. Well done, if it's nicely positioned then perhaps that's all you need.
2. OK, so maybe 2 is acceptable. One at the bottom, and another in the Socialize It widget.
3. I have to ask... why, what benefit are you getting?
4 or more. Are you beyond help, or do you think some counselling might be in order?
The other big sucker of page performance is comments. Sure, we want engagement, and comments is a good way to get it. Every site needs a good social profile these days. But it's a trade off. The more social widgets we have, the slower the page is going to be.
If you are using SBIs' FaceIt! module, then you probably have comments on every page, assuming you selected that option. But the fact is, not every page needs comments on them. So... have you taken the time to go and close the comments sitewide dot on those pages? If you are like most of the sites I've looked at recently, then you haven't. Shame!
While I like to encourage engagement too, a comments block on my contact or privacy page seems rather pointless. I bet that there are other pages on your website that have no comments on them, and probably never will as the content simply isn't something that people get inspired to discuss. Why not remove comments on those pages as well? Closing a sitewide dot on a page does more than just hide the contents of that dot. It removed the content from the source of the page so you don't waste time loading it and then not displaying it.
Ah yes, jQuery. This can be a double edged sword. While it can definitely improve the visitor experience (I use jQuery to run this tabbed box for example) it can slow the page down. But even if you go mad with it, the performance hit will probably be less than a "social button freak" that has peppered their page with buttons and widgets.
All the same, if we observe some of the best practices mentioned on these pages about speed, we can have our cake and eat it too. Or in my case, have my tabbed box and read it too.
What I did was ensure that the jQuery call was placed on this page only. No need to make people visiting other pages download a script that they don't need. That was the first thing. I only use a very small amount of css for the tabbed box, so that is placed in the head section rather than a style-sheet.
And finally, there are two jQuery scripts required. Those can be downloaded rather than referenced from the host site (that's 2 less offsite requests) and combined into one script in my support-files. Result: this page loads nice and quickly, and you would be hard pressed to scroll down the page fast enough to see the tabbed box before it was fully functional and looking nice.
These fancy Pinterest widgets are very tempting. All those lovely thumbnails, it can be hard to resist putting one of these on your page if you have a website in a photogenic niche. In fact I have used them myself... but the performance hit is pretty massive.
This is another of those things that you have to weigh up the pros and cons. Is having the widget worth slowing down your pages? This one makes a heap of http requests. You might like to make a slight compromise as I have done on my own roses website.
What I did was installed the widget on my site, and then took a screenshot of the result. I then created an image of that which I placed on my page in place of the widget, and linked that to my Pinterest account.
So I now have the best of both worlds. I show people that I have a Pinterest account, and if they click the image they can go and visit it as well. And, I only need to supply a small 10kb image instead of several dozen http requests.
So there you have it. A few simple steps that can dramatically speed up your website. Don't get pedantic and go overboard with this. If the Google Pagespeed checker tells me I can save 340bytes (and there are 1000bytes to a KB) by compressing a PNG image, I'm not going to bother. The gains have to be worth the effort. And FYI, the Google speed checker has given me that exact message, I didn't just make it up.
In the next installment, we will look at how to interpret the data from that pagespeed checker... what's important and what you can safely ignore.