site speed

Does the average web user waste two days a year waiting for pages to load?

Maybe. Maybe not. But the truth isn’t important. What’s important is that, in a recent survey of more than 1,500 web users, the average respondent says they feel that’s how much time they waste. And they’re not thrilled about it.

Other findings in this research, which was performed by the UK company 1&1 Internet:

  • 71% of respondents say they’re regularly inconvenienced by slow websites.
  • The average user estimates that they waste 9 minutes every day, or 2 days a year, waiting for slow pages to load.
  • Half believe that websites have either not improved in speed or have become slower over the past five years. Only one out of four web users believe that the websites they use are getting faster each year.
  • Almost one-third of users report that their performance-related stress or anger has increased over the past five years.
  • 78% of users say they’ve felt some kind of negative emotion as a result of a slow or unreliable website. 27% of men say they’ve felt stress or anger, compared to 34% of women.
  • 44% of users say that slow online transactions make them unsure about the success of the transaction.
  • 42% of men and 35% of women have decided not to use a company again as a result of experiencing a slow website.
  • Over the past five years, 37% of web users believe they’ve become more savvy about judging whether a website is running more slowly than it should.

The interesting thing about surveys like this that they don’t necessarily express the reality of web performance, but instead people’s perception of reality. This is a fascinating counterpoint to the hard-and-fast tool-driven metrics that people in our industry tend to focus on. And it’s a good reminder that we live in world where people perceive your pages as being 15% slower than they actually are, and later remember them as being even slower than that.

Takeaway: From an end-user’s perspective, performance is a feeling — not a metric in a report.

Related posts:

Bad news for site owners and mobile users: The average web page is now 1 MB

I wrote about this at greater length in this post for GigaOM (which also includes some nifty graphs), but want to summarize a few of the key points here.

  • According to the HTTP Archive, which gathers stats on the top million sites in the world (as ranked by Alexa), the average web page has surpassed the 1 MB mark.
  • In the past 18 months, the average web page has grown by 50% — from 702 KB in November 2010 to 1042 KB on May 1, 2012. (Side note: Since I wrote the GigaOM piece, the HTTP Archive has refreshed with new data. The average page is now 1059 KB.)
  • At this rate, the average page will hit 2 MB by 2015.
  • Images and third-party scripts (i.e. analytics, ads, social sharing buttons) are the main culprits.

Mobile users take the hardest hit.

Consequences include being throttled by providers or being hit with massive roaming charges. (For example, earlier this month I bought 25 MB of data from my provider for $100 while travelling in Europe. This works out to $4 per page.)

There’s a head-in-the-sand tendency to assume that just because our devices, browsers, and networks are more powerful than ever, end-user performance must also be getting better.

To disprove this, here’s a graph I created, in which I overlaid two sets of numbers spanning the past 12 months. The red line represents the page size data from the HTTP Archive. The blue line represents the mobile load time index from Keynote. While the two lines represent different data sets, it’s pretty clear that the general trend is up — bigger and slower.

Correlation between web page size and mobile load time

As I’ve said many (many!) times, building a mobile-specific site isn’t the answer.

One-third of a site’s visitors will choose to visit the full site if given the option between the two. That’s because people want the same breadth and depth of content and a consistent user experience, no matter what device they use. Site owners who can deliver a fast, reliable, cross-platform user experience are going to be the ones who own the web of the not-so-distant future.

Related posts:

Has your site’s third-party content gone rogue? Here’s how to regain control.

In my travels, I’m seeing a strange dichotomy when it comes to performance:

  • On one hand, site owners are pouring massive amounts of money and energy into site development and delivery.
  • On the other hand, these same site owners are ignoring the out-of-control proliferation of third-party scripts on their sites.

This raises the question: What’s the rationale behind running up a $100K+ monthly CDN tab — ostensibly to shave a couple of seconds off your load times — if you’re going to then implement a single line of unoptimized JavaScript that could not only negate those precious seconds, but take down your site completely?

The answer, more often than not, is this: There is no rationale. Most site owners are either unaware of this issue, or they don’t realize its seriousness.

If the issue of third-party performance is new to you, this post will help you:

1. Understand the impact of all those harmless-looking little snippets of code.
2. Regain control over rogue third-party content.

Background: Third-party scripts are everywhere. Some are fine. Most aren’t.

A few months ago, the folks at New Relic did some digging into the most popular third-party APIs used by the 200,000+ applications the company monitors and took a look at which ones performed the best. No surprise, these are all familiar names:

  • Amazon Web Services (response time: 432ms)
  • Twitter (response time: 832ms)
  • Facebook (response time: 918ms)
  • PayPal (response time: 1.788s)

This is good news for site owners… assuming these are the only four scripts you’re running. But third-party content — analytics, ads, trackers, social sharing widgets, etc. — are on the rise.

As I wrote here several months ago, the average top ecommerce site contains 7 third-party scripts, with some sites containing up to 25 scripts. Cumulatively, these can have a massive impact on page performance. Unoptimized scripts can slow down page load by several seconds, or even stall it completely. Third-party scripts are one of the most common points of failure for sites: just a single line of JavaScript can take down your entire site. Despite this, measuring the impact of third-party content on a site’s usability is often an afterthought — if it even gets thought about at all.

If you want to scare yourself, run a simulation using WebPagetest to see how your site would perform if one of its third-party providers went down. As a for-instance, here’s a simulation I ran, which shows what would happen to Staples.com if its third-party providers went down:

In this case, the main culprit is Omniture, which stalls the site for a full 30 seconds when it goes down. Note that about 50% of top ecommerce sites use Omniture. (I say this not to pick on Omniture, but to point out that if they ever go down, they’re going to take down a lot of sites with them.)

