Can your customer rely on your mobile site?

We often talk about speed and optimization, but site reliability is just as important to get your customers to repeatedly visit to your mobile site and build brand loyalty. According to the Keynote Mobility Survey, 48% of smartphone users experienced a problem with loading errors and the inability to open the page.

This can be a frustrating experience for mobile users and a good reason to either not come back or visit your competitors mobile site. 

There are a few standard practices to combat the pitfalls of bad performance, and continuous monitoring & testing is the best way to find out when and where your mobile site is failing. Finding issues before your customers do and fixing them quickly is the key to scoring well in terms of website reliability. 

Who does reliability right?

Keynote keeps running measurements of mobile websites from several industries on our KeynoteMobile Performance Indices. On any given week we can see different companies at the top of the list for reliability. But if you follow the weekly indices long enough you'll see that the companies that rank best tend to be the same, suggesting a greater attention to mobile website availability. For the week ending September 9th, here's who were on top

Learn more about:

1. Why Web Load Testing?

2. How to monitoring site

3. Free website monitoring 

Monitoring the 340 Trillion Trillion Trillion: Keynote and IPv6

The Keynote Systems’ Startup Shootout Index provides some insight into the three-screen challenge now facing anyone with a web presence. It shows a website's weekly average load time and download success rate (availability) on desktops, smartphones, and tablets. Let's take a look at mobile gaming, but the lessons here apply to any web sites optimizing – or not optimizing – for three screens.

The growth of mobile games is inevitable with the growth of mobile devices that enable them including feature phones, smartphones, tablets and even e-Readers. Adverse to many websites, mobile is a main focus for mobile gaming companies like Rovio.

While their desktop load speed leaves something to be desired, Rovio is the fastest social gaming site on the iPad and second fastest on the iPhone (with a speed of seven seconds). Rovio improved their site by redirecting iPad and iPhone users to a lighter, mobile optimized site. 

Papaya Mobile is another mobile gaming site, loading at a blazing 2.58 seconds on the iPhone, leveraging best practices and simply requiring a login screen as the first step to access the site. The login screen loads very quickly because of its simplicity, a great way to get your gamers on the site efficiently with minimal wait.

While most mobile gaming sites focus on their mobile speed and reliability to retain their loyal customers. Crowdsart has managed to integrate the best of mobile and desktop performance and reliability.

Crowdstar has arguably the best overall performance in the July Startup Shootout for mobile games, with a better than average desktop load speeds and 6.97 seconds to load on the smartphone. What is remarkable about the smartphone loading time is that Crowdstar brings the entire site to iPhone users, rather than offering bits of content to speed mobile interaction. If they optimized their site even further for mobile, they have the ability to achieve even faster speeds. The response time for iPad users is better than average and may end up being tolerable when connected over Wi-Fi instead of the 3G network.

Although Rovio and Papaya charge forward for quick mobile speeds to target their main demographics, leveraging best practices and monitoring slight changes in website development can give many developers the ability to optimize a better overall experience over all three screens.


Related Articles:


A Three-Screen Perspective From The World’s Largest Retailer

Magazines on smartphones: convenient but not quick

Internal Testing Program Using Real Devices

Creating an internal test program using real devices is a challenge. The devices have to be bought, carrier contracts have to be established, test scripts created, users trained, results compiled and analyzed — for each geographic market. And then the devices and contracts have to be dealt with after the testing is done, or maintained for ongoing monitoring.

This complexity is why so many enterprises use an outside test partner that offers an established infrastructure with hundreds or thousands of devices deployed over a broad geography. The test provider works with the client company to develop the necessary scripts, and then leases time to them on its network to run the tests. This is testing in the "public cloud," which means that many clients utilize the same devices and infrastructure to conduct their tests. It's an ideal solution for most companies — there's no upfront capital expenditure and tests can be quickly executed on demand, on a budget-friendly pay-per-use basis.

But when a company has particular security concerns and is reluctant to expose its data on a shared infrastructure, or if it has ongoing testing needs, a "private cloud"solution is in order. In this case, the test provider procures devices and contracts to create a private test network exclusively for the use of a particular client company.

In either case, the client team has ready online access to the entire process, from scripting to running the tests to reading results.

Cloud-based app testing is an automated process. There's no human being working the phones out in the field; rather, the devices are remotely operated by machine, performing the interactions specified in the test scripts and providing feedback on the devices' responses.

Read More at http://keynote.com/benchmark/mobile_wireless/article_mobile_app_performance.shtml

Internet Retailers and Website Performance

How many seconds does it take to lose a shopper to a competitor’s site? How long will a business user wait for Javascript to execute so she can see the data she’s searching for? How many times will a user tolerate delays in downloading a bank transaction, or registering a bid, or completing a form, before they abandon the site?

The cost of poor site performance is not just lost visitors, it’s lost money. In a recent survey, nearly three-quarters of Internet retailers correlate poor site performance with lost revenue, and more than half with lost traffic.

Just a few short years ago, evaluating website performance was a fairly simple affair. “How fast did the page load?” was often the first and last question that needed to be asked. User expectations were far lower, and patience much higher, when the experience of accessing information or making a purchase online was new and different and amazingly convenient.

