Unravelling Mobile Web Performance

4,675 views
4,486 views

Published on

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

Published in: Technology, Business
2 Comments
6 Likes
Statistics
Notes
No Downloads
Views
Total views
4,675
On SlideShare
0
From Embeds
0
Number of Embeds
1,488
Actions
Shares
0
Downloads
54
Comments
2
Likes
6
Embeds 0
No embeds

No notes for slide

Unravelling Mobile Web Performance

  1. 1. Mobile  Web  Performance   Guy  Podjarny,  CTO   guypo@blaze.io   Twi?er:  @guypod  
  2. 2. Agenda  •  Why  Mobile  Web  Performance?  •  The  Different  Aspects  of  Mobile   –  Performance  implicaHons   –  OpHmizaHon  Techniques  •  Summary  •  Q&A  2  
  3. 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. 4. Who  Am  I  #2:  Blaze  Mobitest  •  Mobile  Web  Performance  Measurement   –  Free  Online  Service:  h?p://blaze.io/mobile/  4  
  5. 5. Who  Am  I  #3:  Mobile  Perf  Researcher  h?p://blaze.io/blog/  5  
  6. 6. Terminology   Resource   Doc  Complete,   Waterfall  Chart   (Request/Response)   (a.k.a.  onload,   Start  Render   Load  Time)  6  
  7. 7. Why  Mobile  Web    Performance  Ma?ers  
  8. 8. Users  Expect  Fast  Sites   Source:     Akamai  8  
  9. 9. Users  Abandon  Slow  Sites   Page Abandonment vs. Load Time   Source:   KISS  Metrics  9  
  10. 10. Fast  Sites  Help  Bo?om  Lines   Shopzilla: 5 sec load time improvement   Source:   Shopzilla  10  
  11. 11. Mobile  Browsing  is  Gelng  Big   Sources:   HubSpot,  Twi?er,  Reuters  11  
  12. 12. Mobile  Users  Expect  Equal  Speeds   Source:  Gomez  12  
  13. 13. And  will  abandon  slow  sites   Source:  Gomez  13  
  14. 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. 15. What  Is  Mobile?  •  Mobile  is  not  just  one  thing…  •  Mobile  Network    •  Mobile  Hardware  •  Mobile  SoVware  15  
  16. 16. Mobile  Network  
  17. 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. 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. 19. OpHmizaHon:  On-­‐Demand  Images   Mobile  Walmart  Apparel  Page   Mobile  Walmart  Apparel  Page   Original   Images-­‐On-­‐Demand  19  
  20. 20. OpHmizaHon:  On-­‐Demand  Images  •  Reduced  Requests:  28  Requests  (33%)  •  Reduced  Bytes:  108  KB  (33%)  •  Reduced  Fully  Load  Time:  5.9s  (63%)  20  
  21. 21. OpHmizaHon:  On-­‐Demand  Images  •  Site:  h?p://m.nbcsports.com/  •  Reduced  Requests:  15  Requests  (35%)  •  Reduced  Bytes:  50  KB  (31%)  21  
  22. 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. 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. 24. Async  JS  –  Eliminate  Script  SPOF   Original   Async  JS  24  
  25. 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. 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. 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. 28. Mobile  SoVware  
  29. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. Android  Tablets  Not  IdenHfied  •  www.cnet.com   Nexus  S   XOOM   iPad  2  38  
  39. 39. Frequent  OS  &  Device  Updates  39  
  40. 40. Mobile  Browser  Usage  –  North  America  40  
  41. 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. 42. Mobile  Hardware  
  43. 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. 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. 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. 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. 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. 48. Summary  
  49. 49. What  Is  Mobile?  •  Mobile  is  not  just  one  thing…  •  Mobile  Network  •  Mobile  SoVware  •  Mobile  Hardware  49  
  50. 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. 51. QuesHons?  Mobile  Web  Performance   Guy  Podjarny,  CTO   guypo@blaze.io  
  52. 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. 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. 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. 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. 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. 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  

×