Let’s cycle from Leeds to St Albans…

Eddie Izzard, Dylan Moran and Reginald D Hunter are playing an outdoors gig in St Albans, brilliant. What’s more my friend, Mat, and I got tickets, brillianter. Then we decided that we’d cycle there. Silly.

So this Thursday we’ll set off from Leeds to cycle the 210 (and a bit) miles from Leeds to St Albans. We even planned a route and everything (we’re not normally so organised). We reckon it’ll take us 2 and a half days.

Day 1, Leeds, West Yorkshire to Gunthorpe, Nottinghamshire – 90 miles
Day 2, Gunthorpe, Nottinghamshire to Harrold, Bedfordshire – 70(ish) miles
Day 3, Harrold, Bedfordshire to St Albans, Hertfordshire – 50(ish) miles

So anyway, if I’m super-organised then we may be using Mat’s phone to track the route and I’ll pop it up on here and you can all see how slow we went and how frequently we got lost.

Hurray! Cycling!

p.s. I went for my first long ride in a while on Saturday and got an incredible painful knee whilst riding, apparently this is either because a)my knees are all wrong or b)my saddle is slightly too low. I’ve raised my saddle and it has made things slightly better in the knee-department, the problem now is that my feet barely touch the ground and getting onto the bike is a bit of an acrobatic challenge. Ah well, I’m sure it’ll be fine.

Does your site take too long to load? Probably. So, how to speed it up?

“There is more to life than simply increasing its speed” (Gandhi)

Last week I was doing some speed tests on what I was expecting to be a relatively slow-load site that I’m working on, the results, whilst not completely shocking, were still surprising. The site was taking up to 8 seconds to load fully over a decent speed connection (and would’ve been much much longer over dial-up). This had been an issue that had been nagging away at me more generally for a while now so I thought it was probably time to look into how to address it.

“Delays under half a second impact business metrics”

I have been reading up on the tests that Google had conducted to see how long the average user would wait for a site to load before giving up and moving on (Bing also conducted similar tests). Their findings? Simple, if your site takes too long to load then you will lose traffic and damage the user experience. And by ‘too long’ we are talking in terms of milliseconds. When Bing and Google increased a server-side delay from 1000ms to 2000ms there was a 2.2% drop in user satisfaction (not too bad you’d say) but the ‘time to click’ increased from 1900ms to 3100ms. This second stat is probably the most pertinent as it would indicate that a 1000ms slow down in server-response times results in the user becoming disproportionately unengaged with the site.


I think something else to bear in mind is that if the user does decide to stick with your site, and this level of site-reponse is repeated page after page (or even more slowly) then it would not be too much of a leap to assume that the user satisfaction would start to drop even faster as their frustratingly slow experience exacerbates things.

You’ve lost their attention, how do you get it back?

So, we’ve decided that a slow-loading site is a bad thing? Cool. There seems to be a consensus that the quickest way to get your site to load quicker is to get the file size of the site’s assets down, which may seem obvious but it would seem that not enough people do it, and even those that do (of which I thought I was one) probably aren’t getting things as compressed as they could be.

Efficient (and small) CSS

I’ve never been a huge fan of massively compressing my CSS files. I find the process of stripping out all the white space (line breaks etc) irritating as, in my opinion, it renders my CSS almost unreadable if I ever want to go back and edit it.

To assuage my guilt about never really super-compressing my CSS I read several articles about making my CSS more efficient. It made interesting reading and has changed my coding practices. Perhaps the two most useful things that I learnt about making CSS render efficiently were:

  • CSS reads right-to-left. e.g. with #nav li a – a is the “key selector” i.e. the element being selected, then li, then the id #nav
  • “There are four kinds of key selectors: ID, class, tag, and universal. It is that same order in how efficient they are.”
    • #main-navigation {   }      /* ID (Fastest) */
    • body.home #page-wrap {   }  /* ID */
    • .main-navigation {   }      /* Class */
    • ul li a.current {   }       /* Class *
    • ul {   }                    /* Tag */
    • ul li a {  }                /* Tag */
    • * {   }                     /* Universal (Slowest) */
    • #content [title=’home’]     /* Universal */

There is more on this subject in this excellent article http://css-tricks.com/efficiently-rendering-css/. However I would say that the two points I’ve highlighted above are the basis to making your CSS render as efficiently as possible.

An important point to remember, as the article states, is “So we know that ID’s are the most efficient selectors. If you wanted to make the most efficiently rendering page possible, you would literally give every single element on the page a unique ID, then apply styling with single ID selectors. That would be super fast, and also super ridiculous. It would probably be extremely non-semantic and extremely difficult to maintain. You don’t see this approach even on hardcore performance based sites. I think the lesson here is not to sacrifice semantics or maintainability for efficient CSS.As with every ‘best practise’ you also have to use a modicom of common sense, there is no point in taking a good way of working and applying it in a ridiculous way (sorry if this seems like stating the obvious but I think it is an important point to remember).

Compress that CSS

