Velocity 2012: The 90-Minute Mobile Optimization Life Cycle

The 90-Minute Mobile Optimization Life Cycle

Hooman Beheshti VP Technology, Strangeloop

[email protected]

Velocity 2012

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

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

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



0 6 12

DNS TTFB

TCP Connection

Download



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)

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

Origin Data Center

Origin

3G Connection


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 connections •  Too many bytes


Too Many Bytes



•  Too many connections •  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



•  Too many connections •  Too many bytes •  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



•  Too many connections •  Too many bytes •  No CDN •  Too many round trips •  Poor caching (more on this later)



•  Too many connections •  Too many bytes •  No CDN •  Too many round trips •  Poor caching (more on this later) •  3rd party calls (marketing tags, analytics, etc)


3rd party


3rd party

Before Start Render



•  Too many connections •  Too many bytes •  No CDN •  Too many round trips •  Poor caching (more on this later) •  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

0

10

20

30

40

50

60

70

80

90

100 Round trips to onload

0

100

200

300

400

500

600

700

800

900

1000 Bytes to onload (KB)

0

1

2

3

4

5

6

7

8

9 Start Render (sec)

0

5

10

15

20

25 Doc Complete (sec)


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

0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20




0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20


23 %

25 % ~9%

20.52

15.289

5.231

7.738

7.059

0.679

945

727

218



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

Edge Cache

Edge Cache

Origin Data Center

Origin


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

•  Impact to performance metrics –  No change to round trips –  No change to byte count –  Better start render time –  Better document complete time


Before and After

15.29 sec 13.7 sec


Impact on TTFB

Avg = 655 ms Avg = 394 ms

-39.8 %


What We Helped



0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20




0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20


15.289

13.737

1.552

7.059

6.245

0.814

12% 10 %



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

Edge Cache

Edge Cache

Origin Data Center

Origin

DNS Resolver

CDN DNS Brains


CDN Edge Selection – Mobile Network

Edge Cache

Edge Cache

Edge Cache

Edge Cache

Origin Data Center

Origin

DNS Resolver

CDN DNS Brains

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



CDN 1

CDN 2

Ping cdn.domain.com

Ping IP that CDN picked for desktop

Both pings from phone

Both pings from phone


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)

•  Impact to performance metrics –  Reduction in round trips –  Reduction in byte count (on top of HTTP

Compression) –  Better start render time –  Better document complete time


Before and After

13.7 sec

9.47 sec


What We Helped



0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20




0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20


13.737

9.477

4.260

6.245

3.656

2.589

727

417

310

92

28

64

43% 70 %

41% 31 %



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

•  Impact to performance metrics –  Fewer round trips to onload –  Fewer bytes to onload –  Better start render time –  Better document complete time


Before and After


Before and After

9.47 sec

3.6 sec

5.56 sec

2.2 sec


What We Helped



0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20




0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20


34 %

41 % 41%

64 %

9.477

5.557

3.92

3.656

2.163

1.493

417

275

142

28

10

18



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

0

10

20

30

40

50

60

70

80

90


0

100

200

300

400

500

600

700

800

900


0

1

2

3

4

5

6

7

8


0

5

10

15

20


89 % 71 %

72 % 73 %

20.52

5.557

14.963

7.738

2.163

5.575

945

275

670

93

10

83


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 start render time –  Better document complete time –  Better visual response – snappier page


Before and After

12.61 sec

6.2 sec 2.1sec

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

Deferred Images

Make more images available before

onload


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.1sec

4.7 sec

2.18 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

775msec


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

775msec

236 msec


Before and After

2.18 sec

5.3 sec

1.78 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

Technology

Transcript of Velocity 2012: The 90-Minute Mobile Optimization Life Cycle