1. Website speed correlates (mostly) to position in the primaries.

When you stack these numbers side by side, you see a rough relationship between site speed and recent primary results. At 46.4% and 31.9%, respectively, Mitt Romney and Newt Gingrich led the Florida primary. Interestingly, both also lead when it came to site speed. Gingrich’s site is fastest, with a load time of 7.7 seconds (maybe we shouldn’t be so quick to laugh at his plans to colonize the moon), while Romney’s loaded in 9.3 seconds. Rick Santorum and Ron Paul lagged in both areas, trailing far behind in votes and suffering load times of 10.7 and 13.5 seconds, respectively. (Interesting to note: President Obama’s site fared worst of all, with a load time of 13.6 seconds.)

2. None of the candidates’ sites rose to the challenge of designing for mobile devices.

At recent Velocity conferences and elsewhere online, I’ve emphasized that one-third of mobile users want to access a site’s full content, not just a stripped-down “mobile” version. At the same time, there’s no doubt that making a full site usable on a mobile device is a major challenge — a challenge that none of the candidates rose to. Romney is the only candidate to serve a mobile site, which, to his credit, did link to the full site. The other candidates all deliver their full websites to mobile.

Given how tech-savvy President Obama’s people were throughout his first campaign, it’s not surprising to see that, with his new campaign site, they’ve adopted responsive design principles. Depending on whom you ask, responsive design is the savior of cross-platform development. Done well, it allows content to adapt to a variety of devices — desktop, tablet, and smartphone — maintaining content and design integrity while respecting the constraints of the device. (Here’s a longer review of the President’s new site and whether or not it serves as a good example of responsive design in action. I didn’t experience all the problems the reviewer did, so I’m wondering if they’ve since been fixed.)

3. Mobile experiences ranged from poor to terrible on Android over 3G.

I visited each of the candidates’ sites using two mobile devices and networks: my iPhone over wifi, and a borrowed Android over 3G. While all the sites loaded within 10-20 seconds on my iPhone, their performance on the Android via 3G ranged from slow to unbearable. Romney’s site was fastest, at 21 seconds, but it failed to size properly (see below) in the browser. The full sites for Gingrich, Santorum, and Paul each took several minutes to load.

4. On every site, the primary call to action — donate — was either lost or ineffective for mobile users.

On all the non-optimized sites, the “Donate” button was lost on the screen. Romney’s mobile-optimized site made it easy to find the “Donate” button, but on the Android it kept generating an error message saying there was a problem with the security certificate — not something a potential donor wants to read right before handing over their credit card information.

Why should web performance matter for presidential hopefuls? (Hint: It’s about democracy)

It’s one thing to tout your pro-technology stance to curry favor with voters, but there are a couple of obvious, self-serving reasons to walk the walk when it comes to your web presence: it makes it easier for you to reach more people, and it makes it easier for your supporters to, you know, support you. Candidates may not care about this beyond the lip-service stage right now, but a few things to bear in mind down the road, when campaigning really heats up:

• 25% of Americans who have mobile devices use mobile exclusively. This means 1 out of every 4 voters expects to be able to access the full site via their device.
• According to the source in the point above and to this report from Pew Research, many members of the mobile-only group are technology late adopters, skewing toward older people and those with lower incomes. These groups have traditionally been heavily targeted by Republican candidates.
• By the same token, people with lower incomes are more likely to be users of Androids and non-iPhone devices, and more likely to access the internet via 3G.
• Only 28% of smartphone owners use an iPhone, according to Nielsen. Having a mobile site optimized only for iPhone users is like slamming the door on almost three-quarters

Related posts:

• When it comes to mobile development, does bandwidth still matter?
• O’Reilly Radar interview: You can’t get away with a bad mobile experience anymore
• Interesting findings: 3G mobile performance is up to 10X slower than throttled broadband service

I always enjoy coming to these Meetups, and this time was no exception. Thanks again to Aaron Kulick for inviting me, to LinkedIn for hosting, and to the extremely keen and knowledgeable crowd who turned out.

Related posts:

