Velocity 2012: The 90-Minute Mobile Optimization Life Cycle

The 90-Minute Mobile Optimization Life Cycle

Velocity 2012

Hooman Beheshti
VP Technology, Strangeloop
hooman@strangeloopnetworks.com

Agenda

•  Why is faster better?
•  Measuring performance
–  Tools
–  Challenges
•  Stepwise acceleration
–  Pick a real site, and apply step by step performance
optimizations
•  Lessons from the field

© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 2

Mobile Performance Optimization
Why Should We Care?

Growth of Smartphone Sales
(as % of total mobile phone sales)


Traffic from Mobile Devices (2011)


Mobile Sales


Case Study


Customer Profile

•  Top 200 Internet retailer, US based
•  Target geography: US and Europe
•  $3B in revenue
•  30,000 employees


Page Views by Mobile Device


Experiment

•  Induce delay on HTML
–  200msec, 500msec, 1000msec

•  Apply to small percentage of traffic

•  12 weeks

•  Monitor impact on key business metrics


Results


Impact on Bounce Rate


Impact on Returning Visitors


More Details

•  http://www.webperformancetoday.com/
2011/11/23/case-study-slow-page-load-mobile-
business-metrics/

•  http://velocityconf.com/velocityeu/public/
schedule/detail/21632


Performance Measurement
Measuring Page Speed on Mobile Devices

Measurement

•  Mobile measurement is still a challenge
•  There are some tools out there
–  Still pretty manual
–  Less about performance and more about functionality
–  Lots of simulation
•  More complicated because of the number of
different platforms and devices that we may
need to cover
•  Things are getting better


Chrome Remote Debugging (ICS)

•  A USB connection lets us see activity of mobile
chrome on desktop chrome
•  https://developers.google.com/chrome/mobile/
docs/debugging


iWebInspector

•  Web Inspector, but for iOS Simulator
•  http://www.iwebinspector.com/


Weinre (Web Inspector Remote)

•  Remote debugging from the desktop for what
the phone is doing
•  http://people.apache.org/~pmuellr/weinre/docs/
latest/Home.html


Aardwolf

•  Remote JavaScript debugging (all platforms)
•  http://lexandera.com/aardwolf/


Mobile Perf Bookmarklet

•  More focus on performance

•  http://stevesouders.com/
mobileperf/mobileperfbkm.php

•  Super bookmarklet with lots of
tools built in


PCAP2HAR

•  Turn packet captures to waterfalls
•  http://pcapperf.appspot.com/


Real User Monitoring (RUM)

•  RUM tools are increasing in availability
–  Google Analytics
–  New companies and solutions emerging

•  Measurement on actual devices, for real users

•  Need lots of data to draw conclusions
–  And must have a way to deal with outliers

•  Navigation Timing (only in Chrome for Android
right now)


Webpagetest


Webpagetest’s Mobile Agent

•  Based on the recently open-sourced mobitest
agent
•  Interacts with the server just like a standard
desktop agent
•  Available for Android and iOS
–  Still in the early stages, but key metrics are reported
–  Some features (like scripting) don’t work
–  Cold cache tests and videos are working fine
–  For iOS, it uses UIWebView rather than Safari
•  Even with the limitations, still the best tool for
getting a feel for mobile performance


Visualizing Performance



0 6 12


DNS TTFB

TCP Download
Connection

0 6 12


0 6 12

Back End: The time from when the
request is made by the browser to
last byte of the HTML response

0 6 12


Front End: Everything after the
HTML arrives

0 6 12


Front End: Everything after the
HTML arrives

Important Timers:

Start Render

onLoad (Document Complete)
0 6 12

Stepwise Acceleration
Accelerating a Real Site

Methodology


Setup

•  All testing done on 3G from Vancouver
–  Nexus S with WPT agent
–  Rogers Network

•  Traffic flows through Strangeloop
service
–  We apply optimizations in the path
–  Used host file entries since DNS overwrite
isn’t available on the agent

•  The phone does everything else


Setup
3G Connection

Origin
Origin
Data Center


Cooking Show Methodology

*No tiger blood was used during any of these tests!


Let’s Pick a Site!


A Few Points of Clarification

•  We’re only choosing oreilly.com for fun
•  We’re using it only to show what some
performance problems are – this doesn’t mean
the site has these problems
•  The real site is somewhere in the middle of this
blue bar


Waterfall and Key Performance Metrics


Per Object Breakdown (partial)


Content Breakdown


Problem Analysis


Performance Problems

•  Too many connections


Too Many Connections

83 Connections


Connection Cost is High



•  Too many bytes


Too Many Bytes



•  No CDN


Too Long to First Byte


Time to First Byte

•  Every request is subjected to one round trip

•  Concurrency of requests helps, as does
pipelining – but it’s still a problem
–  More on pipelining later

•  A bigger problem when there are more objects



•  No CDN
•  Too many round trips


Too Many Round Trips


Too Many Round Trips

•  Every request is still paying a penalty
–  TTFB continues to be a problem

•  The higher the latency, the bigger the problem

•  Better concurrency on modern mobile browsers
is helping, but not enough. This is still a huge
problem



•  No CDN
•  Poor caching (more on this later)



•  No CDN
•  3rd party calls (marketing tags, analytics, etc)


3rd party


3rd party

Before Start Render



•  No CDN
•  3rd party calls (marketing tags, analytics, etc)

è Similar to desktop, but impact is different on
mobile devices


What Does it Look Like?

http://www.youtube.com/watch?v=jo4zxzv3USg


Summary of Key Metrics


Key Metrics – Original Site
Round trips to onload Bytes to onload (KB)
100 1000
90 900
80 800
70 700
60 600
50 500
40 400
30 300
20 200
10 100
0 0

Start Render (sec) Doc Complete (sec)
9 25

8
20
7
6
15
5
4 10
3
2 5
1
0 0

Let’s Fix It!


What Are We Going To Do?

•  Stepwise acceleration
–  We’ll accelerate the page in multiple steps
–  We’ll add techniques at each step and evaluate the
performance impact

•  We’ll start with the easy stuff and get more
advanced with each step

•  Try to make the page as fast as possible


Step1: Low Hanging Fruit


Step 1: Optimizations

•  Add keep-alive connections
–  Address the problem with too many connections
–  Lessen the impact of TCP connection setup

•  Add HTTP compression
–  One way to reduce bytes, and an easy one
–  We’ll compress text-based content (HTML, CSS, JS,
etc)


Keep-alive Connections

83 Connections


HTTP Compression


Step 1: What Should We Expect

•  Fewer total connections
•  Fewer bytes
•  Impact to performance metrics
–  Fewer bytes to onload
–  No change to roundtrips
–  Better document complete time
–  Better start render


Before and After

20.52 sec 15.29 sec


What We Helped

•  Connection Count
–  83 connection à 30 connection

•  Key metrics


Step 1: Improvements
100 1000
90 900
80 800
70 700
60 600
50 500
40 400
30 300
20 200
10 100
0 0

9 25

8
20
7
6
15
5
4 10
3
2 5
1
0 0

100 1000
90 900 945
80 800
70
218
700
60 600
50 500 23 % 727
40 400
30 300
20 200
10 100
0 0

9 25

8 7.738 20.52
20
7
0.679 5.231
6
15
5
4 ~9% 7.059 10 25 % 15.289
3
2 5
1
0 0


http://www.youtube.com/watch?v=qMGAOqQQqvw


Pros and Cons

•  Pros
–  Really easy to do
–  Usually a single configuration option on servers,
proxies, or load balancers
–  Great bang for the buck

•  Cons
–  It’s still slow!
–  These are, by themselves, just not enough


Step 2: CDN


CDN

Edge Cache
Edge Cache

Origin
Origin
Edge Cache Data Center

Edge Cache


CDN

•  Static resources are served from locations near
the requesting client (mobile or otherwise)
•  Shorter distance between client and content
means smaller TTFB


What Should We Expect

•  Faster average time to first byte for the objects
on the page
–  No change to round trips
–  No change to byte count
–  Better start render time


Before and After

15.29 sec 13.7 sec


Impact on TTFB

