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

Like this? Share it with your network

Share

High Performance Mobile Web

on

  • 1,252 views

This talk explains best practices and techniques use to build high performance mobile sites. The talk covers a wide range of different topics centred on how to improve performance over the network ...

This talk explains best practices and techniques use to build high performance mobile sites. The talk covers a wide range of different topics centred on how to improve performance over the network and how to improve performance in the software (including both server side & client side).

Statistics

Views

Total Views
1,252
Views on SlideShare
985
Embed Views
267

Actions

Likes
5
Downloads
9
Comments
0

3 Embeds 267

http://intranet 160
http://blog.jamesdbloom.com 91
http://beta.jamesdbloom.com 16

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

High Performance Mobile Web Presentation Transcript

  • 1. High Performance Mobile WebJames D Bloomhttp://blog.jamesdbloom.com
  • 2. ABOUT ME JAMES D BLOOMMobile Web ExpertTechnical  lead  of  mobile  web  at  Be2air    Focusing  on:    -­‐  High  Performance    -­‐  Reliability    -­‐  Wide  Device  Support    -­‐  Keeping  it  Simple    -­‐  Automated  TesEng  
  • 3. This talk….1.   Why  We  Should  Care  About  Performance?  2.   Network   Reducing  Requests   Reducing  Bytes   Increasing  Bandwidth  Efficiency   Reducing  Latency  3.   SoHware   More  Parallelism   Faster  Page  Rendering   Faster  Page  InteracEon  
  • 4. 01 WHY WE SHOULD CARE ABOUT PERFORMANCE?
  • 5. -5s +12% revenue each -100ms-50% hardware +1% revenue Wallmart & Amazon Shopzilla 0.4 -> 0.9s -2.2s -25% searches +15% downloads Google Firefox +1s -4% revenue Bing WHY CARE?
  • 6. LOAD TIME (in seconds) 60   51.38   50   47% expect 44.67   40   <2s 40% abandon 30   if >3s 27.16   20   15.86   12.49   9.21   10.36   11.43   7.65   7.85   8.64   10   5.41   6.03   0  h"p://www.keynote.com/keynote_compe11ve_research/performance_indices/mobile/retail-­‐world  
  • 7. 02 NETWORK - - REDUCING REQUESTS REDUCING BYTES - INCREASING BANDWIDTH EFFICIENCY - REDUCING LATENCY
  • 8. 02 NETWORK - - REDUCING REQUESTS REDUCING BYTES - INCREASING BANDWIDTH EFFICIENCY - REDUCING LATENCY
  • 9. CORELATION TO LOAD TIME Reduce Requests TOTAL REQUESTS 0.46 IMAGE REQUESTS 0.44 TOTAL XFER SIZE 0.40 IMAGE XFER SIZE 0.37 DOMAINS 0.37 Total   Image   Total  Xfer   Image  Xfer   Domains   Requests   Requests   Size   Size  h"p://mobile.h"parchive.org/   Based  on:  Alexa  Top  1,000,000  Sites  
  • 10. COMBINE REQUESTS - BUNDLING•  JavaScript  Bundle   –  Combine  all  files  into  single  bundle  •  CSS  Bundle   –  Combine  all  files  into  single  bundle    
  • 11. COMBINE REQUESTS - SPRITES•  Image  Sprite   –  Combine  all  images  into  CSS  Sprite  
  • 12. COMBINE REQUESTS - INLINING•  Inlining   –  dataURI  for  external  resources   –  Base64  larger  by  8/6  
  • 13. COMBINE REQUESTS - INLINING•  First  Load:   –  inline  resources  and  set  cookie   –  put  resources  in  localStorage  and  update  cookie  •  Subsequent  Load:   –  check  cookie   •  if  updated   –  load  resources  from  localStorage  (at  top  of  page)   •  if  iniEal  value  -­‐>  no  JavaScript  or  localStorage   –  return  with  resources  as  external  links  •  Bing   –  1st  request  54.9  KB   –  2nd  request  5.5  KB  
  • 14. AVOID REQUESTS•  Avoid  redirects  –  71%  of  mobile  sites  have  3xx   –  or  at  least  cache  them  •  Images   –  CSS3   •  gradient,  rounded  corners,  drop  shadow,  text  shadow   –  Avoid  animated  gifs   •  staEc  image  +  JS  •  Load  (and  eval)  on  demand   –  Images  -­‐>  google  image  search   –  JS  -­‐>  gmail  
  • 15. 02 NETWORK - - REDUCING REQUESTS REDUCING BYTES - INCREASING BANDWIDTH EFFICIENCY - REDUCING LATENCY
  • 16. RESPONSE SIZE (in kB) Reduce Image Size IMAGES 67% 358   SCRIPTS 21% HTML 6% 112   STYLESHEETS 4% 33   23   10   OTHER 2% Images   Scripts   HTML   Stylesheets   Other  h"p://mobile.h"parchive.org/   Based  on:  Alexa  Top  1,000,000  Sites  
  • 17. REDUCING BYTES – ADAPTIVE RESOURCES•  AdapEve  Images   –  UA  sniffing  or  media  queries   –  Major  breakpoints  or  server  side  scaling  •  AdapEve  JavaScript   –  UA  sniffing  for  device  specific  JS  •  AdapEve  CSS   –  Media  queries  for  device  specific  CSS  
  • 18. REDUCING BYTES - MINIFY•  Minify  JS  &  CSS   –  Typically  during  bundling  •  Mini  JS  framework   –  don’t  send  desktop  JS  to  mobile  
  • 19. REDUCING BYTES•  Compression   –  Use  gzip  for  text  resources   –  Maximize  lossless  compression  for  images  •  Reduce  Upload   –  Reduce  /  remove  cookies   –  Server-­‐side  cookie   –  Cookie  Free  Domain   •  staEc  resources   •  CDN  •  HIJAX   –  Highjack  full  page  request   –  AJAX  to  replace  <body/>   –  Avoids  reloading  CSS,  JS,  background  images  
  • 20. 02 NETWORK - - REDUCING REQUESTS REDUCING BYTES - INCREASING BANDWIDTH EFFICIENCY - REDUCING LATENCY
  • 21. PARALLELIZE DOWNLOADS•  CSS  at  the  top   –  download  background  images   –  avoid  FOUC  •  JS  at  the  booom   –  avoid  SPOF  
  • 22. PARALLELIZE DOWNLOADS•  async  or  defer  on  script  element  
  • 23. PARALLELIZE DOWNLOADS•  Domain  Sharding   –  >  6  resources  due  to  extra  domain  lookups  
  • 24. DELAYING DOWNLOAD•  delay  load  with  document.appendChild(node)  
  • 25. DELAYING DOWNLOAD•  delay  load  with  document.appendChild(node)  
  • 26. EARLY DOWNLOAD•  Eager  loading   –  Load  staEc  pages  eagerly   –  Store  in  localStorage   –  Uses  spare  bandwidth  
  • 27. 02 NETWORK - - REDUCING REQUESTS REDUCING BYTES - INCREASING BANDWIDTH EFFICIENCY - REDUCING LATENCY
  • 28. CACHING•  Caching   –  Caching  headers   •  Cache-­‐Control,  Expires,  Vary,  Last-­‐Modified,  ETag   –  Finger  print   •  >  1y  cache   •  JS,  CSS  and  images   •  i.e.  build  2932  -­‐>  all_2932_.css   –  Make  pages  cacheable   •  Avoid  cookies  &  headers   •  Use  path  variables   •  Separate  out  variable  content   –  iframe     –  AJAX   –  How  variable  is  content?     •  Always  consider  >  1s  cache  
  • 29. CACHING•  Types  of  Cache   –  Content  Delivery  Network  /  Edge  Cache   •  JS,  CSS  and  images   –  Reverse  Proxies   –  Browser  Cache   •  Limited  space,  regularly  fully  cycled   –  More  control  but  harder  to  use   •  ApplicaEon  Cache   •  Local  Storage   •  WebSQL  /  IndexedDB  
  • 30. 03 SOFTWARE - MORE PARALLELISM - FASTER PAGE RENDERING - FASTER INTERACTION
  • 31. 03 SOFTWARE - MORE PARALLELISM - FASTER PAGE RENDERING - FASTER INTERACTION
  • 32. PARALLEL DOWNLOAD•  Flush  <head/>  early   –  CSS  in  parallel   –  CSS  background  images  (sprites)  in  parallel  
  • 33. PARALLEL SERVICE CALLS•  Parallelize  service  calls  /  DB  queries  •  Render  view  (and  flush  <head/>)  in  parallel   controller task executor build model view render view service & DB calls flush <head/> flush <body/>
  • 34. 03 SOFTWARE - MORE PARALLELISM - FASTER PAGE RENDERING - FASTER INTERACTION
  • 35. FASTER PAGE RENDERING•  Simple  DOM  •  Efficient  CSS  selectors   –  avoid  generic  matches  on  right  side:   –  use  ids  or  specific  classes:  •  Minimize  reflows   –  CSS  in  <head/>   –  <img/>  with  height  and  width  
  • 36. 03 SOFTWARE - MORE PARALLELISM - FASTER PAGE RENDERING - FASTER INTERACTION
  • 37. FASTER PAGE INTERACTION•  Avoid  blocking  UI  Thread   –  Split  tasks   •  Use  events   •  setTimeout   –  Web  Workers     •  data  only     •  no  UI  interacEon   UI Thread execuEon   button 1 UI unpressed button 1 onclick button 1 UI depressed UI Queue button 2 UI depressed button 2 clicked button 1 clicked button 2 onclick button 2 UI unpressed
  • 38. FASTER PAGE INTERACTION•  SyntheEc  events   –  Touch  300ms  delay  •  Timers   –  Lots  >1s   –  Few  <500ms   –  Use  single  global  repeaEng  Emer  for  mulEple  tasks  •  Pre-­‐execute   –  Use  middle  Eer  as  much  as  possible  
  • 39. This talk….1.   Why  We  Should  Care  About  Performance?  2.   Network   Reducing  Requests   Reducing  Bytes   Increasing  Bandwidth  Efficiency   Reducing  Latency  3.   SoHware   More  Parallelism   Faster  Page  Rendering   Faster  Page  InteracEon