to be flushed quickly. The HTML5 Web
storage specification provides a great
alternative to relying only on browser
caching. The HTML5 localStorage
browsers. Script code can easily check
for support of HTML5 localStorage and then use it, if available, to save
and read key/value data, usually 5MB
per domain. This capability makes
localStorage very well suited for
client-side caching, although read/
write speeds do vary for different mobile browsers. It is usually significantly
faster to retrieve a resource from localStorage than to request it from a
server, and it is more flexible and reliable than relying only on cache headers
and the limited browser cache storage
available on most mobile devices. In
addition, this is one area where mobile
browsers are currently ahead of the
desktop in efficiency—
localStorage performance has lagged in desktop implementations where using the
standard browser cache may still be
the best option.
Ease of implementation: Advanced.
While the localStorage mechanism
may be simple to use, building a cache
around it does create some complexi-ties. You will need to take into account
all of the issues that a cache handles
for you, such as cache expiry (when
do you remove items?), cache misses
(what if you expected something to be
in localStorage and it is not?), and
what to do when the cache is full.
Embed Resources in HTML for
First-time Use. The standard pattern in
HTML is to include links to external resources. This makes it easier to maintain these resources as files on the server (or in a CDN) and to update them at
the source rather than in each of many
pages. This pattern also supports
browser caching by allowing cached
resources to be fetched automatically
from the cache rather than from the
server, as previously discussed.
For resources that are not already
cached in the browser or in localStorage, however, this pattern
of linking to external resources has
a negative impact on performance.
A typical page can require dozens of
separate requests in order to gather the
resources needed to render the page.
So, from a performance standpoint, if
figure 1. median load times for desktop and mobile devices.
a resource does not have a high likelihood of already being cached, it is often best to embed that resource in the
page’s HTML (called inlining) rather
than storing it externally and linking to
it. Script and style tags are supported in
HTML for inlining those resources, but
images and other binary resources can
also be inlined by using data URIs that
contain base64-encoded text versions
of the resources.
The disadvantage of inlining is that
page size can become very large, so it is
crucial for a Web application that uses
this strategy to be able to track when
the resource is needed and when it is already cached on the client. In addition,
the application must generate code to
store the resource on the client after
sending it inline the first time. For this
reason, using HTML5 localStorage
on mobile devices is a great companion to inlining.
Ease of implementation: Moderate.
This technique requires the site to have
a mechanism to generate a different
version of the page based on whether or
not the user has visited that page before.
Use HTML5 Server-Sent Events.
Web applications have used various
polling techniques to update pages
continually by requesting new data
from a server. The HTML5 EventSource
object and Server-Sent events enable
a much more efficient unidirectional
channel from the server to the browser.
The server can then use this channel
to send data as it becomes available,
eliminating the HTTP overhead of creating multiple polling requests. This is
also more efficient than HTML5 Web-Sockets, which is a richer protocol for
creating a two-way channel over a full-duplex connection when a lot of client-server interaction is called for, such as
in messaging or gaming.
Ease of implementation: Advanced.
This technique is very implementation
specific. If your site is currently using
other AJAX or Comet techniques for
Eliminate Redirects. When users attempt to navigate to a standard