-39.8 %

Avg = 655 ms Avg = 394 ms


What We Helped


100 1000
90 900
80 800
70 700
60 600
50 500
40 400
30 300
20 200
10 100
0 0

9 25

8
20
7
6
15
5
4 10
3
2 5
1
0 0

100 1000
90 900
80 800
70 700
60 600
50 500
40 400
30 300
20 200
10 100
0 0

9 25

8 7.059 15.289
20
7
0.814 1.552
6
15
5
4
12% 6.245 10 10 % 13.737
3
2 5
1
0 0


http://www.youtube.com/watch?v=aiViEjuVb_g


Pros and Cons

•  Pros
–  CDNs are always good ways to reduce TTFB
–  Physics!
–  Well-established industry; lots and lots of vendors

•  Cons
–  Can sometimes be costly
–  Why wasn’t it faster?


CDNs for Mobile

•  We got faster, but we expected more of an
improvement
–  Before: we forced requests to go from west
coast to east coast
–  After: let the CDNs naturally select closest edge

•  Wondering out loud…
–  Is edge selection for mobile devices not as
effective?
–  3G more of a mystery than WiFi


CDN Edge Selection - Desktop

Edge Cache
Edge Cache
DNS
Resolver

CDN DNS Brains

Origin
Origin

Edge Cache


CDN Edge Selection – Mobile Network

DNS Edge Cache
Resolver Edge Cache

? CDN DNS Brains

Origin
Origin

Edge Cache
DNS
Resolver


CDN Edge Selection – Mobile Networks

•  I have no idea how the inside of the cell
networks work!

•  Test:
–  From the phone (on 3G) ping 2 CDN names
–  From the phone, ping the IP address the CDN
resolved for my desktop



CDN 1

CDN 2


Both pings from phone
CDN 1

Ping cdn.domain.com

Both pings from phone
CDN 2

Ping IP that CDN picked for
desktop

HERESY!!


Important Questions To Ask

•  Not making outrageous claims like “CDNs aren’t
effective for mobile devices”!!

•  CDNs almost surely deploy servers near cell
network exit points. But, what if most of the
latency is inside the cell network?

•  Does the meaning for “closeness” change for
mobile?

•  More research is necessary…


Step 3: Mobile Front End Optimization


Mobile FEO

•  Consolidation of resources
–  Images
–  CSS
–  JavaScript
•  Image Compression
•  Minification
–  JavaScript
–  CSS
•  Optimal use of localStorage (more on this later)


Mobile FEO



•  Fewer round trips will mean the TTFB problem
should get a lot better
•  Fewer bytes will mean better performance
–  Images (from image compression)
–  CSS/JS (from minification)
–  Reduction in round trips
–  Reduction in byte count (on top of HTTP
Compression)


Before and After

9.47 sec

13.7 sec


What We Helped


100 1000
90 900
80 800
70 700
60 600
50 500
40 400
30 300
20 200
10 100
0 0

9 25

8
20
7
6
15
5
4 10
3
2 5
1
0 0

100 1000
90 900
80 800 727
70
92
700
60 600 310
64
50 500
40 400
30 300
417
28
20 200
10 70 % 100 43%
0 0

9 25

8
20
7 6.245 13.737
6
2.589 15 4.260
5
4 10
3
3.656 9.477
2 5
1 41% 31 %
0 0


http://www.youtube.com/watch?v=J_gU2Z_b-6I


Pros and Cons

•  Pros
–  Noticeable and significant benefit over easier
techniques
–  The mobile form factor lets us be more aggressive
with some of the techniques
–  Smart use of localStorage

•  Cons
–  It’s not easy!
–  Techniques must survive site changes (regression)


Step 4: More Mobile FEO


More Mobile FEO

•  Deferral
–  Analytics
–  Marketing tags
–  Ads
–  Etc


3rd Party Calls



•  Deferral of round trips to after onload

–  Fewer round trips to onload
–  Fewer bytes to onload


Before and After


Before and After

2.2
sec
3.6 sec

9.47 sec 5.56 sec


What We Helped


100 1000
90 900
80 800
70 700
60 600
50 500
40 400
30 300
20 200
10 100
0 0

9 25

8
20
7
6
15
5
4 10
3
2 5
1
0 0

100 1000
90
64 % 900
34 %
80 800
70 700
60 600
50 500
28 417
40 400
30 18 300 142
20 200
10 100
10 275
0 0

9 25

8 41% 41 %
20
7
6
15
5
4 3.656 9.477
10
3 3.92
1.493
2 5
1
2.163 5.557
0 0


http://www.youtube.com/watch?v=e0oFr0pSRn8


Pros and Cons

•  Pros
–  Gives you the control that your marketing team may
have given away!
–  Solves a very difficult problem, resulting in
improvements to all key metrics
–  Much better visual experience

•  Cons
–  Again, not easy!
–  Must understand what the purpose of each 3rd party
call is


Quick Summary of Stepwise Acceleration


Overall Improvements

Original

Keep-alive /
Compression

CDN

Mobile FEO 1

Mobile FEO 2


Overall Improvements
100 1000
90 900
80
89 % 71 %
800
70 700
60 600
50 93 500 945
40 400
30 83 670
300
20 200
10 100
10 275
0 0

9 25

72 %
8
7
20
73 %
6
15
5
7.738 20.52
4 10
3 5.575 14.963
2 5
1
2.163 5.557
0 0

Mobile Caching


Stating The Obvious

Caching is Good!!!


First View of a Page


Repeat View with Terrible Caching


Repeat View with Validations Only


Repeat View with Good Caching


Mobile Caching

•  The primary issues with mobile caching:
–  where to put the objects
–  the size of the cache
•  Some good reading
–  Device Cache Sizes
•  Wink toolkit study: http://www.winktoolkit.org/blog/204/
•  YUI study:
http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/
•  Blaze study:
http://www.guypo.com/mobile/understanding-mobile-cache-sizes/
–  Individual Files
•  Steve Souders:
http://www.stevesouders.com/blog/2010/07/12/mobile-cache-file-sizes/
•  More from YUI:
http://www.yuiblog.com/blog/2010/07/12/mobile-browser-cache-limits-
revisited/


Mobile Cache Sizes

•  Cache sizes are much smaller than desktop
–  Android (2.x) about 5-7MB
–  iOS is larger (>50MB)
•  We need to think about:
–  Total cache size limit
–  Individual object size limit
–  HTML pages
•  User behavior may affect what’s served from
cache
•  Things are getting better, but not at the pace we
want


Some More Findings

•  Android:
–  Firefox and Opera (Gingerbread): ~10MB
–  Stock browser in ICS: 25MB
–  Chrome on ICS: much larger and based on amount of
space available
•  http://gent.ilcore.com/2012/02/chrome-fast-for-android.html

•  Android and iOS
–  When there’s room available, saw aggressive caching
behavior


Comparison to Desktop

•  IE
–  http://blogs.msdn.com/b/ie/archive/2011/03/17/internet-
explorer-9-network-performance-improvements.aspx
–  Defaults
•  IE 6/7/8 à 1/32 of disk, cap of 50MB
•  IE9 à 1/256 of disk (bigger disks), cap of 250MB
•  Chrome
–  Spot checked: >300MB
•  Firefox
–  Spot checked: >700MB
•  From Steve: http://stevesouders.com/cache.php


HTML5 localStorage

•  W3C’s Web Storage Spec:
–  http://dev.w3.org/html5/webstorage/
•  Per domain storage
–  Key/value pairs
–  ~2.5MB
–  Test it:
http://dev-test.nemikor.com/web-storage/support-
test/
•  Programmable
–  It can be used for whatever you want
–  This includes acting as a programmable object cache!


Bing’s Use of localStorage


localStorage as a Cache

•  It gives us new space, not shared, to use for
caching

•  It’s programmable and scriptable, something
we’ve never had with HTTP object caches

•  Typically good for caching CSS and JavaScript,
especially those used site-wide

•  Could also be used for small images
–  Using DataURI format for images


A Little Bonus!
Maybe there’s another site we can accelerate…

Velocityconf.com


Waterfall and Key Performance Metrics



http://www.youtube.com/watch?v=hsQnkIPTgo4


Further Analysis


Functional Acceleration

•  Most images are not in the immediate viewport

•  Lots of round trips blocking start render

•  This time, we’ll accelerate with an eye towards:
–  Improving start render time
–  Making the page available quicker


Step 1: Deferral


Deferral

•  Let’s defer:
–  3rd party calls (like before)
–  Images not in the viewport

•  Also basic Mobile FEO
–  Image compression and minification
–  Some consolidation of CSS and JavaScript

•  What should we expect
–  Better visual response – snappier page


Before and After

2.1
6.2 sec sec

12.61 sec 4.7 sec


What We Helped



http://www.youtube.com/watch?v=XD6QkP0bNak


Step 2: Less Deferral?


Let’s Look at the Page Again

Visible

Deferred
Images


Let’s Look at the Page Again

Visible

Make more images
available before
onload

Deferred
Images


Defer less images

•  Let’s not defer one
scroll of images
–  User can scroll faster and
still have the next
screen’s images available

•  If the visual response is
just as fast, then this is
a good option if we
expect people to scroll
on our site right away


Before and After


Before and After

2.18
2.1 sec
sec

4.7 sec 5.3 sec



http://www.youtube.com/watch?v=eLmzd8A7RbA


It’s Not Always About Every Metric!

•  Visually, we’re about the same as full image
deferral, but 4 images are available 2 seconds
earlier

•  Some of this can be done programmatically –
dynamic decisions made by the browser
–  Figure out coordinates for image; choose to download
now or later


Step 3: One Last Thing


One Last Thing


One Last Thing

200
msec


One Last Thing

200
msec

775
msec


Cache the HTML

•  Cache the HTML base page itself
–  Somewhere in front of the server, before the browser
–  In this case, it’s a feature of the service

•  Eliminate server processing time
–  Serve the HTML faster
–  Improve TTFB of the page and all other performance
metrics


Before and After


Before and After

775
msec

236
msec


Before and After

2.18 1.78
sec sec

5.3 sec 3.2 sec



http://www.youtube.com/watch?v=gQgsxDiWqLQ


HTML Caching

•  HTML is typically dynamic
–  It can be static for short periods of time (the velocity
home page is a good example)
–  Some technologies allow fragmentation of the page
into static and dynamic portions
•  HTML can be user-agent specific
–  For velocity’s home page, the same URL generates
different pages depending on the browser
•  With HTML Caching, we need extra smarts:
–  Granular expiration
–  Browser aware
–  Careful with personalized content


We Covered Everything, right?
Not Quite…

Not Done Yet

•  We may have made these 2 pages faster, but
there’s a lot more to mobile optimization

•  Performance is not only about pages
–  We should always think about the site

•  Optimizations should include operational
improvements specific to mobile devices


Site-wide Optimizations - flows

Actual User Interaction


More Performance Optimizations

•  Converting click events to touch events
–  Can save up to 500msec per event
•  Smart use of localStorage
–  Versioning
–  Dynamic decisions based on state of localStorage
•  Redirect suppression
–  Sites that initially redirect to mobile version incur a
costly roundtrip
•  3G vs WiFi
–  navigator.connection.type – Android only for
now

Operational and Other Optimizations

•  Hiding the URL bar
•  Smart image loading for pinch to zoom
–  Automatically detect pinch and grab higher resolution
image
•  Viewport optimizations
–  E.g. Automatic detection of viewport
•  Mobile meta tags
•  Great presentation from Max Firtman:
–  http://velocityconf.com/velocity2011/public/schedule/
detail/19976


Lessons Learned From The Field
Things you should know about mobile devices

Velocity 2012: The 90-Minute Mobile Optimization Life Cycle

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Velocity 2012: The 90-Minute Mobile Optimization Life Cycle

Similar to Velocity 2012: The 90-Minute Mobile Optimization Life Cycle (20)

More from Strangeloop

More from Strangeloop (6)

Recently uploaded

Recently uploaded (20)

Velocity 2012: The 90-Minute Mobile Optimization Life Cycle