mobile

Case study: How effective are CDNs for mobile visitors?

9 May 2013

9 Comments

Substitute “measuring mobile performance” for “herding cats” in this video, and you’ve pretty much nailed the challenge we’re up against every day.

Fortunately, we like cats. :)

Experiment: Measuring the impact of CDN deployment on 3G performance

As we continue to evolve our mobile treatments, we also monitor their effectiveness alongside other optimization solutions. Today I want to call out some interesting results we noted when, as a fun little in-house exercise, we took the O’Reilly website, de-optimized it, and then iterated through a handful of core performance best practices using our FEO service. The goal was to demonstrate the acceleration benefit (in terms of bytes in, start render time, document complete time, connections, and resources) of each practice for a typical 3G mobile user.

While we saw predictable results for step 1 — enabling keep-alives and compression — we were somewhat surprised by what we saw when we added a content delivery network.

Step 1: Apply fundamental best practices

First we added keep-alive connections:

  • What it does: Lessens the impact of TCP connection setup
  • Benefit: Addresses the problem of having too many TCP connections

Then we added HTTP compression:

  • What it does: Compresses text-based content (HTML, CSS, JavaScript, etc.)
  • Benefit: Easy way to reduce bytes/payload

We got the results we expected: faster start render, and about a 25% reduction in doc complete time. This is fantastic, even more so because both these treatments are really easy to do — usually it’s just a matter of a single configuration option on your server, proxy, or load balancer. However, these two treatments aren’t enough to give you the acceleration you need.

Step 2: Use a content delivery network (CDN)

Here’s the elevator-ride explanation of how a CDN works (for an excellent detailed explainer, go here): Static page assets (images, CSS, etc.) are served from locations near the requesting client (mobile or otherwise). The shorter distance between client and content means smaller time to first byte (TTFB) and, ostensibly, faster start render. This means users start to see content in their browser faster.

How a content delivery network works

In our experiment, we expected that adding a CDN would result in faster average time to first byte, start render, and doc complete time. Here’s what we saw:

Before and after: Document complete (aka load time)

Before and after content delivery network deployment

Before and after: Time to first byte (TTFB)

Before-and-after CDN: Time to first byte (TTFB)What we helped

CDN before and after: What we helpedFindings

With a CDN, the page got faster, but not by much. For the unoptimized page, we forced requests to travel from west coast to east coast. After, we let the CDN naturally select the closest edge. As a result, we saw that:

  • Doc complete time decreased by 10%, compared to a 20% improvement we noted in a similar experiment in desktop optimization.
  • We shaved less than a second off start render time, taking it from 7.059 seconds down to 6.245 seconds.
  • True, we cut time to first byte by 39%, but from an end-user perspective, TTFB doesn’t really mean anything because the user still isn’t seeing anything in the browser.

Five questions about CDNs and mobile acceleration

I’m not making any nutty claims like “CDNs aren’t effective for mobile devices.” (Heresy!) But these results do raise a few questions:

  1. Is edge selection for mobile devices not as effective as for desktop?
  2. Some, if not all, CDNs probably deploy servers near cell network exit points. But what if most of the latency occurs inside the cell network? (I’ll admit I’m not an expert on what happens inside a 3G network. I’m ready to be enlightened.)
  3. Does the meaning of “closeness” change for mobile?
  4. Acknowledging the existence of mobile-specific CDNs, how much more effective are they? How do they compare when it comes to 3G versus WiFi? I’ve been trying to dig up case studies, with no luck.
  5. High CDN costs may be justifiable when you see significant benefit for your desktop traffic, but do they deliver sufficient benefit/ROI for mobile users?

Takeaway

LTE is grabbing a lot of attention, but it’s a mistake to sweep 3G under the rug. There are 256 million 3G subscribers in the US, representing 81% penetration, so 3G performance is still a big deal. We need more research. If you have findings to share, please do.

Related posts:

