Google

Downtime may grab headlines, but slow website performance is the silent-but-deadly #1 enemy

30 Nov 2010

10 Comments

When I got back to my desk on Monday morning, I had not one, not two, but eight different emails from colleagues, sending me the same article about the Black Friday outages suffered by JC Penney and American Eagle.

I’m not surprised by this (the emails, I mean, not the outages). Spectacular site outages are the most visible form of IT failure, and, like car crashes, they get the most media attention.

But if we look at the results from Black Friday, while the spectacular car crashes of JC Penney and American Eagle may attract the attention, the real revenue killer is still site speed. But you won’t read headlines about this.

Site speed and site performance are not sexy and spectacular. It’s hard to get an editor excited about running a story with a headline like “An ecommerce site took 12 seconds to load from my house, so I got frustrated and went to a competitor.”

Yet my esteemed colleague, performance expert Lenny Rachitsky, has gone on the record (if Twitter is considered the record) as saying “Downtime is better for a B2C web service than slowness. Slowness makes you hate using the service, downtime you just try again later.”

A tale of two ecommerce mega-sites

To elaborate on this point, let’s compare JCpenney.com with one of its competitors, Macys.com:

Website Availability Page load time (seconds)
Macys.com 100% 21.186
JCpenney.com 99.10% 7.231

According to this news release from performance monitoring company WatchMouse, JC Penney’s website was down for a total of 6 hours and 42 minutes on Black Friday. This is definitely something that JC Penney should be — and no doubt is — concerned about.

But let’s look at Macy’s, which had no downtime issues over the holiday weekend, but whose home page takes an incredible 21.186 seconds to fully load, compared to JC Penney’s passable load time of just over 7 seconds. If we look at the stats on the direct relationship between performance and revenue, and apply the formula that a 1-second performance improvement nets out to be about a 7% increase in conversion, we can deduce that Macy’s slowness is, quite arguably, a much greater revenue-killer than JC Penney’s one-off downtime issue. A relatively slow site like Macys.com might have lost upwards of 30% of its potential revenue this weekend to competitors, due to its poor performance.

There’s also the long-term effect of slow performance. A 1-second delay equals a 16% decrease in customer satisfaction. This dissatisfaction leads to fewer return visits and negative word of mouth. In fact, joint research by Microsoft and Google found that the cost of slowness increases over time and persists for weeks even after site performance is improved.

Users brush off isolated downtime incidents. They don’t brush off the lingering effects of slow page speed.

And yet, given all this, JC Penney made headlines. Macy’s did not.

Right now, site downtime represents the single greatest fear of all IT professionals. Given the massive potential losses caused by slow site performance — a silent and deadly conversion killer — I suggest that sub-par page load times share that top spot.

Related posts:

By: Tammy Everts Category: Tags: , , ,

Almost half of the top 1000 retail websites don’t follow two easy performance best practices. Does yours?

22 Oct 2010

13 Comments

I’m hip-deep in data from a big research project (the topic is still under wraps) that we’re working on here at Strangeloop. We’ve been studying the top 1000 online retailers, and we noticed a trend so significant that it merits some attention of its own.

Check out these charts showing how the top 1000 retail sites rated with two page speed scores: Keep-alive Enabled and Compress Text.*

Alexa Retail 1000: Page speed score for keep-alivesAlexa Retail 1000: Page speed scores for text compression

Summary

  • 85% of these sites use keep-alives.
  • 53% do compression.
  • But when I overlaid these two sets of numbers, I was surprised to find that 47% don’t do one or the other.

These are two of the easiest, lowest-hanging fruit on the performance optimization tree, and almost half of the leading retail websites aren’t taking advantage of them simultaneously.

Keep-Alives

TCP connection is the process by which both the user and the server send and receive acknowledgment that a connection has been made and data can begin to be transferred. Too many TCP connections will slow down your site. It’s not easy to speed up TCP connection, but you can control how many times the connection takes place.

