Engineering HTML5 Applications for Better Performance

Editor's Notes

• #2: 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
• #4: 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.
• #5: 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
• #6: 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
• #7: 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
• #8: 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.
• #9: 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
• #10: 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
• #11: Ok, let’s get back to the
• #12: 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
• #16: 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!
• #17: 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
• #18: 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
• #21: 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
• #22: 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
• #23: 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
• #24: 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;
• #26: This is the tricky part – we have already seen that in most of the cases, it can be a bit difficult to achieve
• #27: 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)
• #28: 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)
• #29: 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!
• #31: 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.
• #32: I think these should qualify for any slick applicationMost of the native apps won’t make it, either
• #33: I think these should qualify for any slick applicationMost of the native apps won’t make it, either