By: Tammy Everts Category: 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: Tags: , , ,

Web Performance 101: An opinionated guide to the 22 links every developer should read

31 Jan 2013

18 Comments

If you’re just starting out on your web performance journey, it’s easy to feel overwhelmed by how much there is to learn about something as “simple” as making pages faster.

When I started this blog three years ago, if you wanted to learn about optimizing performance, the pickings were on the slim side — though generally you could count on any resources you found to be pretty solid. These days, things are different. There’s a massive number of blog posts, videos, and slide decks — but the problem is that there’s a lot of redundant (or to be frank, not super great) information out there.

In this post, I’m going to separate the wheat from the chaff and offer my opinionated guide to the links you should check out if you’re a dev who’s new to the performance scene.

The Manifesto

The Vanilla Web Diet

Despite years of development and performance advocacy, the internet has a serious obesity problem that’s hurting application and page speed. This is a great piece from Smashing Magazine that discusses the reasons behind this trend and finishes with a bold declaration.

The Essentials

If I were teaching a course about performance, these would be required reading/viewing on week one.

Steve Souders’s 14 Rules for Faster-Loading Web Sites

Like Mecca, all web performance roads lead back to Steve Souders’s original performance rules. If you do your job right, one day you’ll have these committed to memory.

Faster Websites: Crash course on web performance

As I mentioned in last week’s podcast, what Google developer advocate Ilya Grigorik doesn’t know about performance isn’t worth knowing. In this three-hour video, he gives an awesome overview of the subject.

The Basics

Make sure you’re taking care of the easy stuff before you dive into the hard stuff. How to pluck the low-hanging fruit from the performance tree.

Waterfalls 101: How to read a waterfall chart

First, you can’t be in this business unless you know how to read a waterfall chart. Our VP Product, Hooman Beheshti, breaks it down really well in this recorded webinar. (If you want the written version instead, there’s a post here.)

Let’s Do Simple Stuff to Make Our Websites Faster

Four easy things you can do to make your website faster.

Slow website? Five ways to speed it up

Five more ways to speed up your pages.

Mobile

If you want to still have a job in performance in five years, I suggest you bone up on mobile.

15 things you can (and should) do to make your site faster for mobile users

Mobile devices and browsers pose some unique performance challenges. There are a number of fundamental and advanced tactics that you can use to take on these challenges and win.

Mobile HTML5

Maximiliano Firtman created this awesome table that illustrates HTML5 compatibility across major mobile and tablet browsers.

Responsive Web Design

Technically, RWD belongs with mobile, but it’s such a hot-button topic these days that I wanted to give it its own section.

Creating a Mobile-First Responsive Web Design

Really, you should just read pretty much everything Brad Frost writes about RWD. This is a good place to start.

Responsive Responsive Design

You may have heard that responsive design means poor performance. Tim Kadlec discusses why this doesn’t need to be true.

Images

Images are one of the single greatest performance problems, but they’re not sexy so they don’t get the attention they deserve. I’m working on a separate post about this, but in the meantime, check out these links.

Optimizing Web Graphics

Good introduction to image optimization from the folks at the Google Dev Blog.

Progressive jpegs: A new best practice

Photos are the main culprit when it comes to slow rendering. Eye-opening stuff about the adoption of progressive jpegs and how well progressive jpegs load across different browsers.

Third-Party Scripts

Third-party scripts are a huge potential point of failure. You need to know how to mitigate this.

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

This post will help you understand the third-party problem and how to get a handle on it.

Social button BFFs

Good tutorial from Stoyan Stefanov explaining how to make your social buttons load asynchronously.

Complete asynchronous ad loading using DFP and LABjs

You can’t optimize the ads that appear on your site, but you can at least ensure they’re not blocking the rest of the page. Sajal Kayan explains how to use DFP’s iframe tagging, combined with LABjs and little bit of JavaScript hackery, to make any ad load asynchronously with negligible impact on rest of the pageload.