• VIDEO: Demystifying web performance automation
• Case study: The impact of HTML delay on mobile business metrics
• Interesting findings: 3G mobile performance is up to 10X slower than throttled broadband service

We came up with the idea of conducting these reports over a year ago, when we realized there was no way to track performance changes and trends — from a real user’s perspective — on an ongoing basis. As I mentioned to CNet’s Stephen Shankland, when we talked about the report the other day, we can’t rely on benchmarking tests run out of data centers to give us any relevant sense of how our sites are actually performing out in the real world. They’ve got ridiculous bandwidth, and they’re parked right next to the content delivery machines, so they’ve got zero latency. By using WebPagetest — which simulates how fast a site loads in a real user’s browser — to measure the performance of the same set of 2,000 sites year after year, we can compare real-world performance snapshots and see what’s changed, and what’s caused the changes.

I don’t want to give away all our findings, the highlights of which are illustrated in the infographics above, but a couple of interesting things we discovered:

• Pages have gotten bigger – from an average of 86 requests last year to 98 requests this year. This kind of growth is consistent with trends identified via the HTTP Archive.
• Repeat views are a whopping 20% slower than they were last year, probably due to the the number of page objects.
• Page Speed scores have gotten significantly worse, from 83% last year to 75% now. I was just talking to Pat Meenan, who created WebPagetest, and he pointed out that a probable reason for the drop is because the newest version of Page Speed checks for more optimizations, which has resulted in lower scores across the board. (Side note: It’s important to know that Page Speed doesn’t take into account advanced front-end content optimization techniques — nor could it, because there are way too many of them to track and measure. As a for-instance, we’ve had experiences here at Strangeloop where we’ve taken a page with a perfect Page Speed score, accelerated it with Site Optimizer, cut load time in half, and ended up with a new Page Speed score of 74%.)

While the findings are a mixed bag of good and bad news, to me the most exciting takeaway is the  attention this report has received from major media outlets like CBS News. It goes to confirm what became evident over Black Friday: site speed has become a mainstream issue.

Download the report: 2012 State of the Union: E-Commerce Page Speed and Website Performance

Download a high-res version of the infographics above (feel free to re-post): Poster: E-Commerce Page Speed and Website Performance (2012)

Related links:

• End-of-year web performance report: Top retail sites are slower, not faster, than the rest of the pack
• Use of content delivery networks doesn’t correlate to faster websites for the Alexa Retail 1000
• Front-end web performance optimization: It isn’t over till it’s over. And it’s never over.

• Are mobile users more or less tolerant of delays than desktop users?
• Are users of one type of system more accepting of delays than users of another?

These questions are a gateway to a fascinating area of research, because they lead into a topic that we all have pet theories about (i.e. Chrome users are more tech savvy than the average person, while Internet Explorer users are less) but have little statistical evidence to back up.

I told Mac that I planned to do more digging and report back, so here I am.

Methodology

1. I took five e-commerce sites (full sites, not mobile versions) that Strangeloop is currently accelerating and pulled their entire transaction volume over the past month — totaling hundreds of millions of unique visits via desktop and mobile. While desktop transactions outnumbered mobile transactions, the mobile numbers were still statistically significant: the smallest set of mobile numbers comprised around 200,000 unique visits and the largest set comprised about 20 million unique visits.
2. I extracted the following data: page views, time on site, and bounce rate.
3. I sorted the data into the following browser/OS groups: Internet Explorer, Firefox, Chrome, iPad, iPhone, and Android (phone).
4. I calculated the averages for each metric and browser.
5. I graphed the numbers and looked for trends. Some interesting patterns emerged:

Three Key Findings

Finding #1: Internet Explorer users consistently view more pages, spend more time on site, and have a lower bounce rate than Firefox and Chrome users.

The average number of page views for IE users was 6.134, as opposed to 5.17 for Firefox users and 5.14 for Chrome users. IE users spent between 30-45 seconds longer on the site than other users, and their bounce rate was lower by 5 or 6 percentage points — a pretty significant difference. Could all of this substantiate the belief (among non-IE users, at least) that IE fans are less tech savvy and therefore slower and more ponderous web users than the rest of us? Or perhaps it’s a hardware issue — are IE users more likely to be using older systems with less processing power?

