Faster sites make more money. It's a statistical fact that is supported by objective studies and data gathering from such organizations as Google, Amazon, Aberdeen, and Gartner. Here are data points found in Akamai's new Slideshare presentation entitled: "Performance Implications of Mobile Design".

83% of consumers expect a website page to load in 3 seconds or less

source: Akamai

25% of visitors abandon a page after 4 seconds or less

source: KISS Metrics

12% increase in conversions by reducing page load time to 2 seconds

source: Shopzilla

I see something becoming more frequent and its increasingly concerning me.   The current method of Performance Testing – capture network level traffic, inspection, correlate, and then replay, is becoming increasingly complex.  In the ‘good old days’ we had simple GET and POST requests.  Then Ajax and Web2 came along, making things a little trickier.  I’m now seeing a lot of requests being generated dynamically within JS – and it’s nearly impossible to understand the JS code and replicate the logic in whatever is the performance tool of choice.  

We also have CDN’s and Magic boxes (e.g. Yottaa, Strangeloop) increasingly being sandwiched between client and the server – what was a static named resource can easily become dynamic from one moment to the next.   Do we want to test the CDN’s or not?  (In the majority of cases the answer is not).

I see performance engineers having to compromise on the traffic they replicate using their tools.  You can argue this has always been the case, but I would say that the approximation is diverging more and more from the actual traffic.

Performance Engineering is Getting More Difficult

Traditional Performance Engineering is at heart of development activity – inspecting the logic of others, decomposing it, simplifying and then replicating.  Good Performance Engineers also understand key business flows, architectures, risk and the metrics produced.   But as the browser logic become more complex the traditional approach is becoming more problematic.

Take a look at the HTML 5 specification - specifically items such as websockets. This will introduce a whole new level of complexity.  Regarding asynchronous communication, the types of messages sent to and from the browser using this method of communication will begin to get increasingly complex (encoded, compressed and event-driven by user actions) as the sophistication of the browser app increases.

The advanced features of SPDY if implemented will also cause a headache… and I think this is just the beginning. HTML clients are going to get more and more sophisticated – they are becoming fully blown Apps.  This ultimately means that the simulated performance behaviour will become harder to mimic and digress increasingly from the actual behaviour of the system.  If the performance engineer wants to effectively mimic this behaviour more accurately (and capture issues) then they will have to replicate the logic implemented in the client. This simply isn’t sustainable as a way forward.  Performance testing in this form is climbing an ever-increasing mountain and eventually it’s going to hit the wall.

So what is the answer?

I’ll attempt to outline a potential solution because it’s never great to highlight a problem without suggesting a possible way out. LoadStorm and HP’s TruClient, while viewed as crude by hardcore performance engineers with years of legacy tool experience (e.g. LoadRunner, Rational), is a sustainable scripting solution for the future. The two major issues are memory footprint & filtering hosts, but I think by using a combination of the two approaches these obstacle’s will be overcome. Having small proxy agents to filter requests (and ping dummy 200’s) in front of a group of client browsers would resolve filtering of host issues and provide more accurate measurements. 

Piping all TCP/IP traffic generated from the cloud directly through the firewall may leverage the benefits of the elastic cloud (Memory and CPU) for testing required inside the firewall. Complex, but solvable, even with the latency issues. The benefits of the LoadStorm approach is that the time to script key business scenarios is extremely quick, the scripting level required is less involved and more accessible to a wider technical audience - and the cost is significantly lower.

Predicting the Future of Performance Testing

Traditional scripting becomes harder and more specialized.  Larger entrenched companies will need to keep hold of their performance engineers as more knowledge becomes locked-up inside them (e.g. Betfair/Expedia).  Some companies with switched on engineers will use the traditional approach and target risk points whilst accepting limitations (e.g. Facebook). 

As the limitations of the traditional approach become more apparent (time to develop, accuracy of simulated behaviour) someone will refine and merge the two very different approaches that currently exist into a workable solution for the lion’s share of the market, which I believe to be companies wishing to leverage < 10k users, with very tight deadlines.

These newer methods will become more prevalent, relevant, easier to leverage and accepted as companies move from internal environments to PaaS/Cloud environments.

Performance Testing isn’t dead – it’s simply going to get more complex...and then change.

Jason Buksh is an independent Performance Testing consultant. He runs and contributes regularly to the popular and independent load and performance testing site perftesting.co.uk.

As we've documented previously on this blog, a majority of perceived Web page load time resides on the front end - i.e., in how a page is rendered to a user. A poorly designed Cascading Style Sheet (CSS) file can have a negative impact on the time it takes a page to display to the user. What's worse, a poor CSS design might load quickly, but inhibit subsequent performance due to expensive redraw behavior. The following article examines a few key issues in CSS performance, and more importantly, how to decide whether it's worth the effort in the first place.

 

