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.