But what about that lower bounce rate? At around 35%, it’s a pretty strong number, especially compared to 41% for Firefox users and 42% for Chrome. A lower bounce rate generally signifies that people who come to your site find it relevant and worth sticking around to check out. Are IE users better searchers and more likely to arrive at the right destination, or are they simply more easily satisfied than other users?

Finding #2: iPad users are more similar to desktop users than they are to smartphone users.

While iPad users view somewhat fewer pages per visit than desktop users (4.54 versus 5.14, 5.17, and 6.13), their average time on site and bounce rate were commensurate with the desktop crowd. This isn’t a huge surprise. We know that most iPad users are browsing in the comfort of their home, and they consider their iPad to be more like a small laptop than an oversized phone. What’s interesting here is that, even though iPad performance lags behind desktop (it is a mobile device, after all, and it suffers from many of the same performance constraints as a smartphone: from low processor power to touchscreen lag), iPad users seem willing to stick around for a longer desktop-like experience.

Finding #3: iPhone users consistently view fewer pages, spend less time on site, and have a higher bounce rate.

At the opposite end of the spectrum from Internet Explorer users we find iPhone users. In every sample group, iPhone users, on average, spent significantly less time on site (2:31 vs 3:20) and viewed fewer pages (2.41 vs 3.1) than Android, and had a higher bounce rate (60.76% vs 57.17%). The shorter time spent on site could be attributed to the (arguable) fact that iPhones are better-powered than other devices, but that doesn’t account for the page views and bounce rate. Do these validate all the stereotypes about iPhone users: that they — or should I say, we — are impatient, savvy web users who will bounce from a site if we can’t find what we want right away and aggressively search elsewhere? Or that we know what we want and can expedite a transaction faster and more efficiently than other users?

Takeaways

This research doesn’t directly answer Mac’s questions, but it does come at them sideways and raise some interesting — to me, anyway — questions about the types of people who use different technologies, and how and why they use them. We can’t answer these questions today, but these findings are food for thought and debate.

Your thoughts?

Related posts:

• Case study: The impact of HTML delay on mobile business metrics
• The relationship between faster mobile sites and business KPIs: Case studies from the mobile frontier [Velocity EU]
• Announcing the Strangeloop Mobile Site Optimizer

Given all this, I couldn’t not respond to this post about responsive design written by Joaquin Lippincott, president of Metal Toad Media: When It Comes to Mobile Development, Stop Worrying about Bandwidth. He makes some good points about the fact that some responsive design techniques — such as swapping out images for CSS3, and using other CSS3 techniques like gradients and transparencies — are processor-intensive, meaning that while they may deliver superior performance, they can be tough on your device’s CPU.

But this statement stopped me in my tracks:

When it comes to building websites in 2012, bandwidth truly doesn’t matter. [emphasis mine] And it’s going to matter even less in 2013 with the roll out of more 4G networks. Additionally many devices are often on wi-fi, so provider network speed is truly a non-issue. Even on 3G, bandwidth isn’t a big deal – we’re streaming HD video, so don’t sweat 20k images.

To say that bandwidth seriously doesn’t matter, in any context, is obvious bait for any performance geek. True, a growing number of mobile users are browsing via tablets at home over their wifi connection, but this shouldn’t distract us from the fact that mobile use is growing across the board, which means that the total number of people connecting over 3G and 4G is still increasing. And any mobile user who is sensitive to their data cap — and to those monthly bills from their telecom provider — will tell you that, for them, bandwidth truly does still matter.

Not surprisingly, there were comments from a few performance geeks at the end of the post, which ultimately led to Joaquin clarifying his point to mean that developers and designers need to balance the trade-offs between bandwidth and CPU load.