Today, however, user expectations are stratospherically higher. With the Internet now tightly woven into the fabric of everyday life, and a multitude of Web sites available to satisfy any given need or desire, users expect not only virtually instant page-loads, but fast and flawless execution of transactions and enhanced functionality that delivers a “rich” site experience.  In the intense competition to attract and keep site visitors, web performance is now a critical business driver for site success.

Read More at http://www.keynote.com/benchmark/index.shtml

The impact of web load testing on performance

What drives the financial impact of a site outage or performance issues is abandonment. It’s important to understand that visitors experiencing a Website with issues don’t result in lost revenue, per se. Only when those visitors don’t return, and/or go somewhere else is revenue lost. A shopper’s tolerance for errors is called “tenacity” in Web load testing parlance. Low tenacity shoppers bail from slow searches and hanging shopping carts in a dash.

If a load test had been run that adequately modeled the impact of the planned launch, the damage would have been done outside business hours and Target management would have been able to decide whether to make changes to their systems and retest, postpone or restructure the launch or just "risk it" and see what happens.  We don't really think they ever had the chance to make those decisions.  Surely they didn't conduct a load test that predicted such an epic fail.  But should they have?

Realistic Web load tests model site usage and shopper behavior. Systems are deployed to simulate high levels of demand from multiple geographically disperse areas. Once the load is generated, the infrastructure and application’s response are watched carefully to identify bottlenecks and breakage points as the entire mesh of the Website’s interconnecting parts are stressed. Only this level of testing can accurately inform e-commerce teams of their preparation adequacy.

Read More

Challenges And Surprises With Web Load Testing

To gauge a Web site’s capacity and scalability, web load testing is one of the most effective ways. But the load tests need to simulate real scenarios. The huge numbers and ranges of variables involved in Web site load testing will always present challenges and surprises.

A load testing scenario can be made significantly more realistic by simulating the behavior of tolerant and

an intolerant user. Familiarity is a major factor in how quickly a simulated user navigates from one page to the next. As with latency tolerance, different people will behave in different ways: users that are very familiar with the Web site move more rapidly (therefore creating more load per unit of time) than users who are visiting the Web site for the first time and need to read and understand how the Web site is organized to go from one page to the next.

You can also run simple in-house experiments using employees and their friends and family to determine, for example, the page viewing time differences between new and returning users.

Read More on Web Based Testing and Website Monitoring. 

Improving Website Responsiveness Involves Tradeoffs

It is easy for a measurement tool to sit on a server and measure all requests for service—and this kind of measurement has its uses, especially when load testing or investigating bottlenecks. But because of the variety of implementation possibilities, a common problem when measuring RIAs is that related requests may appear to originate from separate units of work on the client.

Correlating seemingly separate measurements with a particular application activity, task, or phase is tricky. The more complex the client/server relationship, especially when it involves concurrent interactions, the harder it becomes for measurement and analysis tools to perform that correlation properly.

Having more design and implementation options also creates new opportunities for developers to make performance-related mistakes. Accidentally or deliberately, developers can implement “chatty” client/server communication styles that perform extremely slowly under some workload conditions. Even with thorough testing, some of these problems may remain undiscovered until after the application is deployed unless applications are subjected to a systematic SLM process that includes measurement
activities to identify, investigate, and fix them.

Read More

Unrealistic Load Testing Leads To Unrealistic Inferences

Website need to be tested under the most realistic conditions. These tests should be done using the arrival rates based on actual web logs and a real user – true to life scenario. This will help determine the revenue potential.

Earlier tests might have been conducted within your environment. But website performance testing would only be effective if conducted where the end users are. Unrealistic load testing leads to unrealistic inferences.  You will need true visibility into your end-user experience ensuring the success of your online business.

A big discrepancy in the page response times from different locations may point to the latency issues related to some backbones or the ten worst performing pages as the load level is increased indicating the pages causing performance bottlenecks.

Web Site Preparedness!

One of the major reasons why some companies don’t want to run a web load test on their production site is that they are not looking forward to performing activities such as the database back-ups and restores that a production site load test requires. We believe that such drills are a positive side-benefit of load testing. We have all heard stories of Web sites crashing under heavy load and taking many hours, or even days, to bring their system back.

Practicing system back-ups and recovery following a major load is an extremely important component of Web site preparedness. A load test on your production site will not only show you how well your system can handle a large load, but how well and how quickly your system and crew can recover from a site crash due to overload. If there are problems with post-crash recovery, the right time to discover and fix them is during a test, not while your site is experiencing real traffic peaks.

Read More

Importance Of Website Load Time

An average Web site takes 2– 3 seconds to load. According to Apdex.org, as the load time increases to 4–6 seconds, users start to get frustrated. The level of frustration and the probability of switching to another web site increases if the load time goes beyond 6 seconds. This is where web load testing comes into play and is a very important part of website monitoring.

Many sites do not directly generate revenue, unlike a retail site or travel site, but instead focus on customer service. Sites like credit card, banking, and insurance sites reduce costs, cross-sell products, and help increase customer loyalty by servicing customers online. Website transaction monitoring plays an important role here and is much needed. A poor experience directly translates into increased calls to the call center and a decrease in overall customer satisfaction.  

In the case of online trading sites, online performance is extremely critical. A delay of seconds carries the risk of huge trading losses, and an equally large litigation and regulatory risk. Not only does a technical issue (poor performance, outages, and errors) impact the direct customer or user, it can also have ripple effects.