Now it is an unanswerable argument that compressed CSS is smaller. I outlined above why I’m not a huge fan of this method but it is unavoidable if you want to seriously address your site’s load time. There are, as always, a huge amount of ways you can go about compressing your CSS.

There are a number of online tools that’ll do it for you:

You can look into gzipping your CSS file:

There is an article here about using gzipping on the whole site to speed things up: http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/

Last but not least there seem to be a few ways to compress your CSS file using PHP:

Images, beautiful but deadly

Images make your site look better right? They allow you to use cool fonts as headers (although there are better ways of doing this, here’s one http://www.font-face.com/), they often form the basis of swanky looking navigation and layout elements and more and more often large imagery is used to provide a visual impact that wouldn’t be achieveable with another type of element (http://webdesignledger.com/tips/web-design-trends-for-2010).

The trouble is, images take up space and they take up even more, unnecessary space if you’re using the wrong file format.

Image file formats. What? Where? When? Why?

The three most commonly used, and widely supported, image file formats on the web are .jpg, .png and .gif. You should be using all 3 of these file formats in your designs, they each have a reason for being there. If you use the right format for the correct purpose then you will have a more efficient site.

  • GIF – 8-bit, lossless but limited to 256 colours so are bad for photos. However they do allow single-bit transparency so you can make 1 of the 256 colours that it does render transparent. GIFs are great for block-colour elements such as logos and navigational elements.
  • JPG – 16-bit, capable of millions of colours and designed specifically for photos. However lacks some of the capabilities of GIFs such as transparency and animation. Can be compressed but the compression is lossy and once over about 50% results in noticeably reduced image quality. Should really only ever be used for photos.
  • PNG – comes in 8-, 24- and 32-bit formats designed with the web in mind. The 8-bit format is very similar to GIF in that it supports 256 colours and 1-bit transparency, in addition file sizes are likely to be slightly smaller than GIF equivalents as PNG saves it’s colour data more efficiently. The 32-bit version (named, unsurprisingly PNG-32) allows a similar range of colours to JPG but also offers alpha-channel transparency. Rather than only being able to specify one colour as transparent or not PNG-32 allows you to specify the transparency of every pixel on a sliding scale (from 0-255)…the only drawback being…IE6 doesn’t support alpha transparency (surprise, surprise). I wouldn’t recommend using PNG for photos as the file size is likely to be fairly huge in comparison with a JPG equaivalent (due to the PNG being 32-bit and being a lossless format).

So, to summarise, what should you be using and when?
JPG – to be used for photos, be aware that if you try to reduce the file size by upping the compression then anything beyond 50% compression results in noticeable reduced image quality.
GIF – can be used for simple elements, logos and navigation – although remember that PNG-8 could be an alternative.
PNG – comes in 8, 24 and 32 bit formats (and the file sizes increase with each). 8-bit could be used as an alternative to GIF. 32-bit offers alpha channel transparency which could be useful for design or navigational elements where more sophisticated transparency is required. However always bear in mind that the 32-bit version is the largest file format mentioned here and consider whether or not a GIF or 8-bit PNG could be used if less sophisticated (e.g. one-colour) transparency is required.

As I mentioned previously these guidelines should be considered as just that, guidelines. Don’t take them as hard and fast rules that should be applied as rote to every situation. However I do think that being aware of what each file format was designed for allows you to make more informed choices.

Image optimisation

My final word on images, if you are using an editing package such as Photoshop or Fireworks, make sure that you always export your images (whatever format they’re in) as optimised for the web. This process strips out all of the completely unnecessary meta-data that these programs include as standard and noticeably reduces your image file size.

HTTP requests, and how to reduce them

Every time you include an element that isn’t hard-coded into your page file (e.g. by linking to include an external file) you are introducing a new http request to your server. Whether this is linking to a css or js file or including an image.

If you are including 5 js files in your file then this is 5 http requests, add into this however many images your file includes, at least 1 css file and you’ve probably got at least 10 http requests per page. Unsurprisingly the more http requests you have, the slower your page will load. So, how do you reduce them? Simple, combine elements. Whether this is combining your multiple css or js files into one master file (and then ensuring that is written efficiently and compressed) or combining your images by using sprites (info on sprites here http://css-tricks.com/css-sprites/ and here http://www.fiftyfoureleven.com/weblog/web-development/css/css-sprites-images-optimization)

And finally

I hope the methods I’ve outlined above prove to be useful to you, if anyone else has any other thoughts on how to optimise your website for faster loading then please comment!

I think that all of the methods outlined here are relatively straight-forward and could be easily incorporated into your processes. Things like writing efficient CSS and javascript and then optimising those files, using the appropriate image formats and reducing http requests are all quite easy things to do and will have a noticeable impact on the file size and speed of your sites.

I am aware there are even more methods that you can utilise to optimise your site, and would be interested to hear if anyone thinks they should’ve been mentioned here. I aimed to provide a good and manageable starting point and I hope I’ve done that.

Thanks to the following articles (all of which are worth a read)

Istanbul to Leeds is a very long way

Right as you may or may not be aware this summer I drove one of the support vehicles on the Jane Tomlinson Appeal Istanbul to Leeds charity bike ride.

I had previously driven support on the Appeal’s last ride from John O’Groats to Land’s End. Basically driving support means driving a big van, full of bike stuff around after a group of cyclists trying to ensure they don’t get lost and have enough food and drink and the like. I soon realised that the last ride was relatively straight forward, for a start we stayed in hotels each night whereas this year we would be camping not to mention the language and cultural differences that we would encounter whilst travelling through 10 countries.

It all started for me when I picked up the van from Rothwell in Leeds. John (the chap who was sharing the van-driving with me) and I met up with Al, Dave and Nigel who would between them be driving out the other two vehicles, a car and an RV. We didn’t have anything you could really call a ‘route’ planned although we knew the rough general direction we would be heading in, so off we went.

Despite me forgetting my wallet (idiot) the journey down to Folkestone was pretty straight forward, as was the journey as whole until we got to Austria (bar John forgetting which side of the road to drive on in France and turning into oncoming traffic…a minor hiccup). We had decided we would only be making 2 short (4 hour) stops for sleep on the way out as otherwise we’d be in danger of not getting there in time. The first stop was slightly enforced, a massive lightening storm broke over us as we entered Austria, it was nighttime and I was absolutely knackered so it seemed like a good time to stop. I slept in the van, John, Al and Dave shared the RV and Nige had the car. 4 hours later we were back on our way. The heat became noticeable as we entered Hungary and I seem to remember a sign in Budapest telling us it was 38 degrees (at about 10am) and I soon descended into a disgusting sweaty mess (the van didn’t have air conditioning).

The real cultural differences didn’t become obvious until we entered Romania, but when they did come they were pretty clear. The roads immediately deteriorated and the traffic became a mix of knackered Ladas and dusty HGVs. At one point we passed what looked like a nuclear power station being dismantled (or just falling apart), next to it was the saddest street market I have ever seen simply selling rubbish wooden carvings and giant garden gnomes – very odd. Now I’m sure Romania has some nice parts, however we didn’t see any of them. We saw the bad roads, poverty, buildings falling down, many stray dogs, prostitutes everywhere (even outside McDonalds) and numerous other things that I have since tried to forget. After Romania, Bulgaria was a blesséd relief with friendly people, less scary dogs, no obvious ladies of the night and what, at first, seemed like good roads.

However. Al and Dave had, throughout the trip to that point, unswervingly followed their sat nav – a tactic not to be mocked as it hadn’t lead us wrong until then. They suddenly decided to turn off the nice, smooth motorway that we were on and that seemed to go all the way to where we needed to be. The road we turned onto went through a forest, we were the only vehicles, or people, for miles around and this road was one of the most potholed pieces of tarmac i’ve seen in my entire life. It was more pothole than road for long stretches. Our average speed dropped to about 6mph as we crawled along being shaken from side to side by these gargantuan craters. Then we had a bit of an incident, the RV stopped. It’s hazard lights came on and Dave stepped out to sum up the situation, “it’s buggered”. Cue a couple of hours spent trying to find shade in the scorching Bulgarian sun whilst on the phone to the AA, the RAC and the company we’d hired the RV from. It eventually turned out that due to the amount of potholes the RV thought it had been in an accident and had turned itself off as a ‘safety feature’. Luckily there was a simple reset button and we were on our way again.

The rest of Bulgaria passed fairly uneventfully until we reach the Bulgaria-Turkey border. This border was pretty ramshackle and isolated and I think the guards must’ve been bored, or at least that’s the conclusion i’ve come to explain why we spent the next 5 hours there. A long story for another day but a word of warning, if your hire company says you don’t need printouts of your vehicle documents because ‘everything is done electronically these days’ then don’t assume that’ll actually mean anything to bored and slightly irritable border guards in the arse end of nowhere.

The final story of note on the journey out there (and there are a million other stories i hope to get around to retelling at some point) involves the drivers of Turkey. Now I loved Turkey, the people were amazing. But bloody hell, they’re absolutely mental drivers. I’ve no idea how we managed to make it into Istanbul and to our hotel in one piece, i involved avoiding some of the most ridiculous driving i’ve ever seen, and yes, i’ve been to India! The drivers, combined with it being at night and only about 6 hours sleep in the previous 72 meant that the last part of the journey passed in a weird dreamlike state. Probably not very safe.

But we got there, 2500 miles, 3 days, 9 countries, 1 van. Istanbul to Leeds. I’ll write up a bit of a summary of what happened on the bike ride when I get some time to gather my thoughts, it was quite an experience!

Back, if not in black then at least with tanlines

I have returned from my little driving trip across Europe following some cyclists (www.istanbultoleeds.co.uk).

And I’m straight back into things, working towards getting the final signoff on Will Soden and Pickles and Potter’s sites.

I’m also in the final phase of populating the new site for Run For All. The new site will see a complete redesign and markedly increased functionality, I’m very excited.

So, back to work, a more useful blog will follow in the next week or so.