If you’re an exec/marketing manager: First, test your site and get its keep-alive score. If it’s anything less than an A, then take a look at your site’s waterfall chart. (Here’s a quick primer on how to interpret this chart.) If you’re seeing a lot of orange bars, you have a problem that could be fixed by using keep-alives.

If you’re in dev/ops: Make sure you have the proper configuration on your servers and load balancer. Also, we saw a number of CDNs that don’t do keep-alives properly, so keep your eyes open for lots of orange bars on content coming from your CDN.

Compress Text

The average size of the web pages we studied is 836kb, which is a major slowness factor. Compressing resources can reduce the number of bytes sent over the network. Text compression isn’t the only way to reduce your payload, but it is the easiest.

If you’re an exec/marketing manager: As above, test your site and get its compress text score, then check out its waterfall chart. If you’re seeing a lot of bright blue bars, you have a problem that could be fixed through compression.

If you’re in dev/ops: Make sure you’re following Google’s best practices for compression, as outlined here.

Don’t underrate these two simple measures.

They can have a huge impact on page speed. In a session where I first de-optimized, then re-optimized, the Velocity website, the first fixes I implemented were keep-alives and text compression. With just these two fixes, the site experienced major improvements in these areas:

  • Start render: 52% faster
  • Document complete: 40% faster
  • Fully loaded: 31% faster

These two steps alone are not enough, but they’re definitely must-haves before you reach for the fruit on the higher branches.

*All tests conducted on Webpagetest — IE7 on DSL via the server in Dulles, VA.

Related posts

By: Tammy Everts Category: Tags: , , ,

Demystifying web performance automation

15 Oct 2010

11 Comments

This past Wednesday, I had the great privilege of hanging out with the New York Web Performance Meetup crowd, where I led a session on web performance automation. If you’re interested, here’s the slideshow deck:

Web Performance Automation – NY Web Performance Meetup

Summary

I wanted to identify what kinds of performance best practices are manually do-able versus which practices lend themselves better to automation. After going over performance-related terminology and concepts — such as waterfall charts, first vs repeat views, and concurrency — we jumped into a hands-on case study: optimizing the Velocity website. (Full disclosure: O’Reilly recently became a Strangeloop customer, though we’re not yet implemented.)

Delivery vs transformation: The history of performance automation

It’s important to note how performance optimization has changed over the years, from a delivery-focused approach to a transformation-based approach:

Delivery = “I will deliver what the server gives me as efficiently as possible to the browser.”

Transformation = “I will transform what the server gives me to optimize it for the user’s browser.”

Methodology

This presentation is based on a similar session that I ran with Strangeloop’s VP Product, Hooman Beheshti, at the Velocity conference. Much like that session, I artificially “de-optimized” the Velocity site, then implemented a series of best practices, one by one, showing the speed improvements that accompanied each one.

We reviewed the major performance pains of the unoptimized site:

  • Too many connections
  • Too many bytes
  • Concurrency
  • Bad caching for repeat views
  • No CDN
  • Too many roundtrips
  • And some others

Then we implemented a handful of performance best practices (some from Yahoo and Google, and some from Strangeloop), starting with the low-hanging fruit:

  • Keep-alives
  • Compression
  • Client-side caching
  • Use a CDN
  • Reduce roundtrips
  • Reduce payload further
  • Increase concurrency

Throughout this exercise, we talked about the pros and cons of each of these best practices, including the work involved in implementing and maintaining them.

My hope in doing this session was to demystify the automation process, and show how it can complement hand-crafted optimization, making it another useful tool in the developers’ arsenal.

Many thanks to my hosts, Sergey Chernyshev and Alla Gringaus, who did an incredible job of coordinating the entire event, bringing together a great group of people and making me feel very welcome.

Related posts:

By: Tammy Everts Category: Tags: , , ,

Are your website’s performance goals audacious enough?

23 Sep 2010

18 Comments

“We want you to be able to flick from one page to another as quickly as you can flick a page on a book. So we’re really aiming very, very high here… at something like 100 milliseconds.”

~Urs Hölzle, Senior VP Operations, Google

Urs said this at Velocity this past June (you can hear it at 3:45 of this video), and it’s resonated with me ever since.

