Unravelling Mobile Web Performance
Upcoming SlideShare
Loading in...5
×
 

Unravelling Mobile Web Performance

on

  • 4,015 views

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?...

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

Statistics

Views

Total Views
4,015
Views on SlideShare
2,622
Embed Views
1,393

Actions

Likes
5
Downloads
47
Comments
2

6 Embeds 1,393

http://greenido.wordpress.com 1377
http://paper.li 10
http://webcache.googleusercontent.com 3
http://us-w1.rockmelt.com 1
http://a0.twimg.com 1
http://thinkery.me 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Unravelling Mobile Web Performance Unravelling Mobile Web Performance Presentation Transcript

    • Mobile  Web  Performance   Guy  Podjarny,  CTO   guypo@blaze.io   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   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  
    • 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  h?p://blaze.io/blog/  5  
    • Terminology   Resource   Doc  Complete,   Waterfall  Chart   (Request/Response)   (a.k.a.  onload,   Start  Render   Load  Time)  6  
    • Why  Mobile  Web    Performance  Ma?ers  
    • Users  Expect  Fast  Sites   Source:     Akamai  8  
    • Users  Abandon  Slow  Sites   Page Abandonment vs. Load Time   Source:   KISS  Metrics  9  
    • Fast  Sites  Help  Bo?om  Lines   Shopzilla: 5 sec load time improvement   Source:   Shopzilla  10  
    • Mobile  Browsing  is  Gelng  Big   Sources:   HubSpot,  Twi?er,  Reuters  11  
    • Mobile  Users  Expect  Equal  Speeds   Source:  Gomez  12  
    • And  will  abandon  slow  sites   Source:  Gomez  13  
    • 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  
    • What  Is  Mobile?  •  Mobile  is  not  just  one  thing…  •  Mobile  Network    •  Mobile  Hardware  •  Mobile  SoVware  15  
    • Mobile  Network  
    • 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  
    • 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  
    • OpHmizaHon:  On-­‐Demand  Images   Mobile  Walmart  Apparel  Page   Mobile  Walmart  Apparel  Page   Original   Images-­‐On-­‐Demand  19  
    • OpHmizaHon:  On-­‐Demand  Images  •  Reduced  Requests:  28  Requests  (33%)  •  Reduced  Bytes:  108  KB  (33%)  •  Reduced  Fully  Load  Time:  5.9s  (63%)  20  
    • OpHmizaHon:  On-­‐Demand  Images  •  Site:  h?p://m.nbcsports.com/  •  Reduced  Requests:  15  Requests  (35%)  •  Reduced  Bytes:  50  KB  (31%)  21  
    • 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   Original   Async  JS  24  
    • 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  
    • 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   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  
    • 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?   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  
    • 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   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  
    • Android  Tablets  Not  IdenHfied  •  www.cnet.com   Nexus  S   XOOM   iPad  2  38  
    • 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   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  
    • 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  
    • 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   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  
    • 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  
    • Summary  
    • What  Is  Mobile?  •  Mobile  is  not  just  one  thing…  •  Mobile  Network  •  Mobile  SoVware  •  Mobile  Hardware  49  
    • 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  
    • QuesHons?  Mobile  Web  Performance   Guy  Podjarny,  CTO   guypo@blaze.io  
    • 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