Cloud Connect 2013: Web acceleration and front-end optimization [SLIDES]

10 Apr 2013

0 Comment

If you ever get a chance to hear Hooman Beheshti speak at a conference, drop everything else and go. Hooman has a way of talking about performance that’s incredibly accessible (read: he’s really good at not making you feel bad that he’s so much smarter than you), and every time he speaks at an event he gets rave reviews that I would be jealous about if we weren’t such good friends.

Last week, Hooman spoke at Cloud Connect in Santa Clara, and I asked him if I could post his slide deck here. It’s an excellent overview of the business value of performance, mobile performance issues, measurement and tools, front-end problems and front-end optimization (FEO), the role of CDNs in performance, and some great case studies and examples.

I also wanted to call out a couple of bits of eye candy, because I know there are always a few of you out there on the prowl for new biz value graphics to use in your own presentations. It’s also really interesting to see familiar data presented in a fresh way, which can trigger new insights.

First is the oft-quoted Google research about the impact of load time slowdowns on search. You may have heard these stats before, but this simple graph really drives those numbers home.

Cloud Connect 2013: Impact of page load time on average daily searches (Google)

A reduction of 0.6% may not sound like much, but when you consider that this is a result of a slowdown of less than half a second, and if you also consider the net impact across all of Google’s traffic, it’s pretty staggering.

I also really like this graphic interpretation of Bing’s well-known research, in which they segmented their traffic and served slower pages — in some cases up to 2 seconds slower — to different segments. It’s easy to see at a glance the impact on queries, clicks, revenue, and user satisfaction.

Cloud Connect 2013: Impact of additional delay on business metrics (Bing)Again, you can see how little it takes to hurt metrics. Revenue dropped by more than 1% with just a 500-millisecond delay, and by more than 4% with a 2-second delay. It’s also interesting to note that while the 200-millisecond delay may not have directly affected revenue, it did have a measurable impact on user satisfaction, which is a good reminder of just how sensitive users are to even the smallest changes in load time.

Related posts:

By: Tammy Everts Category: Best Practices, Cloud Tags: , ,

Three web performance SLAs every site owner should consider

1 Apr 2013

1 Comment

In recent podcast chats with Tim Morrow, Mark Jennings, and Geoffrey Smalling, the topic of performance service level agreements keeps coming up, and I think the topic merits a post. Here’s why.

With a good SLA, everyone wins.

Clients are protected from poor service, while also gaining a clear understanding of what to realistically expect from their supplier.

Suppliers are protected from unrealistic client demands, while also benefiting from having a consistent yardstick for meeting expectations, as well as an incentive for exceeding expectations.

Sounds great, right? So why haven’t more companies adopted this practice? A bunch of reasons, all of which are pretty understandable, such as: fear of accountability, inadequate tools for reliably measuring performance, lack of management buy-in, negative past experiences with poor/unrealistic SLAs. But if we truly care about delivering a top-tier online experience, we need to get over these obstacles.

There are three key areas that would benefit from having a solid service level agreement in place:

1. Customer-facing performance SLA

I’m not the first person to champion this idea. People like Jonathein Klein and Stephen Thair have been making eloquent calls for this kind of public performance contract over the last couple of years. To be frank, I don’t think most customers would ever read it (though if asked, the average person would probably tell you they think it’s a good idea because speed matters to them).

But I think the real value of this kind of performance SLA is internal: making a public declaration is a potentially great motivator for making your team accountable for delivering on your promise.

Back in 2011, Jonathan shared an example of what I still think is the best performance SLA I’ve come across:

“The homepage of our site will load in under 3 seconds measured at the 80th percentile via synthetic tests running in New York, LA, Seattle, and Miami every 30 minutes. We will measure this SLA at 8:00AM every morning and base it off the last 24 hours of data.”

This is a perfect yardstick — it’s short, snappy, and quantifiable. Whether you’re a developer or an executive, this is something you can get behind. If you’re looking for a template for your own SLA, this is a great place to start.

2. Third-party provider SLA

Third-party scripts are one of the most common points of failure for sites. At best, unoptimized scripts can slow down your load time, sometimes by many precious seconds. At worst, third-party outages can stall page load completely.

The average top ecommerce site contains 7 third-party scripts, with some sites containing up to 25 scripts. Yet despite this proliferation, most third-party providers don’t offer real-time monitoring of their scripts, nor do they offer meaningful service level agreements (SLAs). In my experience, the only way most people discover third-party SPOFs is by accident, when they visit their own sites.

Sure, you can defer many of your scripts so that they load last, but this isn’t always an option — for instance, when it comes to your third-party ads.