Assessing the Web Performance Impact of CSS

A key principle of performance improvement is that any changes should be driven by data. Before tweaking your site's performance, you need data to tell you which functions or features are causing the biggest delays.

For CSS, the one factor that causes the most performance lags are selectors. Selectors are the statements that specify to which elements a given set of CSS styles will apply. Selectors can be simple, addressing an element by its type:

DIV {
font-weight: bold;
}

Or they can be complex, using a combination of tag name, ID, class and child references to style a specific subset of elements:

#menus ul ul li.current-menu-parent > a{
background:#222;color:#fff;text-shadow:0 0 0 #222;
}

CSS2 and CSS2 also support a sizable number of advanced selectors, including universal selectors, attribute selectors, and pseudo-classes.

Longer selectors generally run more slowly. To profile the running times of selectors, developers can use one of the many CSS profilers available on the Web which will run all of the selectors on a page and calculate their individual running times.

For a simple profiler, you can use Andy Edinborough's CSS Stress Test Bookmarklet, which profiles the running time of all CSS selectors included in a page. Many Web browsers are now shipping with style profilers built in. Opera included a Style Profiler with its Dragonfly release last year. Google Chrome has made CSS selector profiling available in its Page Speed browser extension.

 

CSS Tips and Tricks - and When to Use Them

First things first: how many CSS includes are on your page? Most Web pages can give themselves a performance boost by using Minify to combine multiple style sheet files into a single file download. This reduces the number of HTTP requests a client must make to the server in order to download a page's full array of styles.

For selectors, developers can improve performance by following two simple principles laid out by Wouter Bos:

1. Avoid rules with a large list of descendants. The more complicated a rule, the longer it takes to execute.
2. Make rules as specific as possible. A general selector like "DIV" will apply to all DIV elements on the page.

As Steve Souders makes clear, however, such performance improvements shouldn't be made blindly unless profiler data shows that inefficient selectors are slowing down a page. Souders' tests revealed that, in most cases, revising CSS selectors only results in an average 20ms page performance improvement. Is 20ms significant in web performance? Well, I can't make that decision for you. It can be easily argued that such an improvement is too small for any users to notice. I will admit that I subscribe to the theory that every performance optimization, no matter how small, contributes to the overall enhancement of the site's usability. Little speed gains start to add up when you tweak many aspects of the code.

Sometimes, however, CSS optimization will be required. Juriy Zaytsev ("kangax") provides an in-depth example of one such case, complete with profiling data. He provides a few additional rules for optimization, including:

1. Remove extraneous rules
2. Avoid universal selectors
3. Reduce reflows (rules that re-arrange elements in the DOM) in order to reduce the number of repaints

Some of these improvements, taking in combination, can shave up to a second or more off of rendering times. That's a serious improvement in a world where a one-second delay produces a negative impact on customer satisfaction.

 

Conclusion

CSS improvements are not the first place I would engage in performance optimization. The tunes described above should be undertaken as a lower priority unless there are visible and measurable problems with a page's rendering speed - which escalates them in importance.

In terms of overall performance of a web application, focusing on server optimization, caching optimization, and other improvements will usually yield greater benefits. Once all of these improvements are made, developers should use CSS profilers to decide whether their front-end design could benefit from the tips discussed above.

 
 
 
 
 
 

As Web sites grow in complexity, the amount of content they host from third party sources continues to climb. "Third party content" refers to any content hosted by a separate company and integrated into a Web site using server-side HTML injection, IFRAME hosting, or a client-side AJAX include.

This trend has its advantages and disadvantages. On the one hand, hosting third party content enables sites to add functionality that might otherwise take them months or years to build themselves. On the other hand, that additional functionality comes at the cost of performance. The more third party content a site hosts, the greater the risk it runs of sluggish load times, request timeouts, and client-side parsing errors. The graphic above is a simple illustration of the potential performance hit you can experience by adding one simple third party widget to your site. I know because these numbers are from my real measurements based on adding a Quora follow me widget. More below...

Let's examine:

1. The types of third party content typically hosted on a Web site
2. Assess the performance impact of each type of third party content
3. Explore ways sites can manage their third party content for optimal performance

 

Types of Third Party Content

Advertising comprises a large portion of the third party content found on modern Web sites. Web sites both small and large host third party advertisements to pay for hosting costs, fund staff, and turn a profit. Advertising services are provided by a slew of companies; services include Google AdSense, AdBrite, and Chitika, among many others.

Analytics packages are perhaps the next most popular service hosted off-site. These packages provide detailed visitor analysis and site behavior tracking through a simple piece of code embedded in a Web site's pages. The most popular packages on the market today are Google Analytics, Omniture, Optify, and VisiStat.

