Tag Archives: mobile site speed

HTTP-requests-checker-1024x230.png

8 tips for boosting the speed of your WordPress site

Chances are you’d not have waited for this page to load had it taken a second or two longer.

That’s the truth – users expect web pages to load pretty much as soon as they click on a hyperlink.

Slow loading web pages can become the leading cause of high bounce rates, low user engagement, lost traffic opportunities, and abandoned sales journeys. Here are some numbers to put things in perspective.

What’s more, ecommerce websites associate fast loading with increased revenue, and the reverse is also true.

The calling is clear: your websites need to load super quickly to sustain and nurture audience attention, avoid high bounce rate, and prevent abandoned sales.

If you have a WordPress site, there are a number of easy and effective methods you can begin using today that will significantly increase your site’s loading speed.

Use grids and floats instead of nested tables

It’s surprising how many websites still continue to use nested tables, in spite of the negative impact they have on page loading speeds. Here’s what a nested table code looks like:

<table>
<table>
………
</table>
</table>

Such coding adds additional burden on the browser, delaying complete loading of the content. Instead, use non-nested table structure as follows:

<table>...</table>
<table>...</table>

More importantly, use floats and grids to enhance loading speed. Here is a basic float example:

<h1>Basic float example</h1>
<img src="https://www.examplesite.com/files/image.jpg" alt="image anchor text">
<p> Sample text </p>
<p> Sample text </p>

Reduce the number of HTTP requests

A web page consists of several components – stylesheets, Flash components, images, scripts, and more. To deliver content rich experiences, you need to opt for entire PageSpeed Insights Optimization process.

More the number of elements per page, more the number of HTTP requests made for each of these, resulting in longer page loading time durations, which could hurt your conversions. Yahoo estimates that almost 80% of page loading time is accounted for the time spent in downloading the different elements of the page.

Use the HTTP requests checker tool to find out how many requests your page makes.

