Notes from Velocity 2013: What people are saying about user experience, RUM, and mobile performance

I haven’t been to a Velocity conference since 2011, so it was great to get out of my little ivory tower (just kidding: my tower is made out of regular old cinderblock) and get down to Santa Clara last week. I’m so glad I went. Excellent sessions, inspiring speakers, great hallway conversations and connections — I’d forgotten how fun a conference can be.

But here’s the bad news: No one has yet figured out one performance solution to rule them all.

But there’s also good news: If you specialize in performance, there’s still a lot of fun work cut out for you. Job security FTW!

“User experience” — it’s everywhere!

Everywhere I went, I heard people talking about “the user experience”. This might seem like a no-brainer — hasn’t performance always been about the user experience? — but this term hasn’t been all that widely used  in the past. You might accuse me of splitting semantic hairs, but terminology shifts like this are meaningful. As a hardcore UX person, it’s gratifying to hear people speaking my language.

RUM heavily dominated the sessions, discussions, and  trade show floor.

Yet despite this, every time I chatted with performance engineers at household-name companies, I learned that these companies were using multiple RUM solutions and gathering tonnes of sophisticated data, but operationalizing virtually none of it. Clearly, there’s a massive gap between what the tools can do and what people are actually using the tools to do. This isn’t the fault of the people who are using the tools, but rather an indicator of how quickly RUM has come onto the scene.

Free measurement tools are still #1.

Further to the point above, I wasn’t surprised to learn in several sessions that big companies are still relying on clever in-house hacks using free tools like Google Analytics, WebPagetest, and the HTTP Archive. Again, this highlights the gap between the tools that are out there and what people are using.

People were also talking about…

Other than RUM and user experience, recurring topics included:

  • mobile (still challenging)
  • third-party content (still a massive single point of failure risk)
  • images (still too many of them, and too many are poorly optimized, especially for mobile)
  • caching (most sites still aren’t doing it right)
  • JavaScript (often used unnecessarily, creating significant performance pain)
  • web fonts (still a pain in the neck)

And presenters dropped some solid wisdom…

Some interesting factoids I picked up to add to my permanent collection:

  • Only 3.6% of all page views per month are WPO-accelerated.
  • If a page takes 8+ seconds to load, visitors will spend only 1% of their time on page looking at ads.
  • 50% of your 1-second page load time budget on mobile is taken up by network latency overhead.
  • Don’t count on LTE to be your mobile performance saviour. 3G is going to be around till the ’20s.
  • If you’re designing for mobile, it’s safest to assume you’re going to incur 2000ms of 3G latency.
  • 64% of smartphone users expect pages to load in less than 4 seconds.
  • The folks designing HTTP2.0 claim an easy 30% performance increase on websites with HTTP2.0 / SPDY.
  • HTML5 will overtake flash for video this year.
  • Battery consumption should be on our web performance metric radar.
  • For many sites, 36% or more of desktop page weight comes from 3rd party scripts.

A few highlights from some of my favourite sessions

First, I need to say that it was a serious challenge deciding which sessions to attend. There were so many I wanted to see but missed because they conflicted with other sessions. Fortunately, the folks at Velocity do a bang-up job of making slides and videos available after the conference, so we can all catch up on what we missed.

Here’s a best-of sampling of the sessions I made it to:

Optimizing the Critical Rendering Path for Mobile (Ilya Grigorik, Google)

If you ever get a chance to see Ilya Grigorik speak, then drop everything else and do it. Every slide he presents is gold. Picking just a few to spotlight was hard, but here you go.

Illustrating why we have less than one second to give users something useful on screen:

Ilya Grigorik: Mobile optimization

Then showing how much of that precious second is taken up by network overhead:

Ilya Grigorik: Mobile optimization

If you only took away five points from Ilya’s session, they should be these:

Ilya Grigorik: Mobile optimization

Mobile Performance from Radio Up (Ilya Grigorik, Google)

I’ve been waiting a long time to hear someone offer an understandable explanation of how cellular networks work. I jumped at this session and was not disappointed. Ilya does an excellent job of not just outlining network performance issues, but bringing the conversation back to offering practical advice for mitigating these issues.

Ilya Grigorik: Mobile optimization

This is so easy to forget, and it’s part of what makes real-world mobile performance testing so intensely tricky:

Ilya Grigorik: Mobile optimization

Another set of critical, yet frequently forgotten, takeaways:

Ilya Grigorik: Mobile optimization

Benchmarking the New Front End (Emily Nakashima & Rachel Myers, ModCloth)

As Steve Souders has talked about on several occasions, window.onload is not the best way to measure page speed from a real user’s perspective. I enjoyed Emily and Rachel’s session, which was not only super entertaining, but also illustrated an interesting approach to measuring performance at ModCloth in a way that was meaningful and useful to them.

These are the metrics they determined were most meaningful:

Benchmarking the new front end

They defined a “feature” as any page element that was essential to the user experience. After determining page features, they used Google Analytics and Circonus to generate code to add tracking to each:

Benchmarking the new front end

From feature tracking, it was a logical next step to define “load time” as the point at which all features have been called:

Benchmarking the new front end

And finally, unresponsiveness:

Benchmarking the new front end

The Canadian Public Broadcaster on a Diet (Barbara Bermes & Blake Crosby, Canadian Broadcasting Corporation)

As a former CBC-er, I was really excited to see this session on the agenda. Barbara and Blake presented a great case study showing how they tackled the challenges of serving incredibly dynamic, rich-media-intensive pages to an audience that covers massive geographical territory.

First off, love this quote attributed to Brad Frost:

Mobile web performance at the CBC

Why should we be concerned about mobile? Look what happens in 2014:

Mobile web performance at the CBC

We wrote about this stat when Jakob Nielsen first announced it back in 2010, and it’s still at least as relevant today as it was then:

Mobile web performance at the CBC

A typical media page at CBC.ca fetches from 32 domains. How do your pages compare?

Mobile web performance at the CBC

An illustration of the page diet “yoyo effect”. After you take off some page weight, it creeps up again elsewhere:

Mobile web performance at the CBC

10 Web Performance Optimization Disasters (Joshua Marantz, Google)

Joshua offered a great information-packed session, which you should check out in its entirety. Some interesting stats about WPO adoption:

10 web performance optimization disasters

I like this next slide a lot. :)

10 web performance optimization disasters

Have any of these happened to you? If you say “none, ever” I want to hear how you did it.

10 web performance optimization disasters

Enough with the JavaScript Already (Nicholas Zakas, Box)

This was the last session of Velocity, and it was a full house. I sensed a bit of chagrin in the crowd as Nicholas humorously took everyone to task for egregious JavaScript abuse:

Enough with the JavaScript already!

Data from the HTTP Archive showing the average growth in transfer size and requests. Both have increased by 17% and 20% respectively, in just eight months:

Enough with the JavaScript already!

As Nicholas pointed out, just because you can do all these things with JavaScript, doesn’t mean you should do all these things with JavaScript. He shared this handy table reminding us of the most efficient places to relegate these tasks:

Enough with the JavaScript already!

Summary

Attending Velocity is the best way I can think of to benchmark the current state of performance. From the stage, you get a sense of the past via case studies and other historical perspectives. You also get a good idea of the future, in terms of where some of the smartest people in our community have set their sights. Counterbalancing this with the hallway/lounge/charging station chats, you get a real-world sense of how most companies are actually tackling performance on a day-to-day basis. I’m already counting the days to Velocity NYC this fall.

Related posts: