Yahoo

Browser innovation and the 14 rules for faster loading websites: Revisiting Steve’s work (part 2)

13 Sep 2012

4 Comments

A few months back, I posted part 1 of a 3-part post to answer the question:

“Aren’t many of the web performance rules described by Steve Souders in 2007 already outdated or made obsolete by browser innovation?”

Despite the fact that my company was founded on the premise that Steve’s rules are our bible, I still place a great deal of value on testing core assumptions. Fortunately, testing the first five rules revealed that these performance rules have stood the test of time and are as valid today as they ever were.

Today (finally), I want to look at the next five rules:

Methodology

1. As with my previous post, I used these test cases of the performance rules that Steve created five years ago, and which are still available. Using the Wayback Machine, I timestamped them to October 2007.

Steve Souders: 14 rules for high performing web sites2. Next, I ran each test case on Internet Explorer 6 on WebPagetest to get a sense of what Steve would have seen for performance rules 6 through 10. I did three runs of each test and used the median result.

3. Then I ran each test case on Chrome 19 to see what impact, if any, the rules have on a modern browser. Again, I performed three runs of each test and recorded the median result.

4. Using the above approach, I was able to see and compare the before-and-after results for each rule for both browsers, and then calculate the benefit. You can see the detailed test results, along with links to the tests, in this spreadsheet.

Important: The goal here is not to look at how fast Chrome 19 is versus Internet Explorer 6. We have looked at this in the past. This time I want to look at the relative benefit of each performance rule.

Findings

Here’s a high-level look at the results:

Rule 6: Move scripts to the bottom of the page

What this rule means: It’s better to move scripts from the top to as low in the page as possible. One reason is to enable progressive rendering, but another is to achieve greater download parallelization.

With scripts, progressive rendering is blocked for all content below the script. Moving scripts as low in the page as possible means there’s more content above the script that is rendered sooner. The second problem caused by scripts is blocking parallel downloads. While a script is downloading, the browser won’t start any other downloads, even on different hostnames. [From High Performance Web Sites]

Testing the rule: Steve experimented with placing scripts in various places on a page in order to see their performance impact. Using the methodology above, I was able to see the performance benefit (defined by the improvement in document complete time) of applying two of these techniques to IE6 and Chrome 19:

Rule
 Benefit in IE6 Benefit in Chrome 19
Scripts at the bottom 0.13% 18%
Deferred scripts
 31% 18%

Rule 7: Avoid CSS expressions

What this rule means: CSS expressions are an older technique, supported in Internet Explorer up until the release of IE8, which let you set CSS properties dynamically. The problem with CSS expressions was that they were evaluated more often than most people realized. As Steve pointed out in 2007, moving the mouse around the page can easily generate more than 10,000 evaluations.

This technique has fallen out of practice, largely because of findings like Steve’s. Nobody with any common sense is using this technique anymore, so it’s not relevant.

There may, however, be a modern version of this same issue. I’ve heard reports abut similar issues with JavaScript performance due to easy-to-use JS libraries such as JQuery. Similar to CSS expressions, it’s very easy to hook up functions to JavaScript events like moving the mouse and scrolling, causing similar tens of thousands of calculations to happen. I’m not sure how often this is actually happening out in the real world, but it’s something to be aware of.

Testing the rule: N/A

Rule 8: Make JavaScript and CSS external

What this rule means: If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, you could potentially benefit from cached external files.

Pages that have few (perhaps only one) page view per session may find that inlining JavaScript and CSS results in faster end-user response times.

For front pages that are typically the first of many page views, there are techniques that leverage the reduction of HTTP requests that inlining provides, as well as the caching benefits achieved through using external files. One such technique is to inline JavaScript and CSS in the front page, but dynamically download the external files after the page has finished loading. Subsequent pages would reference the external files that should already be in the browser’s cache. [From High Performance Web Sites]

Testing the rule: Below are the performance gains (defined as the improvement in document complete time in the repeat view) for both browsers:

Rule
 Benefit in IE6 Benefit in Chrome 19
Cacheable external JS and CSS 37% 40%
Post-onload download 42% 45%
Dynamic inlining 38% 44%

Rule 9: Reduce DNS lookups

What this rule means: There’s no test case for this rule — because it’s a given that fewer DNS connections is a good thing — but I still want to review it here in order to talk about why it’s a good thing.

DNS lookup is when the browser looks up the domain of the object being requested by the browser. Think of this as asking the “phone book” of the internet to find someone’s phone number using their first and last name. DNS lookups are cached for better performance — on caching servers maintained by your ISP or LAN, on your operating system’s DNS cache, and in your browser cache.

Steve offers this advice: Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times. My guideline is to split these components across at least two but no more than four hostnames. This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.

It’s important to know that some newer browsers (at least Chrome does) do DNS prefetching as well.

Testing the rule: N/A

Rule 10: Minify JavaScript

What this rule means: Minification is the practice of removing unnecessary characters — such as comments and white space — from code. This improves JavaScript response time because the size of the downloaded file is reduced. Minification is fairly straightforward, unlike its sister practice: obfuscation.

Like minification, obfuscation removes comments and white space, but it also munges the code — converting function and variable names into smaller strings, thereby making the code more compact as well as harder to read. While munging wasn’t originally conceived of as a performance practice, it was found that it can help performance because it reduces the code size beyond what is achieved by minification. (Warning: Obfuscation can lead to bugs, unlike minification, which is relatively problem free.)

In addition to minifying external scripts, you can also minify inlined script blocks. Even if you’re already gzipping your scripts, minifying them will still reduce the size by at least 5%.

Testing the rule: Below are the performance gains for both minification and obfuscation of different-sized files:

Rule
 Benefit in IE6 Benefit in Chrome 19
Small script minified 14% 16%
Small script obfuscated 14% 15%
Large script minified 22% 21%
Large script obfuscated 23% 21%

Conclusion

Once again, it’s reassuring to see how many of the performance rules have stood the test of time. I was really struck by how similar the results were for many of the test cases. I had expected that the rules would still be relevant, but to be perfectly honest, I had also expected that browser evolution would have resulted in more disparity between the results.

It was also interesting to see how a rule — avoid CSS expressions — has become so entrenched over time that it’s no longer an issue.

This has been a really interesting exercise so far. I’m looking forward to part 3.

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: , , , , , , , ,

The 27 best web performance links of Q1 2012

12 Apr 2012

3 Comments

This week, I had a chance to go through the latest links added to Strangeloop’s WPO Hub, and as always, I’m impressed by the breadth and depth of the topics covered. There are a lot of smart people in our industry.

A few things I noted in the first quarter of 2012:

  • We saw a lot of jockeying for performance dominance and audience dominance among browsers, indicating that the war isn’t over yet. This is great news for all of us — from users to site owners.
  • Our understanding of issues that affect mobile performance and third-party performance — topics that most of us were ignorant of just a couple of years ago — is increasingly nuanced.
  • More and more, we’re seeing mainstream coverage of web performance, signalling that this topic has permanently entered the public spotlight. It definitely makes my job easier. :)

Mainstream coverage

For Impatient Web Users, an Eye Blink Is Just Too Long to Wait
Really great piece in the New York Times about Google’s research into the neuroscience behind perceived page speed. Excerpt: ”Remember when you were willing to wait a few seconds for a computer to respond to a click on a Web site or a tap on a keyboard? These days, even 400 milliseconds — literally the blink of an eye — is too long, as Google engineers have discovered. That barely perceptible delay causes people to search less.”

How One Second Could Cost Amazon $1.6 Billion in Sales
Fast Company published this piece about our (lack of) tolerance for wait times in general, and about page speed in particular. Among other things, they cite the stat that one in four people abandons a page if it takes longer than four seconds to load.

Webpages showing sharp growth in girth
This was a fun example of the trickle-up process in action. On December 20th, I predicted that the average web page would hit 1MB in 2012. On December 21st, GigaOM picked it up. On December 22nd, it showed up on BBC News. I love the internet.