A growing segment of third party hosting belongs to widgets, small content controls that enhance a site with additional services or functionality. The simplest widgets are the social media buttons that many content-oriented Web sites add to their pages to make it easier for users to share popular content on Facebook, Twitter, Google+, and similar services. Widgets can also embed videos, host article feeds from other Web sites, display photos, and enable article comments.

 

The Impact of Third Party Content on Performance

The impact of hosting third party content on site performance can be summed up in two words: enormous and detrimental.

As a test to see how a widget impacted the performance of the LoadStorm home page, I added a Quora widget to the page that simply allowed people to follow me. No feed or anything highly functional. The results are displayed below. My thanks go out to WebPageTest for their excellent page load analysis and beautiful graphs (the red ovals are mine).

Before adding the widget:

 

After adding the widget:

 

 

Normally, our home page takes a little more than 1 second to reach document complete, but with the widget it took over 4 seconds. Sorry, that doesn't work for me because I'm too performance conscious. The value of the widget was not high enough to live with the trade-off in poor performance.

I understand that not all widgets will have this much of a negative impact. Maybe not, but I haven't tried them all. Perhaps that will make for a good blog post next week.

 

Minimizing the Performance Impact of Third Party Content

Sometimes, companies can realize a performance benefit by changing their business strategies. In the case of ads, for example, a site with even a modest amount of regular traffic can decide to forgo third party ad programs such as AdSense and instead sell space directly to advertisers. Similarly, a company may decide that the performance hit they're taking on a widget is too severe, and it would be worth investing in a homegrown solution.

Some third party content might not be necessary at all; the drag it creates on performance could negate whatever little value it provides to a Web site. A while back, Joshua Bixby at Web Performance Today urged developers to consider the impact each widget has on their site, and to perform a cost-benefit analysis for each component on a Web page.

If eliminating a third party control isn't feasible, a company can instead select its third party content providers using performance as one of its selection criteria. A few Web sites exist that track the performance of third party content providers. For example, Steve Souders has a page listing nine of the most popular third party services and widgets, along with their relative performance impact (Small, Medium, or Big). While these numbers are a bit old, Souders has published detailed reports on his tests (see, for example, his report on Glam Media) that explain his analytical and testing methodologies.

Absent independent numbers, development teams can run their own tests using a performance testing tool. Over at dynaTrace, Klaus Enzenhofer suggests implementing a URL parameter that turns off all third party content on a site so that teams can gauge the total impact third party content is having on their performance. This approach can be expanded to turn off selected third party widgets, so that a team can assess the impact individual widgets have on site responsiveness.

Finally, for critical widgets, developers should consult with the widget providers regarding what options exist to optimize hosting. For example, Facebook hosts a page for developers on how to use the channelUrl attribute and asynchronous loading to increase load times for their social plugins.

 

Conclusion

The ease with which third party content can be added to a Web site sometimes leads site owners to ignore the performance implications of these popular widgets. While it may not be feasible in your situation to eliminate the use of third party content completely, I strong recommend that you actively manage your off-site widgets through judicious selection and regular performance monitoring.

To put it plainly and frankly:

Before you decide whether to use any particular third party content, try it and find out for yourself - measure the decrease in your site's performance. Is it worth it?

According to industry experts at the Velocity conference, the most popular third party controls on the Web are responsible for between 8 and 15 percent of a page's total load time. Now consider the data that correlates that increase in page load time to the money you make from your site.

Performance testing statistics compiled on performance-testing.org show that even a single second slowdown in page load times can have a negative affect on site revenue. Other stats:

• Better performing website (speed improvements) increased revenue by 7-12%, increased page views by 25%, and reduced hardware by 50%. - Shopzilla actual stats from a site redesign.
• Google found that an extra 500ms in latency cost them 20% of their search traffic.
• Amazon states that for every 100ms of latency, they lose 1% of their sales.
• 50% of surveyed companies said they lost revenue opportunities because of poorly performing applications. - Aberdeen

Performance = Money

 

 

 

 

 

 

Every time you make a change to your website, its speed is affected. Every new plug in, every new picture, change to server settings, or additional fun feature will affect your website speed. Although there are conscious tweaks you can make to a website to speed it up, most often the changes that happen are unintended consequences that can slow down your site. Sometimes the difference is negligible, like a fraction of a second. Other times, the difference can be multiple seconds.

But what is website speed really? What does it mean for your website and your business? This post will take a deeper look at what it means to you and your site’s success.

Consider these statistics:

• 47% web users expect a website to load in less than two seconds.

• 40% of web users will leave a website that takes three seconds or more to load.

• 14% of web users will look for an alternative e-commerce websites if the one they are on loads slow

• 88% of website users are likely to never return to a website where they felt they had a bad user experience.