I talk a lot about the business value of performance and why there’s no such thing as fast enough. But to my knowledge, Google is the only big company out there that has truly internalized this philosophy. In fact, I was down in Mountain View at the Googleplex a few weeks ago, and I heard on more than a few occasions the 100 ms goal spoken about in real terms — things like “This project will help us get closer to the goal.”

I’m not trying to imply that the folks at Google are the only people who care about performance. If you’re reading this blog, you clearly care. But the folks at Google are the only people I’ve met who have a clearly stated performance goal: all pages on their sites will load in 100 ms or less. In fact, they take it one step further and have the audacity to try and get all pages on the world wide web down to 100 ms.

This is a fascinating contrast to the rest of our industry, which tends to focus on benchmarks as indicators of success:

  • The average website in Keynote’s “Business Top 40″ takes 2.34 seconds to load.
  • The average web page loads in 4.9 seconds.
  • The average Fortune 500 website takes about 7 seconds.

So, do you consider your site successful if it loads in less than 7 seconds? Less than 4.9? 2.34? How do you decide where to take aim? Or do you take the attitude that you’ll just sort of chip away at load time when you have time, and content yourself with the knowledge that everyone else has the same attitude?

Benchmarks are useful tools. They give us a sense of our place in the world, and how we perform relative to others. They’re a good starting point for self-analysis. The problem with benchmarks is when they tempt us to focus solely on how we compare to others, who may be as flawed as we are. Google has wisely stepped outside the benchmark arena and has created a goal that has nothing to do with their competitors and everything to do with the actual people who use their products.

Google’s decision to aim at 100 ms makes sense from a human factors perspective. 100 ms gives us the illusion of instantaneous response. 100 ms makes a web experience feel real.

Is 100 ms possible? No, not right now. Will it be possible? Yes, most definitely, largely through the efforts of people who didn’t settle for benchmarks.

My challenge to you is to ignore benchmarks. Create an audacious goal for your site. Evangelize it in your organization. And take aim.

Related posts:

By: Tammy Everts Category: Tags: , ,

UPDATE: Everything you wanted to know about web performance but were afraid to ask

9 Sep 2010

0 Comment

I’m cleaning out my old bookmarks and rediscovered a Forrester report from earlier this year, The Impact of Poor Web Site Performance in Financial Services. I’ve added the following key bits of data to my performance stats cheat sheet:

  • No activity on the web approaches the frequency of online account access.
  • Web site performance is second only to security in user expectations. Web site performance ranks above even functions like single sign-on or a website that is easy to use.
  • 56% of online bankers and brokers expect web pages to load in 2 seconds or less; this is far above the 47% of consumers who are just shopping online.
  • Poor website performance leads to dissatisfaction more often than any other factor. Sixty-four percent of online US bankers and brokers have had a dissatisfying experience when servicing their accounts. Web performance is far and away the biggest reason for this dissatisfaction.
  • As online tasks get more urgent or complex, online users are less likely to try later and more likely to move to more expensive channels to complete the transactions. Fifty-six percent of online bankers would move to offline channels to ask a general account question; 54% of online brokers would move to offline channels to trade investments if the website was unavailable or slow to respond.
  • The ultimate effect of poor performance is a decrease in willingness to recommend a firm, with 48% of online bankers and brokers saying that poor performance had an impact or significant impact on their likeliness to recommend a firm’s services to a friend or family member.

Also, in the time since I started creating this post, Gomez released a new commissioned report called When Seconds Count. It says that:

  • Nearly one-third (32 percent) of consumers will start abandoning slow sites between one and five seconds.
  • 39% say speed is more important than functionality for most websites, while only one in five rank greater site functionality as more important.
  • More than half of mobile users expect websites to load as quickly, almost as quickly or faster on their mobile phone, compared to the computer they use at home.
  • More than a third of mobile users (37%) said they would not return to a slow site, and 27 percent would likely jump to a competitor’s site.

Related posts:

By: Tammy Everts Category: Tags: , , , , , , , , , ,
« 4 5 6 7 8 9 10 11