I dream of a world where all third-party providers offer clear performance service level agreements to site owners. In my ideal world, these SLAs would:

  • Express their annual uptime guarantee as a percentage (ideally, as close to 100% as possible).
  • Describe 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.

Tag management companies have been jumping into the fray, with several vendors stating a clear focus on performance. This is a great start. 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.

For more detailed tips on how to create a meaningful third-party SLA, check out this great post over at Catchpoint.

3. Cloud provider SLA

The cloud offers huge benefits, but it also introduces a huge new area of vulnerability. It’s understandable that we’re tempted to demand control over the performance of our cloud-based applications, because this (or at least the illusion of it) is what we had before the cloud.

This demand is ultimately unrealistic. However, it is realistic to expect that, in exchange for losing some of the infrastructural control you used to have before you deployed your apps to the cloud, you should be able to ask your provider for more visibility and assurances in how their infrastructure will perform for you.

Here’s what it’s fair to ask from your cloud provider:

  • Analytics tools – You should continue to use the performance monitoring tools you already use to monitor your app performance with (WebPagetest, Keynote, Gomez, etc.), but you also need a new visibility toolset (that your cloud provider should help you with) so you can do root cause analysis over parts of the infrastructure that you don’t have control over or visibility into.
  • Detailed performance clauses in your service level agreements – Some cloud SLAs contain a performance clause that addresses availability, but speed is every bit as important as — and possibly more important than — uptime. This clause needs to spell out how your concerns about site speed will be addressed, should they occur.

I’m very curious to learn about other people’s successes and failures with performance SLAs. Have you come across an SLA that rocked your world? Is there another type of performance-related SLA I haven’t considered? Feel free to share in the comments, or email me directly at joshua [[at]] webperformancetoday [[dot]] com.

Related posts:

By: Tammy Everts Category: Cloud, Ecommerce, Third-party content Tags: , , ,

More new findings: Top ecommerce sites are 22% slower than they were last year

27 Mar 2013

8 Comments

Let me say that again, because this is a staggering fact: The world’s top ecommerce sites are 22% slower than they were last year.

In December 2011, the median load time for a site in the Alexa Retail 2000 was 5.94 seconds. Just twelve months later, the median was 7.25 seconds. At this rate of growth, this number could hit almost 9 seconds by the end of this year.

Web page load time changes: December 2011 to December 2012

This was the key finding of our brand-new quarterly report (yes, a new report, not to be confused with last week’s report about web performance in the EU) on ecommerce web performance. If you’re new to these reports, since 2010 we’ve been measuring the load time, page composition, and best practice implementation of the same set of 2,000 leading online retailers, as ranked by Alexa. The goal is to learn how pages are changing over time and what impact, if any, these changes have on per-page performance. The results have been eye-opening.

I have to confess that I frequently feel like that tiresome guy at the party who keeps saying the same things over and over again. Pages are getting slower… pages are getting bigger… the gap between load times and user expectations is getting wider almost by the week. If you’re reading this out there and saying to yourself, “I can’t believe that Bixby guy is going on about this AGAIN,” then forward the next part of this post to five people you think could really benefit from it. If enough people internalize this message, maybe I’ll shut up.*

Three performance myths I would give anything to permanently bust:

Myth #1. Pages are, de facto, getting faster.

What with our better systems, networks, and browsers, pages must be getting faster, right? Everyone believes this instinctively, because most of us seem to be hardwired to believe that technology solves problems rather than creating new ones. But as I said at the top of this post, the quickly emerging fact is that pages seem to not just be getting slower, they’re getting slower at an alarming rate. (Optional: You may choose to take this finding as proof that we shouldn’t always trust our instincts. :) )

Myth #2. Users are more or less satisfied with the status quo.

“People are used to pages that take 5-8 seconds to load. They don’t mind that much.” I still hear this on a regular basis. Site owners rationalize that, because they’re not hearing a lot of complaints, their visitors are happy… or at least happy enough. But as numerous case studies have shown, people talk with their wallets. Faster sites earn more. And user surveys over the years are telling us that people’s expectations for a speedy online experience are continually growing:

Web Page Load Time: User expectations 200-2012

Myth #3. Browser development is more than capable of mitigating the factors, such as page size and complexity, that are causing pages to slow down.

This belief is widely held, even among technical folks. Again, looking to our findings, we saw that for all three browsers, median load times slowed down by anywhere from 3% to 12% in just six months. This downward trend isn’t a browser development issue. Instead, it’s an indicator that despite browser vendors’ huge commitment to speed, development can’t keep pace with the demands of bigger and increasingly complex web pages.
Browser performance: 2011 to 2012

