mobile web performance

The 33 best web performance links of Q2 2012

31 Jul 2012

4 Comments

For some reason, I thought that the past few months had been kind of quiet on the research front, so when I started this post, I thought it would be one of my shortest roundups yet. I was pleasantly surprised to watch it grow to become one of the longest!

There are some great case studies here, of both large and small sites, which I love to see. There’s also some truly excellent debate about responsive design and the mobile web, sparked by a post from Jakob Nielsen last spring, as well as some good stuff about the browser wars and third-party content. So enough with the intro. Let’s get into it.

Case studies

Optimizing Retr-O-Mat’s Web Performance

A casual performance optimizer details her efforts to get Retr-O-Mat’s average load times under 2 seconds. Good information for anyone interested in the nuts and bolts of front-end optimization (FEO).

Web performance can be beautiful too

After performing poorly in a 2011 web performance comparison of leading retailers, Crate and Barrel made WPO a priority moving forward. This blog post from Catchpoint shows just how “beautiful” their performance has been in 2012.

How the Post is improving site performance

Responding to a flood of user frustrations with their website, the IT team at the Washington Post rolled out a number of performance upgrades to their site over the past year. Find out what they did to improve their page speed by 32.4%.

Tips and how-tos

Building a faster web: Tools, tips, and lessons

If “faster connectivity and more bandwidth won’t save us,” then what will? Google’s Ilya Grigorik shares his insight on making the web faster in this in-depth slide deck, and he draws some very interesting conclusions.

How to Make Progress Bars Feel Faster to Users

The human perception of time is anything but linear, and with just minor visual tricks, it gets even more skewed. After reading this post, you may never trust a progress bar again. :)

The 3 white lies behind Instagram’s lightning speed

More cool perceptual tricks. The “secret sauce” behind Instagram’s stellar user experience is rooted in a combination of coding tricks aimed at giving users a feeling of constant responsiveness. Find out how their site “always pretends to work.”

Mobile

The web only works thanks to reload (and why the mobile web fails)

As Mike Belshe points out, web page resources routinely fail, but thanks to the ever-handy reload/refresh button, we can often solve these problems ourselves. With mobile browsing, however, the rules are different. Find out what this means for the future of HTML 5.

Web first for mobile

Performance evangelist Steve Souders focuses his performance research strictly on the mobile web – not on native apps. Why? He’s got more than a few good reasons.

A taste test of mobile website development

A solid webcast on the complex world of mobile development, touching on topics including Responsive Web Design (RWD), server-side device detection, and HTML5 performance on mobile.

Jakob Nielsen on mobile sites vs. full sites

Jakob Nielsen believes that mobile and full sites should be entirely different entities. Summarizing his argument, he states that “good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”

Is Nielsen wrong on mobile? Arguments abound

From Net magazine: Jakob Nielsen’s assertion that “good mobile user experience requires a different design” is being challenged by a noted mobile expert, who argues that rather than stripping down for mobile, companies should be doing more.

Why we shouldn’t make separate mobile websites

More counterpoint to Nielsen’s post. Smashing Magazine’s Bruce Lawson argues that mobile redirection is unreliable, and excluding features for mobile browsers “perpetuates the digital divide.”

Responsive web design: Missing the point

Still more Nielsen backlash: Brad Frost states that, though mobile browsers are getting better at rendering full websites, creating adaptive sites for mobile users is essential to improving the user experience.

HTML5 features increase mobile usage by 28%

Interesting piece explaining how static pages needing an upgrade can vastly improve mobile user engagement through the addition of HTML5. The new release features interactive galleries, overlays, and expandable/collapsible boxes, driving up pageviews and decreasing bounce rates.

Tools

More ways to measure web performance with User Timings

Google Analytics has expanded its collection of Site Speed reports with a new feature called User Timings. The feature enables tracking of specific load times for discrete hits, images, and other user interactions.

New mod_spdy release supports Apache servers

