Unravelling Mobile Web Performance

Mobile Web Performance Guy Podjarny, CTO [email protected] Twi?er: @guypod

Agenda

•  Why Mobile Web Performance? •  The Different Aspects of Mobile – Performance implicaHons – OpHmizaHon Techniques

•  Summary •  Q&A

2

Who Am I #1: CTO of Blaze.io

•  Automated Frontend OpHmizaHon Service –  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

OpHmizaHons from world’s fastest sites

Shared insights from >1M pages analyzed

Blaze performance research team

Who Am I #2: Blaze Mobitest

•  Mobile Web Performance Measurement – Free Online Service: h?p://blaze.io/mobile/

4

Who Am I #3: Mobile Perf Researcher

5

h?p://blaze.io/blog/

Terminology

6

Waterfall Chart

Start Render

Resource (Request/Response)

Doc Complete, (a.k.a. onload, Load Time)

Why Mobile Web Performance Ma?ers

Users Expect Fast Sites

8

Source: Akamai

Users Abandon Slow Sites

9

Page Abandonment vs. Load Time

Source: KISS Metrics

Fast Sites Help Bo?om Lines

10

Shopzilla: 5 sec load time improvement

Source: Shopzilla

Mobile Browsing is Gelng Big

11

Sources: HubSpot, Twi?er, Reuters

Mobile Users Expect Equal Speeds

12

Source: Gomez

And will abandon slow sites

13

Source: Gomez

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

14

Source: New Relic

What Is Mobile?

•  Mobile is not just one thing…

•  Mobile Network •  Mobile Hardware

•  Mobile SoVware

15

Mobile Network

Mobile Networks are SLLLOOOWWW…

17

0

0.5

1

1.5

2

2.5

Broadband Mobile

Upload (Mbps)

0

50

100

150

200

250

300

350

400

Broadband Mobile

Latency (Ms)

0

2

4

6

8

10

Broadband Mobile

Download (Mbps)

Source: PCWorld, FCC, Novarum

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

18

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

Nexus S XOOM iPad iPad2 iPhone IE8

# Requests

# Bytes

# Domains

Correla7on To Page Load Time

OpHmizaHon: On-‐Demand Images

19

Mobile Walmart Apparel Page Original

Mobile Walmart Apparel Page Images-‐On-‐Demand


20

•  Reduced Requests: 28 Requests (33%) •  Reduced Bytes: 108 KB (33%) •  Reduced Fully Load Time: 5.9s (63%)


21

•  Site: h?p://m.nbcsports.com/ •  Reduced Requests: 15 Requests (35%) •  Reduced Bytes: 50 KB (31%)

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

SoluHon: Eliminate SPOFs

•  Common SPOFs – Scripts – CSS –  IFrames – Fonts

•  SoluHon #1: Async JS/CSS •  SoluHon #2: Avoid/Delay IFrames •  SoluHon #3: Avoid Fonts

23

Async JS – Eliminate Script SPOF

24

Original Async JS

Latency vs. Start Render: Async JS in AcHon

25

0

1,000

2,000

3,000

4,000

5,000

6,000

30ms 100ms 200ms 300ms

Start Render Time per Latency (Milliseconds, 10 Top Mobile News Sites)

Original Site With Async JavaScript

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

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

Mobile SoVware

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

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

30

0

5

10

15

20

25

30

iPhone 4 Nexus S Blackberry iPad 2 XOOM

Cache Capacity in MB

-‐

10

20

30

40

50

60

70

iPhone 4 Nexus S Blackberry iPad 2 XOOM

Cache Capacity in Pages

More Info: h?p://www.blaze.io/mobile/understanding-‐mobile-‐cache-‐sizes/

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

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

Pipelining: What Should You Know?

•  Risks – Head-‐of-‐Line Blocking

•  Slow resource delaying fast ones – Resources requested out of order

•  Depends on heurisHcs – Support detected per server/conn – Requires explicit Keep-‐Alive header

•  Conflicts with Domain Sharding

33

Slow Resource delays Fast Resources

ConnecHon 1

ConnecHon 1 ConnecHon 2

With Pipelining

Without Pipelining

h?p://www.blaze.io/mobile/h?p-‐pipelining-‐big-‐in-‐mobile/

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

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

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

Android FragmentaHon -‐ ConnecHons

37

Samsung Galaxy S -‐  Max Conn: 12 -‐  Max Conn Per Host: 12 -‐  Max Piped Requests: 6

Samsung Nexus S -‐  Max Conn: 4 -‐  Max Conn Per Host: 4 -‐  Max Piped Requests: 3

Motorola XOOM -‐  Max Conn: 35 -‐  Max Conn Per Host: 6 -‐  No Pipelining Support

Android Tablets Not IdenHfied

•  www.cnet.com

38

Nexus S XOOM iPad 2

Frequent OS & Device Updates

39

Mobile Browser Usage – North America

40

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

Mobile Hardware

Mobile Hardware: Weaker CPU

•  Weaker CPU = Slower JavaScript – SHll 10x slower than desktop

•  Script Parsing is Slow – About 1-‐10ms/KB

•  Not just JavaScript – Flash, CSS, Dynamic Graphics…

43

-‐ 2,000 4,000 6,000 8,000 10,000 12,000

Macbook Pro

iPhone 4S (5.0)

iPhone 4 (5.0)

iPhone 4 (4.3)

iPhone 4 (4.2)

230

2,227

3,574

4,285

10,303

Sunspider Time by Device/Version

Hardware Impact on Page Load Time

•  Alexa US Top 100: Average Load Times – Measured at night over same WiFi + Cable

44

iPhone 4

iPhone 4S

iOS Simulator

CPU 1-‐Core ~800Mhz

2-‐Core ~800Mhz

2-‐Core 2.7Ghz

CPU Cache 32 KB 32 KB 4 MB

RAM 512 MB 512MB 8 GB

Median Page Load

3.4s 2.9s 1.5s 0

500

1000

1500

2000

2500

3000

3500

4000

iPhone 4 iPhone 4S iOS Simulator

Page Load Time

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

Responsive Images: Resize To Screen

46

128px, 2.9 KB 240px, 6.8 KB

320px, 10.6 KB

480px, 21.3 KB

Full Res, 50.1 KB

Site: lonelyplanet.com Device: iPhone 4 Before: 867 KB AZer: 570 KB

Mobile Hardware: Touchscreen

•  Touchscreen common in Mobile •  Touch can mean many things – Devices lag to decide

•  Impact: Delayed Clicks – Take 300+ ms to decide it’s a click

•  SoluHon: Replace click with touch – May sHll have usability implicaHons

47

Zoom? Click? Scroll?

Summary

What Is Mobile?

•  Mobile is not just one thing…

•  Mobile Network

•  Mobile SoVware

•  Mobile Hardware

49

Mobile Web Performance Aspects

•  Mobile Network –  Slow –  Unreliable –  Ad-‐hoc connecHons

•  Mobile Hardware – Weak CPU –  Small Screens –  Touchscreen

•  Mobile SoVware –  Small Cache –  HTTP Pipelining –  FragmentaHon

50

•  Mobile Network –  Reduce Requests, Bytes –  Async All, Avoid SPOFs – Maintain a Heartbeat

•  Mobile Hardware –  Async/Avoid Scripts –  Progressive Images –  Touch instead of Click

•  Mobile SoVware –  localStorage –  Separate Slow Resources –  Focus, Measure

CHALLENGES SOLUTIONS

Mobile Web Performance Guy Podjarny, CTO [email protected]

QuesHons?

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

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

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

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

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

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

Technology

Unravelling Mobile Web Performance