While I think that anyone who builds sites for a living gets the fact that speed is an important usability issue (or as I prefer to put it: speed is THE important usability issue), I hear alarm bells when I hear people casually toss off statements like “bandwidth doesn’t matter”. To me, this post demonstrates the wide gap that still exists between design and performance. It also makes me wonder what kinds of conversations are happening out there between digital media agencies and their clients, who might not have the technical background to understand the nuances of what’s being discussed.

Your thoughts on juggling responsive design and mobile performance? I’d love to hear stories from the trenches.

Related posts:

• O’Reilly Radar interview: You can’t get away with a bad mobile experience anymore
• Case study: The impact of HTML delay on mobile business metrics
• Interesting findings: 3G mobile performance is up to 10X slower than throttled broadband service

In the 1990s, researchers at the University of Toronto conducted a study in which patients undergoing a colonoscopy were prompted every 60 seconds to indicate the level of pain they were experiencing. Patients rated pain on a scale of zero to 10, in which zero was no pain and 10 was intolerable pain. A total of 154 patients participated in the experiment; the shortest procedure lasted 4 minutes, and the longest was 69 minutes.

In the graphs below, you can see the experience of two representative patients. As you can see, the experience of each patient varied considerably during the procedure, which lasted 8 minutes for patient A and 24 minutes for patient B.

An interesting question emerges from this: Assuming that both patients used the scale of pain similarly, who actually experienced more pain? Based on these graphs, most of us would assume that Patient B suffered significantly more than Patient A.

Surprise finding: Duration of pain doesn’t correlate with perceived intensity

After the procedure, patients were asked to rate the “total amount of pain” they had experienced during the procedure. Surprisingly, Patient A retained a much worse memory of the experience then Patient B — in fact it was twice as bad.

What emerges from this are two very interesting patterns in the human brain, which have been repeated and noted in many subsequent studies:

• Peak-end rule: The total amount of pain was well predicted by the average of the level of pain reported at the worst moment of the experience and at its end.
• Duration neglect: The duration of the procedure had no effect whatsoever on the rating of overall pain.

The fact that duration has no real impact on the overall experience intrigued me, so I dug deeper into this area of research.

I found another study that shed more light on this (a study whose name I really like: the Cold Pressor). In this study, participants were asked to hold their hands in painfully cold water until they are invited to remove it and are offered a warm towel. During immersion, participants were asked to provide a continuous record of the pain they experience.

Each participant endured two cold-hand episodes, with some starting with the short episode and some starting with the long one:

• The short episode consisted of immersion for 60 seconds at 14 degrees Celsius followed by a warm cloth and a 7-minute break.
• The long episode (conducted on the other hand) consisted of the short episode + 30 additional seconds in which the water was made 1 degree warmer without the knowledge of the participant (1 degree Celsius is barely perceptible), followed by a warm cloth and a 7-minute break.

After completing both episodes, participants were told they needed to perform a third trial and were given the choice to repeat either the first or the second experience. The participants had no explicit knowledge that the duration of each episode was different, or that the water temperature had changed.

The peak-end rule theory predicted a worse memory of the short episode, and duration neglect predicted that the difference between 60 and 90 seconds will be ignored. This is exactly what they found: 80% of the participants chose to repeat the long episode and endure 30 seconds of slightly reduced, but totally needless, pain.

If participants had been asked “Would you prefer a 60-second or 90-second immersion?” I’m certain everyone would have selected the short episode. When asked, people knew which episode was longer, but they did not use this information to make their decision.

How do the ‘peak-end rule’ and ‘duration neglect’ apply to web performance?

Interestingly, the peak-end rule would tell us that the last page in a flow (i.e. the end of the experience) would have a large impact on a user’s experience and perception. In an e-commerce scenario, the last experience is often the slowest, caused by a long credit card authentication process. For example, I just booked an airline ticket and tracked the page load time across the flow:

Conclusion: We need more studies

In the past, I’ve shared a case study showing how we tracked abandonment throughout a mobile transaction, and how slowing down different pages in the flow affected bounce rate. As a follow-up to that (which I hope to get to soon), I’m very interested in seeing, on a predetermined flow, the relationship between the performance of the last page and overall user satisfaction (measured by repeat site usage and/or cross referenced with the customer survey data that many of our customers religiously gather).