Luckily, you can reduce HTTP requests without ruining your web design. Here’s how:

  • Combine files: Use scripts and external style sheets (but don’t have more than one script and CSS file each.
  • Image maps: Use contiguous images instead of several image blocks, to reduce the number of HTTP requests.
  • CSS Sprites: Combine multiple images to a sprite, and call the sprite instead of each image. When the sprite contains images from internal pages also, the internal page load times improve, because the content is already downloaded before the user reaches there.
  • Make smaller Javascript blocks inline.
  • Convert images to Base64 coding using an encoder; because it transforms an image into code, the HTTP request is prevented.

Break comments into pages

Your most popular content posts could also be the ones loading the slowest, because of the hundreds of comments on the page. You can’t block comments, because they are conversation starters and link builders for you.

How do you manage, then? WordPress offers a very smart solution – break the comment stream into pages.

In the Dashboard, go to Settings. Under the section Other comment settings, you can tweak the settings for how many comments appear on a page, and which page is displayed beneath the article.

8 tips for boosting the speed of your WordPress site

Upgrade to the latest PHP version

Upgrading your website every time a new PHP version is launched can be a bit of a headache. But it’s worth your time and effort. The same scripts could run almost 25-30% faster on newer PHP versions; imagine the kind of website loading time improvements it can bring for you.

PHPClasses published an extensive experimental study, which highlighted that scripts ran significantly faster on PHP 7.1 as compared to previous versions.

Gzip compression

If you use Google’s PageSpeed Insights tool for a quick analysis of your web pages, it’s likely you will find advice to use Gzip compression. This compression enables web servers to compress heavy website content elements.

The compression is so effective that it could reduce your page size to 30-40% of its initial size. Dolloped speeds, because of this, could increase to three or four times their previous speed.

For many webmasters, installing a Gzip compression plugin continues to be the best option. W3 Total Cache plugin, apart from all its amazing features, also offers HTTP compression.

8 tips for boosting the speed of your WordPress site

Other options are:

  • Ask your web host if it offers Gzip compression.
  • Manually enable Gzip compression via .htaccess (this guide by Kinsta explains how to do so)

Don’t let ad scripts and pop-ups spoil user experience

Chances are you run at least some form of pop-up to optimize conversions. As beneficial as these might be for your website’s monetization strategies, they may also be causing significant damage in terms of higher page loading times.

To take control and strike the perfect balance, you need to know the third-party scripts running on your website, their source, and their impact.

I recommend Pingdom’s Website Speed Test for a thorough analysis of each file and script from a webpage. The tool will tell you which script takes the most time to load.

Gauge the effectiveness of your pop-ups; do away with non-performing pop-up plugins, as they’re only slowing down your page. OptinMonster is one of the most reliable pop-up plugins, helping you optimize conversions without killing speed.

Install a caching plugin

Caching plugins can be a blessing for your website; these plugins create static copies of your webpage content, and instead of making to and fro queries to the database, use the static versions to immediately showcase the web content to users. Since you ordinarily won’t update your web pages daily, caching proves to be very useful for almost all web pages, always.

Among the many caching plugins you can use, WOT Cache Plugin enjoys a lot of trust and popularity. Among its many features are:

  • Combines CSS and Javascript files
  • Leverages the power of page caching and browser caching
  • Utilizes lazy load to massively improve the page load time
  • Helps with database optimization and removes query strings from CSS/Javascript files
  • Saves a lot of bandwidth by reducing the file size of the webpages.

Bonus tip: Seek help from your web hosting service provider

It makes sense to move to a dedicated hosting plan, so that your website gets all the resources it needs to load in a jiffy, always. Ask your web host as to what help it can provide you to improve your website speed.

Most web hosts are willing to offer their technical expertise to help you pluck the low hanging fruits in terms of your website’s speed issues. This, in turn, benefits them, as the load on their servers reduces.

Particularly, ask for their advice on optimizing mobile website speed, because the impact of slow loading is much severe on mobile devices.

Concluding remarks

Every few milliseconds of improvement in your web page’s loading speed could bring tens of percentage point of improvements in its traffic and conversion rates.

Start with these easy and practical tips, most of which will result in almost immediate improvements in page loading speed for your website.

dna46t_bbc_pagespeedtest.png

How JavaScript impacts page loading speed on mobile

The effect of JavaScript on mobile web performance is twofold.

One, it is the second largest contributor to webpage weight, behind images, thereby increasing download time; and two, once downloaded, the browser then needs to run the script, which can delay the downloading/rendering of other (perhaps more important) assets on the page.

JavaScript (aka scripts or JS) is one of the triumvirate of technologies that make web pages (and web apps) work. The HTML (Hypertext Markup Language) controls the structure and content of the webpage; CSS (Cascade Styling Sheets) controls how the site looks on different devices; and JavaScript makes the page more interactive and dynamic.

Scripts perform numerous functions on webpages such as loading ads, A/B testing, tag management (personalizing the page) or displaying an inline video player.

Over the last five years, the total weight of pages sent to mobile devices has quadrupled to 2.2MB. Size matters because, in general, the more data that is sent over a mobile, or fixed, network the longer a page will take to load. More data, more seconds staring at an empty mobile screen.

This suggests that images – which tend to take up more of the total kilobytes (KB) or megabytes (MB) of each page – are the main culprit. But this is not always the case.

JavaScript could potentially have more of an impact on page performance than images. As Patrick Meenan, founder of the web performance testing site WebPageTest and software engineer at Google, explains:

“Scripts are usually a (bigger) issue because of the time it takes to actually execute the script in addition to the download size, while images really only matter because of the download size. With mobile devices for example, it can take several seconds to run a script even after it has been downloaded.” 

It’s not necessarily JavaScript, per se, that is the problem, but how it is implemented: scripts can monopolize browser activity, blocking the download and rendering (displaying) of other content.

“The problems are often compounded where the script is referenced in the page. The content after a ‘blocking’ script (as opposed to an async script) doesn’t exist, as far as the browser is concerned, until after the script has been downloaded and executed. When, as is commonly the case, scripts are put at the beginning of the page this means that the page will be completely blank until the scripts have downloaded and executed.”

We will discuss below the difference between blocking, inline, synchronous (sync), asynchronous (async) and deferred scripts and how to fix JavaScript problems, but first we’ll look at how to spot issues.

Testing for blocking JavaScript

If you have tested your webpages using Google PageSpeed Insights (N.B. you should regularly test your mobile webpages using tools such as WebPageTest and PageSpeed Insights), chances are you have seen the following warning:

! Should Fix:

Eliminate render-blocking JavaScript and CSS in above-the-fold content

Your page has 8 blocking script resources and 7 blocking CSS resources. This causes a delay in rendering your page.

None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

The text and image above is from a Mobile PageSpeed Insights test on BBC.com conducted in February 2017.

Note “above the fold” refers only to the part of the webpage which is visible on a mobile device, without scrolling, Google is not analyzing scripts on the rest of the page.

The BBC is the world’s most popular English language news website, according to Alexa, so to put it in context we should also test the others in the top four. The results suggests two more publishers have similar issues with JavaScript. (The test also highlights CSS issues, but this is not the focus of the article):

  1. BBC.com PageSpeed test (8 blocking scripts; 7 blocking CSS resources)
  2. NYTimes.com PageSpeed test (0 blocking scripts)
  3. ESPN.com PageSpeed test (2 blocking scripts; 3 blocking CSS resources)
  4. CNN.com PageSpeed test (6 blocking scripts; 2 blocking CSS resources)

4x growth in JavaScript use in five years

Over the last five years the amount of JavaScript used on the average mobile page has almost quadrupled from 101KB in February 2012 to 387KB in February 2017. The number of requests (a request is the number of times a browser is required to download an additional piece of content or code) for different JavaScript files has increased from 8 to 21.

This is clearly illustrated in the graph below from HTTP Archive. HTTP Archive tests the top 1 million sites several times every month using data from WebPageTest, and publishes trends and stats that are essential benchmarking for the performance of your site.

How JavaScript impacts page loading speed on mobileFor the top 1 million sites monitored by HTTP Archive, JavaScript accounts for 17.4% of page weight. JavaScript also accounts for 21 out of 93 total requests (22.6%).

For some sites, particularly in the news space, JavaScript has a considerably larger share of page weight than the norm.

The image below compares the breakdown by content type for the average site with BBC.com tested by HTTP Archive (15 February 2017):

  • The first thing to note is how impressively small the BBC page size is: 609KB v 2225KB.
  • The second thing to note is how small the combined size of the BBC images: 70KB v 1501KB.
  • The third thing to note is how proportionally large the scripts are: 458KB or 75.2% of total page size.
  • The fourth thing to note (not shown in the charts below) is that 39 (44.3%) of the BBC’s total 88 requests are scripts.

How JavaScript impacts page loading speed on mobile

When you compare the test results of the top four English language news websites, it is remarkable how much smaller the BBC is than its rivals. It is a one-third to a half of the size, with two to three times less JavaScript.

  1. BBC.com tested by HTTP Archive: Scripts 458KB (75.2%) of 609KB of total data; 39 JS requests (44.3%) of 167 88 total requests.
  2. NYTimes.com HTTP Archive test: Scripts 1511KB (51%) of 2953KB of total data; 73 JS requests (43.7%) of 167 total requests. (N.B. NY Times has a dedicated mobile site at mobile.nytimes.com, which is not listed by HTTP Archive, which may deliver different results.)
  3. ESPN.com HTTP Archive test: Scripts 1183KB (65.7%) of 1802KB of total data; 50 JS requests (47.2%) of 106 total requests.
  4. CNN.com HTTP Archive test: Scripts 1484KB (68%) of 2182KB of total data; 67 JS requests (31.9%) of 210 total requests.

What is the effect on mobile page speed?

So does it follow that the slim-line BBC site would load much faster than all its rivals?

Err, no. On 15 February 2017, HTTP Archive recorded the following load times:

  1. BBC.com: 18.3 seconds
  2. NYTimes.com: 27.4 seconds
  3. ESPN.com: 8.8 seconds
  4. CNN.com: 31.5 seconds

So, the BBC is faster loading on a mobile device than CNN and the New York Times, but considerably slower than the (larger) ESPN.

This is what the two sites look like on a mobile device. (The filmstrip is one of WebPageTest’s most visually compelling features, easily understood by any non-techie). Each frame represents 1 second. When the HTTP Archive test took place, for 9 seconds BBC.com mobile visitors saw nothing, while for 4 seconds ESPN visitors saw nothing.How JavaScript impacts page loading speed on mobile

There could be many reasons why one website might be faster than another, such as server response times, use of content delivery networks (CDN), the impact of ad networks, inclusion of third-party data (common on news sites), or the time and place of the test (in this case California, USA).

However, all other things being equal, it is possible that JavaScript could be a contributing factor. (Apologies for the hedging of bets). As noted above, BBC.com did receive more warnings for blocking scripts above the fold than the other news sites.

Reducing reliance on JavaScript

JavaScript is often used to perform tasks that cannot (easily) be done with HTML or CSS. As the W3C gradually add these features to the HTML or CSS standards and they are implemented by browsers, the JavaScript patch is no longer needed, as HTML/CSS is likely to be more efficient. A good example of this is responsive images.

Alex Painter, Web Performance Consultant at NCC Group:

“As a rule, it’s worth sticking to the principle of progressive enhancement – delivering a site that works without JavaScript and using scripts only for those extra features that can’t be done any other way.

“Using JavaScript to render content can be expensive – it takes time to load and execute. So, for example, if you can use HTML and CSS to achieve the same result, that’s generally going to be faster.

 “When it comes to responsive images, for example, you can use media queries in CSS and picture/srcset in the HTML to deliver the right image for the viewport without having rely on JavaScript.”

Choose asynchronous and deferred JavaScript over blocking and inline scripts

There are a number of ways that JavaScript can be implemented on a webpage, including:

  1. Blocking scripts are synchronous which means they have to be dealt with immediately and ahead of anything else. By default, all JavaScript is parser blocking. As the browser does not know what the script will do to the page, as soon as it meets a request (in the HTML file) to download a JavaScript file, it stops building the webpage, and does not continue until the file is downloaded and executed.
  1. Inline scripts also stop the page build, but as they are included in the HTML, they do not need to be individually downloaded. However too large or too many inline scripts will bloat and delay the initial download of HTML file.
  1. Asynchronous scripts allows the browser to continue parsing (analyzing the code and building the webpage), while the JavaScript file is downloaded. Including the async attribute in the HTML tells the browser that it doesn’t need to put everything on hold.
  1. Deferred JavaScript – tells the browser to leave the execution of the JS file until after it has finished building the webpage, this is signified with the defer attribute.

Are blocking scripts ever justified?

Patrick Meenan:

“If the site functionality relies on the code, then it needs to be run as a blocking script so that it is ready before the page needs it. A very common case for this is tag managers and A/B testing platforms where the code will change the page. In other cases blocking is used when it will be more work to load the functionality asynchronously.”

Reducing size of JavaScript files

How big is too big? How many requests is too many?

This will always be a balancing act.

Patrick Meenan:

“Since the browser will only load six requests at a time for each domain, if you have more than that it needs to request the rest after the first ones have completed, leading to longer times from the request/response delays.

 “Larger JavaScript files also take longer to parse and run (1ms for every 1KB of uncompressed JS is a reasonable estimate).  All else being equal, if you have the same amount of JS in a lot of files it will take much longer to load than if the same amount of JS was in a single file.”

Google recommends minification of JavaScript files using UglifyJS or Closure Compiler.

For more on how to optimize the speed of your mobile site, check out our previous three-part series:

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedInor on Twitter at Andy_Favell.

dna45_image_formats_httparche_t.png

How to optimize images for mobile: Implementing light, responsive, correctly formatted images

The mobile web has a weight problem. Too many mobile sites are slow to load, and bloated with unnecessary bells and whistles, leading to a poor user experience.

Chief among the culprits is images, which as we have seen in part 1 of this series, How to optimize your mobile site speed, account for 68% of total page weight. Then, in part 2, we looked at how to reduce the impact of images on the speed of your mobile site, including how to make sure your images are as accessible as can be. This mostly focused on removing images which do not add value, and making the ones you do use work harder.

But how can you make sure that any images on your mobile site are light, device-responsive, and use the best format to combine speed and quality? This column focuses on optimizing images for mobile, including responsive images and other clever methods for stopping images ruining mobile user experience.

The balancing act of image optimization

The problem with image optimization is that there are no hard and fast rules. Image optimization is always going to be a careful balancing act between user experience, attractiveness and page performance.

Raluca Budiu, Director of Research at Nielsen Norman Group, explains:

“Because the screen is small on mobile, too small images may offer too little information, and too big images may slow down the page too much. We recommend that you start with a modest size image and allow people to zoom in (or download a larger picture of the image).

Most of the time huge images are not a good idea — their information density is low, and they require people to wait for the page to load and/or to scroll down for more content. This is a common problem with responsive one-column designs: because images are supposed to fill up the whole container width, we often end up with huge images that carry little information compared to their size.”

There is no set-in-stone rule for how small a mobile image should be – it’s a trade-off between quality and page size. But a good guideline is to benchmark against the 100 most popular sites. According to httpArchive, the average JPG is 29KB and the average PNG is 16KB.

Reducing the weight of an image is partly about saving the image at the appropriate size and resolution (number of pixels) and partly about compressing the image. Some creative tools, such as Photoshop, will afford some compression, but often not enough, especially with larger image types such as PNG.

There are a number of tools that will very effectively compress images individually or in batches of images. For example the homepages image above was compressed using TinyPNG resulting in a 79% reduction in weight.

For a comparison of the leading compression tools, see GitHub.

Should you use different sized images for mobile, tablet and desktop?

When designing separate websites for mobile, tablet and desktop, whether that is via dedicated URLs (site.com and m.site.com) or serving different sites via a single URL (adaptive web design), it is implicit that images ought to be appropriately sized for the largest device in that category.

The position is perhaps less clear with responsive web design (RWD). With RWD, the principle is to serve the same website to different devices, using CSS to format the content according to the device capabilities and screen size.

This doesn’t mean, though, that websites should necessarily adopt a one-size fits all approach to images, explains Alex Painter, Web Performance Consultant at NCC Group:

“Pages are often slow on mobile because of a failure to deliver images appropriately sized for the viewport. The popularity of responsive design may be partly to blame – the idea that the same content can be reflowed so the layout works in any viewport can mask the fact that imagery hasn’t been optimized for mobile.

Plenty of sites deliver the same images on desktop as they do on mobile – with mobile versions just scaled down to fit. This might not be immediately obvious to end users with high-end devices on fast, reliable networks. But it can make websites completely unusable for people with lower spec phones or with poor connectivity.

 There are two reasons why this is a big problem. The first is simple – it just takes longer to deliver an unnecessarily large image over the network. The second is often overlooked: the mobile device has to work hard to a) decode and b) scale down the image. This is expensive in terms of processing power and memory.”

