Engineering HTML5 Applications for Better Performance

1,621 views

Published on

One second page loads, 100ms UI response time and 60fps animations - even if today's browsers are super fast, meeting these performance goals can be tricky, particularly for mobile browsers.

This presentation outlines some tools & techniques to help to design web apps with performance in mind.

Published in: Technology, Design
  • Be the first to comment

Engineering HTML5 Applications for Better Performance

  1. 1. EnGiNeErInG HtMl5 aPpLiCaTiOnS fOr bEtTeR pErFoRmAnCe LaUrI SvAn @lAuRiSvAn Sc5 OnLiNe @sC5 HtMl5 eXpErTiSe aT yOuR sErViCe  
  2. 2. SlOw pAgE sPeEdS mEaNs lOsT $s! Amazon: 1% revenue increase for every 100ms speedup Google: 0.43% sessions lost for 400ms increase in load time Yahoo: 9% more traffic with 400ms faster page loads More info: http://www.strangeloopnetworks.com/web-performance-infographics/
  3. 3. WeB ApPs To ChAlLeNgE NaTiVe ApPs iN SlIcKnEsS? UsEr eXpErIeNcE   Web   iPhone   U6lizing  HW   accelerated  graphics,   offline  assets,   advanced  gestures   and  high  perf  JS   engines   HTML5   2005   2007   2009   2011   2013   ı3
  4. 4. WeB SiTeS StIlL GeT BiGgEr NoV 2010- SePt 2013 StAtS, HtTp ArChIvE / StEvE SoUdErS
  5. 5. We’rE nOt LeArNiNg!
  6. 6. WeB eNgInEs aRe qUiTe fAsT! LeT’s uSe tHe sAmE yArDsTiCk wHeN mEaSuRiNg HTML5 App •  1000 DOM elements •  1Mb of images and 100 network requests on page load Native App •  1000 widgets? •  1Mb of images and 100 network requests on app startup? How about these? •  1s first page fold •  1s application install?
  7. 7. MoBiLe DeViCeS - 5 yEaRs BaCk iN CpU SpEeD, 10 yEaRs BaCk iN CoNnEcTiOn BaNdWiDtH Samsung My Machine My Machine Galaxy S4 (2003) (2010)   CPU / MFLOPS 1500 373 4,256 Display / Pixels 2073600 1,920,000 4,096,000 Connection Speed / bps 384000* 300,000 4,000,000 Latency 300ms* 100ms 50ms *  Assuming  3G/UMTS  safe  speed,  due  to  low  adop6on  of  4G  networks  
  8. 8. LeT’s TaRgEt fOr MoBiLe ApP PeRfOrMaNcE •  •  •  •  1s app startup time (first page load time) 1s for any subsequent view/page (reasonable delay) 100ms UI response time (noticeable delay) 16ms paints (LCDs will refresh 50-60Hz, the rest is surplus) See e.g. Nielsen (1993): Usability Engineering, or http://www.nngroup.com/articles/the-need-for-speed/ http://www.nngroup.com/articles/response-times-3-important-limits/
  9. 9. If yOuR eMuLaToR rUnS 20 tImEs fAsTeR tHaN tHe TaRgEt, wHaT cAn yOu eXpEcT aBoUt PeRfOrMaNcE?
  10. 10. oNe-sEcOnD PaGe LoAdS
  11. 11. OnE SeCoNd BuDgEt •  •  •  •  •  Turn on radio DNS lookup SSL handshake Load, HTML & critical resources Parse à Layout à Paint … It’s tricky over 3G!! + + + = 300ms! 150ms! 200ms! 200ms! 150ms!
  12. 12. AnAtOmY oF An AvErAgE WeB PaGe
  13. 13. HtTp ReSoUrCe PiPeLiNe IlLuStRaTeD 6 ReSoUrCeS pEr DoMaIn
  14. 14. Not  really  needed   in  the  1st  fold   Conges6on,   load  order?   PaGe LoAd WaTeRfAlL – FiNd tHe PrObLeMs
  15. 15. SiMuLaTe SlOw PaGe SpEeDs •  Developers tend to have ultra-fast computers & networks and forget the Edge & 3G network •  Tip: Network Link Conditioner XCode Plugin & ipfw rules •  For localhost: https://gist.github.com/laurisvan/6783674
  16. 16. MeAsUrE YoUr PaGeS - WeBpAgEtEsT.OrG
  17. 17. CaNnEd ImPrOvEmEnTs MoD_PaGeSpEeD aNd NgX_PaGeSpEeD •  Canned implementation of best practices •  A few dozen different optimizations that rewrite your HTML, CSS, JS and images •  Applicable for ‘web sites’, harder to use for ‘web apps’ •  Sample docker script and nginx conf available at https://github.com/laurisvan/docker-pagespeed
  18. 18. OpTiMiZiNg fOr LaTeNcY 1.  Enable HTTP 1.1 & keep-alive 2.  Cache your content (expires, max-age, ETags etc.) 3.  Use CDN for static assets 4.  Compress & resize the images 5.  JavaScript & CSS monoliths; sprites, icon fonts 6.  Compress & minify: CSS, HTML, JavaScript 7.  Shard resources for a few domains 8.  Adaptive image sizes 9.  Optimize load order: Defer JavaScript, lazy-load images 10. Inline critical CSS & HTML for 1st page fold
  19. 19. ReAd MoRe: HiGh PeRfOrMaNcE BrOwSeR NeTwOrKiNg (IlYa GrIgOrIk / GoOgLe) http://chimera.labs.oreilly.com/books/1230000000545 TL;DR: http://www.igvita.com/slides/2012/webperf-crash-course.pdf
  20. 20. 60 fRaMeS ScRoLl aNd AnImAtIoN
  21. 21. OlD-ScHoOl OpTiMiZaTiOnS WoN’t HeLp YoU •  JavaScript is typically not your problem •  CSS selector lengths typically have only a minor impact •  Browsers spend ~90% of its computation layouting and painting What you want to track is •  The causes of relayout and repainting •  What their costs are •  Tip: Watch out for surprises, like pointer events: http://www.thecssninja.com/javascript/pointer-events-60fps
  22. 22. “TyPiCaL PaInT LoOp” Func6on   call  /  Event   JavaScript  Engine  (CPU  /  Virtual  Machine)   Recalculate   Style   Render  Tree  &  Layout  Engine  (CPU)   Layout   Paint  Engine  (CPU)   Paint   Composite   Layers   Compositor  (GPU)  
  23. 23. AlL CsS OpErAtIoNs aReN’t EqUaL •  Geometry changing ops •  width, height etc… •  Paint-only ops •  borders, outlines, box shadow, etc… •  Composition only (or less) •  CSS3 Transforms, Opacity •  100% GPU only!
  24. 24. OpTiMiZiNg LaYoUtS & PaInTs •  Separate DOM reads from DOM writes https://github.com/wilsonpage/fastdom •  Do your DOM changes through a smart proxy http://facebook.github.io/react/ http://www.ractivejs.org/ •  If you really have a million items, use Canvas instead of based DOM approaches (like SoundCloud’s equaliser bars) •  Avoid expensive paint operations (shadows, border radius, flexbox etc…) •  Use CSS3 transforms for animating (no reflows) •  Use translateZ(0) hack for HW accelerating elements
  25. 25. 1/10 sEcOnD tO ReSpOnD, OnE sEcOnD tO sHoW ThE rEsUlTs
  26. 26. TrAdItIoNaL PaGeS DoN’t Do aNyThInG uNtIl yOu TeLl *click*   Tradi&onal   *click*  
  27. 27. ImMeDiAtE FeEdBaCk bUyS YoU tImE OvErAlL pErFoRmAnCe mAy gEt fAsTeR, tOo *click*   Feedback   *click*  
  28. 28. PrElOaDiNg & BoOtStRaPpInG To ShOw tHe NeXt PaGe FaStEr YoU MaY HuRt YoUrSeLf BaD! *click*   Preloading   *click*   Bootstrapping   +  
  29. 29. LaZy LoAd - OpTiMiZiNg fOr tHe FiRsT PaGe FoLd Lazy  Load   +   +   1st  fold  inlined   +   Rest  of  the  page  as   separate  resources  
  30. 30. QuAlItY AtTrIbUtEs oF yOuR aPp aRe sEt bY yOuR ArChItEcTuRe. PeRfOrMaNcE iS nO ExCePtIoN. At sOmE pOiNt yOuR aRcHiTeCtUrE wIlL fIgHt aGaInSt yOu.
  31. 31. ReCaP: GeTtInG tO tHe pErFoRmAnCe tArGeTs •  •  •  •  •  •  Set the performance goals, prepare for tradeoffs Track the goals from the beginning Don’t guess; measure Simulate the target devices in your daily work Keep your code simple, don’t trade it for performance Perfect is the enemy of the good
  32. 32. HoMeWoRk: PlAn yOuR PeRfOrMaNcE BuDgEt Create a breakdown of your performance budget, with a 1s page load target. Estimate the latency and bandwidth requirements for your site, including the resources you pull from the web. Consider the context; what would be your estimated page load time be for a Cable/DSL, 4G or 3G connection? Justify your estimate through a few paragraphs explanation and a quick breakdown + a few calculations of the resources within your web page.
  33. 33. ThAt’s AlL! AnY QuEsTiOnS?
  34. 34. ThAnK yOu ! LaUrI SvAn Head of Tech, SC5 Online Ltd https://github.com/laurisvan https://twitter.com/laurisvan HtMl5 eXpErTiSe aT yOuR sErViCe  

×