Security

Security is an increasingly urgent issue. You need to know what impact it has on performance.

Speed vs. security: Four ways that security solutions can cause performance problems (and what you can do about it)

Security solutions can be performance bottlenecks, but this doesn’t get talked about very much so I wrote this post about it.

5 easy tips to accelerate SSL

Some folks believe that we just have to suck up the fact that SSL is slow. Not true. Here are some relatively simple workarounds.

SSL Performance Case Study

SSL (Secure Sockets Layer) optimization is extremely complicated, but as William Chan argues, “There’s low-hanging fruit everywhere” for site owners willing to try. In this article, William takes us through an in-depth case study of SSL optimization.

Fonts

Web Font Performance: Weighing @font-face Options and Alternatives

Great collection of tips for making sure your web fonts aren’t slowing down your pages.

Tools

WebPerfDays: Performance Tools

At WebPerfDays London, Steve Souders asked attendees to name their favourite web performance tool. This is a great roundup of tools that smart folks are using.

Improving site performance with YSlow

YSlow is one of the most commonly used tools for helping you analyze the performance of a website based on performance best practices. It’s available as a plugin for all major browsers except Internet Explorer, and it offers usable insight into real-world performance. This tutorial is a great introduction for anyone using YSlow for the first time, or for those who want to learn to use it better.

Configuring an ‘all-in-one’ WebPageTest Private Instance

Using WebPagetest to test a private instance –- i.e. an application that isn’t publicly accessible -– is reasonably straightforward save for a few small differences. Andy Davies walks us through the process.

The Back End

Speeding Up Your Website’s Database

We tend to focus on the front end (and for good reason), but sometimes it’s the back end that’s at least partially to blame. This is a good how-to piece from Smashing Magazine that explains how a database can slow down your site, and how to speed it back up again.

Read more

This is skimming just some of the cream off the top. I’m sure I’ve missed a few links, so feel free to suggest them in the comments and I’ll update this list. If you want to really dig deep, we have a massive Web Performance Hub on the Strangeloop site where we post every great link we find, and I definitely encourage you to check it out.

Related posts:

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

Geoffrey Smalling (CTO, Wine.com): Why performance measurement is an art form, how mobile is a game changer, and where the cloud fits in [PODCAST]

10 Jan 2013

3 Comments

It’s hard to believe it’s only been a month since launching the Web Performance Today podcast. I’ve spoken with some really smart folks so far, and I’m tremendously excited about the upcoming interviews we’ve lined up.

Till now, we’ve heard from some great minds in the performance solution space — guys like Cliff Crocker and Theo Schlossnagle. This week, we’re going to hear from someone who buys those solutions: Geoffrey Smalling, CTO of Wine.com. (Full disclosure: Wine.com is a Strangeloop customer.)

Despite being the number one online wine seller in the world, Geoffrey still considers Wine.com a small ecommerce site, but the insights he shares are relevant to owners and developers of ecommerce sites of all sizes.

While Wine.com may not be an Amazon, it does an inspiring job of taking a big-company approach to performance. The company had its “aha” moment back in 2009, when A/B testing revealed that fast stripped-down versions of pages vastly outperformed the gorgeous bells-and-whistles versions. Since then, they’ve been on a mission to make every single release of their site faster than before, with a goal of delivering every page in 3 seconds or less.

Geoffrey and his team aren’t afraid to adopt new technologies. (On top of Strangeloop, they’ve also been using New Relic for more than a year, and Geoffrey is a big fan of their product; you’ll learn why in the podcast.) He also has a lot of experience with turning down technology vendors, and in this interview he shares his major pet peeves about salespeople.

I enjoyed chatting with Geoffrey immensely, but I especially enjoyed talking about one of my pet topics — mobile. Wine.com has experimented with everything from m.dot sites to iPhone and iPad apps, and the company does a phenomenal job of tracking its successes and failures. Geoffrey was remarkably candid in sharing some of these successes and failures with me. He also shared some astute observations on current mobile usage and where he sees this platform going.

