Your SlideShare is downloading. ×
Engineering HTML5 Applications for Better Performance
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Engineering HTML5 Applications for Better Performance

1,005
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. …

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

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,005
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • I’m Lauri, from HelsinkiI work for SC5, a company that focuses on better HTML5 experiencesToday’s talk is about better performance in HTML5 appsHow many of you have heard HTML5 apps suck in performance?I’m not going to debunk all of that, but more or give some ideas on why it might be soAnd why it’s not that much about the technology, but how the apps are made
  • So here comes the knight in its shiny armor! Make your app HTML5 and it will save your day! Right?Switching your markup for the latest version will not solve the problem for you. Adding new features will not make it for you.You need to engineer the application in the same way as you would do for a native app.
  • And our sites get bigger all the time. Now an average web site is one and half megabytes and makes almost a hundred requests to the serverYes. Time will solve that problem. Another 15 years and we will be alright.If we extrapolate, it seems that our web site seems to double up in size every three years!That will offset most of the performance gains
  • And our sites get bigger all the time. Now an average web site is one and half megabytes and makes almost a hundred requests to the serverYes. Time will solve that problem. Another 15 years and we will be alright.If we extrapolate, it seems that our web site seems to double up in size every three years!That will offset most of the performance gains
  • When looking at these lists you will quickly notice why web pages suckAnd why browser engines are actually quite awesome. This is what I mean when I say browsers are quite impressive!Such requirements for a native app would feel silly, and you would judge them out right away. Your designer just wouldn’t get them through.Or more likely. Your designer just wouldn’t draw those 1000 elements in the visual GUI
  • The problem is we just have taken a few years steps back.Our latest phones might be equivalent to our computers some 5 years backAnd 10 years back in connection bandwidthAnd we got our sluggish web sites. Somehow we have to make that up.
  • I think if you make application with these performance attributes, it should feel pretty good for any usersSome of these are quite hard, though.And most of the native apps don’t do these either
  • This might be a funny anecdote, but there might be some truth into itThink about native app developers and what they have. Their target devices are already quite fast, but the device emulator takes one minute to launch; the app takes 20 seconds to launch and it almost feels somebody’s painting the widgets by hand
  • Ok, let’s get back to the
  • Ok, these are not exact numbers, but they give a hint that one second is easy to waste, even with one resource to loadThe picture below is a simulation of a 3G connection, not the real thingIt’s easy to see that the window for all the critical resources is very short – you will waste the whole 200ms to latency over 3GAnd then you need to be pretty fast to paint them
  • The problem is, you are developing with a slick network connection and soon all the crap starts to build upWhat you would want to do is have a slow network from the start. You will start adding that caching and optimizing soon!
  • Note: If you want to use the same server, you can just direct them to different ports.See http://www.browserscope.org/?category=networkFor convenience, first shard the images. Then your CSS. If you still have concurrency problems, you’ve got problems elsewhere
  • Note: If you want to use the same server, you can just direct them to different ports.See http://www.browserscope.org/?category=networkFor convenience, first shard the images. Then your CSS. If you still have concurrency problems, you’ve got problems elsewhere
  • Unfortunately simulating hardware on your computer will be a bit difficultGetting the measurements from the actual target devices are a bit difficultSo we need to resort the measurements we can do in a normal browser, and extrapolate from that
  • Optimizing JavaScript is great fun, but usually worthless. We have had funny coding competitions internally where we can remove 99% of the JavaScript execution time. It’s fun, but it doesn’t matterThe same applies to CSS engines – they are very fast nowadays, it’s not a problemWhat is problem is the time spent on relayouting the elements, for example rebuilding the render treeAnd repainting the actual items
  • Quite a lot happens after you perform a change in the DOM. Things happen in several layers.First CPU will be busy calculating the geometry & layoutingThen the paint engine will get busy repainting the elements that need itAnd finally GPU will do the compositing. Sometimes the compositing may be done in the CPU, as wellThe point here is – avoid the whole staircase – use styles that cause only cause re-compositing (or painting)Show how these are recorded in Chrome Dev Tools
  • This is actually quite simple:Think your CSS elements – if you have elements that changeShow the FPS counter; do the box shadowbox-shadow: 10px 10px 5px #888888;
  • This is the tricky part – we have already seen that in most of the cases, it can be a bit difficult to achieve
  • Just consider your favouriteHere the main comparison is between a traditional, server-side rendered page and a single-page applicationThe lower flow assumes we’re creating the pages in the browser instead of server; Some AJAX derived model like Single-Page App or PJAXSince we’re in full control of the page load, we don’t need to limit to the dull feedbacks the browser provides (like just highlighting the clicked area)
  • Just consider your favouriteHere the main comparison is between a traditional, server-side rendered page and a single-page applicationThe lower flow assumes we’re creating the pages in the browser instead of server; Some AJAX derived model like Single-Page App or PJAXSince we’re in full control of the page load, we don’t need to limit to the dull feedbacks the browser provides (like just highlighting the clicked area)
  • Ok here we have gone a bit into black arts. In most of the cases you end up hurting yourself bad.It might be wortwhile to bootstrap some small high-latency data, just remember you don’t have too much of it!
  • I think the original quote is from Jan Bosch, but I haven’t traced it back. I heard it back in our university SW architecture class.Don’t start optimization as the “last story in your product backlog”. At that point you will notice there’s cancer everywhere!It is quite possible to do some performance fixes late. You can get it almost good enough. But you cannot get all of the gains, and some of them are almost certainly impossible.For example, our shop template makes far too many API calls – enough to fill the six-request limit. We should have batched them from the very beginningWe had a design flaw of putting very expensive elements to the first fold. Maybe the whole carousel should load lazilyThere will be so many assumptions made earlier, that you just cannot do a change that will not affect the other changes.
  • I think these should qualify for any slick applicationMost of the native apps won’t make it, either
  • I think these should qualify for any slick applicationMost of the native apps won’t make it, either
  • Transcript

    • 1. EnGiNeErInG HtMl5 aPpLiCaTiOnS fOr bEtTeR pErFoRmAnCe LaUrI SvAn @lAuRiSvAn Sc5 OnLiNe @sC5 HtMl5 eXpErTiSe aT yOuR sErViCe  
    • 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. 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. WeB SiTeS StIlL GeT BiGgEr NoV 2010- SePt 2013 StAtS, HtTp ArChIvE / StEvE SoUdErS
    • 5. We’rE nOt LeArNiNg!
    • 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. 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. 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. If yOuR eMuLaToR rUnS 20 tImEs fAsTeR tHaN tHe TaRgEt, wHaT cAn yOu eXpEcT aBoUt PeRfOrMaNcE?
    • 10. oNe-sEcOnD PaGe LoAdS
    • 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. AnAtOmY oF An AvErAgE WeB PaGe
    • 13. HtTp ReSoUrCe PiPeLiNe IlLuStRaTeD 6 ReSoUrCeS pEr DoMaIn
    • 14. Not  really  needed   in  the  1st  fold   Conges6on,   load  order?   PaGe LoAd WaTeRfAlL – FiNd tHe PrObLeMs
    • 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. MeAsUrE YoUr PaGeS - WeBpAgEtEsT.OrG
    • 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. 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. 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. 60 fRaMeS ScRoLl aNd AnImAtIoN
    • 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. “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. 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. 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. 1/10 sEcOnD tO ReSpOnD, OnE sEcOnD tO sHoW ThE rEsUlTs
    • 26. TrAdItIoNaL PaGeS DoN’t Do aNyThInG uNtIl yOu TeLl *click*   Tradi&onal   *click*  
    • 27. ImMeDiAtE FeEdBaCk bUyS YoU tImE OvErAlL pErFoRmAnCe mAy gEt fAsTeR, tOo *click*   Feedback   *click*  
    • 28. PrElOaDiNg & BoOtStRaPpInG To ShOw tHe NeXt PaGe FaStEr YoU MaY HuRt YoUrSeLf BaD! *click*   Preloading   *click*   Bootstrapping   +  
    • 29. LaZy LoAd - OpTiMiZiNg fOr tHe FiRsT PaGe FoLd Lazy  Load   +   +   1st  fold  inlined   +   Rest  of  the  page  as   separate  resources  
    • 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. 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. 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. ThAt’s AlL! AnY QuEsTiOnS?
    • 34. ThAnK yOu ! LaUrI SvAn Head of Tech, SC5 Online Ltd https://github.com/laurisvan https://twitter.com/laurisvan HtMl5 eXpErTiSe aT yOuR sErViCe