More from Google. The latest version of mod_spdy – an Apache module that adds SPDY server support – is intended to fix bugs found in the original release.

“Speed Index” introduced as new performance metric

The Speed Index metric has been added to WebPagetest, helping measure the speed at which page contents are visually populated. The tool is especially useful for comparing page experience before and after optimization.

Browsers

Browser Speed Tests: Chrome 19, Firefox 13, Internet Explorer 9, and Opera 12

Lifehacker conducts it’s semi-regular browser speed tests, pitting the four titans of desktop browsing against each other in races for startup speed, tab loading times, and other performance indicators.

Which Browsers are the Fastest?

An interesting companion read to the Lifehacker piece, New Relic’s “Speed Wars” study shows that, while IE 9 speeds past other browsers on Windows, Chrome 13 on Mac was overall the fastest experience. In mobile speed tests, the fastest experience was delivered by Blackberry Opera Mini at 2.6 seconds, twice as fast as Safari 5.1 on iPad.

How the Chrome Predictor hides latency from users

Ilya Grigorik demonstrates how Google Chrome hides latency from users. Interesting stuff here.

Internet Explorer market share surges, as IE 9 wins hearts and minds

From Ars Tecnica: “The browser wars are back on in earnest. For the second time in three months, Internet Explorer made large gains, picking up almost 1 point of market share. Chrome, Firefox, and Safari all lost out, as Internet Explorer 9 won over new users.”

CDNs

A one-size-fits-all CDN solution isn’t always best

Server configurations come in all shapes and sizes, which means a one-size-fits-all CDN is seldom effective. Find out which Level 3 customer was the beneficiary of a custom CDN solution and how it worked out.

Third-party content

10 Golden Rules for 3rd Party Providers

Murphy’s Law reigned supreme throughout June, with a flood of large-scale outages taking down some of the world’s most popular websites. Given the inevitability of online failures, third-party providers must be prepared to deal with the worst. The folks at Catchpoint outline the 10 Golden Rules by which all third-party providers should live by.

The vendor who flunked the web performance test

Are third-party vendors ignorant to the consequences of slow web performance? According to Catchpoint they are, as they detail a story of one such vendor who was completely unaware of the performance impact of their product.

Average UK website has 14 trackers per page

Interesting findings from TRUSTe: Despite the prevalence of privacy policies, over two-thirds of trackers on UK websites originate from third-party companies, and almost half embed themselves permanently.

Google releases +1 button preview – loads 20% faster

Google announced that they’ve improved performance of the +1 button and Google+ badge. By reducing the size of the js/plusone.js loader and making the code smarter, page elements now load 20% faster.

Third-party JavaScript should be loaded asynchronously

Old news to some, but still worth mentioning: Third-party JavaScript should be loaded asynchronously, as it helps avoid slowdowns and can speed up page loads.

Third-party front-end performance, Act 1

Application provider Bazaarvoice is delving into the realm of front-end performance, and provides an interesting third-party perspective.

Opinions and analysis

Performance Nightmare: Nasdaq & the Facebook IPO

When Facebook began trading on May 18, 2012, a series of performance failures on Nasdaq.com caused a huge headache for the company. This article from Intechnica asks how much these badly timed hiccups cost investors.

More, better, faster: Steve Souders on WPO

Steve Souders kicked off O’Reilly’s Velocity video podcast series with an in-depth discussion of the state of web performance optimization. Key topics included measuring slowness, performance monitoring tools, and whether mobile disrupts performance.

Other research

How complex systems fail

As a complex and interdependent system, the web is prone to catastrophe at the highest levels. In this fascinating paper on resilience engineering, presented at Velocity 2012, Dr. Richard Cook outlines the reasons why all complex systems are intrinsically hazardous, why disaster is always just around the corner, and how failure-free operations still require experience with failure.

The growing epidemic of page bloat