I hope you enjoy this podcast as much as I did. Thanks for listening. :)

Listen to the podcast: Geoffrey Smalling

Related posts:

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

2013 predictions: The average web page will hit 2MB, Android will pull ahead of iOS for good, and your smartphone will get infected with a virus

11 Dec 2012

6 Comments

It wouldn’t be December without a batch of audacious predictions for the new year. Assuming we all survive past December 21st, here’s what I think 2013 will hold for site owners, mobile users, CIOs/CTOs, RUM vendors, and the browser wars.

1. The average web page is going to hit 2MB.

A year ago, I predicted that the average web page would hit 1MB in 2012, which it did in May. Today, the average page is 1280KB. In a post I wrote last month, I predicted that, at the current rate of growth, typical page size would hit 2MB in early 2014. I’m upgrading that prediction to the end of 2013. Call it a hunch. This has massive implications for site owners in terms of bandwidth, but mobile users will be hardest hit, from both a usability perspective and a throttling/data cap perspective.

2. By the end of 2013, at least half of all North Americans will own a tablet.

Currently, 29% of North Americans own some kind of tablet. With the proliferation of new inexpensive tablets, with the emergence of kids as a mostly untapped tablet market, and with Christmas just around the corner, I’m predicting that more than 50% of North Americans will own a tablet by year end.

3. Global mobile traffic will hit 25% of total internet traffic.

Right now this number is 13%, but numbers are surging in China and India.

4. 25% of online shopping will be via mobile.

With the explosive adoption of tablets, we’re going to see a major jump in mobile shopping. Mobile phones and tablets represented 24% of online shopping on Black Friday, up from 6% just two years ago. We’re going to see that Black Friday stat become the norm.

5. 2013 will be the year your smartphone gets infected with a virus.

You know it’s coming. Cue the dark lords of anti-virus software to the rescue.

6. Android will pull ahead of iOS smartphone adoption. For good.

In five years, we’re all going to look back on 2013 as the year Android pulled ahead for good on smart phones. When it comes to this kind of call, I use the Strangeloop team as the canary in the coal mine. My dev team is moving to Android en masse. I haven’t seen this type of shift since 2009 when the mass exodus from Blackberry began.

7. Mobile performance will continue to be a major problem.

Mobile sites will remain too slow. Too many people still believe that their simplified mobile site is the answer (which it’s not, because it’s often too simple), or that responsive web design is the answer (which it’s not, because RWD pages can actually be even bigger and slower than a typical page). There’s no single magic bullet for mobile performance. Companies are going to have to really apply themselves to finding solutions that work for their unique situations.

8. This will be a great year for Chrome, an okay year for Internet Explorer, and a bad year for Firefox.

Internet Explorer will halt the bleeding and stabilize, but not grow, its market share. Chrome will hit 45% of worldwide browser market share by the end of the year — almost entirely at the expense of Firefox.

9. Two of the four largest CDNs will be acquired and integrated into larger companies.

I’m not naming names, and I have no inside information. This is just my hunch that we’re going to see big changes in this market.

10. Netflix will continue its decline, while Amazon video delivery will ascend.

Amazon’s rise in video delivery to the home will become evident in 2013. Amazon can outspend almost anyone for content — and when it comes to video, content trumps all.

11. DDOS attack mitigation will dominate the enterprise.

There’s nothing CIOs/CTOs hate more than visible failure. Sixty-five percent of the top ecommerce sites will have a mitigation strategy in place by the end of 2013.

12. RUM vendors will finally start to make money.

Real user monitoring will move from the sideshow to the main stage for half of analytics vendors. We’ll even see the first example of actionable RUM, which operations can use to trigger alarms that matter. Operations will start to trust RUM. By year end, RUM will be found on 35% of ecommerce sites.

Related posts:

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