So what do these statistics mean to you? Well, it means a 7% reduction in conversions for each second delay. It also means that if you’re an e-commerce site that makes $100,000 per day, that a one second delay could cost you upwards of $2.5 million in sales per year. When you look at it in terms like that, you start to understand why site speed is so important.

Many people believe that your website speed only impacts the time it takes your page to load, and that is party true. However, site speed also affects the time it takes to move between pages, the amount of time it freezes, and how many times the user sees an error message when some part of the website doesn’t load fast enough.

Google and other internet properties are getting in on the site-speed game. In 2010, Google implemented a change in their algorithm and introduced a site-speed signal. At the time the change only affected 1% of search queries; however, Google has made a point to encourage webmasters to start looking seriously at their site speed. This is undoubtedly a trend that is not going away.

Though Google gives preference to both the relevance of the page as well as its page ranking, if two sites are identical in every other way, Google is likely to pick the one with the fastest speed.

Even with Google out of the picture, the fact is users often base their experience of your site on its load time and usability. Sacrifice these and you are sacrificing your websites effectiveness.

We live in a fast-paced world, and even though 10 seconds seems like a very small amount of time, there are few people willing to wait that long for a website to load. Also, a slow load time will eventually affect your Google qualities score because Google also looks at your bounce rate (how long the person stays on your website). If a visitor to your website gets sick of waiting for it to load and leaves, then your bounce rate goes up, which means your Google score goes down. This can directly affect your bottom line.

Site speed is largely overlooked in the world of online business, but it is one of the most important ways to dominate your market and crush your competition. If you don’t know how fast your site is, it’s time you found out.

If you are website owner or web admin, here are a few free tools that you can use to calculate your website speed:

• Page Speed, Page Speed is a Firefox add-on that displays the performance of web pages and provides suggestions for improvement.

• YSlow is a tools from yahoo that makes recommendations on ways to improve your websites speed.

• Pingdom is tool set with a web based load time tester. Enter in your website URL to get a visual report of bottlenecks on your website.

• Google Webmaster Tools show website performance by displaying the speed of your site as it is experienced by visitors in different geographic regions.

These tools will help you assess the speed of your pages with a single user requesting them, but you also need to test your site for when many users are visiting. Load testing is critical to your business because speed is most important when your number of buyers is highest.

Written by Adam Chronister founder of Accelerated Freelance. Accelerated freelance is a Spokane Internet marketing firm who specialize in website design, Internet marketing, social media marketing and competitor analysis services and more.

As we've noted in previous articles, Web site developers and system administrators are paying greater attention to mobile performance these days. Wading into these waters requires a new approach to Web performance measurement, as well as new tools to support it. In this article we will review the difference between mobile testing and desktop testing, the tools (both free and commercial) currently available for measuring mobile performance, and, finally, some tips and tricks for developing Web sites that exhibit high performance on mobile operating systems such as iOS, Android, Windows Phone, and Blackberry.

 

Client-Side vs. Server-Side Performance

The first factor in improving mobile performance is figuring out exactly how much improvement your site needs. This requires an accurate measurement of the current state of performance. But what do you measure, and how? As Web Performance Today recently pointed out, over 90% of performance gains on mobile devices are to be found on the mobile client's front end, and not on the server side. This suggests the need for tools that measure mobile performance on the device side.

 

Measuring Mobile Performance

Given the importance of client-side performance for mobile sites, how do developers capture client performance data? This isn't an easy task, given the plethora of devices and operating systems (iOS, Windows, and multiple flavors of Android) in today's market.

The pcapperf toolkit goes a long way to meeting the need for a mobile performance measurement tool. Using pcapperf, developers can upload PCAP files captured from a private wireless network and analyze them using the online tool to pinpoint performance issues.

Development teams can also take inline measurements using LoadTimer, an IFRAME-based test harness that can be used from your mobile Web browser of choice. Besides capturing page load measurements, LoadTimer also supports recording and submitting data to creator Steve Souder's live database of crowdsourced mobile performance results.

A third option for measuring mobile performance is Mobitest, an online tool from Blaze.io that runs a given URL through a variety of mobile operating system devices. This sophisticated but simple tool gathers performance information for iOS 5.0, a number of Android versions, and Blackberry OS 6.0. The downside is that Blaze.io has a limited number of devices available for testing, so users may have to wait a few minutes for their results.

 

Improving Mobile Performance

Mobile device users have less power and less bandwidth speed available to them than users on desktops or laptops. The most significant work a team can undertake to increase mobile performance is to offer a streamlined version of its site. Developers have a few options in front of them for accomplishing this, including:

• Using a CSS media attribute of "handheld" to serve a stylesheet specifically tuned for mobile devices.
• Parsing the User-Agent header, which provides detailed information on the Web browser used to access the site. At Tuts+, Connor Zwick gives a detailed example of how to perform mobile browser detection using PHP.

Developers who use some form of mobile browser detection can greatly optimize performance by using HTML, CSS and JavaScript code that is fine-tuned for mobile platforms. In particular, development teams should take care to leave out any code that simply is not relevant to the mobile experience (e.g., background images, most event handlers). David B. Calhoun published a great series of posts that cover many of the coding tricks required to make a site function properly and perform smoothly on mobile devices.

Next, to reduce reload latency times, developers should serve up their mobile site directly, rather than redirecting to a new URL that hosts a mobile version of the site (e.g., redirecting from foo.com to mobile.foo.com.

Developers should take care to reduce the amount of data flowing over the network from server to client. This includes:

• reducing both the number and size of images included in any given Web page
• reducing the number of HTTP requests required to load a page
• reducing the size or number of external dependencies (JavaScript and CSS files in particular) that a page loads
• replacing separate images with CSS sprites, CSS gradients, and inline images

This is where performance data can help guide development. If the data shows an inordinate amount of data flowing to the client, or a large number of requests being issued to load a single page, developers should target these areas for performance improvement.

Finally, all of the tips and tricks that we have covered in previous articles for reducing data delivery over the network apply to mobile devices: use GZIP compression, use caching and Content Delivery Networks (CDNs) judiciously, and Minify all JavaScript and CSS files.

Conclusion

Mobile Web performance is a huge topic, and the knowledge base behind it is growing rapidly as the popularity of mobile computing continues to climb. For more information on mobile performance, readers should check out some of the wonderful presentations that have been given by experts in this arena, including Maximiliano Firtman and Steve Souders. And stay tuned to this blog - we'll have more articles on mobile Web performance in the near future!

Ok, now I just want to get silly for a couple of moments. I know you come to the LoadStorm blog to read insightful, unique articles about load testing and web performance. I get it. You are a geek like me. There is a 93.6% probability that you are a Star Trek fan too. Yep, I've got Worf as my ringtone.

Please indulge me with a little diversion from our normal deeply technical tips & tricks to bring you a funny picture. To set the stage for why this appeals to me, I was born and raised in Lexington, Kentucky. That makes me a University of Kentucky Wildcat basketball fan by heritage. It's in my blood. I cannot help being a fanatic any more than Yoda could take credit for his big pointy ears. It is a given in this universe.

This special Google search image is a tribute to this year's college basketball player of the year: Anthony Davis. He is a Wildcat. His performance on the court is extraordinary. He is already the consensus #1 pick in the next NBA draft.

If he was a web application, he would have sub-second average response time with over 1 million concurrent users. If he was a Constitution-class Federation starship, he would have a top speed of warp 23. If he was on the cast of Big Bang Theory, he would be Sheldon's more intelligent younger brother who leaves in multiple parallel universes simultaneously. If he was an Android app, iPhone would shutdown manufacturing immediately and leave thousands of children around the world unemployed. If he was a survivor on Battlestar Galactica, the fleet would have found Earth in a week. If he was president of a third-world country, the Justice League of America would move it's headquarters to his country faster than you can say "invisible plane".

Here is a young man with amazing humility and impeccable teamwork, so what do people use as his defining characteristic? His eyebrows. Or more accurately, his eyebrow. Earning a nickname from announcers and bloggers - "The Brow" - which is not used in derision, but with admiration. It has gone so far that kids make signs for ESPN SportCenter saying things like "Florida is gonna get Browdown". It's insane. Funny, but insane. Perhaps I just have a twisted sense of humor. Google jumped on that bandwagon because it was a powerful energy surge in the universe, but they are premature in calling the Cats this year's champions. That won't happen for another 6 weeks!

To Anthony: You are a hero to geeks like me. May you have a long and illustrious career in the NBA, make lots of money, and stay humble. Listen to Jamal Mashburn about what to do with your investments. And....please get a pair of tweezers.

Anthony is to basketball what LoadStorm is to load testing tools.

Ok, now I just want to get silly for a couple of moments. I know you come to the LoadStorm blog to read insightful, unique articles about load testing and web performance. I get it. You are a geek like me. There is a 93.6% probability that you are a Star Trek fan too. Yep, I've got Worf as my ringtone.

Please indulge me with a little diversion from our normal deeply technical tips & tricks to bring you a funny picture. To set the stage for why this appeals to me, I was born and raised in Lexington, Kentucky. That makes me a University of Kentucky Wildcat basketball fan by heritage. It's in my blood. I cannot help being a fanatic any more than Yoda could take credit for his big pointy ears. It is a given in this universe.

This special Google search image is a tribute to this year's college basketball player of the year: Anthony Davis. He is a Wildcat. His performance on the court is extraordinary. He is already the consensus #1 pick in the next NBA draft.

If he was a web application, he would have sub-second response time with over 1 million concurrent users. If he was a Constitution-class Federation starship, he would have a top speed of warp 10.5. If he was on the cast of Big Bang Theory, he would be Sheldon's more intelligent younger brother. If he was an Android app, iPhone would shutdown manufacturing immediately and leave thousands of children around the world unemployed. If he was a survivor on Battlestar Galactica, the fleet would have found Earth in a week. If he was president of a third-world country, the Justice League of America would move it's headquarters to his country faster than you can say "invisible plane".

Here is a young man with amazing humility and impeccable teamwork, so what do people use as his defining characteristic? His eyebrows. Or more accurately, his eyebrow. It has gone so far that kids make signs for ESPN SportCenter saying things like "Florida is gonna get Browdown". It's insane. Funny, but insane.

To Anthony: You are a hero to geeks like me. May you have a long and illustrious career in the NBA, make lots of money, and stay humble. Listen to Jamal Mashburn about what to do with your investments. And....please get a pair of tweezers.

A couple weeks ago, we looked at some of the best Web performance articles written in 2011. There was so much good material out there that we couldn't stop with just a single round-up!

 

Selecting Tools and Designing Tests

Jason at Performance Testing Professional published a couple of great guides last year on the subject of choosing the right testing framework to fit your company's needs. In his first article, Jason discussed some guiding principles for selecting a performance testing vendor. Most companies only adapt a performance testing framework after experience a major issue in production, so Jason gears several of his 11 questions towards investigating this instigating incident. His other questions focus on factors such as how your company plans to integrate performance testing into its existing QA cycle, and how often new system builds are deployed into production. He also lays out seven factors for making a final decision, including initial price, overall maintenance cost, and the platform's scripting capabilities and overall learning curve, among others.

Continuing his analysis in a separate article, Jason reviews the three major types of load testing platforms - freeware, commercial, and cloud-based - and discusses which tools tend to suit which types of projects. He also bemoans that no one has yet pulled together the existing open source tools into a freeware platform that provides a workable alternative to the commercial standards. (As we will see below, though, at least a few people are thinking about how to do this in the mobile performance space.)

Meanwhile, over at the dynaTrace blog, Alois Reitbauer published an epic post about common errors made in measuring server response times. For example, rather than using averages, which do not capture the pain felt by most users, Reitbauer urges developers to follow performance experts and measure percentiles, which capture how many users are experiencing sub par response times. He also counsels against measuring server-side response times, mixing together different transaction types in one's measurements. Performance tests, argues Reitbauer, should be as close to a real world end user's experience as possible.

Elsewhere, the folks at Web Performance tackled an age-old question: how do you know many concurrent users to simulate in your tests? Michael Czeiszperger provides some basic formulas for calculating average hourly loads based on daily traffic. Web Performance also provides a simple online calculator for estimating virtual users.

 

A Pair of Innovative Ideas

Steve Souders is responsible for writing some altogether excellent content in 2011. We mentioned Steve in Part 1 of our round-up, pointing users to his excellent presentation on mobile performance. A few months after giving that talk, Steve created a great application called LoadTimer, a Web-based framework for measuring performance of pages on mobile devices. Initially created to address the lack of good testing options for the Kindle Fire's Silk browser, LoadTimer works on a variety of mobile tablet platforms. To confirm this, Steve used it to compare the Web browsing performance of the Kindle Fire, iPad 2, and the Samsung Galaxy. Souders suggests that, combined with pcapperf and the Mobile Perf bookmarklet, LoadTimer provides a solid foundation for a mobile performance measurement toolkit.

Earlier in the year, Souder announced another innovation: the HTTP Archive, an active repository of performance information gathered from around the Web. Souder's goal in collecting this data is to provide snapshots of current and past trends in Web data delivery. For example, Souder has used his collection to calculate how much data is downloaded for the average Web page, and how much is downloaded for each type of page asset (HTML, images, Javascript, stylesheets, etc.). Souder also produces trending charts that demonstrate how data usage on the Web is increasing over time.

 

Garbage Collection and the Perils of Performance Hacking

When you're testing Java applications, the virtual machine you use can greatly impact performance. Another winning article from dynaTrace last year focused on the different garbage collection behavior in the industry's top three Java Virtual Machine environments: Sun's HotSpot JVM, Oracle JRockit, and the IBM JVM. Each JVM uses different garbage collection algorithms, and author Michael Kopp discusses how each can be tuned for maximum performance.

And finally, a cautionary tale. Sometimes, when we've found a performance problem, it's tempting to resort to a quick hack to fix it. Cliff Click provides an object lesson in the dangers of ad hoc optimization, as he discovers that a 32-bit cast he made 20 years ago now malfunctions when run under 64-bit JVMs.

 

Conclusion

We saw a lot of great content in 2011 pertaining to mobile performance, server performance, and the selection of load testing platforms. We expect in 2012 that mobile performance will continue to be a hot topic, and we also expect to see more content focused on performance testing applications that live in the cloud.

Both webmasters and web designers always need to keep a close eye on website loading times. A slow response time will result in less visitors and less profits. Load testing is done to ensure that a website remains responsive under heavy loads. Most webmasters don't perform load tests, and they discover that their website cannot handle a sudden influx of visitors at the worst possible moment -- when it actually occurs!

Many a website has been "slashdotted". Getting featured on a popular website like Slashdot or going viral on social media like Twitter should be a moment of triumph. But if that traffic increase causes a website to slow down or even temporarily close, then their webmaster will have the heartbreak of watching both extra exposure and profits disappear down the drain.

By load testing a website before it is tested by a torrent of real visitors, such a scenario can be avoided. Load tests enable web developers to simulate the visitors, thereby telling the webmasters what level of traffic begins to reduce the response times of their websites. Therefore, testing facilitates a process of web performance optimization and allows the website to deliver a superior user experience for visitors.

Speed Beats Glamor

In the late 1990s, when Adobe Flash was first emerging as a favorite web technology, it seemed the Internet would soon be full of Flash websites. But this didn't happen. Impressive as those websites might be visually, it was soon found that most web surfers didn't have the patience to sit through Flash websites' extended loading times. Users wouldn't wait, and they are growing more impatient every day.

The need for balance between response time and new website technologies continues to this day. Just as engineers must ensure a bridge won't fall down under the strain of extra cars and lorries, web developers must ensure their websites remain responsive under a flood of visitors.

The fact is that a snappy user experience beats a splendorous one hands-down. For the most part, users want to be able to engage with a website's content, not admire its fancy animations and appearance. They are unwilling to wait for a great website design.

The web performance firm Strangeloop offers several astonishing facts about how a website's loading time effects its visitors' behavior:

• Just three seconds wait was enough for 57% of web surfers to turn away from a website, and 80% of those will never return!
• A one second delay in page-loading time led to 11% fewer page views and a 7% loss in conversions.
• By speeding up their average page load time from 6 seconds to 1.2 seconds, Shopzilla's revenues increased by a whopping 12%!
• A 100 millisecond improvement in responsiveness at Amazon.com increased their revenue by 1%.
• Yahoo! reported that a 400 milliseconds slow down in their pages loading resulted in 9% less traffic.

The reasons why page-loading speeds effect human behavior so much is somewhat surprising. Usability expert Jakob Nielsen suggests it is due to short-term memory decay and the desire to feel in control. If visitors have to wait, their attention goes elsewhere and they have to re-establish what they were doing when the page finally loads, breaking up the user experience. Additionally, being made to wait leads us to attribute arrogance and incompetence to companies that have slow websites.

These facts give you an idea of how important responsiveness is to a website's success, and why load testing is so essential.

How Does Load Testing Work?

In a nutshell, load testing simulates a flood of visitors for a set period of time. Data is collected on a website's responsiveness during the test, so that problems can be diagnosed and fixed. It is impossible to run such a test without a tool for this purpose. There are many load testing tools available today that generate the flood and measure the responsiveness.

The simulated flood of visitors is created by having many servers simultaneously request content from a web server. But these requests aren't simply asking for the front page again and again like a botnet performing a denial-of-service attack. They make requests as instructed by the person running the load test, so that the requests emulate those made by real web surfers.

This allows the load test to be more realistic, as they can even emulate the behavior of different types of visitors. For example, an e-commerce store can test how their site responds to 100,000 people simultaneously browsing its products, or what happens if 10,000 people simultaneously decide to make a purchase.

The web testing tool will provide metrics, charts, and key performance indicators regarding the load tests. With this information, a web developer can discover what are the bottlenecks that prevent the website from being more responsive.

These system bottlenecks can be for all sorts of reasons, such as:

• Poor/expensive SQL queries are coded in the application.
• Server size (CPU, memory) is too small.
• System architecture has not been designed for scalability.
• The website is waiting for embedded media or other resources from a different site.
• The database has too few connections enabled.
• JVM memory management and/or garbage collection is configured improperly

After diagnosing and fixing such problems, another load test can be run to optimize a website's performance further. It is best to only fix one bottleneck between tests. Otherwise, you can't know for sure which fix resulted in speed gains. Load testing is by necessity a process rather than a singular event. Testing leads to optimization (fix) and testing must be conducted again and again after every fix.

Load Testing is More Important than Ever!

Web pages are increasing in size rapidly. Back in 1995, the average page size was only 14.1 kilobytes. In 2010, it had increased to a massive 498 kilobytes. And this rapid growth doesn't appear to be slowing down.

Websites and web applications have become very important to companies. Not only the marketing value of having a brochure available to anyone at any time, but there are billions of dollars transacted through the web. E-commerce is an obvious system for money to exchange hands, however there are thousands of web applications buying/selling/trading every minute without any human intervention.

Social media sites like Facebook, Twitter, and Google+ are web applications that see hundreds of millions of visitors per day. While we don't know exactly how much revenue they are generating from this traffic, it has unquestionably spawned enormous value on Wall Street. Load testing and web performance optimization has been a very public initiative for all social media sites – especially for the much-maligned “fail whale” of Twitter. Hardly a day goes by when some online media writer doesn't mention the responsiveness of social media sites.

Web traffic growth, record money spent online, and hundreds of millions of daily visitors make optimizing page loading times more important than ever before. Load testing is an important part of this optimization and can no longer be overlooked.

Hoping for the best is no longer a viable strategy.

While we've touched upon client side caching in our series on Web performance, we haven't discussed how client caching has grown more rich and useful over the years. In the initial days of the Web and the HTTP/1.0 protocol, caching was mostly limited to a handful of headers, including Expires, If-Modified-Since, and Pragma: no-cache. Since then, client caching has evolved to embrace greater granularity. Some new technologies even permit the deployment of offline-aware, browser-based applications.

Browser Request Caching

The most common and oldest type of client-side caching on the client is browser request caching. Built into the HTTP protocol standard, browser request caching allows the server to control how often the browser requests new copies of files from the server. We discussed the major aspects of browser request caching in part 1 of our series. Over time, Webmasters have taken to using different headers to improve caching on their site, including:

Pragma: no-cache. This old directive is used mostly by HTTP/1.0 servers, and instructs a client that a specific response's contents should never be cached. It is used for highly dynamic content that is apt to change from request to request.

Expires. Supported since HTTP/1.0, this header specifies an explicit expiration date for cached content. It can be superseded by the value of the Cache-Control header. For example, if Cache-Control: no-cache is sent in a response, this will take precedence over any value of the Expires header.

If-Modified-Since: Since the HTTP/1.0 protocol, clients have been able to use this header to request that the server only send data if the resource has been changed since the specified date. If there have been no changed, the server returns an HTTP 304 Not Modified response.

Last-Modified. This HTTP/1.0 and 1.1 header designates when the resource was most recently changed. Browsers usually supply this value as the value of the If-Modified-Since header.

Cache-Control. This core directive, introduced in the HTTP/1.1 standard, specifies whether a response's contents can be cached, and if so, for how long. The header "Cache-Control: no-cache" obsoletes the "Pragma: no-cache" header of the HTTP/1.0 protocol.

ETag. The ETag ("entity tag") header is a hash value that is specific to a given version of a resource. It can be used by the client in conjunction with the If-Match, If-None-Match, and If-Range headers to decide whether it should generate a new request for the latest version of a resource. The format of entity tags themselves is defined in section 3.11 of RFC2616.

Note that this header and the Last-Modified header are exclusive; servers should set one or the other. The ETag header is new with the HTTP/1.1 protocol standard.

For modern applications, the good folks at Google recommend setting one of either Cache-Control or Expires, and one of either Last-Modified or ETag.

 

Javascript/AJAX Caching

With the advent of JavaScript and AJAX, more Web applications are downloading data dynamically. JavaScript developers can use the XmlHttpRequest object to fetch data in XML (or other) format, and display it in real time without forcing a refresh of the entire page. This presents opportunities for finer-grained caching based on the nature of the data displayed within the page.

AJAX applications can still use all of the browser request caching mechanisms discussed above. The resource requested by the XmlHttpRequest object will be stored in the browser's file cache just as other HTTP objects are. A given AJAX application can go further and make refresh calls to the XmlHttpRequest object using programmatic rules. In his article "An AJAX Caching Strategy", Bruce Perry shows how he uses a custom CacheDecider object that he wrote in JavaScript to determine when to update an AJAX display of oil, gasoline, and propane prices.

 

HTML5 Caching

Developers creating HTML5 applications can create fully offline-aware applications using the HTML5 ApplicationCache interface. The Application Cache uses a cache manifest file to specify which files in an HTML5 application can be used offline, and which files require a network connection. The manifest may also specify a list of fallback files for network resources when the user is offline. For example, instead of fetching the file /get-data.php when disconnected, the manifest can instruct the browser to display the file /offline.html instead. This manifest is referenced in the HTML element of an HTML5 app:

<html manifest="manifest.appcache">
...
</html>

 

Conclusion

Web performance optimization is very important, and today's Web application development team can boost site performance and improve its site's load testing scores by selecting from a variety of client side caching techniques. An effective client side caching strategy can reduce load times by several factors. The most recent innovations in client side caching, such as the HTML5 Application Cache, enable an application to run (though perhaps in a more limited form) even without a network connection present.