Think Quarterly: The Speed Issue
Google’s “Think Quarterly” isn’t exactly a mainstream publication, though it’s pretty widely read in the tech community, but I’m including this link here because I love the broad approach — ranging from technical to philosophical — of this particular issue, which is dedicated to the idea of speed. It includes articles by Urs Hoelzle, Kristen Gil, Jeff Jarvis, and Tjaco Walvis. Definitely a must-read.

Browsers

Which Browsers are the Fastest?
Interesting study from New Relic. Key findings were that, while IE 9 outperforms other browsers on Windows, Chrome 13 on Mac was overall the fastest experience (2.4 seconds). In mobile speed tests, the fastest experience was on Blackberry Opera Mini (2.6 seconds), twice as fast as Safari 5.1 on iPad.

Internet Explorer market share surges, as IE 9 wins hearts and minds
Summary: ”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.”

Browser Speed Tests: Chrome 17, Firefox 10, Internet Explorer 9, and Opera 11.61
As always, the latest round of Lifehacker browser speed tests generated some interesting results. Overall, Chrome was the winner, but the tests crossed a lot of parameters, and each browser had its strengths. Definitely worth checking out, especially if you’re new to understanding the nuances of browser performance.

Internet Explorer Performance Lab: reliably measuring browser performance
The MSDN blog offers a detailed look behind the scenes at the IE Performance Lab. Be sure to check out the comments, too.

Chrome Fast for Android
A must-read if you care about mobile web performance: Google engineer Tony Gentilcore’s top 10 Chrome for Android speed features.

Chrome 16 – World’s Most Popular Browser
Interesting observation from Google engineer Mike Belshe: In January 2012, Chrome 16 quietly became the world’s most popular browser.

Case studies and other research

Just One Second Delay In Page-Load Can Cause 7% Loss In Customer Conversions
The folks at TagMan partnered with the UK’s leading glasses e-tailor, Glasses Direct, to study page speed and conversion behavior. Their findings substantiated Aberdeen’s 2009 findings, in which slower page load times correlated with a 7% drop in conversion rate.

Real User Monitoring at Walmart.com
Cliff Crocker, Aaron Kulick, and Balaji Ram joined forces at a meeting of the SF Web Performance Meetup to tell a RUM (real user monitoring) story through the lens of three job functions at Walmart.com: the performance data analyst, the developer, and the business analyst. Some excellent slides demonstrating the business value of performance. (I featured my four favourite slides in this post.)

The Performance Golden Rule
Excellent post from Steve Souders. He revisits his six-year-old stat about where end-user response time happens and confirms that 76-92% still happens at the front end. I really love this kind of post. In our industry, it’s crucial to keep revisiting these kinds of numbers and testing our assumptions.

The Need for Speed
Great case study for web performance geeks: How Chemeo delivers “pure bounce with pure value”.

No framework needed
Nice case study from 37signals about how they shaved 500ms from a page and got a 5% conversion bump.

January 2012 Site Performance Report
It’s great to trumpet success stories, but we learn as much by talking about what’s not working as by talking about what is.  This report card — in which the team at Wayfair shares how they suffered page slowdowns of up to 370% —  is a good reminder that optimization is a neverending task.

When good back-ends go bad
In this post for the annual Performance Advent Calendar, Pat Meenan talks about the fact that, while the back end is only responsible for 10-20% of response time, when it goes wrong, it can really go wrong. Among other things, Pat shares his findings that ”It is not uncommon to see 8-20s back-end times from virtually all of the different CMS systems.” Ouch.

Mobile

M-commerce site performance hampered by Verizon
Not exactly news, but still a good reminder from Internet Retailer that you’re at the mercy of networks when it comes to mobile performance: “The load times for virtually all of the 30 retailers on the Keynote Mobile Commerce Performance Index for the week ending Feb. 12 were negatively affected by a dip in performance on the Verizon wireless network.”

Mobile UI performance considerations
More goodness from the Performance Advent Calendar. If you’re just starting out with mobile web performance and don’t know where to begin, this post by Estelle Weyl is a good place to start. You should also check out her session slides from Velocity EU.

Tips and how-tos

Web Font Performance: Weighing @font-face Options and Alternatives
Nice collection of tips for making sure your web fonts aren’t slowing down your pages.

Timing the Web
Still more Advent Calendar goodness. dynaTrace technology strategist Alois Reitbauer explains how to use navigation timing to measure page load time.

Third parties

3rd Party Providers and DNS Poisoning Risks
Here’s a topic that doesn’t get talked about enough, via the Catchpoint blog: ”DNS cache poisoning refers to data breach, whereby new DNS records are introduced in the DNS Cache of a resolver or computer and divert traffic to a different IP address. The cache poisoning can be caused by hackers trying to divert traffic to a phishing/malware sites or it could be a configuration mistake. In either case the end result is not good for end users – they will end up accessing the wrong site or not access your site at all.”

Are External Services Slowing You Down? New Relic Infographic Reveals the Fastest and Most Popular External APIs
More research (with infographics) from New Relic, this time showing the four fastest 3rd-party APIs among the 200,000+ applications the company monitors.

Tools

Welcome YSlow Open Source
Yahoo has released the source code for YSlow under the BSD Open Source license. They’re encouraging devs to “use the source code, learn how it works, fork it to make your own projects and enhance it with new rules, features, and whatever will improve this tool we all love.”

Google: SPDY Gaining Adoption
Article in Web Pro News about the fact that SPDY is gaining support among browsers, developers, and vendors: “Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we’re actively working on a full featuredmod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.”

Introducing mod_spdy, a SPDY module for the Apache HTTP server
Google engineers Matthew Steele and Bryan McQuade break down how Google’s mod_spdy for Apache works.

The Biggest Misconception about Google Page Speed
Really interesting findings from Catchpoint: “There is no correlation between Page Speed Score and how fast a page loads.” This corroborates our own findings here at Strangeloop. A while back, I was talking about this with Pat Meenan, and 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. It’s also 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%.

And finally, a shameless plug for Strangeloop’s annual performance state of the union, which came out in January. We tested the top 2,000 Alexa-ranked retail sites and analyzed the results against our findings from the previous year. Among other things, we found that the average e-commerce website takes 10 seconds to load, web pages are getting bigger, and Internet Explorer 9 outperforms other browsers.

If you have any other 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 links:

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

The 25 best new web performance links of Q3

5 Oct 2011

6 Comments

A few people have asked me why I no longer do these monthly link roundups, and I didn’t have a good answer. (Not-good answer: I got busy.) But there have been so many great reads over the past three months that it feels like they really deserve the spotlight.

Not surprisingly, mobile is an even bigger deal than ever. There have been some great new presentations and studies. I was surprised, when digging through my bookmarks, to note just how many case studies there are, including under-the-hood reports from companies like Twitter and Facebook. To me, this is a really inspiring indicator of how much openness and excitement there is in our industry.

We’ve added these to our WPO Hub, which I encourage you to check out. It contains hundreds of links — organized by topic, source, research type, and industry — to the best performance-related content on the web.

Mobile

Mobile HTML5
For hardcore HTML5 and/or mobile geeks, this is an awesome table, created by mobile performance guru Maximiliano Firtman, which illustrates HTML5 compatibility across major mobile and tablet browsers.

Steve Souders: High Performance Mobile
A lot of people in our community (including myself) were kicking themselves for not being able to attend Steve’s talk at the San Francisco/Silicon Valley Web Performance Meetup. Next best thing: watching the video of his talk.

Mobile WPO
In June, I had the privilege of being a speaker at the Web Performance Summit. Fellow speaker Tim Kadlec gave a fantastic overview of the current mobile state of the union at the Web Performance Summit in June, which is a must-see.

Measuring Mobile Performance
Another great presentation, this one from front-end performance consultant Stephen Thair’s presentation to the London Web Performance Meetup Group. It’s packed with useful tips and how-tos.

What Mobile Users Want
Gomez revisited their two-year-old survey of mobile user expectations with this excellent report, which compares new data with those earlier benchmarks. Gomez found that mobile users are even more impatient than ever. 74% say they will abandon a site after waiting 5 seconds or less for it to load, up from 20% just two years ago. (If you want to see another take on this data, I created this set of graphs showing just how dramatic these changes are.)

