Understanding your website
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Beeby, Martin
Building a high performance front end is a balancing act. You need to understand all the different moving parts and subsystems in the browser and how they interact with each other. Small changes can significantly impact page and app load time, memory consumption, and processor use which has a huge impact on your user’s experience! In this session, we will dive into the subsystems of the browser and learn to optimise performance on sites and in web apps. We will also deep dive into the new performance analysing tools in IE11 available expose good and bad run-time patterns for your sites and web apps, and provide users with a fast and fluid experience.
 Hello, everybody. Hello, that one last guy just coming in. Come in. There's plenty of seats. I'm Martin Beebe. I'm from the UK. Anyone from the UK? Not many. Okay. I'm a developer evangelist in the developer relations team over there. I'm speaking about Internet Explorer F12 developer tools. Is everyone okay with that? Is that what you've come for? Good, good. And so we're going to be talking about the kinds of things which are new in the sort of tools. It's not going to be a 101 necessarily of our tools. It's going to be showing you the things that are new since the April release and a few things which I think are really interesting when you're trying to debug and look at performance in your website. And so we're going to be looking at a few things around the tools. The things that you can do with those F12 tools. We'll look at the web runtime architecture so we can see the places that we may need to optimize in our own web applications and the way that we can use those tools to get that to optimize it. And then we'll look at some real world demos, some real world problems which we will have traced using these tools. I do a lot of debugging. I've been a web developer for over 12 years. This is me when I was 16. I do a lot of debugging. It's only two years ago. Actually 18 years old now. And it's really frustrating. Debugging is one of the worst parts of web development in my opinion. And to be honest, the Internet Explorer DevTools have never really been very good up until there was a mark change in IE9 around funding and development inside of them. But they got a little bit better with IE10 and they've got a lot better with IE11 where we're kind of catching up to what our competition are doing in terms of developer tools. But also in some small areas, actually doing things differently from them and giving you more insight into the Dev Platform in different ways from our competitors, which is interesting. One of the things that's really quite interesting or cool about the new F12 tools is that the release that they just shipped, which was in April, was sort of out of band. Like they did an IE11 release back in November or something like that. And then they shipped again the tools just back in April. So they're shipping the DevTools in a much more sort of regular cadence, which is really interesting. They're adding new features out of band of IE11. So the actual DevTools that you will have got, you will have if you have IE11 installed on your machine, should have been updated back in April to this version that we're going to be talking about today. All of the updating in IE now happens silently in the same way that it does with other browsers. So we should be seeing people move more quickly up the chain and to the newer browsers. And also this is quite interesting. There's these new tools, but also like WebGL features as well, were dropped in between releases. So it's quite interesting that seeing that team working in a more agile kind of way. How many people have not seen the F12 tools before? Have never opened in an Explorer 11 and seen these tools. One person. If you've ever seen any other browser developers, browser vendors tools, it does very similar things. You can select elements, you can look at the CSS, you can choose to manipulate the DOM. There's eight different tools in total. And maybe if I use this, I could probably do this a little bit easier. These tools along the side, does that come out? There's eight tools in total. We've got DOM explorers, we've got memory profilers, we've got CSS editors. We've got all sorts of different things in the chain of what we're able to do. And I'm going to talk about the things which are kind of new in the developer tools. So first up we have one thing to point out is that these tools are in IE 11 across Windows 8.1 and across Windows 7 as well. It's not specific to the latest version of Windows. It's also on Windows 7. So any version of Windows IE 11 will be updatable to these tools. So you can get these on Windows 7 as well. So this is the NDC website. And we're going to look at this area where we've got this purple section. I'm going to change that background color by just selecting that element and then just changing it to 336699 which is hotmail blue. Or we can just choose from the images, choose from different colors, sorry, can choose and settle upon maybe. This is your, weirdly is not, it's your mind. Click on something like blue violet. So we can change a background property of an element quite simply. There you would expect that to be able to be done. We can go over here and we can select the, to delete an item. And you'll notice as I'm changing these elements there's a very small color to the side of the property which indicates that this has been changed. There's been some kind of manipulation done on this. And we only just added this in the latest version of the tools and it just shows all the changes between versions. And we can see here a delta between what I originally had in our CSS and this is a sort of diff file. We can then just go into that changes tab, cut and paste those CSS changes and then paste them into an editor. I'm just going to paste them into the console here. But you'll see as you make those manipulations and CSS changes directly inside of the CSS editor you can then go to the new changes tab and you can directly cut and paste those changes and put them back into your editor and back into your website. It was quite hard to do that in the previous tools. You would make these changes, you'd do lots of different manipulations and so forth and then it was difficult to actually go and get that stuff and put it back into your website. And this enables that and makes it slightly easier. Another really simple feature that I've added to the DOM is the ability to reorder the DOM and manipulate the DOM at will. So we can sort of drag elements around the DOM using the DOM Explorer. So if I were to select an element here and bring up the F12 tools I can take a div, like the bottom div, the bottom section of this website and I can drag and drop it to different sections. So you can manipulate the DOM, you can edit the DOM, you could add elements, you can delete elements, you can move elements around. All kind of basic kind of simple stuff. One of the problems that we used to have a lot inside of IE 11 tools or something which was a constant sort of request or feature request was when you are editing CSS elements and they have pseudo states like hover states. It's very, very difficult to work on that CSS because it's difficult to hover over an element and check its CSS properties without having too much. So what we've done is I've given you the ability to scroll over, say on the bottom of the NDC site you have these little elements which you, as you scroll over on the bottom and they change and their background color changes slightly. What you can do is you can select one of those elements and then if you press this little A colon which is just up in the corner here, you can click on that and then you can enable the hover state for that element and when you enable a hover element then the CSS changes because it's had the hover state applied to it. So here we can change that background from 3 through 3 to something like hot pink. Notice again the color just to the left of background has changed as a manipulation which has happened here to our CSS and now that's been applied across the document and we can switch the hover state on and off. It's very useful when you're trying to do CSS debugging specifically when you're dealing with pseudo states like hover and things like followed or visited on Horeff links as well. So that's kind of some of the newer features around the DOM Explorer. So next up is some of the stuff we've done with JavaScript. Now with JavaScript for a long while you've been able to add breakpoints, watches to your JavaScript code. You can debug it, you can go in there, you can have a look at variables, you can expand collections, you can look at objects and so forth. But one of the complications that we have in this modern world is that a lot of the JavaScript we have on our web page is not our own JavaScript. It's actually other people's JavaScript. So we might be using Angular, we might be using jQuery. And when you're trying to debug that stuff it's very, very difficult to figure out what's your code and what's in these libraries. And inevitably the bugs probably exist in your code and not the libraries. So while we're trying to sort of step through this code and breakpoint through this code, what we want to try and do is create a way of just debugging your code rather than debugging jQuery, a minified version of jQuery. So we added this feature called Just My Code which C Sharp developers might recognize from Visual Studio. So the actual team which work on the DevTools in IE now are actually part of the Visual Studio team. They're the same people which build the tools for the Windows 8 JavaScript applications. So if you've seen these tools, the F12 tools, they actually exist directly embedded inside of Visual Studio as well. It's all built by the same team, whereas it used to be built by Internet Explorer. So for example, here we go, we have a, in the inside of the debugger we have a breakpoint and on the NDC website and we put it onto a function called setPopup. And you see as I step through it, I end up in this library, jQuery 1.8.2, an old version of jQuery. And you'll notice as I step through this code, I'm just ending up in this sort of, I'm not in my code anymore, I don't even know where I am, I'm in this sort of world of jQuery, very clever stuff but I've got no idea what it is. So I can press this one which says debug my own code. And then if I play this again, what you'll note is we step through it and we end up back in jQuery again. Because at the moment, they're not using a minified version of jQuery, so the IE's not picking up as different code. So we use this little tool here and say actually this piece of code is actually an external library and then we restart that code again and then this time when we step through and play, we'll refresh the website, what will happen is we will only step through our code and we won't actually end up inside of jQuery. So it's your only stepping through code which is your own code, you're not stepping through other libraries and so forth. And I mentioned this a moment ago that how do we know which libraries are there? There's some basic sort of pattern matching in there which says if it contains.min, i.e. it's a minified version file, then it will set it automatically as it's not your code. And there's a few other rules as well. But generally you're going to be going in here and you're going to be setting these files as in this instance, this jQuery file, it doesn't belong to me or it's done by some other developer on my team. I don't need to debug that, I just need to debug my own code. And this is quite useful because not only is it stopping that idea of as you're stepping through code, it's also stopping any frames appearing in the call stack as well from their code. So their code will just have one single frame rather than all of the different deep calls that it might have in the call stack, it will just have one single frame. Also, any first-chance exceptions, so for example you can in the debugger switch on first-chance exceptions to kind of debug things like where you might have something which is contained in a try-catch block. And you could switch on first-chance exceptions so that it will always break, even though it's catched, it will still break because you want it to be debugging something there. But when you have just my code enabled, all those exceptions are only going to be thrown if they belong to your code and not if they are in other libraries. Because other libraries might be using sort of featured detection to do this sort of stuff as well. So things, it's not just the step through and the debugging, it's also first-chance exceptions and so forth as well. Another new feature we've added, there's a community project called Source Maps. Google have had this for a little while and the idea is in modern web development you're often not developing standard JavaScript or standard CSS anymore. You're often using abstractions like less or abstractions like TypeScript or CoffeeScript to produce your JavaScript. And the problem arises is you're writing, say, your CoffeeScript file and it has all your clever little properties and methods and so forth in it. But then when it actually goes into production or onto the actual website and you're using developer tools, you're dealing with the outputted JavaScript of those tools. You're not dealing with CoffeeScript, you're not dealing with TypeScript, you're dealing with the output of those tools. And for a developer which has never seen that output, it could be quite confusing. TypeScript doesn't offer a lot of things for you which you don't necessarily need to know as a developer. So when you're trying to debug it, it can become very confusing. So this concept of Source Maps became a, so it's not a standard but it's a community project which was started outside of Internet Explorer. And all it does really is a way of saying between two files, if you're at point X in one file, what's the relationship between another file? So if I'm in a TypeScript file and I'm at line 15, what line is that actually in JavaScript on the other side? And what that means is that we can then sort of wire up debugging so that you can debug your own, your actual TypeScript rather than the sort of outputted JavaScript. So we'll take a look at that. So if we look at the TypeScript website, they actually have a Source Map enabled. And they have a JavaScript file and then they've got a TypeScript file which is linked up to it. And so if we, if this plays, they have this little thing at the bottom, like a little cloud which is actually done in Babylon.js. Okay. Don't know why that video is not playing. Well, there we go. So we've got a, on the TypeScript website, we've got these clouds which are running and that's actually generated by a TypeScript file. So if you go into the debugger, into the script files here, you'll see that there is a file called cloud.ts, not.js, it's.cloud.ts. So this is the TypeScript file which is used to then go and generate the JavaScript. And you can see you've got all of your TypeScript stuff in there. And we can actually add breakpoints now to TypeScript even though the website's dealing with JavaScript because of this source mapping functionality. So if I add a breakpoint in there, it breaks at that point even though the browser's sort of interpreting JavaScript, we're breaking inside of TypeScript. So we can debug in the code that we wrote rather than the code that was generated by the compiler, by the TypeScript compiler. And we can step through our code just as if we were using debugging JavaScript. And this will work with any kind of source mapped generated files. So TypeScript, when you compile it, there's a flag which you can say to generate a source map. There's lots of different languages, CoffeeScript and TypeScript being some of the most popular, but there's lots of different languages which use this. And the cool thing is when you're in a TypeScript file, you can press this button to switch off the TypeScript and just go back to vanilla JS. So you can sort of compare your original TypeScript to the output of JavaScript to that content. And it's doing this all using source maps. This is a feature which has been in Google Chrome for a little while now. And the same is true, obviously, as well of CoffeeScript. So it's exactly the same principle. We go into the file and rather than the TS file, we have a.coffee script if you're not aware, it's kind of like a Ruby-based syntax for generating JavaScript. And we can put breakpoints in there. And it's going to correspond with actually the breakpoints in real JavaScript. So we can inspect elements and so forth as well. And we can do the same thing about switching between the CoffeeScript and the output of JavaScript as well. So it's really useful if you're a CoffeeScript or TypeScript developer and you want to stay in that world rather than having to deal with the outputted JavaScript. It's really quite powerful. One of the big problems with IE11, the original tools, where you would often get yourself heavily involved in some debugging. And you would have breakpoints set up everywhere. You'd have watches and so forth set up everywhere. And you'd mistakenly close down the browser. And then if you opened it back up, all your watches, all of your breakpoints, had all disappeared. And you had to get yourself back into that position so you can start debugging again. One of the things we've added back in there is this persistence. So not only are we persisting the breakpoints and all of the watches that you might have created when you're debugging from the tools, it will also, all the tabs that you have open, all the documents that you have open in your tools will also start back up exactly where you left off. So if you're doing a lot of a big, huge project, it can be really, really beneficial. I also added a few different ways of navigating using the keyboard inside of the DevTools. So one which I commonly use is Control Shift F. And it's kind of just get me out of here. So you are debugging code and so forth. And you've got too far into deep. And you just want to restart the whole thing and restart the whole experience. You just press Control Shift F and it's like a refresh of the browser. It just goes back into the tools from clean. We've always had this feature to navigate between the different elements inside of the DevTools. So there's eight different tools inside of the DevTools. And you could say so Control 1, it would go to the first one. Control 2, it would go to the second one. And then on the third, it would go to the debugger. And you can, it's useful because actually that's quite a fiddly menu structure when you're using it specifically on a, specifically with a mouse and specifically when it's very short. And it's actually quite useful if you're doing, if you're using your keyboard, just to press Control 1, Contrast to get the DomExplorer up and so forth. One thing which we added with the new version is Control Brace. And Control Brace allows you to move up one or Control Close Brace allows you to move down. So it's just another way of moving up and down all the different tools there directly from the keyboard, which is quite useful. Whenever I show DevTools out to developers who have been using Chrome DevTools, one of the things they would always complain about was our console.log functionality. If in JavaScript you want to log an object, for example, you would say console.log and you would say, I don't know, console.log window or console.log body. In Chrome, you would get a full object tree of body or you get a full, whatever you passing you would get that as an object, i.e. previously would convert that into a string literal and you'd just get object object. And it would be absolutely, it would be kind of useless. So we fixed that. So you can say console.log, throwing any object and then you can inspect that object at any time. And it's useful, you know, if you're, if you've got properties which hand around in the global namespace and you want to inspect them, you can just console.log put your object through and see that. We went a little bit further than that as well and we've labelled the ability to add multiple objects. So you can console.log and then send an array, well, a list, sorry, of objects. And it's going to be two, it can be three or it can be four. And what's outputted is you have a, you will get a sort of array, a node array of all of the different objects so you can inspect them separately. And it's quite useful if you've just, you know, you don't want to, you know, a quick look up of a lot of objects at once and just get them all on screen so that you can inspect them. So for messaging or writing messages out to the console, this can be quite useful, is the ability to console.log a string. So if you've ever done string formatting in C sharp, it's kind of a slightly rudimentary way of doing a string.format where you go console.log and you pass in a string and then you have these sort of percentage s and percentage s here. And that relates to the first object and the second object. And what it will do is it will just to string those objects and put them into the string. So you end up with this, oh wow, it's percentage s and I'm reading percentage s and I'm passing in date and document title. You end up with those objects all put out in a string. Oh wow, it's Thursday, Jan 5th, I did this yesterday and I'm reading the document title which is NDC Oslo. Useful as well because not only does it give you the string, it also gives you the objects as well. And so you can go into them and check them out as well. You don't just end up with a string, you also end up with the object. So console.log has been massively improved. There was also a terrible thing that we did in IE 8 and IE 9 which was completely different to other browsers, whereas if you called console.log from your website and the dev tools were not open, you would throw an error. Did anyone ever get caught by that issue? It's in production for me. I put stuff like console.log in my websites all the time and then it would stop working in IE for some reason. It was just because console was always an object on every other vendor's browser tools but on ours it wasn't. I think we solved that in around IE 9 but what we now do is allow you to, when you console.log anything, if you have this setting set which is inside of your internet options, always record developer console messages, even if you haven't got the tools open it's always going to be logging console.log. So if you went to a website and there was a ton of console.logs which happened and then you opened the tools, you'll still see those console.logs appear in your console. So you don't have to then go and refresh the page. All that stuff is recorded and that picture is some old logging. Never mind. When we are working with, we're all using jQuery now, right? One uses jQuery and it's really dull to write document.getElement by ID over and over again when you can just use this beautiful little dollar sign everywhere. If you're obviously working on a website which has got jQuery, you can just inside the console put the dollar sign and use it, use the shizzle selector to your heart's content. But if you don't, all the other browsers to manufacturers enabled to still select elements by ID using the dollar sign and IE never used to. We added I think in IE 11. So you can just say dollar and then pass a selector or an ID of an element ID and it's going to return the object which it matches. Another one which is quite useful is dollar underscore which returns whatever the last object was that you committed to the console. So in this instance we use dollar, dollar, H1. And dollar, dollar, H1 is another little dollar trick which will return an array of all the H1s on the document. So I've got all the whole array which is then returned is like this node list here and it's only actually got one in the actual whole document. And then I'm actually not sure that this is even helping with all this circling, never mind. And then we can use dollar underscore zero to return, it takes the last object and then it's the index, the zero index of that last object. And then that returns the H1 and then we can say dollar underscore dot inner HTML. So we can build upon an object again and again by getting the last object that we committed to the console. And the reason why we would do this rather than just writing all as one line string which would be dollar, dollar, H1, dot, index zero dot inner HTML is that there will be no way of the browser to resolve the intelligence of the object because it has to evaluate all of those selections up front. So by doing this, this way in parts, you're evaluating the objects, I'm gradually building them up and then you can still use intelligence on those objects. So dollar underscore, dollar, dollar, selection and dollar selection have all been added into IE tools to kind of bring us up to par with what other developer tools are doing and it makes it very easy to select all elements and objects from Internet Explorer. But developer tools are not just about debugging your application. In fact, that's the thing that most people will use DevTools for, right? Like the reason why you would pick up IE DevTools would probably be because someone's reported a bug in IE and it's not happening in other browsers so their DevTools are useless because it's only happening in IE. However, there are a number of features that have been added to our DevTools which actually aren't really about debugging necessarily, but also can actually help you improve performance of your web page. And performance really matters nowadays because we're building websites not just for desktops and for powerful Intel Slates and computers and laptops. We're actually building them for mobile phone devices which actually have very restricted hardware. And so it's important to think about things like network, memory and power consumption of your code so that you can deliver an experience which is really good for your users. When you think about network, we have a networking tool and it shows us all of the networking things that happen. It shows you all of the sort of requests that are made and you can calculate how long the requests make and that's a very useful tool and you might see that in Chrome. And you can see that in IE as well and it's in Firefox and all the major tools. And that's really useful because it helps us understand what the band, how much is actually getting passed through the pipes and what's getting passed through the pipes. It can also help us understand latency as well. How far are things going? Are we having to go to America to go and pick up that image? Are we going to China to pick up that JavaScript file? And understanding those things and doing a network trace is really useful to kind of solve some of these problems and figure out why a website is not performing well. It might be down to some kind of network problem. If we look at the performance of a website, actually we can do an awful lot to improve the perceived performance of a website just by doing some clever ways of understanding our website and understanding how it works and getting the user content on the screen very, very quickly. So, for example, a web page might take 1.81 seconds to load in its entirety from where the browser considers it completely loaded. But in this particular page, the actual times of glass or the time which we actually put something on the screen is 0.65 seconds. And that's really the thing that counts because that's the perceived performance of that website. And there's a lot of ways and there's a lot of these developer tools inside of Internet Explorer now are helping you to discover how you can get this perceived performance improved, not just overall page load times, but actually how we can make it feel like it's faster as well. We'll see that on this trace particularly there's CPU time of 1.39 seconds. That means there's an idle CPU time of 0.42 seconds which we could benefit if we understood how our website is working and why and how we're using CPU, we could improve this even further and we could reduce the overall load times of this web page by using having better CPU utilization. One of the biggest problems which happen with specifically single page applications is memory utilization. And one of the biggest problems that we face with memory utilization is images. It seems ridiculous. It's not problems of creating too many objects on the window. It's just using far too many images because every image is decoded and then put onto the stack, on the memory stack. And this is a hockey stick graph of 5,000 websites and we traced each of those memory, the memory footprint of each of the top 5,000 websites. And what you'll notice is that most are kind of under a 20 meg, most websites. And then you've got this small selection of websites which go up to all the way to like 180, 200 megabytes of image memory just to load on a single web page, on a single page. And this happens quite a lot. This is one of the biggest problems when people come to us with performance problems with their websites. It's often just misuse of images and overuse of images. So understanding memory and how you're using your memory in your application is really important as well. And the other thing is power consumption. Obviously people are using mobile devices and they are less likely to use applications which drain their battery. And it's probably easier than you think to drain someone's battery. Say for example you're writing a HTML5 application for this phone and it was like a GPS sat nav kind of application. Okay, so if you're a sat nav you're going to need to go to the GPS so you're going to have to enable the antenna. So that's probably going to be using like 2 watts of electricity or something like that. And then you're going to be taking some images, some map tiles and you're going to be loading them on the GPU and you're going to be loading them on the website. So you're going to be using the GPU, that's going to be an extra watts or 3 watts. And then maybe because there's quite a lot of computation which is going on you're going to be using an extra core in that device as well. That could be an extra couple of watts as well. Soon you're up to like 5 watts of electricity, the maximum that a phone can use. And all of a sudden your phone starts getting really hot because you're using all of the features of this phone. It's very easy in a single page application to start using loads and loads of features. You're starting using the antenna, you're starting using the GPU, you're starting using multi-cores. All of a sudden the phone's getting really, really hot. And it's getting really hot and the battery is draining. So what the most users do, well they take their phone and they plug it in. Because it's a sat nav they'll probably be able to plug it into their car and it's fine. But it's not fine because the phone is getting really hot. It sort of enables thermal mitigation and it says I'm too hot, I'm too hot to charge. So it stops charging because it's a way of reducing the heat on the phone. It's still running your application, it's still draining the application. And you end up in a situation where the phone just dies because you were trying to do some very complicated stuff continuously using a very low powered device. And that device will eventually run out of battery because it's trying to keep itself cool. And it won't charge when it's trying to keep itself cool. So understanding how you're using or how many of the subsystems you're using and what you're doing with your web application is really important. Not just for memory, not just for speed, but also for power consumption as well. And really performance in a website isn't just about being fast, it's also about being efficient. If we look at the way that the web works or the way a browser works and what it does. So we start off, make a request for a web page as networking, DNS translations, all that sort of thing. We actually go and get the files, all the different references. I think there's something like 94 in an average payload, there's 94 requests that go off. 94 requests that go off, we can actually only service for the same DNS name, same domain name, we can only service six of those at a time. We can't do, so if they all came off the same domain, we wouldn't be able, they would block, we'd do it in batches of six and they would block and block and block. So if you're spreading across different DNS names and so forth, that's useful, a way of improving the network performance potentially. But then the more different domains that you have, the more DNS lookups that you have. And so networking isn't as simple as just using a CDN, it can be more complicated than, it's different depending on each website. Then we take all of those files and we pass them. So all your HTML or the CSS files and so forth, we pass all of those things and with the HTML thing, we create a DOM tree, a list of all the objects in the DOM. It has no recollection of the styles which are going to be applied at this point, it's just objects in a tree. We take the CSS cascade, which is all of the styles and so forth, we interpret JavaScript. It's important here that we have to interpret all of the JavaScript which is loaded into the page before we can move on to the next point because it could affect the DOM tree. There's DOM APIs which actually JavaScript is in the sandbox, these DOM APIs might come out of that sandbox and affect things in the system. And then once we've got all of this, we've got the CSS tree, we've got the DOM tree, we've got the CSS, we then can start formatting and applying to these DOM elements and all the formats. And then we know where things should be so we can start laying things out. And we lay them out as like rectangles on the screen. And then once we've laid out everything out, we know where everything should be, we know what colors it should be. It goes to a thing called a display tree. And IE is then ready to paint. Paint what it has in its display tree to the GPU, to the computer. And I say ready to paint because IE doesn't decide when it paints, the monitor decides when it paints because it has a refresh rate of say 60 hertz, it can repaint say every 16 milliseconds. So there's a hardware interrupt which goes back to IE through Windows and says, I'm ready to paint. Have you got a new display tree for me? And IE says, yes, I've got a new display tree, here you go. So it's quite important to correlate display trees with paints because if we're doing all this work of calculating the display tree and not painting it, that's all just wasted CPU cycles. And then we actually then go and paint that display tree when we get this hardware sync, v-sync we call them. When we get that, we can then paint it to the screen. And we composite all that information and we do lots of fancy tricks in IE. We do a lot more compositing in direct text than I think anyone else, practically everyone else. Most of we're basically painting surfaces using direct text. And then when we, so everything from text to SVGs to everything, even JPEGs now are all being, we're using direct text to paint those things. And then we, and then someone can actually go and edit that document or they could change it by manipulating the screen and so forth or changing, and then we have to go through this whole cycle again and again and again and again. And obviously this iterates and iterates and iterates and iterates and iterates and iterates. New DOM trees, new display trees, all of the time being created as things are changed and things are manipulated. Every time you manipulate, we have to create a new DOM tree because something has changed. And it's important to make sure that you don't create ones which are pointless because that's all just wasted CPU cycles. So if I go to something like, this is quite an interesting point where we paint these GPU surfaces, we paint these surfaces and then someone might use a touch device and they might pinch zoom. And what we do in Internet Explorer is we do, you can actually see how we're interacting directly with the bitmap on the GPU so this doesn't actually go back to the browser at all. So if I zoom in, you'll know that the arrow function, that text is really jaggy. As soon as I let go, it goes back to the display and it repaints the whole screen. But actually when I'm manipulating the screen there, I'm actually manipulating directly on the GPU. It's not going back to Internet Explorer to do any of that manipulation. It's only when I let go of the screen. And we do quite a lot of things like that which try and prove the overall performance by leveraging the GPU rather than having to do full repaints. And it means that when you're doing things like to semantically zoom or moving and zooming certain the site, you're not blocking the UI thread from doing other things. Okay, so how do we get intimate insight into what actually is happening here? That whole tree, how do we figure out what's going on there? Well, there's a thing called the event tracing for Windows and it logs events, it gives insights to the platform and it traces the CPU. And basically there are two tools, oops, there are two tools which kind of interrogate that information which comes out from that Windows system. One is the UI responsiveness tab on the F12 developer tools, which is at the top there. And the other is the Windows performance toolkit. And in the IE team, if you ever see any of the engineers doing performance debugging, they will use both one or either of these tools. They give slightly different results, they're intended for slightly different things. The F12 tools are the ones that we're going to look into. And I said earlier that the images are a real big problem in terms of using oversized images or using too many images. Well, this is two traces using that UI responsiveness tab, which we have done on a website called physicsafaster.io forward slash demos. It's called the right size image demo. And the top graph is a website which is taking all of the images and the images are much larger than their actual space and then they're resized by the browser. And this is quite a common technique now because of retina displays. People are just throwing up a very, very large image and then resizing it so it looks better on retina screens. But the problem you'll see is this kind of ton of blue in that top graph. And all of that blue, if I can zoom in, I don't know if I can. All of that blue you'll see on the thing here, on the key at the top, all that blue is image decoding. There's a ton of rendering, there's a ton of image decoding which is going on. And this green bar which runs across the bottom, that is visual throughput. So how often are you running at 60 frames per second? So a full green bar means you're running 60 frames per second and everywhere it dips, these little dips in the middle there and towards the end, all of the places where you're not managing to get to 60 frames per second. And so it basically means that the UI thread, if you're doing animations or anything like that and you haven't got 60 frames per second, it's going to potentially look a little bit jaggy or jumpy because you're not painting enough frames to the screen. So that image decoding, just by having oversized images is causing us problems here. And you'll see by using the right sized images on the bottom graph, we're saving nearly a third of the time. It's improved the speed of the website immensely just by using the right sized images because you're not making, and it's perceptually something you might not necessarily notice as a developer, but you've got to recognize that the browser is having to do a ton of work just to make those images the right size to display on the GPU. The other one is deferring script execution. This is, most people do this nowadays, but it's still, most people don't realize necessarily why they do it. Often people say, don't put script tags in the head of your document. And you can put them in the head of document, but just if you do, make sure that you mark them as async or put the script tags at the bottom of the document. And the reason why this improves performance so much is because every time the browser, any browser encounters JavaScript, by contract it has to execute the entirety of that JavaScript file. So it has to load it from wherever it is, bring it into the browser and then execute it because it could manipulate the DOM tree, it could manipulate the display tree. So you'll see on the first graph, there's this big chunk of white space where nothing's happening. And that's just loading the resource, loading the head, stopping the JavaScript file because that JavaScript file may contain something which edits the document. By putting it, that script file, that long loading script file at the bottom of the page, it will eventually load, but it isn't blocking our UI thread, it isn't blocking us from doing other stuff. So in this instance, I think there's an animation which is happening on the page. And the bottom trace is giving us whether those peaks are happening, that says doing our animation every sort of 16 milliseconds we're doing some kind of animation. And you'll note that the difference in speed is immense. So I'm able to get something happening, some animation happening on the screen on the bottom trace in 84 milliseconds, whereas on the top screen, it's happening in 438 milliseconds. So it's taking an awful lot of time, a lot longer. And the only change I'm making on that page is moving my scripts from my head to the bottom of my page. The other thing you often see a lot of people do is include too many frameworks. So you might have jQuery just to do selection when you could just maybe use document.getElement.id, or you might have Angular in there because you were going to use it but then you decided not to. Or you might have just modernize it but you don't actually do any feature detection. You often find that people will take boilerplate code, have tons and tons of JavaScript libraries in there, not necessarily use any of them, and then you get traces like this. And the top trace is just this C of orange. And that's C of orange's garbage collection. Because although you're not doing anything with those libraries that you've included in your web page, they're still creating objects, or they've created objects on the global namespace somewhere perhaps. And all that has to stay in memory somewhere. So if you've got lots of memory on the page and it's being used again and again, there's different things loading all the time, then garbage collection has to kick in. And every time garbage collection kicks in, it's going to be interrupting your UI thread, it's going to be interrupting your CPU. So that C of orange means every time, it just means basically if I was to look at this trace, it shows me that there's just far too much garbage collection going on. And so there's, for some reason, there's just far too many objects which are being, which need to be destroyed. We're getting to the upper limits of our memory. And for this demo, this example, this demo, the frameworks which are included don't actually do anything. They just initialize. And then, you know, we've got these memory problems already. So reducing the number of frameworks can really help. This is quite a complicated one to explain, but coalescing style and layout changes. So this is an example where on the left hand side, you see a little menu. And that menu is being controlled at the moment as I scroll. And that's not a particularly great way of doing it. And then this time, as I'm moving up and down, it's rather than being controlled by the scroll mechanism, on a specific frequency, it's updating the position and then using CSS3 animations to move the object. Now, the first instance where we're tying an element and then every time we scroll, there's a scroll event, we're moving that object, that's a very high definition input. There's tons of, every time you scroll, which could happen like every two or three milliseconds, you're basically saying to the DOM tree, what you had before, sorry, your display tree, what you had before is no good anymore. Throw that away and create a new display tree. Throw that away and create a new display tree because you're moving something on the document every, say, 10 milliseconds. But we're not actually drawing it to screen. So we're creating this display tree and we're not drawing it to screen, so it's all just wasted CPU cycles. So what you want to try and do is you want to link the work that you're going to be done and make sure that when we do work, it actually end up being painted on the screen. So rather than using an event for a wheel mouse event, for example, moving up and down, it would be better to use something like request animation frame, which is a JavaScript API, which fires basically an event every time we get this interrupt from the monitor. Every time we can print, we can paint the monitor, sorry, we're going to respond, request animation frame is going to throw up an event and say, I can paint now, you should create the tree now and then we can paint it. And the other thing which we did there, because that's not going to be, you're not going to get an animation nice and smooth, what we do is every, that request animation will fire, say, every 16 milliseconds or whatever the refresh rate in the monitor is. And as it fires, it's going to be in lots of different positions and we transition the object using CSS3 transitions. And the other benefit of doing that is that we offload all that animation rather than doing it in JavaScript, we're putting it into a, we're putting it into the GPUs work. So if we look at the trace of the first element and then the second element, the first element we're doing work, we're doing two lots of work, but only if one of them in that is getting painted. So all of that, the blocks of two, only one of those elements in that block of two is actually getting painted. So I think it's, I can't see that, never mind. So what you want to try and do is correlate or coalesce your style and layout changes so that they happen at the same time. The other benefit of this, if we're using, and this is a general rule as well, animation with CSS animations is far better than animations with JavaScript because we can take the animation, we can put it on the GPU and let that do it and leave our CPU to run our website. So if we look at the first trace on, this isn't using the DevTools, it's using that Windows performance analyzer. And it shows the CPU usage, the GPU utilization. And you'll notice that in the JavaScript animation, we're using the UI thread and the HTML render thread. But when we're using the animation just in CSS, we're only using stuff which is related to the GPU and scheduling for the GPU. We're not doing or blocking the HTML thread at all. So it's really useful when you're doing this work, using request animation frame rather than sort of set time out or timers or scroll wheels and making sure that you have CSS animations which transition things over as well. Another one quickly is when you're building websites and you're using images, it's very easy to just use PNGs. I use fireworks for all of my graphics and I export as PNG just out of a matter of fact. I never really thought about it much before. But there's actually a memory penalty to using PNG over JPEGs. And obviously if you're using alpha transparencies, then you have to use PNGs. But in the most cases, for just a standard image, you should be using JPEGs. And again, that build website, we took the one website which had PNGs and one which had JPEGs, exactly the same dimensions these images, but they were just different image formats. And we used the memory tool. And the memory tool in the F12 tools allows you to take a snapshot of the memory stack of the memory heap and we can say how many objects, how many JavaScript objects are in that thing at that time. And then we can take a second snapshot and we can see how many objects are in it at that time. And we can see the delta if there's more objects being added or less objects that have been added. And we can keep taking snapshots after snapshots and then comparing them with different things. So we can have a look and see how memory usage has changed over time. So this tool is very useful for seeing memory leaks, for example. If something is constantly creating objects in memory, we will spot it using this memory tool by profiling. But here I'm using it just purely to say, okay, we took a snapshot using PNGs and we've got 8.6 megabytes of memory, decoded memory. And then if we just use JPEGs, exactly the same images, it looks exactly the same. We've now got half of that, that's 3.59 megabytes. So there's a massive amount of saving in memory that you get from using something like JPEG over PNG. It's important to remember that when you're thinking about an image, it's not necessarily the image on disk which you're calculating. So for example, you might have a 557kb disk image, but the memory usage of that image to keep that in memory is actually the width of the image roughly, the width of the image times by the height of the image times by 4. So that 557kb image is actually 2.67 megabytes when it's decoded. So you don't need many of those to start getting to quite a lot of images inside of memory. And people don't necessarily realize this, I don't think, when they're building their applications. So the way that we deal with when we're trying to display an image inside of Internet Explorer, a request goes out for that image and some of it's received, it's like a stream. And so we start decoding some of it. Then more of it's decoded and decoded. It gradually streams in and we start decoding. And then we process that code and then we copy the elements of the GPU. And then we finally paint it to screen. And so we can see over here on the CPU thread we've got various bits of work, the actual color coding from, I've just realized on there. But say the UI thread is meant to be pink in here, but it's meant to be blue. So that blue section is the UI thread and then the green section is the decoding. So it's doing some stuff on the UI thread, it's then doing some decoding work. There's the decoding work. And then we have this weird space where it's not doing anything on the CPU and it's not doing anything on the GPU and there's just blank space on both. And what's actually happening here is we're making a copy from the CPU to the GPU. So we're taking the image and we're copying the GPU. Now you might be thinking, well, on a modern laptop that's not really a problem because memory bus is really fast and you can do that really, really quickly. But on low-end mobile phones it can be like six megabytes per second. So we could theoretically get to a point where to copy that image, that 2.97 megabyte image on a low-end phone might take half a second to copy it from memory to the GPU. And you start realizing on low-powered mobile phones images and the heavy use of images can really make a browser on a mobile phone appallingly slow. And it's actually getting down to memory bus speeds, which is kind of mind-blowing really. No one ever really thinks about that when you're designing websites. But you start seeing this stuff in the Web Performance Analyzer. I won't go through any more of this to others to say in IE 11 we've added features to try and improve this slightly, try and improve performance of JPEGs, I think by about 40% ahead of what we had in IE 10, because we've actually realized that we can do a lot of the processing and decoding together on the GPU rather than in CPU. So the IE 10 model is where we do the processing separately, then we copy it to the GPU. We actually do a copy to the GPU, do the processing on the GPU for JPEG decoding. So JPEGs are genuinely, genuinely smaller in memory, but also in IE 11 specifically, we've also got 30%, 40% speed increases in terms of using JPEGs as well. So on IE specifically, there's a really good reason to use JPEGs as well. But I think the important thing when you're looking at these tools and creating websites and using these tools to kind of debug your websites, you start realizing that we're no longer just creating websites for these very high-powered machines. We're not just limited by bandwidth and network, it's a whole orchestra of all these different subsystems working together. It's very, very complicated, and we're trying to deliver these tools to give you insight and to enable you to kind of debug your websites, to get insight into how you can improve performance to your page as well. I think when you're developing websites, a lot of people think about designing first for mobile, but I think you should be thinking about performance optimization for mobile as well. Think about how much you're using in terms of memory. Just check on your website using the memory analyzer, how much memory you're using, what's your memory footprint. Because it might not sound too bad if you're using only 20 megs of memory, but lots of people have multiple tabs open on, even on mobile phones nowadays, you can have multiple tabs open in a browser. And if you're 20 meg in one tab and 20 in another, well, the browser, agile switching between those tabs is going to be switching that memory around. It's going to be saving it to disk, it's going to be bringing it back into memory, and you're going to be thrashing the hard drive. And it can be a case of actually reducing the lifespan of the hard drive or the storage on a phone just by thrashing it by moving stuff back and forth from memory and using poor memory management. So think about mobile first when you're designing websites and thinking about low-powered hardware and using these tools to try and get some insight into that. Up until very recently, that was a bit of a problem on something like Windows Phone because we didn't have any tools to give you that. You can now, if you've got Visual Studio and Windows 8.1 phone and IE 11 installed on the phone, you can use Visual Studio to debug websites on those phones as well. So you can either do this in the emulator or you can actually plug in a device and use that. But you go to the debug menu, other debug targets, and then debug Windows Phone into the Explorer. It will bring up a dialog box. And then all of the tools that I showed, kind of the memory, the DOM Explorer, all of those things will work as well on the browser on here. So it doesn't have to be your code, it could be any website, and you can sort of start interrogating your mobile phones as well. That's kind of it. It's a whistle-top-store, whistle-stop tour of the developer tools. And I hope that you kind of will look at those tools and see that we're trying to do some interesting things, not just to help you debug websites, but also improve performance. So if you are interested at all in looking at the tools in more detail, I'll be at the stand, the IE or the Windows stand, all the rest of today. And please come along with your websites and we can have a look at the performance of them. So thank you very much. Okay. If anyone's got any questions, I don't know if anyone's got any questions. We've got five minutes left. I have no idea. Let's try it. I don't know how it works on the Norwegian Coreboard Keyboard. We can try. But yeah, I hope there's a different key mapping, but I don't know. So there's a question. Browser mode. Yeah. You can change the IE version down to IE 7. IE 7. So the question is, have we brought back browser mode? Yes, you can emulate IE 7, IE 8, IE 9, IE 10, and IE 11 using the tools. Obviously some of the tools like the memory analyzer won't work when you're trying to debug in IE 7 emulation. But you can use that. So the question is, in conditional, do we support conditional comments? Yeah. I think conditional comments should now be included in the DevTools. Because we stopped conditional comments in IE 10 to comply with the HTML5 rendering specification. But yeah, I think if you change the emulation mode, it will still take in consideration conditional comments. Yeah. I'll check that. But I'm pretty sure it does. Yeah. I don't know. Do you use that what you use, your Dev Machine to run? So you want to run IE 11 on 70,000. Yeah. To get these tools working, there's a whole lot of plumbing which requires IE 11. So these DevTools will only work in IE 11. You could use, I don't know if the, try, you could install Visual Studio and see if the DevTools works through that. I don't know. Yeah. You need IE 11 to get these DevTools working. Anymore? Thank you very much.
 Hello, everybody. Hello, that one last guy just coming in. Come in. There's plenty of  seats. I'm Martin Beebe. I'm from the UK. Anyone from the UK? Not many. Okay. I'm a  developer evangelist in the developer relations team over there. I'm speaking about Internet  Explorer F12 developer tools. Is everyone okay with that? Is that what you've come  for? Good, good. And so we're going to be talking about the kinds of things which are  new in the sort of tools. It's not going to be a 101 necessarily of our tools. It's going  to be showing you the things that are new since the April release and a few things which  I think are really interesting when you're trying to debug and look at performance in  your website. And so we're going to be looking at a few things around the tools. The things  that you can do with those F12 tools. We'll look at the web runtime architecture so we  can see the places that we may need to optimize in our own web applications and the way that  we can use those tools to get that to optimize it. And then we'll look at some real world  demos, some real world problems which we will have traced using these tools. I do a lot  of debugging. I've been a web developer for over 12 years. This is me when I was 16. I  do a lot of debugging. It's only two years ago. Actually 18 years old now. And it's really  frustrating. Debugging is one of the worst parts of web development in my opinion. And  to be honest, the Internet Explorer DevTools have never really been very good up until  there was a mark change in IE9 around funding and development inside of them. But they got  a little bit better with IE10 and they've got a lot better with IE11 where we're kind  of catching up to what our competition are doing in terms of developer tools. But also  in some small areas, actually doing things differently from them and giving you more  insight into the Dev Platform in different ways from our competitors, which is interesting.  One of the things that's really quite interesting or cool about the new F12 tools is that the  release that they just shipped, which was in April, was sort of out of band. Like they  did an IE11 release back in November or something like that. And then they shipped again the  tools just back in April. So they're shipping the DevTools in a much more sort of regular  cadence, which is really interesting. They're adding new features out of band of IE11.  So the actual DevTools that you will have got, you will have if you have IE11 installed  on your machine, should have been updated back in April to this version that we're  going to be talking about today. All of the updating in IE now happens silently in the  same way that it does with other browsers. So we should be seeing people move more quickly  up the chain and to the newer browsers. And also this is quite interesting. There's these  new tools, but also like WebGL features as well, were dropped in between releases. So  it's quite interesting that seeing that team working in a more agile kind of way. How many  people have not seen the F12 tools before? Have never opened in an Explorer 11 and seen  these tools. One person. If you've ever seen any other browser developers, browser vendors  tools, it does very similar things. You can select elements, you can look at the CSS,  you can choose to manipulate the DOM. There's eight different tools in total. And maybe  if I use this, I could probably do this a little bit easier. These tools along the side,  does that come out? There's eight tools in total. We've got DOM explorers, we've got memory  profilers, we've got CSS editors. We've got all sorts of different things in the chain  of what we're able to do. And I'm going to talk about the things which are kind of new  in the developer tools. So first up we have one thing to point out is that these tools  are in IE 11 across Windows 8.1 and across Windows 7 as well. It's not specific to the  latest version of Windows. It's also on Windows 7. So any version of Windows IE 11 will be  updatable to these tools. So you can get these on Windows 7 as well.  So this is the NDC website. And we're going to look at this area where we've got this  purple section. I'm going to change that background color by just selecting that element and then  just changing it to 336699 which is hotmail blue. Or we can just choose from the images,  choose from different colors, sorry, can choose and settle upon maybe. This is your, weirdly  is not, it's your mind. Click on something like blue violet. So we can change a background  property of an element quite simply. There you would expect that to be able to be done.  We can go over here and we can select the, to delete an item. And you'll notice as I'm  changing these elements there's a very small color to the side of the property which indicates  that this has been changed. There's been some kind of manipulation done on this. And we  only just added this in the latest version of the tools and it just shows all the changes  between versions. And we can see here a delta between what I originally had in our CSS and  this is a sort of diff file. We can then just go into that changes tab, cut and paste those  CSS changes and then paste them into an editor. I'm just going to paste them into the console  here. But you'll see as you make those manipulations and CSS changes directly inside of the CSS  editor you can then go to the new changes tab and you can directly cut and paste those  changes and put them back into your editor and back into your website. It was quite hard  to do that in the previous tools. You would make these changes, you'd do lots of different  manipulations and so forth and then it was difficult to actually go and get that stuff  and put it back into your website. And this enables that and makes it slightly easier.  Another really simple feature that I've added to the DOM is the ability to reorder the DOM  and manipulate the DOM at will. So we can sort of drag elements around the DOM using  the DOM Explorer. So if I were to select an element here and bring up the F12 tools I  can take a div, like the bottom div, the bottom section of this website and I can drag and  drop it to different sections. So you can manipulate the DOM, you can edit the DOM,  you could add elements, you can delete elements, you can move elements around. All kind of  basic kind of simple stuff. One of the problems that we used to have a lot inside of IE 11  tools or something which was a constant sort of request or feature request was when you  are editing CSS elements and they have pseudo states like hover states. It's very, very  difficult to work on that CSS because it's difficult to hover over an element and check  its CSS properties without having too much. So what we've done is I've given you the  ability to scroll over, say on the bottom of the NDC site you have these little elements  which you, as you scroll over on the bottom and they change and their background color  changes slightly. What you can do is you can select one of those elements and then if you  press this little A colon which is just up in the corner here, you can click on that  and then you can enable the hover state for that element and when you enable a hover element  then the CSS changes because it's had the hover state applied to it. So here we can  change that background from 3 through 3 to something like hot pink. Notice again the  color just to the left of background has changed as a manipulation which has happened here  to our CSS and now that's been applied across the document and we can switch the hover  state on and off. It's very useful when you're trying to do CSS debugging specifically when  you're dealing with pseudo states like hover and things like followed or visited on Horeff  links as well. So that's kind of some of the newer features around the DOM Explorer.  So next up is some of the stuff we've done with JavaScript. Now with JavaScript for a  long while you've been able to add breakpoints, watches to your JavaScript code. You can debug  it, you can go in there, you can have a look at variables, you can expand collections,  you can look at objects and so forth. But one of the complications that we have in this  modern world is that a lot of the JavaScript we have on our web page is not our own JavaScript.  It's actually other people's JavaScript. So we might be using Angular, we might be using  jQuery. And when you're trying to debug that stuff it's very, very difficult to figure  out what's your code and what's in these libraries. And inevitably the bugs probably exist in  your code and not the libraries. So while we're trying to sort of step through this code and  breakpoint through this code, what we want to try and do is create a way of just debugging  your code rather than debugging jQuery, a minified version of jQuery. So we added this  feature called Just My Code which C Sharp developers might recognize from Visual Studio.  So the actual team which work on the DevTools in IE now are actually part of the Visual  Studio team. They're the same people which build the tools for the Windows 8 JavaScript  applications. So if you've seen these tools, the F12 tools, they actually exist directly  embedded inside of Visual Studio as well. It's all built by the same team, whereas it  used to be built by Internet Explorer. So for example, here we go, we have a, in the  inside of the debugger we have a breakpoint and on the NDC website and we put it onto  a function called setPopup. And you see as I step through it, I end up in this library,  jQuery 1.8.2, an old version of jQuery. And you'll notice as I step through this code,  I'm just ending up in this sort of, I'm not in my code anymore, I don't even know where  I am, I'm in this sort of world of jQuery, very clever stuff but I've got no idea what  it is. So I can press this one which says debug my own code. And then if I play this  again, what you'll note is we step through it and we end up back in jQuery again. Because  at the moment, they're not using a minified version of jQuery, so the IE's not picking  up as different code. So we use this little tool here and say actually this piece of code  is actually an external library and then we restart that code again and then this time  when we step through and play, we'll refresh the website, what will happen is we will only  step through our code and we won't actually end up inside of jQuery. So it's your only  stepping through code which is your own code, you're not stepping through other libraries  and so forth. And I mentioned this a moment ago that how do we know which libraries are  there? There's some basic sort of pattern matching in there which says if it contains .min, i.e. it's a minified version file, then it will set it automatically as it's not  your code. And there's a few other rules as well. But generally you're going to be going  in here and you're going to be setting these files as in this instance, this jQuery file,  it doesn't belong to me or it's done by some other developer on my team. I don't need to  debug that, I just need to debug my own code. And this is quite useful because not only  is it stopping that idea of as you're stepping through code, it's also stopping any frames  appearing in the call stack as well from their code. So their code will just have one single  frame rather than all of the different deep calls that it might have in the call stack,  it will just have one single frame. Also, any first-chance exceptions, so for example  you can in the debugger switch on first-chance exceptions to kind of debug things like where  you might have something which is contained in a try-catch block. And you could switch  on first-chance exceptions so that it will always break, even though it's catched, it  will still break because you want it to be debugging something there. But when you have  just my code enabled, all those exceptions are only going to be thrown if they belong  to your code and not if they are in other libraries. Because other libraries might be  using sort of featured detection to do this sort of stuff as well. So things, it's not  just the step through and the debugging, it's also first-chance exceptions and so forth  as well. Another new feature we've added, there's a community project called Source  Maps. Google have had this for a little while and the idea is in modern web development  you're often not developing standard JavaScript or standard CSS anymore. You're often using  abstractions like less or abstractions like TypeScript or CoffeeScript to produce your  JavaScript. And the problem arises is you're writing, say, your CoffeeScript file and it  has all your clever little properties and methods and so forth in it. But then when it  actually goes into production or onto the actual website and you're using developer  tools, you're dealing with the outputted JavaScript of those tools. You're not dealing with  CoffeeScript, you're not dealing with TypeScript, you're dealing with the output of those tools.  And for a developer which has never seen that output, it could be quite confusing. TypeScript  doesn't offer a lot of things for you which you don't necessarily need to know as a developer.  So when you're trying to debug it, it can become very confusing. So this concept of  Source Maps became a, so it's not a standard but it's a community project which was started  outside of Internet Explorer. And all it does really is a way of saying between two files,  if you're at point X in one file, what's the relationship between another file? So if  I'm in a TypeScript file and I'm at line 15, what line is that actually in JavaScript  on the other side? And what that means is that we can then sort of wire up debugging  so that you can debug your own, your actual TypeScript rather than the sort of outputted  JavaScript. So we'll take a look at that. So if we look at the TypeScript website, they  actually have a Source Map enabled. And they have a JavaScript file and then they've got  a TypeScript file which is linked up to it. And so if we, if this plays, they have this  little thing at the bottom, like a little cloud which is actually done in Babylon.js.  Okay. Don't know why that video is not playing. Well, there we go. So we've got a, on the  TypeScript website, we've got these clouds which are running and that's actually generated  by a TypeScript file. So if you go into the debugger, into the script files here, you'll  see that there is a file called cloud.ts, not.js, it's.cloud.ts. So this is the TypeScript  file which is used to then go and generate the JavaScript. And you can see you've got  all of your TypeScript stuff in there. And we can actually add breakpoints now to TypeScript  even though the website's dealing with JavaScript because of this source mapping functionality.  So if I add a breakpoint in there, it breaks at that point even though the browser's sort  of interpreting JavaScript, we're breaking inside of TypeScript. So we can debug in the  code that we wrote rather than the code that was generated by the compiler, by the TypeScript  compiler. And we can step through our code just as if we were using debugging JavaScript.  And this will work with any kind of source mapped generated files. So TypeScript, when  you compile it, there's a flag which you can say to generate a source map. There's lots  of different languages, CoffeeScript and TypeScript being some of the most popular, but there's  lots of different languages which use this. And the cool thing is when you're in a TypeScript  file, you can press this button to switch off the TypeScript and just go back to vanilla  JS. So you can sort of compare your original TypeScript to the output of JavaScript to that  content. And it's doing this all using source maps. This is a feature which has been in  Google Chrome for a little while now. And the same is true, obviously, as well of CoffeeScript.  So it's exactly the same principle. We go into the file and rather than the TS file,  we have a.coffee script if you're not aware, it's kind of like a Ruby-based syntax for  generating JavaScript. And we can put breakpoints in there. And it's going to correspond with  actually the breakpoints in real JavaScript. So we can inspect elements and so forth as  well. And we can do the same thing about switching between the CoffeeScript and the  output of JavaScript as well. So it's really useful if you're a CoffeeScript or TypeScript  developer and you want to stay in that world rather than having to deal with the outputted  JavaScript. It's really quite powerful. One of the big problems with IE11, the original  tools, where you would often get yourself heavily involved in some debugging. And you  would have breakpoints set up everywhere. You'd have watches and so forth set up everywhere.  And you'd mistakenly close down the browser. And then if you opened it back up, all your  watches, all of your breakpoints, had all disappeared. And you had to get yourself back  into that position so you can start debugging again.  One of the things we've added back in there is this persistence. So not only are we persisting  the breakpoints and all of the watches that you might have created when you're debugging  from the tools, it will also, all the tabs that you have open, all the documents that  you have open in your tools will also start back up exactly where you left off. So if  you're doing a lot of a big, huge project, it can be really, really beneficial.  I also added a few different ways of navigating using the keyboard inside of the DevTools.  So one which I commonly use is Control Shift F. And it's kind of just get me out of here.  So you are debugging code and so forth. And you've got too far into deep. And you just  want to restart the whole thing and restart the whole experience. You just press Control  Shift F and it's like a refresh of the browser. It just goes back into the tools from clean.  We've always had this feature to navigate between the different elements inside of the  DevTools. So there's eight different tools inside of the DevTools. And you could say  so Control 1, it would go to the first one. Control 2, it would go to the second one.  And then on the third, it would go to the debugger. And you can, it's useful because  actually that's quite a fiddly menu structure when you're using it specifically on a, specifically  with a mouse and specifically when it's very short. And it's actually quite useful if you're  doing, if you're using your keyboard, just to press Control 1, Contrast to get the DomExplorer  up and so forth. One thing which we added with the new version is Control Brace. And  Control Brace allows you to move up one or Control Close Brace allows you to move down.  So it's just another way of moving up and down all the different tools there directly  from the keyboard, which is quite useful. Whenever I show DevTools out to developers  who have been using Chrome DevTools, one of the things they would always complain about  was our console.log functionality. If in JavaScript you want to log an object, for example, you  would say console.log and you would say, I don't know, console.log window or console.log  body. In Chrome, you would get a full object tree of body or you get a full, whatever you  passing you would get that as an object, i.e. previously would convert that into a string  literal and you'd just get object object. And it would be absolutely, it would be kind  of useless. So we fixed that. So you can say console.log, throwing any object and then  you can inspect that object at any time. And it's useful, you know, if you're, if you've  got properties which hand around in the global namespace and you want to inspect them, you  can just console.log put your object through and see that. We went a little bit further  than that as well and we've labelled the ability to add multiple objects. So you can console.log  and then send an array, well, a list, sorry, of objects. And it's going to be two, it can  be three or it can be four. And what's outputted is you have a, you will get a sort of array,  a node array of all of the different objects so you can inspect them separately. And it's  quite useful if you've just, you know, you don't want to, you know, a quick look up  of a lot of objects at once and just get them all on screen so that you can inspect them.  So for messaging or writing messages out to the console, this can be quite useful, is  the ability to console.log a string. So if you've ever done string formatting in C sharp,  it's kind of a slightly rudimentary way of doing a string.format where you go console.log  and you pass in a string and then you have these sort of percentage s and percentage  s here. And that relates to the first object and the second object. And what it will do  is it will just to string those objects and put them into the string. So you end up with  this, oh wow, it's percentage s and I'm reading percentage s and I'm passing in date and document  title. You end up with those objects all put out in a string. Oh wow, it's Thursday,  Jan 5th, I did this yesterday and I'm reading the document title which is NDC Oslo. Useful  as well because not only does it give you the string, it also gives you the objects  as well. And so you can go into them and check them out as well. You don't just end up with  a string, you also end up with the object. So console.log has been massively improved.  There was also a terrible thing that we did in IE 8 and IE 9 which was completely different  to other browsers, whereas if you called console.log from your website and the dev tools were not  open, you would throw an error. Did anyone ever get caught by that issue? It's in production  for me. I put stuff like console.log in my websites all the time and then it would stop  working in IE for some reason. It was just because console was always an object on every  other vendor's browser tools but on ours it wasn't. I think we solved that in around IE  9 but what we now do is allow you to, when you console.log anything, if you have this  setting set which is inside of your internet options, always record developer console messages,  even if you haven't got the tools open it's always going to be logging console.log. So  if you went to a website and there was a ton of console.logs which happened and then you  opened the tools, you'll still see those console.logs appear in your console. So you don't have  to then go and refresh the page. All that stuff is recorded and that picture is some  old logging. Never mind. When we are working with, we're all using jQuery now, right?  One uses jQuery and it's really dull to write document.getElement by ID over and over again  when you can just use this beautiful little dollar sign everywhere. If you're obviously  working on a website which has got jQuery, you can just inside the console put the dollar  sign and use it, use the shizzle selector to your heart's content. But if you don't,  all the other browsers to manufacturers enabled to still select elements by ID using the dollar  sign and IE never used to. We added I think in IE 11. So you can just say dollar and then  pass a selector or an ID of an element ID and it's going to return the object which it matches.  Another one which is quite useful is dollar underscore which returns whatever the last  object was that you committed to the console. So in this instance we use dollar, dollar,  H1. And dollar, dollar, H1 is another little dollar trick which will return an array of  all the H1s on the document. So I've got all the whole array which is then returned is  like this node list here and it's only actually got one in the actual whole document. And  then I'm actually not sure that this is even helping with all this circling, never mind.  And then we can use dollar underscore zero to return, it takes the last object and then  it's the index, the zero index of that last object. And then that returns the H1 and then  we can say dollar underscore dot inner HTML. So we can build upon an object again and again  by getting the last object that we committed to the console. And the reason why we would  do this rather than just writing all as one line string which would be dollar, dollar,  H1, dot, index zero dot inner HTML is that there will be no way of the browser to resolve  the intelligence of the object because it has to evaluate all of those selections up  front. So by doing this, this way in parts, you're evaluating the objects, I'm gradually  building them up and then you can still use intelligence on those objects. So dollar underscore,  dollar, dollar, selection and dollar selection have all been added into IE tools to kind  of bring us up to par with what other developer tools are doing and it makes it very easy  to select all elements and objects from Internet Explorer. But developer tools are not just  about debugging your application. In fact, that's the thing that most people will use  DevTools for, right? Like the reason why you would pick up IE DevTools would probably be  because someone's reported a bug in IE and it's not happening in other browsers so their  DevTools are useless because it's only happening in IE. However, there are a number of features  that have been added to our DevTools which actually aren't really about debugging necessarily,  but also can actually help you improve performance of your web page. And performance really matters  nowadays because we're building websites not just for desktops and for powerful Intel  Slates and computers and laptops. We're actually building them for mobile phone devices which  actually have very restricted hardware. And so it's important to think about things like  network, memory and power consumption of your code so that you can deliver an experience  which is really good for your users. When you think about network, we have a networking  tool and it shows us all of the networking things that happen. It shows you all of the  sort of requests that are made and you can calculate how long the requests make and that's  a very useful tool and you might see that in Chrome. And you can see that in IE as well  and it's in Firefox and all the major tools. And that's really useful because it helps  us understand what the band, how much is actually getting passed through the pipes and what's  getting passed through the pipes. It can also help us understand latency as well. How far  are things going? Are we having to go to America to go and pick up that image? Are we going  to China to pick up that JavaScript file? And understanding those things and doing a network  trace is really useful to kind of solve some of these problems and figure out why a website  is not performing well. It might be down to some kind of network problem. If we look at  the performance of a website, actually we can do an awful lot to improve the perceived  performance of a website just by doing some clever ways of understanding our website and  understanding how it works and getting the user content on the screen very, very quickly.  So, for example, a web page might take 1.81 seconds to load in its entirety from where  the browser considers it completely loaded. But in this particular page, the actual times  of glass or the time which we actually put something on the screen is 0.65 seconds. And  that's really the thing that counts because that's the perceived performance of that website.  And there's a lot of ways and there's a lot of these developer tools inside of Internet  Explorer now are helping you to discover how you can get this perceived performance improved,  not just overall page load times, but actually how we can make it feel like it's faster  as well. We'll see that on this trace particularly there's CPU time of 1.39 seconds. That means  there's an idle CPU time of 0.42 seconds which we could benefit if we understood how our  website is working and why and how we're using CPU, we could improve this even further and  we could reduce the overall load times of this web page by using having better CPU utilization.  One of the biggest problems which happen with specifically single page applications is memory  utilization. And one of the biggest problems that we face with memory utilization is images.  It seems ridiculous. It's not problems of creating too many objects on the window. It's  just using far too many images because every image is decoded and then put onto the stack,  on the memory stack. And this is a hockey stick graph of 5,000 websites and we traced  each of those memory, the memory footprint of each of the top 5,000 websites. And what  you'll notice is that most are kind of under a 20 meg, most websites. And then you've got  this small selection of websites which go up to all the way to like 180, 200 megabytes  of image memory just to load on a single web page, on a single page. And this happens  quite a lot. This is one of the biggest problems when people come to us with performance problems  with their websites. It's often just misuse of images and overuse of images. So understanding  memory and how you're using your memory in your application is really important as well.  And the other thing is power consumption. Obviously people are using mobile devices  and they are less likely to use applications which drain their battery. And it's probably  easier than you think to drain someone's battery. Say for example you're writing a HTML5 application  for this phone and it was like a GPS sat nav kind of application. Okay, so if you're  a sat nav you're going to need to go to the GPS so you're going to have to enable the  antenna. So that's probably going to be using like 2 watts of electricity or something like  that. And then you're going to be taking some images, some map tiles and you're going to  be loading them on the GPU and you're going to be loading them on the website. So you're  going to be using the GPU, that's going to be an extra watts or 3 watts. And then maybe  because there's quite a lot of computation which is going on you're going to be using  an extra core in that device as well. That could be an extra couple of watts as well.  Soon you're up to like 5 watts of electricity, the maximum that a phone can use. And all  of a sudden your phone starts getting really hot because you're using all of the features  of this phone. It's very easy in a single page application to start using loads and  loads of features. You're starting using the antenna, you're starting using the GPU, you're  starting using multi-cores. All of a sudden the phone's getting really, really hot. And  it's getting really hot and the battery is draining. So what the most users do, well  they take their phone and they plug it in. Because it's a sat nav they'll probably be  able to plug it into their car and it's fine. But it's not fine because the phone is getting  really hot. It sort of enables thermal mitigation and it says I'm too hot, I'm too hot to charge.  So it stops charging because it's a way of reducing the heat on the phone. It's still  running your application, it's still draining the application. And you end up in a situation  where the phone just dies because you were trying to do some very complicated stuff continuously  using a very low powered device. And that device will eventually run out of battery  because it's trying to keep itself cool. And it won't charge when it's trying to keep itself  cool. So understanding how you're using or how many of the subsystems you're using and  what you're doing with your web application is really important. Not just for memory,  not just for speed, but also for power consumption as well. And really performance in a website  isn't just about being fast, it's also about being efficient. If we look at the way that  the web works or the way a browser works and what it does. So we start off, make a request  for a web page as networking, DNS translations, all that sort of thing. We actually go and  get the files, all the different references. I think there's something like 94 in an average  payload, there's 94 requests that go off. 94 requests that go off, we can actually only  service for the same DNS name, same domain name, we can only service six of those at  a time. We can't do, so if they all came off the same domain, we wouldn't be able, they  would block, we'd do it in batches of six and they would block and block and block.  So if you're spreading across different DNS names and so forth, that's useful, a way of  improving the network performance potentially. But then the more different domains that you  have, the more DNS lookups that you have. And so networking isn't as simple as just using  a CDN, it can be more complicated than, it's different depending on each website.  Then we take all of those files and we pass them. So all your HTML or the CSS files and  so forth, we pass all of those things and with the HTML thing, we create a DOM tree,  a list of all the objects in the DOM. It has no recollection of the styles which are going  to be applied at this point, it's just objects in a tree. We take the CSS cascade, which  is all of the styles and so forth, we interpret JavaScript. It's important here that we have  to interpret all of the JavaScript which is loaded into the page before we can move on  to the next point because it could affect the DOM tree.  There's DOM APIs which actually JavaScript is in the sandbox, these DOM APIs might come  out of that sandbox and affect things in the system. And then once we've got all of this,  we've got the CSS tree, we've got the DOM tree, we've got the CSS, we then can start formatting  and applying to these DOM elements and all the formats. And then we know where things  should be so we can start laying things out. And we lay them out as like rectangles on  the screen. And then once we've laid out everything out, we know where everything should be, we  know what colors it should be. It goes to a thing called a display tree. And IE is then  ready to paint. Paint what it has in its display tree to the GPU, to the computer. And I say  ready to paint because IE doesn't decide when it paints, the monitor decides when it paints  because it has a refresh rate of say 60 hertz, it can repaint say every 16 milliseconds.  So there's a hardware interrupt which goes back to IE through Windows and says, I'm ready  to paint. Have you got a new display tree for me? And IE says, yes, I've got a new display  tree, here you go. So it's quite important to correlate display trees with paints because  if we're doing all this work of calculating the display tree and not painting it, that's  all just wasted CPU cycles. And then we actually then go and paint that display tree when we  get this hardware sync, v-sync we call them. When we get that, we can then paint it to  the screen. And we composite all that information and we do lots of fancy tricks in IE. We do  a lot more compositing in direct text than I think anyone else, practically everyone  else. Most of we're basically painting surfaces using direct text. And then when we, so everything  from text to SVGs to everything, even JPEGs now are all being, we're using direct text  to paint those things. And then we, and then someone can actually go and edit that document  or they could change it by manipulating the screen and so forth or changing, and then  we have to go through this whole cycle again and again and again and again. And obviously  this iterates and iterates and iterates and iterates and iterates and iterates. New DOM  trees, new display trees, all of the time being created as things are changed and things  are manipulated. Every time you manipulate, we have to create a new DOM tree because something  has changed. And it's important to make sure that you don't create ones which are pointless  because that's all just wasted CPU cycles. So if I go to something like, this is quite  an interesting point where we paint these GPU surfaces, we paint these surfaces and  then someone might use a touch device and they might pinch zoom. And what we do in Internet  Explorer is we do, you can actually see how we're interacting directly with the bitmap  on the GPU so this doesn't actually go back to the browser at all. So if I zoom in, you'll  know that the arrow function, that text is really jaggy. As soon as I let go, it goes  back to the display and it repaints the whole screen. But actually when I'm manipulating  the screen there, I'm actually manipulating directly on the GPU. It's not going back to  Internet Explorer to do any of that manipulation. It's only when I let go of the screen. And  we do quite a lot of things like that which try and prove the overall performance by leveraging  the GPU rather than having to do full repaints. And it means that when you're doing things  like to semantically zoom or moving and zooming certain the site, you're not blocking the  UI thread from doing other things. Okay, so how do we get intimate insight into what actually  is happening here? That whole tree, how do we figure out what's going on there? Well,  there's a thing called the event tracing for Windows and it logs events, it gives insights  to the platform and it traces the CPU. And basically there are two tools, oops, there  are two tools which kind of interrogate that information which comes out from that Windows  system. One is the UI responsiveness tab on the F12 developer tools, which is at the top  there. And the other is the Windows performance toolkit. And in the IE team, if you ever see  any of the engineers doing performance debugging, they will use both one or either of these  tools. They give slightly different results, they're intended for slightly different things.  The F12 tools are the ones that we're going to look into. And I said earlier that the  images are a real big problem in terms of using oversized images or using too many images.  Well, this is two traces using that UI responsiveness tab, which we have done on a website called  physicsafaster.io forward slash demos. It's called the right size image demo. And the  top graph is a website which is taking all of the images and the images are much larger  than their actual space and then they're resized by the browser. And this is quite a common  technique now because of retina displays. People are just throwing up a very, very large  image and then resizing it so it looks better on retina screens. But the problem you'll  see is this kind of ton of blue in that top graph. And all of that blue, if I can zoom  in, I don't know if I can. All of that blue you'll see on the thing here, on the key at  the top, all that blue is image decoding. There's a ton of rendering, there's a ton  of image decoding which is going on. And this green bar which runs across the bottom, that  is visual throughput. So how often are you running at 60 frames per second? So a full  green bar means you're running 60 frames per second and everywhere it dips, these little  dips in the middle there and towards the end, all of the places where you're not managing  to get to 60 frames per second. And so it basically means that the UI thread, if you're  doing animations or anything like that and you haven't got 60 frames per second, it's  going to potentially look a little bit jaggy or jumpy because you're not painting enough  frames to the screen. So that image decoding, just by having oversized images is causing  us problems here. And you'll see by using the right sized images on the bottom graph,  we're saving nearly a third of the time. It's improved the speed of the website immensely  just by using the right sized images because you're not making, and it's perceptually something  you might not necessarily notice as a developer, but you've got to recognize that the browser  is having to do a ton of work just to make those images the right size to display on  the GPU. The other one is deferring script execution. This is, most people do this nowadays,  but it's still, most people don't realize necessarily why they do it. Often people say,  don't put script tags in the head of your document. And you can put them in the head  of document, but just if you do, make sure that you mark them as async or put the script  tags at the bottom of the document. And the reason why this improves performance so much  is because every time the browser, any browser encounters JavaScript, by contract it has  to execute the entirety of that JavaScript file. So it has to load it from wherever it  is, bring it into the browser and then execute it because it could manipulate the DOM tree,  it could manipulate the display tree. So you'll see on the first graph, there's this big chunk  of white space where nothing's happening. And that's just loading the resource, loading  the head, stopping the JavaScript file because that JavaScript file may contain something  which edits the document. By putting it, that script file, that long loading script file  at the bottom of the page, it will eventually load, but it isn't blocking our UI thread,  it isn't blocking us from doing other stuff. So in this instance, I think there's an animation  which is happening on the page. And the bottom trace is giving us whether those peaks are  happening, that says doing our animation every sort of 16 milliseconds we're doing some kind  of animation. And you'll note that the difference in speed is immense. So I'm able to get something  happening, some animation happening on the screen on the bottom trace in 84 milliseconds,  whereas on the top screen, it's happening in 438 milliseconds. So it's taking an awful  lot of time, a lot longer. And the only change I'm making on that page is moving my scripts  from my head to the bottom of my page. The other thing you often see a lot of people  do is include too many frameworks. So you might have jQuery just to do selection when  you could just maybe use document.getElement.id, or you might have Angular in there because  you were going to use it but then you decided not to. Or you might have just modernize it  but you don't actually do any feature detection. You often find that people will take boilerplate  code, have tons and tons of JavaScript libraries in there, not necessarily use any of them,  and then you get traces like this. And the top trace is just this C of orange. And that's  C of orange's garbage collection. Because although you're not doing anything with those  libraries that you've included in your web page, they're still creating objects, or they've  created objects on the global namespace somewhere perhaps. And all that has to stay in memory  somewhere. So if you've got lots of memory on the page and it's being used again and  again, there's different things loading all the time, then garbage collection has to  kick in. And every time garbage collection kicks in, it's going to be interrupting your  UI thread, it's going to be interrupting your CPU. So that C of orange means every time,  it just means basically if I was to look at this trace, it shows me that there's just  far too much garbage collection going on. And so there's, for some reason, there's just  far too many objects which are being, which need to be destroyed. We're getting to the  upper limits of our memory. And for this demo, this example, this demo, the frameworks which  are included don't actually do anything. They just initialize. And then, you know, we've  got these memory problems already. So reducing the number of frameworks can really help.  This is quite a complicated one to explain, but coalescing style and layout changes. So  this is an example where on the left hand side, you see a little menu. And that menu  is being controlled at the moment as I scroll. And that's not a particularly great way of  doing it. And then this time, as I'm moving up and down, it's rather than being controlled  by the scroll mechanism, on a specific frequency, it's updating the position and then using  CSS3 animations to move the object. Now, the first instance where we're tying an element  and then every time we scroll, there's a scroll event, we're moving that object, that's a  very high definition input. There's tons of, every time you scroll, which could happen  like every two or three milliseconds, you're basically saying to the DOM tree, what you  had before, sorry, your display tree, what you had before is no good anymore. Throw that  away and create a new display tree. Throw that away and create a new display tree because  you're moving something on the document every, say, 10 milliseconds. But we're not actually  drawing it to screen. So we're creating this display tree and we're not drawing it to screen,  so it's all just wasted CPU cycles. So what you want to try and do is you want to link  the work that you're going to be done and make sure that when we do work, it actually  end up being painted on the screen. So rather than using an event for a wheel mouse event,  for example, moving up and down, it would be better to use something like request animation  frame, which is a JavaScript API, which fires basically an event every time we get this  interrupt from the monitor. Every time we can print, we can paint the monitor, sorry,  we're going to respond, request animation frame is going to throw up an event and say,  I can paint now, you should create the tree now and then we can paint it. And the other  thing which we did there, because that's not going to be, you're not going to get an animation  nice and smooth, what we do is every, that request animation will fire, say, every 16  milliseconds or whatever the refresh rate in the monitor is. And as it fires, it's going  to be in lots of different positions and we transition the object using CSS3 transitions.  And the other benefit of doing that is that we offload all that animation rather than  doing it in JavaScript, we're putting it into a, we're putting it into the GPUs work. So  if we look at the trace of the first element and then the second element, the first element  we're doing work, we're doing two lots of work, but only if one of them in that is getting  painted. So all of that, the blocks of two, only one of those elements in that block of  two is actually getting painted. So I think it's, I can't see that, never mind. So what  you want to try and do is correlate or coalesce your style and layout changes so that they  happen at the same time. The other benefit of this, if we're using, and this is a general  rule as well, animation with CSS animations is far better than animations with JavaScript  because we can take the animation, we can put it on the GPU and let that do it and leave  our CPU to run our website. So if we look at the first trace on, this isn't using the  DevTools, it's using that Windows performance analyzer. And it shows the CPU usage, the GPU  utilization. And you'll notice that in the JavaScript animation, we're using the UI thread  and the HTML render thread. But when we're using the animation just in CSS, we're only  using stuff which is related to the GPU and scheduling for the GPU. We're not doing or  blocking the HTML thread at all. So it's really useful when you're doing this work, using  request animation frame rather than sort of set time out or timers or scroll wheels and  making sure that you have CSS animations which transition things over as well. Another one  quickly is when you're building websites and you're using images, it's very easy to just  use PNGs. I use fireworks for all of my graphics and I export as PNG just out of a matter of  fact. I never really thought about it much before. But there's actually a memory penalty  to using PNG over JPEGs. And obviously if you're using alpha transparencies, then you  have to use PNGs. But in the most cases, for just a standard image, you should be using  JPEGs. And again, that build website, we took the one website which had PNGs and one which  had JPEGs, exactly the same dimensions these images, but they were just different image  formats. And we used the memory tool. And the memory tool in the F12 tools allows you  to take a snapshot of the memory stack of the memory heap and we can say how many objects,  how many JavaScript objects are in that thing at that time. And then we can take a second  snapshot and we can see how many objects are in it at that time. And we can see the delta  if there's more objects being added or less objects that have been added. And we can keep  taking snapshots after snapshots and then comparing them with different things. So we  can have a look and see how memory usage has changed over time. So this tool is very useful  for seeing memory leaks, for example. If something is constantly creating objects in memory, we  will spot it using this memory tool by profiling. But here I'm using it just purely to say,  okay, we took a snapshot using PNGs and we've got 8.6 megabytes of memory, decoded memory.  And then if we just use JPEGs, exactly the same images, it looks exactly the same. We've  now got half of that, that's 3.59 megabytes. So there's a massive amount of saving in memory  that you get from using something like JPEG over PNG. It's important to remember that  when you're thinking about an image, it's not necessarily the image on disk which you're  calculating. So for example, you might have a 557kb disk image, but the memory usage of  that image to keep that in memory is actually the width of the image roughly, the width  of the image times by the height of the image times by 4. So that 557kb image is actually  2.67 megabytes when it's decoded. So you don't need many of those to start getting  to quite a lot of images inside of memory. And people don't necessarily realize this,  I don't think, when they're building their applications. So the way that we deal with  when we're trying to display an image inside of Internet Explorer, a request goes out for  that image and some of it's received, it's like a stream. And so we start decoding some  of it. Then more of it's decoded and decoded. It gradually streams in and we start decoding.  And then we process that code and then we copy the elements of the GPU. And then we  finally paint it to screen. And so we can see over here on the CPU thread we've got  various bits of work, the actual color coding from, I've just realized on there. But say  the UI thread is meant to be pink in here, but it's meant to be blue. So that blue section  is the UI thread and then the green section is the decoding. So it's doing some stuff  on the UI thread, it's then doing some decoding work. There's the decoding work. And then  we have this weird space where it's not doing anything on the CPU and it's not doing anything  on the GPU and there's just blank space on both. And what's actually happening here is  we're making a copy from the CPU to the GPU. So we're taking the image and we're copying  the GPU. Now you might be thinking, well, on a modern laptop that's not really a problem  because memory bus is really fast and you can do that really, really quickly. But on  low-end mobile phones it can be like six megabytes per second. So we could theoretically get  to a point where to copy that image, that 2.97 megabyte image on a low-end phone might  take half a second to copy it from memory to the GPU. And you start realizing on low-powered  mobile phones images and the heavy use of images can really make a browser on a mobile  phone appallingly slow. And it's actually getting down to memory bus speeds, which is  kind of mind-blowing really. No one ever really thinks about that when you're designing websites.  But you start seeing this stuff in the Web Performance Analyzer. I won't go through any  more of this to others to say in IE 11 we've added features to try and improve this slightly,  try and improve performance of JPEGs, I think by about 40% ahead of what we had in IE 10,  because we've actually realized that we can do a lot of the processing and decoding together  on the GPU rather than in CPU. So the IE 10 model is where we do the processing separately,  then we copy it to the GPU. We actually do a copy to the GPU, do the processing on the  GPU for JPEG decoding. So JPEGs are genuinely, genuinely smaller in memory, but also in  IE 11 specifically, we've also got 30%, 40% speed increases in terms of using JPEGs as  well. So on IE specifically, there's a really good reason to use JPEGs as well.  But I think the important thing when you're looking at these tools and creating websites  and using these tools to kind of debug your websites, you start realizing that we're no  longer just creating websites for these very high-powered machines. We're not just limited  by bandwidth and network, it's a whole orchestra of all these different subsystems working together.  It's very, very complicated, and we're trying to deliver these tools to give you insight  and to enable you to kind of debug your websites, to get insight into how you can improve performance  to your page as well. I think when you're developing websites, a lot of people think  about designing first for mobile, but I think you should be thinking about performance optimization  for mobile as well. Think about how much you're using in terms of memory. Just check on your  website using the memory analyzer, how much memory you're using, what's your memory footprint.  Because it might not sound too bad if you're using only 20 megs of memory, but lots of  people have multiple tabs open on, even on mobile phones nowadays, you can have multiple  tabs open in a browser. And if you're 20 meg in one tab and 20 in another, well, the browser,  agile switching between those tabs is going to be switching that memory around. It's going  to be saving it to disk, it's going to be bringing it back into memory, and you're going  to be thrashing the hard drive. And it can be a case of actually reducing the lifespan  of the hard drive or the storage on a phone just by thrashing it by moving stuff back  and forth from memory and using poor memory management.  So think about mobile first when you're designing websites and thinking about low-powered hardware  and using these tools to try and get some insight into that. Up until very recently,  that was a bit of a problem on something like Windows Phone because we didn't have any tools  to give you that. You can now, if you've got Visual Studio and Windows 8.1 phone and IE  11 installed on the phone, you can use Visual Studio to debug websites on those phones as  well. So you can either do this in the emulator or you can actually plug in a device and use  that. But you go to the debug menu, other debug targets, and then debug Windows Phone  into the Explorer. It will bring up a dialog box. And then all of the tools that I showed,  kind of the memory, the DOM Explorer, all of those things will work as well on the browser  on here. So it doesn't have to be your code, it could be any website, and you can sort  of start interrogating your mobile phones as well.  That's kind of it. It's a whistle-top-store, whistle-stop tour of the developer tools.  And I hope that you kind of will look at those tools and see that we're trying to do some  interesting things, not just to help you debug websites, but also improve performance. So  if you are interested at all in looking at the tools in more detail, I'll be at the stand,  the IE or the Windows stand, all the rest of today. And please come along with your websites  and we can have a look at the performance of them. So thank you very much.  Okay. If anyone's got any questions, I don't know if anyone's got any questions. We've  got five minutes left. I have no idea. Let's try it. I don't know how it works on the Norwegian  Coreboard Keyboard. We can try. But yeah, I hope there's a different key mapping, but  I don't know. So there's a question. Browser mode. Yeah. You can change the IE version  down to IE 7. IE 7. So the question is, have we brought back browser mode? Yes, you can  emulate IE 7, IE 8, IE 9, IE 10, and IE 11 using the tools. Obviously some of the tools  like the memory analyzer won't work when you're trying to debug in IE 7 emulation. But you  can use that. So the question is, in conditional, do we support conditional comments? Yeah. I  think conditional comments should now be included in the DevTools. Because we stopped conditional  comments in IE 10 to comply with the HTML5 rendering specification. But yeah, I think  if you change the emulation mode, it will still take in consideration conditional comments.  Yeah. I'll check that. But I'm pretty sure it does. Yeah. I don't know. Do you use that  what you use, your Dev Machine to run? So you want to run IE 11 on 70,000. Yeah. To get  these tools working, there's a whole lot of plumbing which requires IE 11. So these DevTools  will only work in IE 11. You could use, I don't know if the, try, you could install  Visual Studio and see if the DevTools works through that. I don't know. Yeah. You need  IE 11 to get these DevTools working. Anymore? Thank you very much.
Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_0_95.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_96_4523.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_4524_6107.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_6108_8579.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_8580_8699.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_8700_9887.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_9888_11207.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_11208_11351.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_11352_11531.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_11532_11603.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_11604_12107.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12108_12215.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12216_12407.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12408_12503.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12504_12551.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12552_12683.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12684_12803.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12804_12875.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12876_12959.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_12960_13535.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_13536_15599.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_15600_16979.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_16980_17051.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_17052_17315.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_17316_17543.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_17544_17999.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_18000_20411.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_20412_23615.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_23616_23723.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_23724_24275.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_24276_24803.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_24804_25331.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_25332_26003.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_26004_26255.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_26256_26435.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_26436_26711.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_26712_27527.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_27528_28787.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_28788_29243.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_29244_30119.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_30120_33419.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_33420_34571.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_34572_37559.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_37560_38231.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_38232_39431.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_39432_46223.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_46224_46379.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_46380_46427.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_46428_52019.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_52020_52151.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_52152_52247.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_52248_52343.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_52344_52427.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_52428_52475.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_52476_52523.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_52524_52703.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_52704_53819.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_53820_54503.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_54504_54551.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_54552_55739.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_55740_56111.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_56112_57827.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_57828_60227.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_60228_62447.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_62448_62639.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_62640_62747.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_62748_62795.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_62796_62891.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_62892_62987.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_62988_65675.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_65676_66467.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_66468_66527.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_66528_68159.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_68160_68519.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_68520_68579.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_68580_68687.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_68688_68963.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_68964_70367.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_70368_76427.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_76428_78395.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_78396_78455.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_78456_78647.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_78648_78887.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_78888_79019.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_79020_84107.png Martin_Beeby_-_Understanding_your_website_through_the_IE11_F12_tools_84108_84233.png