Outages are inevitable. As site owners and managers, our job is to figure out a strategy to mitigate these outages.

I dream of a world where all third-party providers offer clear service level agreements to users.

In an ideal world, all third-party providers would offer a clear SLA that, at the very least:

  • Expresses their annual uptime guarantee as a percentage (ideally, as close to 100% as possible).
  • Describes the process for reimbursing site owners (if site owners are paying for the service provided by the script) if uptime drops below the SLA guarantee.

Right now, most third-party providers don’t offer real-time monitoring of their scripts, nor do they offer meaningful service level agreements (SLAs). My hope is that, as site owners become more educated about the importance of page speed, they’re going to start demanding properly optimized scripts, as well as better monitoring, reporting, and accountability.

In the meantime, what can site owners do to take control of third-party performance?

Until recently, adding third-party code to your site meant giving up a lot of control over how your pages load. Not any more (sort of). Here are four options at your disposal:

1. Deferral

In simplest terms, deferral is a front-end optimization technique that delays the execution of non-critical scripts until the rest of the page has loaded and rendered on the browser.

Pro: It’s a relatively easy fix.

Con: Deferral won’t work for all content. If your site hosts ads, your advertisers won’t be happy to have their ads show up last. Save deferral for third-party scripts like analytics beacons, tracking pixels, and social widgets.

2. Asynchronous loading

With asynchronous loading, third-party scripts load in parallel with the crucial page content. Async code can be tricky to program, which is all the more reason why it’s been gratifying to note its increasing rate of adoption among third-party providers. All the social buttons on this blog are async versions. (You can read about why I removed the non-async StumbleUpon button.)

Pro: Lets you display ads and other business-critical third-party content without blocking primary content.

Con: Slow third-party scripts will prevent onLoad event from firing. This post will give you a detailed understanding of how the onLoad event works. But the short answer is that a page’s onLoad determines its load time as measured by performance measurement tools. Too many delayed onLoads will mess up your results. If you’re tracking thousands of pages over extended periods of time, these messed-up results will make it a pain to pinpoint other potential performance problems.

3. Third-party timing and script killing

Also known as “tag management”, this technique involves establishing an allotted time for scripts to load. Then, if a script fails to load in that time, it’s either killed or deferred. Strangeloop has been an early pioneer of this technique in both our desktop and mobile FEO solutions, and it’s been gratifying to see it catching on.

Pro: Gives site owners the most control over third-party content.

Cons: Doesn’t lend itself to hand-coding. Best performed by an automated system.

4. Just say no

Ask yourself if you really need that widget. Perform a cost-benefit analysis of what a proposed new third-party tool offers your site and determine if it’s really worth the performance hit. Because make no mistake about it: there’s always a performance hit. And too many hits, no matter how small, add up.

Pro: Status quo is easy to maintain.

Con: Can be incredibly difficult to resist the siren song of the latest widget du jour.

And don’t forget to audit your third-party scripts.

It doesn’t matter how well you optimize the rest of your site if a single line of external JavaScript can take out the whole thing. If you aren’t already conducting regular audits of your site’s third-party content, you should be. The audit should identify:

  • All the third-party scripts your site is running, and on which pages they appear.
  • Which of the above performance practices (load asynchronously, deferral, timing/killing) each script follows.
  • Does the third-party provider offer a service level agreement? If so, what are the terms?

What’s your experience with third-party snippets? Which ones are worth the performance hit? Which ones should send us running to the hills?

Related posts:

Marrying CDNs with front-end optimization for maximum acceleration

Content delivery networks (CDNs) make sites faster. Front-end optimization (FEO) solutions like the ones we develop at Strangeloop make sites faster. But in our industry, there’s very little talk about the dynamic between CDNs and FEO. This morning, I had a great opportunity to talk about this at the 2012 Content Delivery Summit.

If you’ve ever looked for hard data about the combined benefits of a CDN+FEO solution, you’ll be interested in the slides from my session. It includes a case study that clearly shows the acceleration gains using just a CDN, then the additional gains of adding FEO to the mix:

As I mentioned in my talk, this year is going to mark a lot of major innovation in desktop and mobile acceleration, including aggressive advances in CDN and FEO technology. A few other trends I’ve noticed from the trenches:

  • 200+ of the top ecommerce sites have been running automated FEO for two or more years.
  • 5 out of 10 internet retailers have an automated FEO strategy and plan to implement it in 2012.
  • FEO-accelerated sites are 30-50% faster than non-FEO sites.
  • CDNs are increasing their MRR with customers by 40-50% on top of existing acceleration solutions like DSA.

Many thinks to Dan Rayburn, who organized the summit and invited me to speak. It was a great opportunity to speak with a new audience, alongside an excellent roster of speakers.

Related posts:


Velocity podcast: The Business of Performance

A while back, I spoke with Mike Hendrickson at O’Reilly about how to measure and make sense out of performance from a business perspective. It was a pleasant surprise to see the resulting podcast featured on O’Reilly Radar today.

It’s a pretty short video, but if you’re in a rush, you can skip the first five or six minutes where I talk about how we launched Strangeloop as a performance pioneer six years ago, and get right into the juicy stuff about the business value of performance at around the seven-and-a-half-minute mark.

Last week, O’Reilly also ran a great interview with our VP of Technology, Hooman Beheshti, which you should check out. Hooman will be talking about advanced front-end optimization for mobile at Velocity this June, and even if he didn’t work here, I’d still encourage you to attend his session. When it comes to FEO, and to performance in general, he’s one of the most knowledgeable people you could hope to find, and he has an amazing gift for explaining complex material in an interesting, entertaining way.

Related posts: