The Mobile Web is a complicated beast, making Mobile Web Performance a tough problem to tackle. Is an iPad on WiFi a part of the Mobile Web? How about a laptop with a 3G stick? This presentation tries to split the Mobile Web into three categories, to make it more manageable: Network, Software & Hardware. For each, it reviews the performance challenges this category entails, and offers possible solutions to those challenges. A recording of this presentation (with audio) is available here: http://vimeo.com/32917131

1. Mobile
Web
Performance
Guy
Podjarny,
CTO
guypo@blaze.io
Twi?er:
@guypod

2. Agenda
• Why
Mobile
Web
Performance?
• The
Different
Aspects
of
Mobile
– Performance
implicaHons
– OpHmizaHon
Techniques
• Summary
• Q&A
2

3. Who
Am
I
#1:
CTO
of
Blaze.io
• Automated
Frontend
OpHmizaHons
from
Shared
insights
from
Blaze
performance
OpHmizaHon
Service
world’s
fastest
sites
>1M
pages
analyzed
research
team
– Dynamically
applies
opHmizaHon
best
pracHces
• Cloud-­‐based
service
– No
soVware
or
hardware
– Integrates
with
CDN
services
• Quick
deployment
– 1
hour
or
less.
– No
code
changes
required
Faster,
more
efficient
site

4. Who
Am
I
#2:
Blaze
Mobitest
• Mobile
Web
Performance
Measurement
– Free
Online
Service:
h?p://blaze.io/mobile/
4

5. Who
Am
I
#3:
Mobile
Perf
Researcher
h?p://blaze.io/blog/
5

6. Terminology
Resource
Doc
Complete,
Waterfall
Chart
(Request/Response)
(a.k.a.
onload,
Start
Render
Load
Time)
6

7. Why
Mobile
Web
Performance
Ma?ers

8. Users
Expect
Fast
Sites
Source:
Akamai
8

9. Users
Abandon
Slow
Sites
Page Abandonment vs. Load Time
Source:
KISS
Metrics
9

10. Fast
Sites
Help
Bo?om
Lines
Shopzilla: 5 sec load time improvement
Source:
Shopzilla
10

11. Mobile
Browsing
is
Gelng
Big
Sources:
HubSpot,
Twi?er,
Reuters
11

12. Mobile
Users
Expect
Equal
Speeds
Source:
Gomez
12

13. And
will
abandon
slow
sites
Source:
Gomez
13

14. Front-­‐End
vs.
Back-­‐End
Performance
• Back-­‐End
Performance
– Time
to
generate
page
– 10%
of
page
load
Hme
• Front-­‐End
Performance
– Network
Time
– Browser
Time
– 90%
of
page
load
Hme
Source:
New
Relic
14

15. What
Is
Mobile?
• Mobile
is
not
just
one
thing…
• Mobile
Network
• Mobile
Hardware
• Mobile
SoVware
15

16. Mobile
Network

17. Mobile
Networks
are
SLLLOOOWWW…
Latency
(Ms)
400
350
300
250
200
150
100
50
0
Broadband
Mobile
Download
(Mbps)
Upload
(Mbps)
10
2.5
8
2
6
1.5
4
1
2
0.5
0
0
Broadband
Mobile
Broadband
Mobile
Source:
PCWorld,
FCC,
Novarum
17

18. SoluHons:
Reduce
Requests
&
Bytes
• Why
Reduce
Requests?
– High
Latency
+
Slow
Upload
=
Big
Req
Overhead
– #
Requests
has
highest
correlaHon
to
load
Hme
• Why
Reduce
Bytes?
– Simple
math
–
less
to
download,
be?er
load
Hme
Correla7on
To
Page
Load
Time
0.35
0.3
0.25
0.2
#
Requests
0.15
#
Bytes
0.1
#
Domains
0.05
0
Nexus
S
XOOM
iPad
iPad2
iPhone
IE8
18

19. OpHmizaHon:
On-­‐Demand
Images
Mobile
Walmart
Apparel
Page
Mobile
Walmart
Apparel
Page
Original
Images-­‐On-­‐Demand
19

20. OpHmizaHon:
On-­‐Demand
Images
• Reduced
Requests:
28
Requests
(33%)
• Reduced
Bytes:
108
KB
(33%)
• Reduced
Fully
Load
Time:
5.9s
(63%)
20

21. OpHmizaHon:
On-­‐Demand
Images
• Site:
h?p://m.nbcsports.com/
• Reduced
Requests:
15
Requests
(35%)
• Reduced
Bytes:
50
KB
(31%)
21

22. Mobile
Networks
are
unreliable
• High
Packet
Loss
– High
noise
environment
– Any
request
may
be
delayed
• Non-­‐Sustainable
Speeds
– Long-­‐lasHng
interrupHons
– Moving
client
• SoluHon:
Eliminate
Single-­‐Points-­‐of-­‐Failure
22

23. SoluHon:
Eliminate
SPOFs
• Common
SPOFs
– Scripts
– CSS
– IFrames
– Fonts
• SoluHon
#1:
Async
JS/CSS
• SoluHon
#2:
Avoid/Delay
IFrames
• SoluHon
#3:
Avoid
Fonts
23

24. Async
JS
–
Eliminate
Script
SPOF
Original
Async
JS
24

25. Latency
vs.
Start
Render:
Async
JS
in
AcHon
Start
Render
Time
per
Latency
(Milliseconds,
10
Top
Mobile
News
Sites)
6,000
5,000
4,000
3,000
2,000
1,000
0
30ms
100ms
200ms
300ms
Original
Site
With
Async
JavaScript
25

26. Non-­‐Persistent
Comm.
Channel
• Mobile
Nets
have
limited
capacity
– Limited
by
spectrum
&
ba?ery
• ConnecHons
are
made
ad-­‐hoc
– Then
dropped
by
device
&
tower
• Impact:
1.5-­‐2
second
delay
– Likely
for
every
single
page…
• SoluHon:
Maintain
a
heartbeat
– Send
a
dummy
request
every
2-­‐3
seconds
– Will
maintain
a
live
cell
tower
connecHon
– Make
sure
you
stop
it
aVer
a
while...
26

27. Non-­‐Persistent
Comm.
Channel
• Mobile
Nets
have
limited
capacity
– Limited
by
spectrum
&
ba?ery
• ConnecHons
are
made
ad-­‐hoc
– Then
dropped
by
device
&
tower
• Impact:
1.5-­‐2
second
delay
– Likely
for
every
single
page…
• SoluHon:
Maintain
a
heartbeat
– Send
a
dummy
request
every
2-­‐3
seconds
– Will
maintain
a
live
cell
tower
connecHon
– Make
sure
you
stop
it
aVer
a
while...
27

28. Mobile
SoVware

29. Mobile
SoVware
Is
Cool!
• Designed
for
the
web
– Browsing
a
key
acHon
from
day
1
• Designed
for
Performance
– Try
to
adapt
to
hardware,
ba?ery
and
network
limitaHons
• Supports
modern
standards
– Namely
HTML5
&
CSS
3.0
• Includes
smart
browsers
– Modern
JS
Engines,
look
ahead
downloads,
DNS
prefetching…
• All
in
all:
A
friend,
not
a
foe
29

30. Mobile
Cache
Sizes
Too
Small
• Mobile
Persistent
Cache
around
0-­‐25
MB
– Memory
cache
a
bit
bigger,
but
short
lasHng
– Compares
to
75-­‐250
MB
on
Desktop
• Cache
cycled
through
several
Hmes
a
day
– Average
page
size
~400
KB
mobile,
~800KB
desktop
– Average
desktop
user
browses
88
pages/day
Cache
Capacity
in
MB
Cache
Capacity
in
Pages
30
70
25
60
50
20
40
15
30
10
20
5
10
0
-­‐
iPhone
4
Nexus
S
Blackberry
iPad
2
XOOM
iPhone
4
Nexus
S
Blackberry
iPad
2
XOOM
More
Info:
h?p://www.blaze.io/mobile/understanding-­‐mobile-­‐cache-­‐sizes/
30

31. Small
Cache
SoluHon:
localStorage
• Use
HTML5
localStorage
for
caching
– Available
on
all
major
mobile
plaworms
– Doesn’t
expire,
survives
power
cycle
– Size
limit
is
usually
~5MB
• Most
useful
for
caching
JavaScript
&
CSS
files
– Using
for
images
will
quickly
consume
the
5MB
• Scriptable
Access
enables
other
opHmizaHons
– h?p://www.blaze.io/technical/browser-­‐cache-­‐2-­‐0-­‐scriptable-­‐cache/
• In
addiHon,
use
far-­‐future
expiry
dates
– Impacts
Android’s
cache
evicHon
policy
31

32. Mobile
SoVware:
Pipelining
• HTTP
Pipelining
is
around
since
HTTP
1.1
– Idea:
sending
mulHple
requests
on
connecHon
before
receiving
response
– Most
useful
in
high
latency
environment
• Big
in
Mobile
– ~65%
of
mobile
clients
– Also
included
in
iOS
5
– Hardly
used
on
Desktop
32

33. Pipelining:
What
Should
You
Know?
With Pipelining
• Risks
– Head-­‐of-­‐Line
Blocking
Slow
Resource
delays
• Slow
resource
delaying
fast
ones
Fast
Resources
– Resources
requested
out
of
order
• Depends
on
heurisHcs
ConnecHon
1
Without Pipelining
– Support
detected
per
server/conn
– Requires
explicit
Keep-­‐Alive
header
• Conflicts
with
Domain
Sharding
h?p://www.blaze.io/mobile/h?p-­‐pipelining-­‐big-­‐in-­‐mobile/
ConnecHon
1
ConnecHon
2
33

34. Pipelining
Network
Capture
(Galaxy
S)
• Samsung
Galaxy
S
– Max
Conn:
12
– Conn
Per
Host:
12
– Max
Piped
Reqs:
6
– Pipelining
Support
Scope:
Per
Conn
– Conn/Pipe
Request
DistribuHon:
Fill
First
• Full
Details:
hMp://www.blaze.io/technical/hMp-­‐
pipelining-­‐request-­‐distribu7on-­‐algorithms/
34

35. Pipelining:
What
to
do?
• Make
sure
your
servers
support
HTTP
pipelining.
– Most
reasonably
new
servers
do
• Use
separate
domains
for
slow
&
fast
resources
– Helps
avoid
a
slow
response
delaying
a
fast
one
• Use
“ConnecHon:
Keep-­‐Alive”
– Good
pracHce
anyway,
but
criHcal
for
pipelining
– Include
an
explicit
keep-­‐alive
header
for
Android
• Use
Domain
Sharding
carefully
(or
not
at
all)
– Serving
resources
from
one
domain
helps
pipelining
– Android
is
limited
to
4
connecHons
total
anyway…
35

36. Mobile
SoVware:
FragmentaHon
• Too
Many
Browsers…
– Top:
Android,
iOS
– Other:
Opera,
Blackberry,
IE
Mobile,
WebOS,
Firefox
• Too
li?le
visibility..
– Especially
on
iOS
and
Blackberry
– True
for
vendor-­‐specific
changes
to
Android
• Too
frequent
changes…
• Too
few
supporHng
tools…
36

37. Android
FragmentaHon
-­‐
ConnecHons
Samsung
Galaxy
S
Samsung
Nexus
S
Motorola
XOOM
-­‐ Max
Conn:
12
-­‐ Max
Conn:
4
-­‐ Max
Conn:
35
-­‐ Max
Conn
Per
Host:
12
-­‐ Max
Conn
Per
Host:
4
-­‐ Max
Conn
Per
Host:
6
-­‐ Max
Piped
Requests:
6
-­‐ Max
Piped
Requests:
3
-­‐ No
Pipelining
Support
37

38. Android
Tablets
Not
IdenHfied
• www.cnet.com
Nexus
S
XOOM
iPad
2
38

39. Frequent
OS
&
Device
Updates
39

40. Mobile
Browser
Usage
–
North
America
40

41. FragmentaHon:
SoluHons
• Focus
on
top
devices
– Android
&
iOS
first
• Blackberry
&
Opera
second
– Test
on
key
Android
devices
&
tablets
• Bolster
Server-­‐Side
DetecHon
with
Client-­‐Side
– If
screen
is
wide,
redirect
to
desktop
version
• Measure!
– Hosted:
h?p://blaze.io/mobile/
– Your
Devices:
h?p://pcapperf.appspot.com/
• Stay
on
top
of
news
41

42. Mobile
Hardware

43. Mobile
Hardware:
Weaker
CPU
• Weaker
CPU
=
Slower
JavaScript
– SHll
10x
slower
than
desktop
• Script
Parsing
is
Slow
– About
1-­‐10ms/KB
Sunspider
Time
by
Device/Version
iPhone
4
(4.2)
10,303
• Not
just
JavaScript
iPhone
4
(4.3)
4,285
– Flash,
CSS,
iPhone
4
(5.0)
3,574
Dynamic
Graphics…
iPhone
4S
(5.0)
2,227
Macbook
Pro
230
-­‐
2,000
4,000
6,000
8,000
10,000
12,000
43

44. Hardware
Impact
on
Page
Load
Time
• Alexa
US
Top
100:
Average
Load
Times
– Measured
at
night
over
same
WiFi
+
Cable
iPhone
iPhone
iOS
4
4S
Simulator
Page
Load
Time
4000
CPU
1-­‐Core
2-­‐Core
2-­‐Core
3500
~800Mhz
~800Mhz
2.7Ghz
3000
2500
CPU
Cache
32
KB
32
KB
4
MB
2000
1500
1000
RAM
512
MB
512MB
8
GB
500
0
Median
3.4s
2.9s
1.5s
iPhone
4
iPhone
4S
iOS
Simulator
Page
Load
44

45. Mobile
Hardware:
Form
Factor
• Mobile
Devices
are
Small…
– Comes
with
the
territory
• Two
Main
Sizes
– Smartphone
(2.6’’
to
5.5’’)
– Tablet
(7’’
to
10’’)
• Design
Challenge
-­‐
Performance
Opportunity!
– Can
reduce
data
to
match
screen
size
• At
least
for
Smartphones…
– Can
anHcipate
exact
resoluHon
45

46. Responsive
Images:
Resize
To
Screen
128px,
240px,
6.8
KB
2.9
KB
320px,
10.6
KB
480px,
21.3
KB
Site:
lonelyplanet.com
Device:
iPhone
4
Before:
867
KB
AZer:
Full
Res,
50.1
KB
570
KB
46

47. Mobile
Hardware:
Touchscreen
• Touchscreen
common
in
Mobile
• Touch
can
mean
many
things
– Devices
lag
to
decide
Zoom?
Click?
Scroll?
• Impact:
Delayed
Clicks
– Take
300+
ms
to
decide
it’s
a
click
• SoluHon:
Replace
click
with
touch
– May
sHll
have
usability
implicaHons
47

48. Summary

49. What
Is
Mobile?
• Mobile
is
not
just
one
thing…
• Mobile
Network
• Mobile
SoVware
• Mobile
Hardware
49

50. Mobile
Web
Performance
Aspects
CHALLENGES SOLUTIONS
• Mobile
Network
• Mobile
Network
– Slow
– Reduce
Requests,
Bytes
– Unreliable
– Async
All,
Avoid
SPOFs
– Ad-­‐hoc
connecHons
– Maintain
a
Heartbeat
• Mobile
Hardware
• Mobile
Hardware
– Weak
CPU
– Async/Avoid
Scripts
– Small
Screens
– Progressive
Images
– Touchscreen
– Touch
instead
of
Click
• Mobile
SoVware
• Mobile
SoVware
– Small
Cache
– localStorage
– HTTP
Pipelining
– Separate
Slow
Resources
– FragmentaHon
– Focus,
Measure
50

51. QuesHons?
Mobile
Web
Performance
Guy
Podjarny,
CTO
guypo@blaze.io

52. Sources
• h?p://transiHon.fcc.gov/Daily_Releases/Daily_Business/2011/db0802/DOC-­‐308828A1.pdf
• h?p://www.pcworld.com/arHcle/189592/atandt_roars_back_in_pcworlds_second_3g_wireless_performance_test.html
• h?p://blog.kissmetrics.com/loading-­‐Hme/
• h?p://www.slideshare.net/kleinerperkins/kpcb-­‐top-­‐10-­‐mobile-­‐trends-­‐feb-­‐2011
• h?p://www.google.com/events/io/2011/sessions/use-­‐page-­‐speed-­‐to-­‐opHmize-­‐your-­‐web-­‐site-­‐for-­‐mobile.html
• h?p://blog.newrelic.com/wp-­‐content/uploads/infog_061611.png
• h?p://statcounter.com/
• h?p://danzarrella.com/new-­‐data-­‐on-­‐mobile-­‐facebook-­‐posHng.html#
• h?p://www.comscoredatamine.com/2011/02/top-­‐mobile-­‐acHviHes-­‐in-­‐us/
• h?p://blog.twi?er.com/2010/09/evolving-­‐ecosystem.html
• h?p://www.ecousHcs.com/pcmag/arHcles/2392095
• h?p://mobile.h?parchive.org/
• h?p://www.h?parchive.org/
• h?p://blog.newrelic.com/wp-­‐content/uploads/infog_061611.png
• h?p://www.gomez.com/wp-­‐content/downloads/19986_WhatMobileUsersWant_Wp.pdf
• h?p://www.akamai.com/dl/whitepapers/ecommerce_website_perf_wp.pdf
• h?p://www.novarum.com/novarum_blog/2009/02/real-­‐measurements-­‐of-­‐municipal-­‐wireless-­‐technologies-­‐wifi-­‐wimax-­‐
and-­‐cellular.html
• h?p://www.neHndex.com/
• h?p://features.journalism.org/2011/10/25/tablet-­‐revoluHon/
• h?p://www.markeHngtechblog.com/ecommerce/infographic-­‐how-­‐is-­‐mobile-­‐impacHng-­‐retail-­‐commerce/
52

53. Techniques
to
Reduce
Requests
• Merge
Files
– Consolidate
JS/CSS
Files
– Inline
small
JS/CSS
into
HTML
– Inline
small
images
into
CSS
– Avoid
CSS
@imports
• Avoid
Unnecessary
Requests
– Load
Images
On-­‐Demand
– Avoid
redirects
where
possible
• Cache
More
– Cache
as
much
as
possible
– Version
files
for
long-­‐term
cacheability
53

54. Techniques
to
Reduce
Bytes
• Compress
– Use
GZIP
compression
for
Text
Resources
– Use
Lossless
Image
Compression
• Remove
Surplus
Data
– Minify
JavaScript,
CSS
&
HTML
– Remove
unused
content
(CSS,
JS)
– Reduce
quality
to
display
size
• Shrink
Uploads
– Serve
StaHc
Files
from
Cookieless
Domains
54

55. Form
Factor:
OpportuniHes
• Responsive
Images:
Resize
To
Display
Size
– No
point
in
sending
large
image
to
small
screen
– Useful
Tool:
SenchaSrc
(resize
on
the
fly)
– Refinement:
Lazy
load
bigger
image
on
zoom
• Use
@media
to
use
minimal
CSS
– Example:
<link
rel="stylesheet"
type="text/css”
media="screen
and
(max-­‐device-­‐width:
480px)”
href=”smartphone.css"
/>
– Can
include
resized
CSS
images
• Be
careful
with
Progressive
Design
– Watch
for
excessive
JavaScript
or
blocking
render
55

56. Weaker
CPU:
SoluHons
for
JS
• Use
Less
JavaScript…
– Don’t
send
Desktop
JS
to
Mobile
if
not
used
– Pre-­‐Execute
as
much
as
you
can
• Run
Dynamic
code
on
server,
return
staHc
content
– Avoid
heavy
JavaScript
Libraries
• Defer
Scripts
– Run
scripts
that
aren’t
criHcal
only
aVer
onload
– Defer
EvaluaHon
of
Inline
JavaScript
• Download
code
as
comment,
evaluate
on-­‐demand
• Async
Scripts
– As
explained
earlier
56

57. Weaker
CPU:
SoluHons
for
Non-­‐JS
• CSS
– Avoid
CSS
Expressions
– Avoid
inefficient
CSS
Rules
• Example:
html
div
p
a
{color:
red}
• Minimize
reflows
– Specify
image
dimensions
– Avoid
dynamic
content
not
at
bo?om
– Avoid
dynamic
reordering
of
resources
• Avoid
Flash
57