Better roads and faster cars don’t reduce travel times when there are 10 times the cars and only one new lane. As Joe Barber writes, the same holds true for web infrastructure and modern content.

With what seems a constant stream of innovation in infrastructure technology, why is the performance of websites degrading at a faster rate than ever before? It’s not only a perception that things just take longer online – the reality is that all round the world response times on pages are degrading. There are two trends that marketers should be aware of: mobile is now representing anywhere upwards of 60% of traffic, and mobile suffers the most from degradation in performance.

I was recently asked by a Marketing reader to come into their agency for an afternoon’s ‘open think tank’ where mobile and technology discussions relating to their client base were debated and analysed. Most alarming was the number of this agency’s clients that were experiencing performance issues with their website and the amount of impact and social media negativity this was causing. But of most surprise was the lack of understanding as to why things were slowing down.

The amount of information shared and downloaded by the world’s internet users (which number 2.4 billion, according to Forrester) is showing no signs of slowing – in volume or in size. It is outpacing the ability of ISPs to efficiently deliver and, despite network upgrades and better hardware, it is reported than in three years’ time we will have over 10 times the volume with barely twice the infrastructure.

How the web got fat

Internet penetration and usage is expanding at exponential rates. But the issue is not a growing internet population. A quick lesson on the web: every image, every CSS file, every Javascript included file and every video or other page object must be loaded by the receiving device.

So, for example, the basic HTML is sent to a mobile for an ecommerce site – the handset browser then starts loading the page and for each of these assets makes a separate request to a server somewhere for the file. Where files don’t exist, they time out. Some assets sit on various content delivery networks (CDNs) and some are internally hosted – font files from, say, Google. And the list goes on.

It’s not unusual for a whole page to have over 100 requests for the objects that make up the final web page to be displayed. Then the style sheet may dictate that for this mobile device of a specific width, then ignore 50% of the images, resize the rest and ignore three menu items by hiding them. Responsive design has delivered probably triple or even more of what was needed – the final presentation layer is stunning, but the time required to perform the whole task, especially on a mobile device, is causing page abandonment and frustration. It’s the same with many brand portals. Size does matter.- in fact, that’s the least of the problems. Innovation in content quality, quantity and resolution has surpassed innovation in internet delivery. Users are expecting the same pipes that deliver web pages and emails to deliver billions of high-definition media files. We’re facing a congestion crisis, amplified on mobile, impacting everyone in the ecosystem.

On the whole, web developers give little consideration to the delivery and performance issue of websites. Their objective is to build an engaging and functional ecommerce or information portal using the latest HD video clips and image assets with upwards of four or five downloaded third-party fonts. And their solution for mobile and tablets is now a web developer’s dream: responsive web design. But all these things contribute to degrading performance. Combine that on ecommerce sites with four or five specialised plug-ins and the storefront will be sluggish at best.

I don’t want to alienate web developers, but responsive web design is like a comfortable pair of loafers. They’re the comfy shoe of choice, but you don’t use them for jogging, running, playing football or hiking through the mountains. Responsive web design is the same, but some developers use it all the time for every circumstance. Responsive sends the exact same page and assets to every device regardless of size and then puts the final rendering load on the browser.

I have seen many fat pages of three megabytes and up that simply won’t be as quick on mobile.

The web performance challenge is not just a single thing that needs updating. Maybe that’s why it isn’t being addressed or getting the profile of concern it should. Increasingly, the important part being dictated by companies is speed of development and deployment. In an old study done by Amazon, it was found that small improvements increased sales – a 1% increase in revenue was achievable with sub-millisecond improvements in response times.

A web developer’s solution is to just throw more hardware at a site running slowly. But this is short-term thinking and a very costly approach. Once you add a couple of database servers, application servers, a handful of Varnish servers and a load balancer, you have a reasonable amount of kit now centralised with single points of failure. It’s a situation that’s almost counter to the principles of cloud computing.

The essence of the problem can be summarised as follows (predominantly as it relates to mobile):

• responsive web design expects handsets to have to perform a lot of work before pages are displayed or at least usable, but development of responsive design is faster,
• web pages, overall, have increased in size from an average of 600 kilobytes to between five and eight megabytes (a factor of 10),
• mobile devices, including tablets, account for at least 30% of the time using very slow and congested public shared Wi-Fi hotspots, or slow office connections hosting environments are becoming complex, centralised and having a single point of failure (and are costly),
• the volume of content overall is growing, while technologies to deliver have not kept pace, and
• web and application development disciplines are vastly different to hosting and network infrastructure skills – we can’t seem to have beauty and speed!

Addressing performance issues

The objective here is not to find a way to fix the challenge. There are many smarter folk in the universities that are trying to solve it. The important thing for this discussion is to understand that throwing hardware at a problem won’t necessarily fix or improve performance (at least not cost-effectively) and that the initial design and framework piece is critical to ongoing usability. Consider the target device, environment and how to best get the message to that platform quickly and with minimal baggage.

What surprises me most about the numerous discussions and email exchanges with readers is the lack of understanding or appreciation for this downward trend in web performance. Despite a litany of reports and white papers and stats and figures showing the degrading response times, the overwhelming noise is around the excitement of responsive web design, or the latest six-megabyte brand homepage that really hasn’t been properly tested on a public Wi-Fi using an old Android smartphone.

Ecommerce sites are loading their headers with third-party plugins and tools only to have sites crash when minor spikes in traffic occur. One online retailer I spoke to had to increase their hosting infrastructure by five times that originally estimated just to get acceptable response times in normal traffic conditions.

It’s not all doom and gloom

While web developers and web application vendors ignore performance and keep building feature-laden, bloated, immersive and engaging sites, there are a handful of infrastructure players that have been working on solving this speed challenge. The challenges are more than just performance – when you get to accelerate websites and protect them from attacks, traffic spikes and downtime, there are a host of considerations in play. Ultimately, many of our legacy technologies like CDNs (fancy FTP, file transfer protocol, servers ‘repurposed’) and web servers can’t really be patched any further to address the issues. Instead, firms like Heroku.com and Yottaa.com have engineered solutions from the ground up, and we at Edge80.com want to be part of the solution, as well. They vary in how they’re implemented and the way they work, but provide an ability to eliminate much of the hosting infrastructure, including Varnish servers and pass-the-load balancing and spike management back to a true cloud-based platform.

Speed does matter. Size does matter. Response time does matter. Don’t ignore the final mile of delivery.

Responsive web design is great at the presentation layer, but not always well- suited for performance. Better roads and faster cars don’t reduce travel times when there are 10 times the cars and only one new lane. Throwing more hardware at the problem may help, but will change the ROI model and almost certainly hit the back pocket hard.

Think about the design, the content and the page structures. Carefully.