I don’t usually pimp my own writing here, but this information is too important not to share. I wrote a piece for GigaOM showing that the average page size is now over 1MB, according to the HTTP Archive. At current growth rates, the average page could hit 2MB by 2015, which is a really big deal, especially for mobile users.

How fast are websites around the world?

Some fascinating findings here. Google’s Site Speed Reports provides detailed latency data for page load times by separating data according to device, location, and industry.

These links were all sourced from Strangeloop’s Web Performance Hub, which contains hundreds (and by now, possibly even thousands) of industry-wide links, organized by topic, source, research type, and industry. It’s a pretty good resource, if I do say so. If you have any new links to recommend, let me know.

http://t.co/EHbRdT6r
10 Golden Rules for 3rd Party Providers [article]
Catchpoint – June 26, 2012
Summary: Murphy’s Law reigned supreme throughout June, with a flood of large-scale outages taking down some of the world’s most popular websites. Given the inevitability of online failures, third-party providers must be prepared to deal with the worst. Find out the 10 Golden Rules by which all third-party providers should operate by.
http://t.co/LGYUpGn1
End-to-end optimization: Taking content delivery to the next level [blog post]
Web Performance Today – June 27, 2012
Summary: Strangeloop Networks is thrilled to announce the launch of our latest product, Network Accelerator. Learn all about how this product works, what it does – and most importantly – why it’s a major step forward for content delivery networks.
http://t.co/T4z69s7k
How complex systems fail [research paper]
CTALab.org – June 26, 2012
Summary: As a complex and interdependent system, the web is prone to failure and catastrophe at the highest levels. In this fascinating paper on resilience engineering, Dr. Richard Cook outlines the reasons why all complex systems are intrinsically hazardous, why catastrophe is always just around the corner, and how failure-free operations require experience with failure.
http://bit.ly/LzGPqN
Mobile optimization starts with mindset: Hooman Beheshti interviewed at Velocity 2012
O’Reilly Media – June 25, 2012
Summary: Where are we in the mobile optimization life-cycle? What mindset should site owners adopt when boosting mobile performance? Are performance measurements improving? In this video, Strangeloop Technology VP Hooman Beheshti offers his unique insight on the current state of mobile.
http://t.co/Vnced8tq
The 90-Minute Mobile Optimization Life Cycle [slides]
Strangeloop Networks – June 25, 2012
Summary: Strangeloop Technology VP Hooman Beheshti wowed attendees at this year’s Velocity Conference with a presentation on the mobile optimization life cycle. For those who missed it, be sure to check to check out these fascinating slides.
http://bit.ly/Nu1gCi
Ghosts of Velocities Past: 9 presentations that are still relevant today [blog post]
Web Performance Today – June 20, 2012
Summary: Velocity’s short (yet incredibly important) history is filled with memorable moments, and these 9 presentations from past conferences remain relevant today. Perhaps not trendsetting anymore, but certainly trend affirming, which may just be better.
http://bit.ly/MFuxMR
My recent post on SEOMoz: 13 Questions (and Answers) About Google, Site Speed, and SEO [article]
SEOmoz – June 18, 2012
Summary: In this article, Strangeloop president Joshua Bixby breaks down how site speed and performance metrics affect Google page ranks. For anyone who has ever wondered how Google manages to make performance metrics affect SEO, this article is a must-read.
http://mz.cm/M24fGc
Introducing: New Browser Tax feature for our ecommerce customers [blog post]
Web Performance Today – June 14, 2012
Summary: Ever wish you could arbitrarily tax your customer base for failing to stay current, with zero repercussions? With the new Strangeloop Browser tax, your wish is now a reality!
http://bit.ly/NC5Q65
Optimizing Retr-O-Mat’s Web Performance [blog post]
Finding Marbles – June 9, 2012
Summary: For the “WPO guy’s wife,” average load times just aren’t good enough. In this post, a blogger and casual performance optimizer details her efforts to get Retr-O-Mat’s average load times under 2 seconds. Great information for anyone interested in the nuts and bolts of WPO.
http://t.co/k0lXkniG
Browser Speed Tests: Chrome 19, Firefox 13, Internet Explorer 9, and Opera 12 [article]
Lifehacker – June 12, 2012
Summary: It’s a battle of startup times, tab loading times and other KPIs between the four titans of Windows browsing. Lifehacker’s speed tests are always entertaining for what they’re not afraid to say, and this article is no exception.
http://bit.ly/Nb2ibS
Marrying CDNs with front-end optimization for maximum acceleration [blog post]
Web Performance Today – June 12, 2012
Summary: Front-end optimization (FEO) has been weaving its way further into content delivery networks (CDNs) over the past two years, and the dynamic between these two technologies continues to evolve. In this video presentation, Strangeloop’s Joshua Bixby breaks down the benefits of combining these performance solutions.
http://bit.ly/L3aatz
How the Chrome Predictor hides latency from users [article]
Igvita.com – June 4, 2012
Summary: Google Chrome features countless tools for supercharging load times, but when those aren’t enough, the browser can hide latency from users. Find out how!
http://bit.ly/Nw6ZMh
Building a faster web: tools, tips, and lessons [slides]
Igvita.com – June 3, 2012
Summary: If “faster connectivity and more bandwidth won’t save us,” then what will? Google’s Ilya Grigorik shares his insight on making the web faster in this in-depth slide deck, and draws some very interesting conclusions.
http://bit.ly/L0eERH
The “performance poverty line”: What is it and why does it matter? [blog post]
Web Performance Today – June , 2012
Summary: The “performance poverty line” is the point at which business metrics have sunk so low, load times cease to matter. But how is this line measured? Does it differ between industries? And most importantly: is there hope?
http://bit.ly/NJAqs2
A one-size-fits-all CDN solution isn’t always best [article]
Level 3 – June , 2012
Summary: Server configurations come in all shapes and sizes, which means a one-size-fits-all CDN is seldom effective. Find out which Level 3 customer was the beneficiary of a custom CDN solution.
http://bit.ly/M9P5xt
Why the Facebook outage is (yet another) wakeup call for site owners [blog post]
Web Performance Today – June , 2012
Summary: The hazards of running third-party scripts are well documented, but the May 31st Facebook outage was another stern reminder. In this post, Strangeloop’s Joshua Bixby discusses all things third-party, including rogue content and common performance pitfalls caused by third-party content.
http://bit.ly/JQj7GX
The web only works thanks to reload (and why the mobile web fails) [article]
Belshe.com – June , 2012
Summary: Web page resources routinely fail, but thanks to the ever-handy reload/refresh button, we can often solve these problems ourselves. With mobile browsing, however, the rules are different. Find out what this means for the future of HTML 5.
http://bit.ly/NAAQ3O
How to Make Progress Bars Feel Faster to Users
UXMovement – June , 2012
Summary: The human perception of time is anything but linear, and with just minor visual tricks, it gets even more skewed. After reading this post, you’ll never trust a progress bar again!
http://bit.ly/NcsVfg
Does the average web user waste two days a year waiting for pages to load? [blog post]
Strangeloop Networks – June , 2012
Summary: It may not be true, but in web performance, perception is reality. Web users in the UK are less than pleased about their online experience, but just how cranky are they?
http://bit.ly/LSFIlv