But it doesn’t have to be this way. Helped in part by the advocacy of the Responsive Images Community Group, the HTML specification now makes it easier for developers to create a number of alternate images for different device types – to suit different screen sizes (viewport), resolutions (number of pixels) or device capability.

The webpage HTML tells the browser which of these images to select for screens up to a maximum width and if the image should take up all or just part of the screen width.

Previously, some developers would use JavaScript to specify the use of different images, but using the HTML <picture> element should be more efficient, reducing the extra code and requests that slow down page load times.

Alex Painter:

“Delivering the right image for the viewport is now reasonably straightforward. We’ve had CSS media queries for background images for some time, but until recently images referenced in the HTML was more of a problem.

Now, we have the responsive images specification: the <picture> element, with the srcset[set of alternative image sources] attribute and sizes attribute that make it possible to define which image should be delivered for which viewport width (or to allow the browser to make the most appropriate choice from a selection of images).

The spec is now very well supported by browsers, and developers should ideally be using it rather than using JavaScript to achieve the same end.”

How to optimize images for mobile: Implementing light, responsive, correctly formatted images

Who is using responsive images?

A peek at the source code of major websites such as Amazon, Facebook and the BBC confirms that none is yet using the <picture> element to serve responsive images.

Would they benefit from doing so? Serving different images to each platform potentially offers several advantages:

  • Allows the website to show a larger, higher resolution image on the desktop.
  • Reduces the picture sizes and total page weight and thus speeding up mobile load time.
  • Enables the mobile site to show a zoomed in image on mobile. (Note the cropped image of the dog above).
  • Retailers can display Mobile-Friendly Hero Images on mobile while sticking to traditional pack shots on larger displays.