Mobile website optimization now factors into mobile search ads quality
Google’s official announcement that mobile-optimized sites will factor into landing page quality and perform better in AdWords. This didn’t get a ton of media attention, but I think it should have. This algorithm change has implications beyond just AdWords, and I wrote about this here.

Tools

The Complete List of End User Experience Monitoring Tools
This is helpful list of tools for RUM and other user monitoring is a work in progress. Send your suggestions for additions to the folks at CorrelSense.

Yahoo! YSlow (Mobile)
YSlow for Mobile is now available as a bookmarklet. Users can run the equivalent of regular YSlow in Mobile browsers as well as any bookmarklet-enabled desktop browsers. [Note that this is a beta version.]

How-tos, case studies, and other research

Social button BFFs
Good post from Stoyan Stefanov on how to make your social buttons load asynchronously.

How-To: Optimize Social Plugin Performance
Facebook developers share some best practices, such as asynchronous loading, that can improve the performance of social plugins on your website.

Twitter’s mobile web app delivers performance
In-depth look at how Twitter developed its mobile app to maximize speed and performance.

“And that is why you need to speed up your site!”
I’m biased. I like this case study from performance consultant André Scholten because it validates my theory that, by using browser type and connection speed as proxies, you can use Google Analytics to simply demonstrate how faster sites make more money. Personal bias aside, it’s a pretty nifty speed-revenue analysis.

How We Improved Page Speed By Cleaning CSS, HTML and Images
Front-end developer Lara Swanson walks through a detailed case study showing how Dyn tackled performance optimization on its site.

How case-sensitivity for ID and ClassName can kill your page load time
Interesting findings from Andreas Grabner, showing how case-sensitivity causes a huge execution time difference in Internet Explorer 7, Internet Explorer 8, and Firefox 6.

Creating a Performance SLA with your customers – Betfair’s Customer Charter
Stephen Thair analyzes Betfair’s performance commitment in its customer charter, and discusses what a performance SLA should contain. Some thought-provoking stuff here.

Google +1 Button Performance Review and Google Triples the Speed of the +1 button
After Aaron Peters did a thorough audit of the +1 button’s performance and found some issues that could slow down page load by up to 2 seconds, Google responded by making some fixes to make the button faster. What I like about this pair of links is that it illustrates the level of transparency and mutual respect in our industry.

New performance findings

HTTP Archive: nine months
Nine months after the launch of the archive, Steve Souders compares performance data from November 2010 and August 2015 and discovers increases in total transfer sizes, requests per page, redirects, and page errors.

Website performance drop threatens top retailers
Report from Site Confidence analyses average download speeds for the UK’s top e-tailer websites and found an increase from 12 seconds in the first quarter of the year to 12.5 seconds in quarter two. This is a pretty steep increase from the average 10 second load time from the 2010 holiday season. This slowdown comes at a time when ecommerce is hurting in the UK.

Browsers and connectivity

Introducing Amazon Silk
You already know about Amazon Silk, but I just wanted to mention that I really like the short explainer video on the official blog. As someone who’s been working on “how it works” videos for my own company’s products lately, let me tell you: it isn’t easy.

Browser Market Pollution: IE[x] is the new IE6
Google Chrome team member Paul Irish explains why developers may soon need to develop with 76 different browsers in mind.

Browser Speed Tests: Firefox 7, Chrome 14, Internet Explorer 9, and More
Lifehacker tested browsers across a variety of functions — from cold boot-up to memory use — and Opera emerged as the clear winner.

The way carriers manage networks can hurt phone performance
Among other things, CNN writer Amy Gahran says that ”One of the largest U.S. carriers (unnamed in the study, since the data was made anonymous for legal reasons) appears to be slowing its network speed by as much as 50%.”

Industry news

Israel Web Performance Meetup Group
It’s always exciting news when a performance meetup group springs up.  Say hi to the new group based in Herzeliyya, Israel.

Opinion pieces

Why I think automation is the future of #webperf
Stephen Thair costs out manual versus automated performance optimization. I’m posting this link here, so you can guess that I like his conclusions. :)