Related posts:

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

Early findings: Mobile browser cache persistence and behaviour

12 Jul 2012

1 Comment

If you’ve spent any time in the mobile space, you know that the browser cache is a critical limiting factor for performance. I often talk about:

  • how unreliable the mobile browser cache is,
  • how poorly it persists data, and
  • how poorly it observes basic caching headers.

You may also know that one of the key benefits that front-end optimization (FEO) can bring to the mobile world is a more useful browser cache. Our team, led by Hooman Beheshti and Jarrod Connolly, has been working for years to perfect mobile acceleration, and they’ve spent a huge amount of time digging into the browser cache conundrum. Hooman recently presented some very interesting findings at Velocity, which I want to expand on today.

Background:

Much has been written about how poor mobile caching is. For a thorough overview, read more here, here, here, here, and — my favourite link — here. But for our purposes today, here’s the Reader’s Digest version:

1. Mobile cache sizes are far too small.

The stock browser in Android (2.x) has a cache size limit of around 5.7MB. iOS is much larger (>50MB).

2. When we think about mobile cache sizes, we need to take into account a bunch of variables.

We need to consider the total cache size (which is a shared cache for all our browsing), individual object size limits for caching, and the fact that HTML pages may be treated slightly differently.

But we had more questions about mobile caches, so Hooman set out to get some answers. Below is what he found.

Question 1: How do non-stock browsers cache on Android?

Further to this question, Hooman wanted to see if anything has changed with Android ICS (Ice Cream Sandwich, version 4.0 of Android). His methodology was pretty similar to what others have done to determine mobile cache sizes (see the links above).

Here’s what came out of it:

  • On Gingerbread (Android 2.3.x), Firefox and Opera both had cache sizes that were slightly larger than the stock browser. They both came out at around 10MB.
  • The stock ICS browser had an HTTP cache that was much bigger than its predecessor. Hooman’s tests showed a limit of 25MB.

He was also going to test Chrome on ICS (Chrome is not available for Gingerbread), but then found this great article from Tony Gentilcore from Google that outlines how the Chrome cache is large and persistent. Better yet, the cache size is dynamic and based on the amount of disk space available, which is great news.

To put things into perspective, it’s good to compare mobile cache sizes to those of desktop browsers, which are usually in the range of 100s of MB:

  • This article from IE tells us that in IE6/7/8 the IE cache size was 1/32 of the disk, with a default cap of 50MB. IE9 is 1/256 of disk size (not a bad thing since disks are much bigger these days) and has a default cap of 250MB. Cache size is user configurable in IE.
  • Spot checking our own Chrome and Firefox browsers showed a cache size of >300MB on Chrome and >700MB on Firefox.
  • Steve has a great post on cache sizes with some crowdsourced info on what’s out there now.

Conclusion: Mobile caches are lacking when it comes to how much content they can hold.

This is especially true when you consider that an HTTP object cache is a shared resource for a browser. If you do even minimal browsing on your smartphone, you’re bound to fill up the cache rather quickly. But things are getting better. ICS is a good example of that. And even though progress may not be occurring at the pace we’d like, any progress is good. This also highlights the value of using localStorage as an object cache, which mobile acceleration solutions like Strangeloop’s Mobile Optimizer automatically enable a site to do.

Question 2: How do mobile browser caches behave with various user actions (e.g., closing the browser, locking the phone, shutting down the phone)?

This is an extremely important question that’s never been satisfactorily answered. There is very little data on the persistence of the cache and how (and if) objects are fetched from cache. Here’s a breakdown of Hooman’s suite of experiments in this area.

Methodology

Considering the hundreds of permutations that something like this could end up with, we tried to keep things simple. We put an Android Nexus S (version 2.3.7) and an older iPhone 3GS (iOS version 5.1.1) through the following paces:

1. We used a single page with ~2MB of images on it to prime the cache.

2. In priming the cache, we used four different sets of cache control headers (including none at all) on the images to see their effect on caching:

  • No cache headers at all
  • A Last-Modified header only
  • A Cache-Control: max-age header, together with a Last-Modified header
  • A Cache-Control: max-age header only

3. Then, after priming the cache, we performed some user actions and revisited the page.

4. Through network traces, we determined if, when, and how the browser went back to the server to fetch any of the images.

Results

The table below shows all the permutations and how each phone behaved in various circumstances.