Finding the best format for your images

The most common formats for images used in mobile/mobile-friendly sites are JPEG 46%, PNG 28%, GIF 23% and SVG 1% according to httpArchive.

How to optimize images for mobile: Implementing light, responsive, correctly formatted images

Using an inappropriate image format can increase file size and effect quality when images scale for different screen sizes.

There are two types of web image: raster and vector. The first is made up of dots (like a digital photograph), while the second is made up of lines and shapes. JPEG, PNG and GIF are raster. SVG is a vector. SVG is a newer format not as widely used (yet), but is recommended for responsive design sites by this course on Responsive Images from Google and Udacity.

There are pro and cons for each, and every web designer has a different opinion and favorite formats. You need to research your own company policy, but in general:

  • JPEG is most commonly used for web photographs
  • GIF is common for animations as well as simple graphs, icons and logos
  • PNG is common for higher quality graphs, logos, icons and other illustrations and photos with graphical effects
  • SVG is good for graphs and logos, page headers – things that are designed by an illustrator.

For more information on format types and sizes, see Google’s guide to optimizing images.

Alternatives to traditional images

Webpages are made up of many small images, such as icons and buttons. If these are made using individual GIF/PNG/JPEG images, it all adds to the page size and each one requires an individual browser request, which can slow down page load time.