The duration neglect phenomenon is even more interesting. If human memory neglects to take duration into consideration as a key factor in determining the pain or gain of an experience, why is page performance so closely correlated to overall user satisfaction and key metrics like bounce rate, page views and conversion. I think we need to perform more controlled studies on real participants to really understand how duration neglect relates to our world.

I’ve been thinking about designing a few studies to mimic the controlled psychology studies above. If you have an experiment design you’d like to share — or better yet, if you run a psychology department and want to collaborate — let me know.

Related posts:

• “Phone rage”: How people react to slow mobile sites
• Case study: The impact of HTML delay on mobile business metrics
• This is your brain on a slow website: Lab experiments quantify “web stress”

• these tools collect use data accurately,
• these tools analyze data accurately, and
• these tools depict data accurately.

Why? Because, no matter how great we think we might be as statisticians, most of us are not.

How do I know this? Because I showed ten performance leaders the same simple data points and asked them for their interpretations… and eight of them got it wrong.

Should they be embarrassed about this? Not really. Here’s why…

Related posts:

• 2012 predictions: The average web page will hit 1 MB, Google and Siri will face off, and Chrome, Windows 7, and RUM will rise
• You are the worst judge of your web site’s performance. Here’s why.
• Why the performance measurement island you trust is sinking

1. Early findings: 97% of mobile end-user response time happens at the front end

I revisited Steve Souders’s four-year-old stat that says that 80% of end-user response time occurs at the front end, and made a surprising discovery: After analyzing beacon data from 5 million Strangeloop customer transactions, I found that the front end is where a whopping 97% of mobile response time happens.

2. How to perform a 5-minute page speed/revenue analysis of your e-commerce site

I converted a performance non-believer, first by showing him that his site was 30% faster in IE8 than in IE7, and then by pointing out that the value per visitor on his site was 29% higher for IE8 than it was for IE7. Using two simple tools you probably already have at hand, you can quickly calculate how a faster user experience correlates to greater order value on your own website. (We later used this post as the basis for a short webinar, which you can watch here.)

3. The 12 most-asked questions about how Google factors page speed into its search rankings

It’s a well-known fact that site speed is a critical ranking factor for organic search. One of the most-asked questions I receive is: How exactly does Google do this? Over the last year and a bit, I’ve done quite a bit of digging to get the answers. I thought it would be useful to start an FAQ-style repository for the answers.

4. Automating complexity: The future of website performance optimization

Applying performance best practices in a general sense will take care of 80% of front-end web performance problems, but the last crucial 20% can only be achieved through painful real world testing and iterative problem solving. We need to find a way to do this quickly and cost-effectively. Back in January, this was my vision.

5. Google’s new Page Speed service: A handy resource for smaller site owners

When Google announced their Page Speed service in July, the most frequent question fielded was, “Is the Page Speed service a threat?” In short, no. If anything, it offers yet more validation that site speed is a crucial business issue.

6. Fourth-party calls: What you don’t know can hurt your site… and your visitors

There’s a growing awareness of the fact that third-party content can cause a major hit to your website’s performance. Good. Great. Now we need to tackle what I’ve dubbed “fourth-party calls”. Not only can these insidious server calls leach performance, they also have massive security implications.

7. Slow websites make people angry

Aberdeen Group has reported that “A one-second delay in page load time equals a 16% decrease in customer satisfaction.” But what does that customer dissatisfaction look like in the real world? I searched Twitter to find out. It wasn’t pretty.

8. Front-end optimization: It isn’t over till it’s over. And it’s never over.

A concise example illustrating three important things about front-end optimization (FEO): the current performance rules are not complete; these performance rules will never be static; and the front-end optimization market is evolving faster than the current performance tools can measure.

9. This is your brain on a slow website: Lab experiments quantify “web stress”

Fascinating study: Brain wave analysis reveals that people have to concentrate up to 50% more when using badly performing websites. EOG technology and behavioral analysis also reveal greater agitation and stress in these periods.