It’s not an easy table to read, so here’s what’s happening:

  • In all the green cells, all the images were fetched from the cache. No requests for those images went over the network to the server.
  • In all the orange cells, nothing was fetched from the cache. All the images were re-fetched from the server.
  • In the blue cells, the requests were made from the server, but with some relevant caching headers in the requests. If you want to know exactly what these headers mean, it’s best to consult RFC2616.
User action Device Primed with no cache headers Primed with Last-Modified Primed with Last-Modified and max-age Primed with max-age
New window or tab Android All from cache All from cache All from cache All from cache
iOS None from cache All from cache All from cache All from cache
Exit browser, lock phone, unlock phone, open browser Android All from cache All from cache All from cache All from cache
iOS None from cache All from cache All from cache All from cache
Kill browser, launch browser Android All from cache All from cache All from cache All from cache
iOS None from cache All from cache All from cache All from cache
Reboot phone Android All from cache All from cache All from cache All from cache
iOS None from cache All from cache All from cache All from cache
After page loads, click URL and hit “Enter” Android All from cache If-Modified-Since and Cache-Control:max-age=0 If-Modified-Since and Cache-Control:max-age=0 All from cache
iOS None from cache All from cache All from cache All from cache
Refresh after page loads Android Cache-Control:no-cache Cache-Control:no-cache Cache-Control:no-cache Cache-Control:no-cache
iOS Cache-Control:max-age=0 If-Modified-Since and Cache-Control:max-age=0 If-Modified-Since and Cache-Control:max-age=0 Cache-Control:max-age=0

Observations and conclusions

Most of the cells show behavior that is expected from a well-behaving browser. But there are a few areas Hooman highlighted as particularly interesting:

Primed with No Cache Headers

It’s interesting that Android was so aggressive and chose to cache the images even if they didn’t have caching headers on them. This is particularly aggressive.  But that’s not necessarily a bad thing, especially if this behavior is specific to images. But it makes it that much more likely that the cache will fill up quickly. iOS, by contrast, doesn’t cache any images if they don’t have any caching headers at all.

After page loads, click URL and hit “Enter”

This whole row was interesting because, to the Android, this is very much like a refresh of the page. For situations where the original images were put into the cache with the Last-Modified validator, the browser wants to validate all the way to the origin server. (Intermediate caches can’t validate on their own because of the max-age=0 directive.) This is true even if there was a max-age put on the image when it originally went into the cache.

Primed with Last-Modified

When the image went into the cache with just a Last-Modified validator, caching was rather aggressive form both Android and iOS. This is actually probably a good thing. It’s also possible that this behavior would be different if we had revisited the page much later than when the images originally went into the cache.

A few caveats

As Hooman points out, even though this is all very telling, it’s important to consider that we didn’t test the hundreds of permutations that could have included how full the cache was and combinations of different content types (images, scripts, CSS, HTML, etc). So these observations apply just to images. It’s possible that some of the behaviours could have been different if other file types were introduced into the mix.

Also, while some research out there suggests that the iOS cache isn’t persistent (it reportedly gets wiped after the device shuts down), we didn’t find this in our research.  However, the fact that we used a small amount of images could explain this discrepancy.

Final thoughts: Mobile browser vendors need to offer more visibility into their products

This is all great info and we’ll continue to test and get insight into how mobile browsers work. This is not only important for the performance community, but also vital to our own product development here at Strangeloop.

But we’d also like to re-iterate what others have said, which is to ask browser vendors to provide more visibility and documentation into what their browsers are doing (kudos to Chrome and Tony for starting to walk that path). As mobile browsing is poised to rival and overtake desktop browsing in the near future, the more we know, the better we can design our web applications and the products that help optimize them.

For a greater understanding of mobile performance challenges, I encourage you to download Strangeloop’s mobile optimization whitepaper (not a product shill, I promise).

Related posts:

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

Jumping in the Velocity Wayback Machine: 9 presentations that are still relevant today

20 Jun 2012

3 Comments

