not assume that touchend on a button means click unless there was also a touchstart event on the button— not if the user touched somewhere else and dragged to the button before ending the touch. You could use a touchmove event after touchstart to prevent treating the following touchend as a click, assuming the moving gesture was not intended to be a click.

In addition, you may still want to handle the onclick event to ensure the browser changes the appearance of the button to show a clicked state, and to support browsers that do not handle touch events. To avoid duplicate code execution when both touchend and onclick code fire, add a click event handler that calls preventDefault and stopPropagation if the click was the result of a user tap that was already handled by touchend. 4

Ease of implementation: Advanced. This technique requires much more work to add and maintain links on a page. The code testing for touch events must be resilient against gestures that may be happening instead of a click, such as a zoom or swipe.

Support the SPDY Protocol. Some of the performance bottlenecks that afflict websites, whether desktop or mobile, result from inefficiencies in the application-layer HTTP and HTTPS protocols. In 2009, Google began work on an alternative protocol named SPDY (pronounced “speedy”) that addresses some of these limitations. The goal is to make this an open source project that will be implemented by multiple browsers and Web servers, but initially it was supported only in Google’s Chrome browser (in version 10 or later) and on Google sites. As Web servers are released that implement SPDY, sites will be able to use this protocol for any user with a browser that supports it. In a test implementing SPDY on a representative group of 25 of the top 100 Internet sites, Google observed speed improvements from 27% to 60%. 2

SPDY automatically uses gzip com-
pression on all content, and unlike
HTTP, it also uses gzip on header data.
SPDY employs multiplexing technol-
ogy to enable multiple streams of re-
quests of responses to be sent over a
single TCP connection. In addition,
SPDY allows requests to be prioritized,
so, for example, a video that is cen-
tral to a page’s content can be given a
higher priority than an advertisement
in the margin.

Do not forget to test!

No discussion of performance optimization would be complete without a reminder that continuous and careful testing is essential. Every change to your system is just a theory until it is tested against a baseline. Guessing where performance bottlenecks occur is meaningless unless based on real test data.

Great open source and commercial tools are available to provide synthetic tests, complete with geographical distribution and bandwidth/latency throttling. In addition, real-user monitoring (RUM) tools take testing out of the lab and into the field of unpredictable user behavior.

Look for testing options that sup-
port mobile, as well as desktop sce-
narios. If you choose an automated
solution, be sure to choose one that
continually tests and refines the opti-
mizations it applies.

Related articles on queue.acm.org

Mobile Application Development: Web vs. native

Andre Charland and Brian LeRoux

http://queue.acm.org/detail.cfm?id=1968203

The Evolution of Web Development for Mobile Devices

Nicholas C. Zakas

http://queue.acm.org/detail.cfm?id=2441756

Making the Mobile Web Faster

Kate Matsudaira

http://queue.acm.org/detail.cfm?id=2434256

References

1. bustos, l. every second counts; how web-site performance impacts shopper behavior. GetElastic (2009); http://www.getelastic.com/performance/.

2. chromium Projects. SPDy: an experimental protocol for a faster Web; https://sites.google.com/a/chromium. org/dev/spdy/spdy-whitepaper.

3. everts, t. case study: how effective are cDns for mobile visitors. Web Performance Today; http://www. Webperformancetoday.com/2013/05/09/case-study- cdn-content-delivery-network-mobile-3g/.

4. fioravanti, r. creating fast buttons for mobile Web applications. google Developers (2011); http://code. google.com/mobile/articles/fast_buttons.html.

5. linden, g. marissa mayer at Web 2.0. geeking with greg (2006); http://glinden.blogspot.com/2006/11/ marissa-mayer-at-Web-20.html.

6. mod-spdy; http://code.google.com/p/mod-spdy/.

7. Phocus Wright. Phocus Wright/akamai study on travel site performance; http://connect.phocuswright. com/2010/06/phocuswrightakamai-study-on-travel- site-performance/; http://www.akamai.com/dl/ whitepapers/akamai_PcW_travel_Perf_Whitepaper. pdf.

8. radware. case studies from the mobile frontier: the relationship between faster mobile sites and business kPIS (2011); http://www.strangeloopnetworks.com/ resources/research/state-of-mobile-ecommerce-performance/.

9. radware. 2012 state of mobile e-commerce performance; http://www.strangeloopnetworks.com/ resources/videos/case-studies-from-the-mobile-frontier-the-relationship-between-faster-mobile-sites-and-business-kpis-video/.

10. tealeaf. report on the mobile customer experience. based on the harris Interactive 2011 mobile transactions Survey; http://www.tealeaf.com/ customer-experience-management/resource-center/ rgister.php?doc=mobile-cem.

11. W3c. network Information aPI (2012); http://www. w3.org/tr/netinfo-api/.

12. yuI. Imageloader. yahoo! user Interface library; http://yuilibrary.com/yui/docs/imageloader/.

 

Tammy Everts has worked in user experience and Web performance since 1997. She currently works at radware, evangelizing performance both in-house and out in the world. Previously, she held roles as research director at Strangeloop networks and director of user experience at habanero consulting. She blogs about performance issues, research, and trends at http:// webperformancetoday.com.