10. Why the performance measurement island you trust is sinking

I routinely encounter customers that have been led, by the very experts they trust, into believing that their site performance can be measured by the wrong tools. This post was written to explain exactly why you can’t always believe the experts.

This is my last post of 2011. Before I sign off for the year, I want to take a moment to thank you for coming to this site, for reading, and for your thoughtful comments. It’s a privilege to write for such an engaged community at such an exciting time in our industry. I’m looking forward to even more exciting times ahead.

Related posts:

• The 20 best web performance links of Q4
• The 25 best new web performance links of Q3
• This month’s 21 best new web performance links

1. The average web page will surpass 1 MB in size.

Between December 2010 and now, the average web page grew from 716 KB to 965 KB, according to the HTTP Archive. That’s 30% growth in slightly less than one year. This kind of growth is the norm, as pages have grown at a rapid rate since 1995, when the average page size was just 14.1 KB. It’s pretty safe to assume that this growth will continue. We’re going to see sites grow by at least another 30%, taking them well over the 1 MB mark — a number that would have blown our minds 10 years ago. The main culprits: images (which account for more than half of the average page size) and third-party scripts like analytics, ads, and social sharing widgets.

2. Site owners are going to demand more transparency and control over third-party content and scripts.

As the graphs above show, scripts are the fastest-growing area of page growth. In just one year, scripts have grown by 50%, from 115 KB to 172 KB on the average page. As I wrote here a couple of months ago, the average top e-commerce site contains seven third-party scripts, with some sites containing up to 25 scripts. These can have a serious impact on page performance. Poorly optimized third-party scripts can slow down page load by several seconds or even stall it completely.

Currently, most third-party script providers don’t offer real-time monitoring of their scripts, nor do they offer meaningful service level agreements (SLAs). As site owners become increasingly educated about the importance of page speed, they’re going to start demanding that scripts be properly optimized to either load asynchronously (or better yet, load after document onLoad). They’re also going to demand better monitoring, reporting, and accountability from script providers.

3. Chrome will become the dominant browser.

For the past year, we’ve seen Internet Explorer and Firefox slowly dropping in popularity, while Chrome’s popularity has been rising steadily. Right now, IE is still dominant, and Chrome just passed Firefox. Chrome’s success is well deserved. It’s fast, clean, and comparably glitch-free. With Chrome set to unite with Android, which is as much a semantic merger as a technical one, we’re going to see Chrome’s numbers climb sharply.

4. Windows is going to surprise us on mobile.

Everyone thinks it’s an iOS/Android world, but that could all change when we see Windows 7 embedded in the next wave of Nokia devices. I recently had a chance to play around with a Win7 device, and it was pretty slick (which, coming from a die-hard iPhone user, is saying a lot). Remember how Internet Explorer blew Netscape out of the water back in the ’90s? Windows 7 might not be a game changer to quite that extent, but we’re going to see it become a contender in the mobile universe.

5. Mobile consumer behavior will continue to evolve as mobile users’ expectations grow.

Marriott recently reported that 47% of their mobile bookings happen on the same day as check-in. This implies an important paradigm shift among mobile user behavior. Clearly, these users have developed the expectation that they can book on demand and on the go. Mobile users expect 100% availability and quick response. There’s zero “try again later” mentality. They won’t return to a poorly performing site — they’ll bounce to another site that can give them what they want immediately. We’re going to see more of this type of behavior, and site owners are going to have to adjust to the fact that mobile users are even more demanding than desktop users.

6. Companies will focus internally on mobile development.

As I mentioned in this piece on O’Reilly Radar, the 2011 holiday shopping season has proven that the mobile web is no longer a curiosity. Rather than keeping mobile on the sideline, in 2012 companies will grow their mobile teams, and these will eventually match the size and scope of their regular development teams.

7. Amazon Silk is not going to spark a browser revolution.

As I also mentioned in the O’Reilly interview, while Silk offers a performance boost for some tablet content, even its own product manager, Brett Taylor, says of tablet browsing, “It’s not meant to process and crunch a lot of heavy data.” I’ve written many times about the difference between basic versus advanced content optimization. Basic optimization techniques – such as those embedded in Silk – can actually slow down, or even break, pages. Web pages are becoming even more complex, data-intensive, and dynamic. Because of this, advanced content optimization – which takes a big-picture approach to accelerating the entire site — is increasingly emerging as the only reliable way to optimize sites without causing harm.

8. Google and Siri could begin a long face-off.

Google has become synonymous with search, and it would require a massive paradigm shift to dislodge them from this position. Siri has the potential to be a formidable contender. By taking users completely out of keyword-entry mode, and by focusing on local search, Siri is incredibly attractive to mobile users, who are often task-oriented and on the move. But it all comes down to results. Google became dominant in search because it delivered the most relevant results, and it delivered them fast. If Siri can do the same – and to be blunt, right now Siri kind of sucks — then it’ll be interesting to see how Google responds.

9. Companies are going to start shining a spotlight on internal application performance.

2010 and 2011 marked the years when companies realized how important site speed was for their e-commerce sites. Now that everyone has internalized the fact that faster pages equal more revenue, they’re going to take this insight and apply it to their internal web-based applications. There are a lot of studies, dating back as far as 1968, showing that employees can radically increase their productivity — in some cases by more than double — when computer response time is improved by just 2 or 3 seconds. But very few companies did anything with these findings. We’re going to see a renaissance in this kind of research, and we’re finally going to see companies aggressively pursue improving internal performance.

10. The CDN market is going to become a lot more competitive.

Until recently, whole site acceleration or dynamic site acceleration (DSA) was a big-ticket solution offered by one company. Now there’s a growing selection of competitive products backed by innovative companies offering newer technology and, ultimately, faster sites. Unlike the price wars that happened in the video delivery marketplace a few years back, the added value will keep prices and margins at reasonable rates (nothing like the usurious rates currently being charged). The big winners here are going to be savvy site owners, who could see their bills reduced, and their service quality go up.

11. Real user monitoring will make performance testing accessible to smaller, “mortal” companies.

Performance testing is challenging. When synthetic tests (sometimes called backbone tests) were first developed, they came with a pretty major price tag, which meant they could only be embraced by site owners with deep pockets. With the recent proliferation of affordable, quality real user monitoring (RUM) tools, site owners will be able to finally get real insight into their visitors’ behavior — at a decent price.

Agree? Disagree? I’d love to hear your thoughts.

Related posts:

• 2011 Web performance predictions for the mobile industry
• Automating complexity: The future of website performance optimization
• End-of-year web performance report: Top retail sites are slower, not faster, than the rest of the pack

This roundup (which includes links pulled from the Strangeloop WPO Hub), includes some increasingly refined thinking about mobile optimization, a handful of excellent tutorials and case studies (including some great new presentations from Velocity EU), and some revolutionary browser developments.

But my favourite link is this first one…

The best link of Q4

Retailers need for tech speed
Does it tell us anything new? No. But I’ve lost count of how many people I’ve forwarded this two-minute segment on CNBC’s “Power Lunch” — which discusses the importance of speed for e-commerce sites, particularly for mobile users, during the holiday shopping season. For me, this shows that site speed has finally jumped into the mainstream. I’m excited to see how this attention snowballs in 2012.

Mobile

Mobile UI Performance
This slide deck from Estelle Weyl’s excellent presentation at Velocity EU gives an overview of mobile performance challenges, why we need to address them differently than we deal with desktop sites, and detailed tips on how to do just that.

Performance Automation 101
This slide deck from Jeroen Tjepkema’s Velocity EU presentation explains what performance automation is, how it works, and why it’s the only viable solution for dealing with the challenges of mobile device/browser fragmentation.

HTML5 Techniques for Optimizing Mobile Performance
Great post on HTML5 Rocks: ”In this article, we will discuss the bare minimum of what it takes to create a mobile HTML5 web app. The main point is to unmask the hidden complexities which today’s mobile frameworks try to hide. You will see a minimalistic approach (using core HTML5 APIs) and basic fundamentals that will empower you to write your own framework or contribute to the one you currently use.”