It’s going to be a busy two weeks. I’m in London right now, meeting with some of our partners, then off to talk about mobile at USI in Paris on Monday, then straight to Santa Clara to sit on a Velocity panel about performance tools on Tuesday.

Now that I’ve fulfilled my self-pimping obligation, I want to take a minute to revisit some of my favourite sessions from past Velocity conferences. Recently I read somewhere that we tend to distrust information that’s more than a year old, but I have to say that I find these slide decks, some of which are three whole years old, still interesting and relevant today.

Velocity 2011

Performance Measurement and Case Studies at MSN

Paul Roy, Alex Polak, Gregory Bershansky

MSN shared some case studies that showed how speeding up load time affected page clicks. I live for these kinds of case studies, so I was happy to learn that:

  • In an experiment with implementing synchronous jQuery load, they experienced a +0.5% increase in search clicks and page clicks.
  • In another experiment with improving JavaScript execution time, they experienced a +1.2% increase in search clicks and a +0.5% increase in page clicks.

But what I thought was particularly interesting was the case study around delaying ad loading. They experimented with delaying the loading of a major ad by 1 second, which improved the time to onload by 500ms. As a result, they saw an increase page clicks and views, but a 15% dropoff in ad clicks.

Obviously this kind of ad performance hit isn’t viable for a site that relies on CTR for revenue, but what grabbed my attention was MSN’s takeaway from this exercise:

Velocity 2011 - Microsoft case study: Delay ad loading

My favourite thing about this session was that, rather than being scared off by the initial 15% hit to CTR, Microsoft persists in looking for the sweet spot that yields faster load time without hurting advertisers. This improvement may end up just being a hundred or so milliseconds, but the message here is that it’s a goal worth chasing.

The Impact of Ads on Performance and Improving Perceived Performance

Julia Lee, Senior Director of Engineering, Yahoo! Mail

With almost two billion page views a day, the cumulative effects of latency can hit Yahoo mail hard. They found that 73% of their overall latency was due to ads. No surprise when you look at how convoluted an ad’s server call can be:

Velocity 2011 - Third-party ad call
What does this convolution add up to, performance-wise? Julia shared that in the old days, before redirects, the average ad experienced about 464ms of latency. Over time, that number grew to 2.7 seconds.

Mobile Web & HTML5 Performance Optimization

Maximiliano Firtman

If you’re in mobile web development, this slide deck is a must-see. Starting at slide 51, Maximiliano gives an impressively thorough breakdown of optimization tips, from handling images to deferring content. This slide is my favourite:

Velocity 2011 - Why mobile websites are slow

Velocity 2010

Performance Testing: Putting Cloud Customers Back in the Driver’s Seat

Imad Mouline

In this session, Imad shared some KPI data,back when such information was still hard to come by, including this graph showing that speeding up a page by just 4 seconds decreases abandonment by 25%:

The Impact of Web Performance on Page Abandonment

Psychology of Performance

Stoyan Stefanov

This was a great presentation that demonstrated (to many of us for the first time) the human factors side of web performance. For example, Stoyan showed that there’s a distinct difference between perceived speed and actual speed. When it comes to web performance, this difference works against us:

Actual versus Perceived Time

Metrics 101

Sean Power

There were a handful of messages that were threaded throughout many of the presentations and discussions at Velocity 2010. The relationship between performance and the bottom line was one of them. Sean presented some visuals that hammered these points home. Among other things, he showed how, as latency increases, conversion rate drops:

Impact of increasing latency on conversion rates

Sean also showed the long-term effects of poor performance: a poorly performing website suffers not one but two waves of abandonment, as users spread the word of their poor experience and drive other users away from the site.

Long-term impact of poor performance on user behavior

In the last part of his session, Sean offered a realistic step-by-step plan for dev/ops folks to measure performance and outcomes in their organization. He said that if you create only one graph for your site, it should be one that looks something like this, which shows the direct impact of page load on conversions:

Sample graph: The relationship between web page load time and conversions

Velocity 2009