Did I miss any great new links? Do you have other suggestions for the Hub? Let me know!

Related posts:

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

Revisiting the performance equation

30 Jun 2011

4 Comments

Way back in the good old days — that would be circa 2007, of course — we talked a lot about the performance equation here at Strangeloop. I came across this venerable equation today as I was going through some old reports, and I wanted to look at it again.

In September 2006, Peter Sevcik and Rebecca Wetzel of NetForecast published a paper called “Field Guide to Application Delivery Systems” (available for free by request here). The paper focused on improving wide area network (WAN) application performance and included the following equation:

While this equation looks at WAN performance, we wanted to take it and use it as the basis for a web application performance equation. So in 2007, we created this equation, along with our now rather dated definitions (note the IE 6 example), below:

Variable Definition
R Response time. The total time from the user requesting a page (by clicking a link, and so on) to when the full page is rendered on the user’s computer. Typically measured in seconds.
Payload Total bytes sent to the browser, including markup and all resources (such as CSS, JS, and image files).
Bandwidth Rate of transfer to and from the browser. This may be asymmetrical and might represent multiple speeds if a given page is generated from multiple sources. Usually, it is averaged together to create a single bandwidth expressed in bytes per second.
AppTurns The number of resource files a given page needs. These resource files will include CSS, JS, images, and any other files retrieved by the browser in the process of rendering the page. In the equation, the HTML page is accounted for separately by adding in round-trip time (RTT) before the AppTurns expression.
RTT The time it takes to round-trip, regardless of bytes transferred. Every request pays a minimum of one RTT for the page itself. Typically measured in milliseconds.
Concurrent requests Number of simultaneous requests a browser will make for resource files. By default, Internet Explorer 6 performs two concurrent requests. This setting can be adjusted but rarely is.
Cs Compute time on the server. This is the time it takes for code to run, retrieve data from the database, and compose the response to be sent to the browser. Measured in milliseconds.
Cc Compute time on the client. This is the time it takes for a browser to actually render the HTML on the screen, execute JavaScript, implement CSS rules, and so on.

Why I want to put this equation back on the table

What’s great about this equation, and the reason I want to revive it for conversation, is that it represents many of the areas where we add value. Equations like this are really useful to point out how you affect load time (i.e. using feature X makes payload smaller and thus reduces page load time).

Another reason for resuscitating this performance equation is because some people have a hard time visualizing waterfalls, and I have found that an equation helps.

In an ideal world, I would love to put up a slide describing our technology, which looks something like this:

But the reality is that this is much more complicated than I wished for.

Exercise: How does the equation stack up next to a waterfall?

I am no math genius, but when I started thinking about the equation in terms of the modern waterfall, I realized quickly that either we were totally misguided, completely ignorant, or the world has changed dramatically.

I started the exercise by looking at a waterfall. In order see how useful this is, I randomly selected the top test in the test history on WebPagetest. It happened to be Yahoo.

Very quickly, many unanswered questions started cropping up. For example: Given how different upload and download bandwidth are, do I need to divide these out and consider them differently?

So I made a small edit to the equation to take this into consideration:

Then I looked at the number of different domains and the fact that they all have different RTT times and different levels of concurrency. So I edited the equation again:

And another question: Where is connection and DNS time taken into consideration? If some roundtrips start new connections and/or resolve DNS, then that needs to be taken into consideration. So I edited the equation again:

Then things just got stupid as I tried to answer many more unanswered questions, such as:

  • How do I guess at a concurrency constant when concurrency is so varied within the waterfall?
  • How do I calculate Cc?
  • How do I capture blocking scripts?

The questions just kept coming.

After trying to take all of these items into consideration, I wound up with a big mess and abandoned the project altogether. My observations were as follows:

  • Our world is so complicated that a formula can’t be developed to synthetically deduce performance.
  • Formulas like this are descriptive in nature and should remain squarely in the hands of the marketing department.

Anyone know of anything that easily describes page load time? I’m willing to ship a nice case of Canadian beer to anyone who comes up with something representative and at least somewhat defensible.

Related posts:

By: Tammy Everts Category: Tags: , ,
1 2