Three methods that can help keep page size and image requests down are:

  • CSS sprites – combines a collection of smaller graphics into a single CSS file. N.B. Overloading sprites with too many or too large graphics will be counter-productive.
  • Icon fonts – is a library of icons sent as one single file.
  • CSS shapes – are shapes built using CSS, rather than as a traditional image

Mike D’Agruma Lead Front-End Web Developer, E-volve Creative Group:

“To save on file size, I generally stay away from loading larger, more popular icon libraries, and use Fontastic to create my own custom icon fonts. This method works extremely well on a variety of levels: 1) As I’m only using a small number of custom icons, the font file size is drastically smaller; 2) Icons are created with SVGs, which ensures they’ll be extremely crisp on devices; 3) You can’t beat this option for flexibility, as font icons are extremely customizable with CSS.

Another great way to safe on time, file-size and server requests is to use CSS to create shapes – you can create most shapes and add as many effects and transitions as you’d like with CSS.

 Take Summit County Metro Parks mobile site as an example, in the header section alone, I was able to use a combination of CSS shapes and font icons to create what could’ve been six different images. Activating the mobile menu shows an example of a CSS-shape animation (the hamburger menu morphing into an “X”), and the use of an additional icon on the right side of accordion triggers shows open and closed states.”

How to optimize images for mobile: Implementing light, responsive, correctly formatted images