The User and Business Impact of Server Delays, Additional Bytes, and HTTP Chunking in Web Search

Eric Schurman and Jake Brutlag

There were many cool things about Velocity 2009. One was the presentation of so much brand-new data about the relationship between page speed and business metrics — often done by deliberately slowing down pages, which was considered a pretty radical idea. For many people, this connection, which we take for granted today, was a revelation. Another cool thing was the research partnerships, like this one between Amazon and Google. Definitely worth a watch.

The Secret Weapons of the AOL Optimization Team

Dave Artz

More groundbreaking research. AOL found that visitors in the top ten percentile of site speed viewed, on average, 7.5 pages per site visit. Visitors in the bottom ten percentile viewed just 5 pages per visit.

Shopzilla’s Site Redo – You Get What You Measure

Philip Dixon

This is a seminal piece of research. Back in 2009, Shopzilla became the poster child for web performance when they shaved almost 5 seconds from their page load times and increased revenue by 7-12%.

It’s been fascinating to note the evolution of themes from year to year, and to follow the ever-deepening nuances of performance. I’m looking forward to seeing what Velocity 2012 holds.

Related posts:

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

Bad news for site owners and mobile users: The average web page is now 1 MB

24 May 2012

47 Comments

I wrote about this at greater length in this post for GigaOM (which also includes some nifty graphs), but want to summarize a few of the key points here.

  • According to the HTTP Archive, which gathers stats on the top million sites in the world (as ranked by Alexa), the average web page has surpassed the 1 MB mark.
  • In the past 18 months, the average web page has grown by 50% — from 702 KB in November 2010 to 1042 KB on May 1, 2012. (Side note: Since I wrote the GigaOM piece, the HTTP Archive has refreshed with new data. The average page is now 1059 KB.)
  • At this rate, the average page will hit 2 MB by 2015.
  • Images and third-party scripts (i.e. analytics, ads, social sharing buttons) are the main culprits.

Mobile users take the hardest hit.

Consequences include being throttled by providers or being hit with massive roaming charges. (For example, earlier this month I bought 25 MB of data from my provider for $100 while travelling in Europe. This works out to $4 per page.)

There’s a head-in-the-sand tendency to assume that just because our devices, browsers, and networks are more powerful than ever, end-user performance must also be getting better.

To disprove this, here’s a graph I created, in which I overlaid two sets of numbers spanning the past 12 months. The red line represents the page size data from the HTTP Archive. The blue line represents the mobile load time index from Keynote. While the two lines represent different data sets, it’s pretty clear that the general trend is up — bigger and slower.

Correlation between web page size and mobile load time

As I’ve said many (many!) times, building a mobile-specific site isn’t the answer.

One-third of a site’s visitors will choose to visit the full site if given the option between the two. That’s because people want the same breadth and depth of content and a consistent user experience, no matter what device they use. Site owners who can deliver a fast, reliable, cross-platform user experience are going to be the ones who own the web of the not-so-distant future.

Related posts:

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

Velocity podcast: The Business of Performance

25 Apr 2012

1 Comment

A while back, I spoke with Mike Hendrickson at O’Reilly about how to measure and make sense out of performance from a business perspective. It was a pleasant surprise to see the resulting podcast featured on O’Reilly Radar today.

It’s a pretty short video, but if you’re in a rush, you can skip the first five or six minutes where I talk about how we launched Strangeloop as a performance pioneer six years ago, and get right into the juicy stuff about the business value of performance at around the seven-and-a-half-minute mark.

Last week, O’Reilly also ran a great interview with our VP of Technology, Hooman Beheshti, which you should check out. Hooman will be talking about advanced front-end optimization for mobile at Velocity this June, and even if he didn’t work here, I’d still encourage you to attend his session. When it comes to FEO, and to performance in general, he’s one of the most knowledgeable people you could hope to find, and he has an amazing gift for explaining complex material in an interesting, entertaining way.

Related posts:

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