using the month view to jump ahead a
few days at a time, exposing how slow
it can be to take a round trip to the
server to serve the same quantity of
data. The round trip involves a noticeable spinner even over Wi-Fi, while
the precached data appears instantly,
even on old devices.
Optimize Images. Particularly for
dynamic images, applying the best
compression available will pay off
handsomely in overall page speed. You
can test image quality on a device to
determine if there is a noticeable difference between 50% JPEG quality and
80% or 90%, and note the significant
reductions in size that can be achieved.
Even dramatic reductions in JPEG quality are often not visible, and the savings
can be as much as 40% of the file size.
Similar advice applies to .PNG and .GIF
files, though these are used less for dynamic content (and therefore they are
served from app cache and are not as
sensitive to size).
Avoid Inefficient CSS Selectors.
Almost every recommendation in
Google’s “Optimize Browser Rendering” section applies perfectly to mobile, particularly the concerns about
needlessly inefficient CSS. There is a
trade-off to consider, however: using
a complex CSS selector can avoid a
Document Object Model (DOM) modification. While complex CSS selectors
are considered inefficient by Google,
they are fast compared with doing the
equivalent work in JavaScript on a mobile device. For other cases where the
CSS selector is not being used to avoid
JavaScript execution, Google’s recommendations apply.
Reduce DNS Lookups. Ideally, a
site would load with 0 DNS lookups,
as each represents a round trip with
the potential to block all other activity. Minimally, however, a DNS lookup
will fetch the manifest file, which is
done in parallel with page load as the
browser brings in resources from the
application cache. So it is fairly safe
to use the name of your host site and
assume it will be in the system’s DNS
cache whenever the device is online.
If you rely on using multiple hosts
to parallelize content loading, you
may need one more hostname lookup. There is no point using more
than two hosts to parallelize content
loading since in the best of cases you
By putting your
deferred script
at the bottom and
uncommenting
it only when needed,
you can very
effectively amortize
the cost of using
Javascript across
the runtime
of your application.
are likely to be limited to four simultaneous connections. A second DNS
lookup is probably preferable to hard-coding the IP address in your application. This would cause all content
to download every time your servers
moved and would make it impossible to make good use of any CDN
(content delivery network) you may
be using to serve data. On balance,
the recommendation here is to stick
with a single hostname for serving all
resources, as the benefit from multiple hostnames to get more parallel
downloads is small relative to the implementation complexity, and actual
speed gains are unlikely to be significant over poor networks.
Minify JavaScript and CSS.
Minification is beneficial for mobile, though
the biggest effect is seen in comparing
uncompressed sizes. If minification
poses a challenge, be sure to compare
the sizes only after applying gzip to get
a realistic sense of the gains. They may
be below 5% and not worth the extra
serving and debugging complexity.
Which Recommendations should
Be used only occasionally?
Some recommendations depend on
the context of the particular project and
should be used only on certain sites.
Use Cookie-Free Domains for Sub-components. Using cookie-free domains applies to mobile, except that all
static content should already be served
by the app cache, so the effect is not as
strong. If you are not using app cache,
then follow this recommendation.
Avoid Empty Image SRC. If you
need to create image tags that contain
a dummy image, then you can use a
data URL to encode a small image in
place of an empty string until you can
replace the image source.
Keep Components Under 25KB.
The 25KB restriction does not apply to
resources in the app cache but does apply to everything else. If older devices
are important to your site, you may still
want to respect this recommendation.
If you are designing primarily for future devices, however, only HTML pages still need to be lightweight: the rest
of your resources will stay cached in
memory until the user restarts the iOS
device or forcibly exits the process; and
on Android, your components will stay
in persistent cache until they expire.