Mobile Performance Manifesto
Love this post from David Calhoun itemizing and describing mobile performance best practices.

Tools

How WebPagetest works
If you’ve ever wondered how exactly WebPagetest gathers performance data from the various browsers it simulates, this is great post from Pat Meenan in which he cracks the hood of WebPagetest and explains all that.

Mobile Perf Bookmarklet
Steve Souders offers one mobile bookmarklet to rule them all: a new “master bookmarklet” that lets you install a handful of common debugger and profiler bookmarklets in your mobile broswer in one step.

Is Synthetic Monitoring Really Going to Die?
Alois Reitbauer asks: “Will User Experience Management using JavaScript agents eventually replace synthetic monitoring or will there be a coexistence of both approaches in the end?” As you might guess, the answer is not cut and dried.

Case studies, how-tos, and other research

Diagnosing Slow Web Servers with Time to First Byte
Much as it pains me to admit it, from time to time performance pains aren’t caused at the front end. Performance expert Andy King gives some good tips on how to use the time to first byte metric, as displayed on a waterfall chart, to help diagnose a slow server.

The art and craft of the async snippet
Stoyan Stefanov examines the topic of asynchronous code “from the perspective of a third party – when you’re the third party, providing a snippet for other developers to include on their pages, be it an ad, a plugin, widget, visits counter, analytics, or anything else.”

Why loading third party scripts async is not good enough
We talk about asynchronously loading third-party snippets as if that’s the sole cure for performance pains, but in this case study, Aaron Peters reminds us that sometimes it’s okay to defer their loading until after onload.

Fast Loading JavaScript
Slide deck from performance consultant Aaron Peters’ great Velocity EU presentation: “A walk-through of several JavaScript loading techniques with a characteristics table for each and at the end a decision tree to help you decide which technique to use.”

How Downtime Financially Impacts Top Ecommerce Websites
Compelling infographic showing how downtime affected the Internet Retailer 500 in 2010. Includes the estimate that downtime resulted in more than $300 million in lost revenue for the IR 500.

Testing for Frontend SPOF
Excellent post from Pat Meenan in which he simulates third-party outage with a blackhole server in order to demonstrate — via WebPagetest-generated video — how that outage slows down or disrupts page load.

Browsers and connectivity

SPDY of the Future Might Blow Your Mind Today
Great post (“definitely for protocol geeks”) by Google software engineer Mike Belshe on SPDY’s evolution and how Kindle Silk is taking it beyond other browsers.

Chrome Fast
Slides from Google software engineer Tony Gentilcore’s excellent presentation at Velocity EU, in which he gives an overview of the Chrome platform and explains what makes Chrome fast.

Report reveals drop between peak and off-peak surfing
No big surprise, but a good reminder (especially if you rely on synthetic testing) that real-world performance is a nebulous thing: UK study finds that web speed is up to 69% slower during evening peak time.

The end of an era: Internet Explorer drops below 50% of Web usage
Mark the month and year. November 2011 was the first time in more than a decade that Internet Explorer’s share of global browser usage dropped below 50%.

Opinion pieces

Your CDN is not a silver bullet for web performance
In the e-commerce and SaaS world, the two most common causes of poor web performance are third-party content and server-side processing. Neither of these bottlenecks are addressed by loading static content from a closer location via a content delivery network.

Why you have less than a second to deliver exceptional performance
dynaTrace’s Alois Reitbauer writes: “Being exceptionally fast is becoming the dogma for developing web applications. But what is exceptionally fast and how hard is it to build a top performing web site?” I like posts like this because they remind us what the fundamental questions are that our industry is trying to address.

If you have any other great links to share, let me know in the comments. And if you’re looking for more great links, we have hundreds — sorted by topic, industry, and type — over in the Strangeloop WPO Hub.

Related posts:

• The 25 best new web performance links of Q3
• Cheat Sheet: Everything you wanted to know about web performance but were afraid to ask
• 22 not-so-short links about web performance