BUILD 2012: 50 Performance Tricks to make your HTML5 Applications and Sites faster


Creating high performance Web applications is crucial for every Web developer, be it a Web site that runs on a standards based Web browser or a Windows Store App. Microsoft recently hosted the BUILD 2012 conference at the Microsoft campus in Redmond, WA. At this conference, I had the opportunity to share the Internet Explorer team’s favorite 50 performance tips to make HTML5 apps and sites faster. If you weren’t able to attend the conference, I recommend you check out the video.

These performance tips and tricks apply equally to Web sites that run on standards based Web browsers, and Windows Store Apps, which are also just the Web. There are six principals detailed in the talk that will help you improve the performance of your apps and sites today:

  • Quickly respond to network requests
  • Minimize bytes downloaded
  • Efficiently structure markup
  • Optimize media usage
  • Write fast JavaScript
  • Know what your application is doing

I hope you enjoy the talk.

— Jatinder Mann, Internet Explorer, Program Manager

Comments (37)

  1. Joe says:

    Wish they could figure out how to embed a video on their site. The right hand side of the video is covered by the sidebar. Including the button to go full screen.

  2. ieblog says:

    @Joe Thanks for letting us know. This has been corrected.

  3. Joe B. says:

    @ieblog, lets try running this simple animation code in console of FF16 and then IE10:

    (function LayerMovement() {

       var layer1 = document.createElement('div');

       var startTime = new Date() ;

       for( var i = 0; i <= 1000000; i++ ) { // one-million iterations

           layer1.style.x = i + 'px';

           layer1.style.y = i + 'px';

       }

       var endTime = new Date();

       console.info((endTime – startTime) + " milli-seconds");

    })();

    Results (on same machine):

    Firefox: 496 milli-seconds

    IE10: 962 milli-seconds

    Can you make it faster than FF 🙂

  4. Speednet says:

    @Joe B.,

    You win the award for the stupidest benchmark test since the advent of the web browser.  I hope Microsoft NEVER even considers optimizing their browser for that kind of completely irrelevant nonsense.  If you routinely move divs a million times offscreen, then by all means continue using Firefox, which you say can do it a half-second quicker.

    BTW, "millisecond" does not contain a hyphen.

  5. Silverlight says:

    Too bad Channel9 is still using Silverlight player as opposed to HTML5, which effects the performance as mentioned in the video.

    Thanks for these GREAT tips IE team.

  6. mike-mcgrath says:

    Excellent set of performance tips well explained. Thanks for this Jatinder.

  7. @Silverlight says:

    Go to their website and click the Format button.

  8. Marcos Caceres says:

    Please add controls to the HTML5 video. (*grumble* …silverlight… *grumble*)

  9. Posting comment stops the video says:

    AAAH!!!!! FFS!!! Posting a comment stops the video!!!! NO!!!!!

  10. WebGL trick or treat says:

    How good is HTML5 WebGL performance on IE10?

  11. Stvn Nuñez says:

    gracias por ello.

  12. Jens says:

    …… "Please add controls to the HTML5 video. (*grumble* …silverlight… *grumble*) "

    They do it, when HTML5 can do real Fullscreen 🙂

  13. Does someone has a resumé of all 50 tips? Don't have the time to watch an hour video.

  14. @WebGL trick or treat says:

    WebGL is an independent standard which has NOTHING to do with HTML5.

  15. @Pirre-Alain Vigeant says:

    Welcome to Channel9 by Microsoft. You can go to the video page (mentioned in the blog post just before the video): channel9.msdn.com/…/3-132

    And click on "Slides" under the video, to download power-point presentation (or click View Online if you don't have PowerPoint installed).

  16. @Jenz says:

    Actually you can go full-screen using HTML5 video control. Open the video page channel9.msdn.com/…/3-132

    Click Format and select HTML5.

    Play the video and click full screen icon.

  17. Tip Number One says:

    Tip Number One:

    Debug in a browser that has developer tools that don't suck as bad as IE's tools!  The only developer tool that can't even draw the DOM tree properly after 5 years.

    Utterly pathetic developer tools… to match the browser that couldn't implement document.getElementById(id) on their first try!

  18. @Tip Number One says:

    I look forward to your implementation on Open Source

  19. @Tip Number One says:

    Can you give me one example where F12 Dev tool doesn't draw a correct DOM?

  20. LJ says:

    @Joe B.

    Interestingly, my results are completely different to yours (I have made a jsfiddle with your function and an additional corrected function that actually changes .top and .left as I assume you meant: http://jsfiddle.net/xUtcZ/1/).

    IE10:

    Test 1: 597ms

    Test 2: 2430ms

    FF17:

    Test 1: 1025ms

    Test 2: 4403ms

  21. Steve says:

    Regarding the bad DOM tree for the IE Developer tools that @"@Tip Number One" doesn't seem to get (likely an MS FanTroll) here's a side by side comparison showing how much FAIL there is in the IE version.

    Here's the DOM in Firebug for the Digg homepage:

    http://i.imgur.com/4sVRQ.png

    And here's the DOM in IE's DevTools:

    http://i.imgur.com/kdknQ.png

    So, lets go through these to compare… the windows were sized the same for comparison by the way.

    1.) With Firebugs natural view you see WAY more actual usable DOM content.  In IE, the body tag is still 8 tags off the screen

    2.) "Text – Empty Text Node" – talk about an absolutely INSANE WASTE OF SPACE AFTER EVERY SINGLE ELEMENT RENDERED ON THE PAGE!

    3.) Notice in Firebug with their natural wrapping you can see and read every single class on the body tag? in IE you have to do MILES of horizontal scrolling to see all the content you need

    4.) Why is IE rendering a DIFFERENT DOCTYPE than the one specified in the actual HTML markup?

    5.) Because IE renders basic nodes with text content as this utterly ridiculous "tree branch" vs. what is actually in the source… you can't even see what is in the title tag without expanding that node.  The +/- expansion should be fore the child nodes… not the text content of the element.

    6.) Not shown, but in IE when you "expand" an element with text content you get: "Text – 'The actual text content'" – why do we need a prefix wasting space to tell us that text is text?

    7.) Not shown, but in Firebug when I "expand" a script element I see all the script code… even if it was in an external file I see it inline… with line numbers!

    8.) Not shown, but in Firebug when I "expand" a style element I see all the style code… even if it was in an external file I see it inline… with line numbers!

    9.) Did I mention the "Text – Empty Text Node" yet? yeah, it becomes infuriating when you start drilling down into nested elements!

    Just look how absolutely pointless this UI is!

    http://i.imgur.com/mRw5k.png  – how is this *REMOTELY* helpful?!

    10.) The problem with IE's rendering of the DOM tree is some whack job format is that it doesn't even look like the code we published and thus it is so hard to read it

    There's so much more (no live updates in IE, inline editing pains, bad cursor placement, scrolling & focus issues, no ability to add CSS rules, adding attribute usability failures when you press Enter after the name and your focus jumps to nowhere instead of to itself or better yet the value field!…)

    Now I will give Microsoft some credit… the first few versions they made with caMeLcASe aND UPPERcase element/attribute names was absolute garbage and I'm so glad they got rid of that – it shows that deep down someone at Microsoft actually cares about our eyesight but this current mess needs soooo much help it isn't funny.

    By the way, if there is a public fund set up to donate a few bucks to hire a real developer to fix the IE tools I would GLADLY contribute to this fund!

  22. @Steve says:

    In an ideal world: "MSDN blog, is not the place to submit the issues you are facing with F12 developer tools. Please submit feedback on connect using submit feedback button, so we can follow your request there."

    You got me all wrong, I am not a FanTroll. I personally feel like IE team doesn't have any permanent member because its a free product & they treat it like one; don't wana spend their "resources" on a free product. So when they are required to release a newer version of IE, real engineers from other teams (Visual Studio, Windows, SQL Server, SharePoint) group together, do the standards updates, fix some regression issues, play little with UI elements, handover the customer care to a cheap call-center in india (where they got wobbling heads, farting spices, copy pasting text from a word file and closing bug repos regardless to its severity) and finally they get back to their original teams.

    I am well-aware of the situation on Connect. Out of 100 submitted bug reports or suggestions, hardly two will get real attention. But these are the odds everyone is playing with over there. People like us care more about ecosystem than Microsoft and its cheap strategies.

    – John

  23. Steve says:

    Hi John.  I'm sorry if I jumped to conclusions and included you in a group of "MS FanTrolls"  but as a regular reader of this blog and a Web Developer for well over a decade it drives me nuts when commenter's come on this blog and suggest that every "dig" against Microsoft/IE is invalid.

    There are many reasons why I do most of my development in Firefox or Chrome but one of the biggest is that I find the tools/options in IE to be very limiting, incomplete, not designed with usability in mind etc.

    While I agree that the IE blog is not the correct place to file a bug report I'm going to have to lay down my "EngageReality[TM]" card and repeat for all those still unaware that MS Connect is a *horrible* bug tracking tool, the content is for the most part ignored by Microsoft because they use other tools internally, does not enable test cases to be *shared* across reporters/testers so that they can be verified/refined, and worst of all the entire backlog of issues is *wiped clean* on a new release as if they never happened.

    Not only is this a massive insult to everyone that contributes any time/effort into the system but it is also the way to inform your users that you don't care about them – actions speak louder than words.

    As a result after IE8 bug tracking ended and the slate was wiped clean for the 2nd time developers/testers/users like myself were fuming and *not* ever going to fall for that again.

    Let me be 110% clear.  "I WILL NEVER FILE OR LOOK AT A BUG REPORT IN CONNECT FOR THE REST OF MY LIFE…. UNLESS MICROSOFT STEPS FORWARD WITH A PUBLIC APOLOGY ON THIS BLOG AND IN WRITING INDICATES THEY WILL NEVER AUTO-REMOVE ANY BACKLOG BUGS UNLESS ****THEY**** HAVE CONFIRMED THAT THEY NO LONGER OCCUR IN THE NEW VERSION…. AND THEY PROMISE TO ACTUALLY PARTICIPATE IN THE CONNECT FEEDBACK PROCESS REGULARLY!"   providing no feedback until days before the release and marking everything as "won't fix" is **not** how a bug tracking system works!

    Now I apologize for the yelling but we've learned that the only way to get yourself heard by Microsoft is on this blog (after you've posted twice cause the system deletes your posts).

    I provided clear screenshots indicating where Microsoft's dev tools fail compared to the competition and detailed in writing some of the more significant issues.

    The nice part about the IE Blog is that it is 100% public… and indexed by Google.  So when the next 1,000 developers get frustrated with the IE tools and start Googling for solutions, addons, patches, fixes etc. they will come across this post and the screenshots and understand that Microsoft *HAS* been informed about this and the ball is in their court to resolve the issues.

    If the developer reads this in 2014 and the issues are still not resolved – they know exactly how to gauge Microsoft's commitment to developers and the IE product.

    If I wrote/filed all of this in Connect… no one would know… not even Microsoft.

    Sad but true.

  24. IE User says:

    IE10 preview recommends some websites that I never use when typing in an internet adress (url). How to get rid of that?

  25. Real McCoy says:

    @Steve, @John..

    "Sad but true." its very true. I reported similar shortcomings to Microsoft Connect last year connect.microsoft.com/…/extensibility-in-f12-developer-tools. On 23rd March, 2011 IE team replied that they will take it into consideration in their on going efforts and closed it By Design. But in terms of adaptability, its hard to use F12 developer tools compared to Firebug. I believe its a matter of 20 days (~2 sprints) to implement the easy-to-update DOM and CSS for a software developer employed at Microsoft to refine F12 tools. IE10 was a good opportunity when Microsoft's CEO himself inviting developers world-wide to join the ecosystem, but they didn't care (perhaps some marketing guy at Microsoft thinks its not worth it).

    F12 dev tools have some outstanding features which I do admire. Like change-user agent string, clear cache for the current domain, layout view, built-in color-picker, ruler etc. But for developers and designers, enhanced fast manipulation of live DOM and CSS, enhanced Console and enhanced Network monitor are the most wanted features. But F12 tools' console lacks auto-suggestions unlike firebug (perhaps a baby-instance of visual studio's intellisense would have done the trick) and now that firebug provides preview of HTML in Network, F12's Network is just fine (one step behind).

    I appeal to the F12 dev tools team at Microsoft to open the channel on uservoice.com and implement features as per our feedback just for few months, there is no reason that F12 wouldn't be the best tool out there (which will make Internet Explorer as a "complete solution" for client side web development).

    If you are reading it please feel our pain !!

  26. Riasat says:

    >easy-to-update DOM and CSS

    >reverse the sort order in css side panel

    These are the things that makes F12 dev tools worse than Firebug. Because of these, I still have to use firefox :/

  27. Real McCoy says:

    @Riasat, Try checking out the "Trace Styles" in F12 dev tools, which filters the actual styles applied on current element for you.

  28. Mitchel says:

    I'm so glad someone finally released the anger over the IE dev tools.  I've hated them since day 1 but didn't have the time/passion to rant about them to Microsoft vs developers I interact with.

    Kudos for getting this out in the open.  Hopefully Microsoft is listening and going to tell us that they are actually going to fix these tools to be usable!

  29. @steve says:

    Looking at the two pictures you've published, I notice that Firebug obviously does not show the entire stuff. EPIC FAIL!

  30. @f12-trolls says:

    Too bad your beloved Firebug can't inspect SVG doc elements & yes F12 can. EPIC FAIL!

  31. Darryl says:

    Oh great the MS trolls are back this time trying to defend the craptactular IE dev tools.

    Text – Empty Text Node

    The #1 technology of the web is HTML and IE plainly fails to even render it correctly in their DOM tools.

    IE is the Epic Fail!… Not the other browsers/dev tools that handle it correctly… And always have.

    Text – Empty Text Node

    I think the best way to resolve this and get IE's tools fixed is to sign off every post with the empty string as our signature… Or randomly though our comments.

    Text – Empty Text Node

    Darryl

    Text – Empty Text Node

  32. Riasat says:

    @Mitchel

    I know but it doesn't really help when you are designing cascading styles. Disable the applied style shown in trace style and some other style will be applied on the element. How do you find the new one? Have to scroll thru the *long* list.

  33. Adam says:

    PS it is almost 2013 Microsoft! Lets get this decade plus markup mess fixed please!

    regarding the F12 dev Tools can we also get the Style tab and CSS tab updated to *NOT* show uppercase tag names in the selector!?

    it's not just painful to read but causes a cognitive check because you have to think for a second… "wait… where did that style come from? I didn't declare that!… oh wait, Microsoft munged it for me… ugh…"

    ditto for the "element source with style (CTRL+T)" which again generates god awful CamelCase/UPPERCASE markup

    OMG! I have no idea what planet Microsoft lives on but the "Format JavaScript" option on the Script tag totally ruins any reasonable indentation scheme… Either show proper K&R style… or if you must wrap the opening brace… the opening and closing brace must be at the same indentation.

    In your XSL stylesheet to show the cookie information you have an invalid CSS property declaration for the td.title class.  "=" is not the valid delimiter for a property:value combo in CSS.  Just because IE has historically failed at parsing CSS properly doesn't mean you should continue to endorse bad coding practices.

    The same problem is in your image report XSL file "width=25%;" is not valid CSS.

    PS You get no bonus points for specifying a meta X-UA-Compatible tag locked to IE=9 when you don't even specify a doctype… you have full control over what renders and yet you fail to render something decent in standards mode – FAIL.

  34. feedback to microsoft from user says:

    From now on, please release an operating system and a browser in a cycle of five years.

    After it is serious from the next to the next!

  35. user says:

    So… When will the final version of IE10 be released?

  36. feedback says:

    If it is going to display or it does not carry out specific operation at some sites, a browser will not react.

    There is also an OK site in Chrome or Firefox.

    I want you to correct, talking with the administrator of each site even for the formal version.

  37. Catalin says:

    Hello,

    If this is a post about html5 sites and apps, why are you using a silverlight player? Have you heard about html5 player?

    Thanks!

Skip to main content