Takeaway: Pass it on.

I am extremely happy that Radware is committed to continuing the tradition of releasing these quarterly  “state of the union” reports. As time passes, we’re gaining some invaluable insights. Based on these latest results, I’m very curious to see what our Summer 2013 report will hold.

I urge you to download this report (and the infographics, too). And I was only slightly kidding when I suggested that you forward this post to people who need to have a few performance myths dispelled. Our community does a lot of preaching to the choir. What seems basic to us is not necessarily basic to the rest of the world. We need to get out there and make sure these simple messages are being heard.

*Maybe.

Related posts:

By: Tammy Everts Category: Best Practices, Ecommerce, Infographics, Research Tags: , , , , , , ,

Mike Belshe (Twist): “Time is fixed. It’s precious. We all wish we had more of it.” [PODCAST]

22 Mar 2013

2 Comments

I’m always being asked why I got into the web performance business. My standard response is that I got here via the content management systems I used to develop many years ago. We saw that there was a business problem, in that the companies that bought our CMS would then ask us if we could do anything to speed up page rendering, and so we started down the performance path.

But really, I got into this business for the same reason that many people — including you, perhaps — did: because I consider time the most valuable thing we have.

It sounds trite, but so do a lot of true things. As my most recent podcast guest, Mike Belshe, says, “Time is fixed. It’s precious. We all wish we had more of it.”

This attitude is what prompted Mike to create Google’s groundbreaking SPDY protocol, which has the potential to fulfil Google’s stated mandate: make the web universally faster.

And even though Mike left Google a year and a half ago, this attitude remains a driver behind his latest experiment, Twist — an online service that could radically reduce the amount of time you waste waiting for your chronically late friends to show up (or a myriad of other waiting-game scenarios). I’ve tried it, and it actually is kind of miraculous how well it works.

In this podcast, Mike and I had a far-reaching discussion about time, SPDY, Twist, mobile, native apps, and HTML5 versus Java. I enjoyed it immensely. I hope you do, too.

Listen to the podcast: Mike Belshe

Related posts:

By: Tammy Everts Category: Podcast Tags: , , ,

New findings: Typical leading European commerce site takes 7.04 seconds to load

19 Mar 2013

3 Comments

Last fall, at Velocity London, I had a really great talk with Stephen Thair, who is a UK-based web performance consultant, Velocity committee member, WebPerfDays organizer, and all-around knowledgeable guy. Among other things, we talked about how frustrating it can be for performance pros based in Europe to preach outside their community.

As Stephen said:

“I guess it’s a bit frustrating in the UK at the moment. One of the things that I found is that we haven’t yet got that killer web performance case study in one of the big major retailers. So we are still, I think, a bit in the evangelical stage. We are still trying to get the message out there. There are still a lot of websites in the UK that don’t even have gzip turned on.”

So we set out to help fill that gap. In December of 2012, working with Radware (our soon-to-be parent company) in conjunction with our partners at Level 3 in Europe, we studied the page speed and composition of 400 top European retailers, as ranked by Internet Retailer magazine, to see how these sites would load for visitors using Chrome 23 (the most popular browser in the EU at the time of testing) via the test server in Amsterdam. (We chose the Amsterdam location because it allowed us to test across all major browsers.) The report was released today.

While the results may not be shocking if you’ve been paying close attention to this space, they may come as an eye-opener to online retailers in the EU. Our chief finding was this:

The median page took more than 7 seconds to load.

Depending on whom you ask, the average internet user expects web pages to load in less than 3 seconds, 2 seconds, or even 400 milliseconds. The last time the average person reported being cool with 7-second load times was around 2001.

The survey also found that:

  • 1 out of 4 pages took more than 10 seconds to load.
  • 1 out of 3 pages contained more than 100 resources.
  • 79% of sites don’t use a recognized CDN. (A “recognized CDN” refers to any CDN listed in the extensive directory of CDNs maintained by WebPagetest.)
  • Speaking to Stephen’s point about gzip at the top of this post, 1 out of 5 sites failed to implement text compression, a relatively simple technique that delivers easy, significant performance gains.

Why you should care about these findings

I may be pointing out the obvious, but it may need to be pointed out: these expectations are universal. Internet users in the EU do not have lower performance expectations than users in North America. These findings should be a wake-up call for European site owners. (Not that North American site owners should be resting easy. Last fall, we found that the median leading US commerce home page took almost 7 seconds to load.)

Download the report: State of the Union: European Ecommerce Page Speed and Web Performance

Related posts:

By: Tammy Everts Category: Best Practices, Ecommerce, Research Tags: , , , , , , ,
1 2 3 4 5 6 7 8 »