Web design techniques for improving perceived load time

When you have trimmed the fat, removed the unnecessary images and optimized the remainder, but the page is still not loading fast enough – what do you do? Cheat.

Make sure the most important stuff loads first, says Raluca Budiu:

“When a page loads, make sure that the text loads first, so that people can start scanning the content. As images load, don’t shuffle the already loaded content around — it will cause readers to lose their place on the page, and sometimes they will even click on the wrong link because the right target unexpectedly moved.”

There is a difference between perceived load time and actual load time. All that matters to the user is that the content on they are looking at, or for, is available. They do not want to be staring at an empty screen while the browser fetches images they may never see.

There are three common techniques for delivering this. Robert Gaines, a Kansas, US-based, web and app developer explains:

 “1. Deferred loading, or delayed loading, uses JavaScript to stop images and other assets loading until after the main content of a webpage has finished loading. Deferred loading reduces the amount of time it takes for a webpage’s primary content to render, but reduces the need to cut images that would otherwise slow down a webpage.

2. Lazy Loading loads assets when and as they are needed. So content is loaded above the fold first, then below the fold as the user scrolls. With image galleries – such as product searches on retail sites – thumbnail images are used, larger images are only loaded when a corresponding thumbnail is clicked.

3. Progressive image loading first loads low quality images while a webpage is being rendered and then replaces them with high quality images after primary content has finished loading. Progressive image loading balances performance with visual appeal. Unlike deferred loading, it doesn’t leave users waiting for secondary images to load after primary content.”

Tools such as Photoshop allow images to be saved as progressive JPEGs, or interlaced PNG, which will load in the way described.

This course on Responsive Images from Google and Udacity is a good introduction to this subject; it is aimed at web developers, but everyone will benefit. You can skip the coding exercises.

 

This article is Part 3 of a three-part series on how to optimize your mobile site speed. Read the previous instalments in this series:

A version of this column was originally published on our sister site, ClickZ. It has been republished here for the enjoyment of our audience on SEW.