UserTime Blog

The number one issue I have looking at performance data is how to deal with outliers. Numerical averages are terrible for outliers -- one request from a mobile browser on an Edge network somewhere skews a whole bucket of measurements.

The best tool we've found is Apdex. Apdex distills a collection of timing metrics into color-coded buckets (excellent, good, fair, poor, unacceptable) you can glance at and immediately take away useful info.

We've gone a step further and made our scatter-plot graphs into Apdex charts as well:

Read up on Apdex here -- it really is a nice system. Right now we set the "satisfied" baseline at 2 seconds. In the future, we'll make that configurable per-site.

iPhones != Desktops

You probably have different expectations for mobile performance on your site than you do for traditional PCs. Depending on your site, your emphasis may be primarily mobile, or it may be primarily desktop. Regardless, you probably don't want to lump them all together.

We now partition metrics according to device class: Computer, Phone, or Tablet:

Drill Downs

Finally, we've made it possible to drill down into any bucket to see the individual requests it comprises. Just click on the page view count to see a detail of each pageview.

If you're not already using the beta version of UserTime, hit our signup link in the sidebar. We're sending out invitations as we add capacity to the system, and we'd love to get your feedback.

What if we could reduce cross-atlantic RTTs from 150ms to 100ms? This would have a larger effect on the speed of the internet than increasing a user’s bandwidth from 3.9Mbps to 10Mbps or even 1Gbps.

- Mike Belshee in More Bandwidth Doesn’t Matter (much)

Over the past 10 years, web servers have become faster and cheaper. Networks have become much faster. Yet, website performance has mostly stayed the same or gotten worse. We blogged about this on the Scout blog.

If Computers are Faster, Why Are Web Pages Slower?

The culprit is a bloated aesthetic. Weight and complexity of site design have outpaced the increases in network and computer speed.

Now, there is a ton of evidence that users love speedy websites. Fast sites make users click more, stay longer, trust you more, spend more money, and come back more often.

What do we gain from the bloat? At best, we get more visual variety, richer imagery, and more sophisticated interactions. More often, however, we get a surfeit of advertisements, “send to a friend” widgets, and gratuitous Flash effects.

Is the style of design giving us slower sites worth it? Or is a performance-oriented minimalist aesthetic poised for a resurgence?

Safari 5 Leads the Charge

The popularity of Safari 5’s “Reader” feature — which strips content of all its adornments down to stark, mostly imageless text — suggests the time is right. This writeup expresses it well:

Apple’s vision of the web does not include Twitter sidebars, recently popular article links, fancy headers or sharing widgets. In short, Reader cuts through the distractions to the actual content. Of course, that’s exactly what good design should do in the first place — focus your attention on what’s important. If every web page were well-designed, there would be no need for Reader. Clearly, that’s not the case.

Some sites already embrace such an aesthetic, for example, Craigslist, Hacker News, and the Google and Bing home pages.

Advertising is the Loser

The loser in such minimalist design is advertising. Safari Reader notably strips away all advertisements, along with all other images and distractions form the main content. Perhaps a shift to speedier, more streamlined designs will be accompanied by sensible revenue models beyond advertising. For example, micropayments for content sites.

Faster sites, focused designs, fewer advertisements, fair payments for content creators — isn’t that a web aesthetic we could all get behind?

Both will provide a Velocity Conference Recap.

• San Francisco Web Performance Meetup
• Boston Web Performance Meetup

If you told me that's it completely reasonable to shave 200ms off the response time of a webpage on our Scout service, I'd look for the snake oil in your hands. We like to keep the server generation time under 300ms - that's just not realistic. 

You, however, are not a liar. I'm just looking in the wrong place. For example, did you know that just updating your Google Analytics tracking code to load asynchronously may improve performance by 200ms? Our customers don't care what makes our site load faster.

Want to make things faster? The client-side is the place to look. It's where 80% of the time spent rendering a web page is spent, and there's a crap-ton of optimization potential there. It's the place where 200ms shaving dreams come true.

UserTime is our effort at making the web faster, beginning with the client side. We're starting with the basics - measurement collection. The truth: UserTime is a solid free service now, but it's not worth paying for (yet). The measurements are a start, but we need to make it easier to solve performance problems before we'd pay for it ourselves (by payment, I mean something that's affordable for those far outside the Fortune 100 - a free option and paying options between $20 - $300/mo). We all win with a faster Internet, and we'd love your help making it happen.

We'll talk about what we're working on and post client-side performance tidbits here and on that Twitter thing. If you'd like to be notified as spots open up for our testing period, signup for a BETA invite. 

Finally, a big high five goes out to Alistar Croll, Sean Power, and Steve Sounders. Alistar and Sean have put together the authoritative book on web monitoring, aptly titled Complete Web Monitoring. The book pointed us to the Episodes timing framework, which Steve created. Our timing logic is based on Episodes.

- Google, "How we're making the web faster"

Yahoo released Boomerang during Velocity – looks like some advancements on Episodes. It adds measurements for bandwidth, DNS latency, and server latency. The DNS measurements are non-trivial. For the other measurements, you need to place a set of images on your server. Comes with good documentation.