Understanding your website
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | 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 | |
| Identifiers | 10.5446/50818 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201496 / 170
2
3
5
6
8
11
12
16
21
22
23
27
31
35
37
42
43
45
47
48
49
50
52
54
56
57
58
61
65
66
67
71
74
77
80
81
83
84
85
87
88
89
90
91
94
95
96
97
98
100
102
107
108
112
114
115
116
118
120
121
122
123
126
127
128
130
133
135
137
138
139
140
141
142
143
144
145
147
148
149
150
153
155
156
157
158
159
160
161
162
163
166
169
170
00:00
WebsiteRange (statistics)InternetworkingSoftware bugWebsiteSoftware developerQuicksortAreaTheory of relativityGoodness of fitComputer animation
00:49
World Wide Web ConsortiumRun time (program lifecycle phase)ArchitectureEmulationWeb applicationComputer architectureWeb-DesignerDemo (music)Run time (program lifecycle phase)Web 2.0Real numberQuicksortSoftware developerTerm (mathematics)DemosceneWeb browserMusical ensembleAreaVirtual machineInternetworkingChainBlogDifferent (Kate Ryan album)MereologyMathematicsBitRevision controlComputing platformComputer animationMeeting/Interview
03:01
Formal languageMaxima and minimaDuality (mathematics)SineClique-widthComputer fontMenu (computing)Hidden Markov modelSoftware developerAiry functionLatin squareMathematicsTotal S.A.Drag (physics)Sheaf (mathematics)Element (mathematics)WindowCategory of beingQuicksortText editorChainDifferent (Kate Ryan album)Semiconductor memoryDivision (mathematics)AreaWeb browserLogical constantGraph coloringWebsiteRevision controlComputer fileDifferenz <Mathematik>State of matterVideo game consoleFilm editingLimit (category theory)Point (geometry)Server (computing)Greatest elementProfil (magazine)Software developerProcess (computing)Source codeMedical imagingComputer animation
06:35
WebsitePrice indexEvent horizonSoftware developerMaizeRechentafelElement (mathematics)State of matterGreatest elementQuicksortWebsitePerturbation theoryMathematicsGraph coloringSoftware bugComputer animation
07:26
Revision controlVisualization (computer graphics)State of matterQuicksortCodeLibrary (computing)InternetworkingLink (knot theory)MereologyPoint (geometry)Control flowCartesian coordinate systemWindowWeb pageSoftware developerSoftware bugObject (grammar)Descriptive statisticsProcess (computing)RoutingSpeech synthesisSource codeJSONComputer animation
09:01
Video game consoleNim-SpielQuicksortLibrary (computing)CodeInformation extractionRevision controlMultiplication signPoint (geometry)Control flowDebuggerFunctional (mathematics)WebsiteMoment (mathematics)1 (number)Software bugPattern languageComputer fileComputer animation
10:23
String (computer science)Function (mathematics)Exception handlingMathematicsAbstractionException handlingLibrary (computing)QuicksortComputer filePattern languageFunction (mathematics)Line (geometry)Category of beingLevel (video gaming)Software developerInternetworkingCodeProjective planeRevision controlSource codeFrame problemMappingStandard deviationSystem callPoint (geometry)Block (periodic table)DebuggerWeb 2.0Social classMultiplication signPoint cloudScripting languageSoftware bugWebsiteInstance (computer science)Process (computing)Java appletProduct (business)Computer animation
13:36
Open setJava appletSubsetScalabilityVideo game consoleDebuggerPoint cloudMenu (computing)Newton's law of universal gravitationComputer fileSystem callComputer fileCompilerDifferent (Kate Ryan album)Source codePoint cloudContent (media)Formal languageCodeMappingPoint (geometry)Functional (mathematics)Function (mathematics)Scripting languageQuicksortWeb browserWebsiteFlagGraphical user interfaceControl flowProcess (computing)GoogolTouch typingFamilySoftware bugVideoconferencingComputer animation
15:44
Lie groupComputer fileDebuggerScale (map)Link (knot theory)Maxima and minimaDemo (music)Point cloudSystem callVideo game consoleRule of inferenceShift operatorScripting languagePosition operatorRevision controlCodeObject (grammar)Network topologyDebuggerMenu (computing)Web browserVideo game consoleContrast (vision)Graphical user interfaceElement (mathematics)Real number2 (number)Data structureQuicksortComputer fileFunction (mathematics)Software developerString (computer science)Functional (mathematics)Closed setDifferent (Kate Ryan album)Process (computing)Keyboard shortcutControl flowProjective planePoint (geometry)Decision theoryNavigationJava appletGame controllerSpeech synthesisBuildingLogarithmComa BerenicesShift operatorInternet forumComputer animation
19:11
Video game consoleFunction (mathematics)Newton's law of universal gravitationSoftware developerObject (grammar)Context awarenessConstructor (object-oriented programming)Daylight saving timeString (computer science)Content (media)Artistic renderingSoftwareComputer-generated imageryPhysical systemRepeating decimalComputer configurationResultantGamma functionRow (database)Video game consoleObject (grammar)Web pageString (computer science)LoginSoftware developerInternetworkingReading (process)Error messageProduct (business)WebsiteMessage passingCategory of beingQuicksortTouchscreenMultiplication signSet (mathematics)Open setFile formatLogicCoefficient of determinationElectronic mailing listWritingFunction (mathematics)Sign (mathematics)Quantum stateNamespaceRight angleComputer animation
22:17
Video game consoleSoftware developerNeuroinformatikObject (grammar)Tablet computerLaptopWeb browserString (computer science)InternetworkingVideo game consoleSoftware developerSubject indexingWeb pageWebsiteSign (mathematics)Selectivity (electronic)Electronic mailing listElement (mathematics)BuildingComputer hardwarePower (physics)Software bugCartesian coordinate systemNumberSoftwareIntelCellular automatonFamilyCodeContent (media)MereologyQuantum stateRight angleInstance (computer science)Process (computing)1 (number)Semiconductor memoryComputer animation
25:19
Semiconductor memoryBand matrixWebsiteSoftwareQuicksortGraphical user interfaceFigurate numberComputer fileMedical imagingMusical ensembleComputer animation
26:17
BefehlsprozessorStructural loadWeb pageUtility softwareMultiplication signContent (media)Single-precision floating-point formatSoftware developerTouchscreenPoint (geometry)WebsiteWeb pageSemiconductor memoryWeb browserDigital photography2 (number)Cartesian coordinate systemStructural loadBefehlsprozessorInternational Date LineInternetworkingTracing (software)Computer animation
27:41
Computer-generated imageryRead-only memoryMedical imagingPerturbation theoryWeb 2.0Object (grammar)QuicksortSemiconductor memoryWindowPlug-in (computing)Maxima and minimaCartesian coordinate systemWeb pageGraph (mathematics)WebsiteNumberWeb applicationSingle-precision floating-point formatNavigationStructural loadSpeicheradresseSelectivity (electronic)NeuroinformatikSystem callLevel (video gaming)Core dumpUtility softwareComputer animation
30:57
IcosahedronWeb pagePhysical systemWebsiteRectangleObject (grammar)TouchscreenNetwork topologyElectronic visual displayCycle (graph theory)InternetworkingComputer wormElectronic mailing listPoint (geometry)Web browserQuicksortDomain nameNeuroinformatikWeb serviceWindowInterrupt <Informatik>Bit rateScripting languageCross-correlationProcess (computing)Direct numerical simulationComputer hardwareTouch typingStapeldateiBlock (periodic table)Multiplication signCuboidDomain nameComputer fileTranslation (relic)SoftwarePosition operatorFile format1 (number)InformationDifferent (Kate Ryan album)Existential quantificationElement (mathematics)BefehlsprozessorZoom lensDirection (geometry)SurfaceVector potentialGraph coloringComputer animation
34:50
TouchscreenArrow of timeWebsiteFunctional (mathematics)FamilySemantics (computer science)Raster graphicsZoom lensElectronic visual displayInternetworkingNetwork topologyThread (computing)Computer animation
35:33
Network topologyElectronic visual displayMiniDiscTracing (software)Event horizonBlogScripting languageComputer-generated imageryMaxima and minimaEvent horizonLoginComputing platformWindowTracing (software)Software developerPhysical systemDependent and independent variables1 (number)ResultantObject-oriented programmingInformationOrbitComputer animation
36:21
Computer-generated imageryMedical imagingSpacetimeRight angleWeb browserReading (process)PhysicalismTouchscreenDemo (music)Real numberCycle (graph theory)Graph (mathematics)Term (mathematics)Dependent and independent variablesElectronic visual displayTracing (software)Computer animation
37:09
Computer-generated imageryRight angleScripting languageEmailBefehlsprozessorTwin primeSoftware frameworkReduction of orderSingle-precision floating-point formatMIDIWechselseitige InformationPhysical lawAnnulus (mathematics)Menu (computing)SummierbarkeitUniformer RaumScalable Coherent InterfaceEvent horizonoutputCross-site scriptingIndependence (probability theory)Graphics processing unitThread (computing)SynchronizationDuality (mathematics)Scripting languageMenu (computing)Greatest elementBlock (periodic table)Object (grammar)Instance (computer science)QuicksortTracing (software)Process (computing)Frame problemMultiplication signEvent horizonRule of inferenceoutputDifferent (Kate Ryan album)TouchscreenWell-formed formula2 (number)Cross-correlationNetwork topologyArithmetic meanUtility softwareDisk read-and-write headInformationMathematicsNamespaceWeb pageSpeicherbereinigungWindowMoment (mathematics)Scheduling (computing)Group actionLimit (category theory)Film editingThread (computing)CodeMedical imagingBoilerplate (text)Software developerKey (cryptography)Category of beingWeb browserExergieElectronic visual displayFrequencyGreen's functionLibrary (computing)BitSemiconductor memoryMechanism designSource codeSpacetimeGraph (mathematics)Computer filePosition operatorRight angleDependent and independent variablesSmoothingFamilyRoundness (object)Software frameworkJava appletState of matterDemo (music)WebsiteDesign by contractBuildingCASE <Informatik>Element (mathematics)Cycle (graph theory)BefehlsprozessorBit rateVolumenvisualisierungSelectivity (electronic)Codierung <Programmierung>Alpha (investment)NumberInterrupt <Informatik>Web 2.0Computer animation
45:58
Independent set (graph theory)EmailSemiconductor memoryConvex hullGame theoryStack (abstract data type)Object (grammar)File formatMedical imagingWebsiteSemiconductor memoryMultiplication signDimensional analysisMathematicsReliefDifferent (Kate Ryan album)Memory managementProfil (magazine)LeakComputer animation
46:54
Video game consoleSoftware developerSemiconductor memoryPrime idealRead-only memorySpacetimeMiniDiscClique-widthDimensional analysisComputer-generated imageryCodierung <Programmierung>Graphics processing unitProcess (computing)Thread (computing)Electronic visual displayGastropod shellComputer fileHuffman codingData conversionMedical imagingPoint (geometry)Term (mathematics)Musical ensembleNumberSemiconductor memoryCASE <Informatik>Limit (category theory)Process (computing)Sheaf (mathematics)Thread (computing)SoftwareComputer hardwareMultiplication signWebsiteData storage deviceWindowWeb browserOpen setEmulatorBuildingSpacetimeStreaming mediaElement (mathematics)Bit rateVisualization (computer graphics)Codierung <Programmierung>Web pageHard disk driveHuman migrationLaptopCodeInsertion loss2 (number)CodeDisk read-and-write headMiniDiscEndliche ModelltheorieProjective plane40 (number)Software bugGoodness of fitBefehlsprozessorBitClique-widthBus (computing)Band matrixMemory managementMobile WebVirtual machineInternetworkingWeb 2.0Mathematical optimizationCartesian coordinate systemComputer animation
52:40
Installation artOnline helpView (database)Computer fileArchitectureProcess (computing)Visual systemWeb pageInternetworkingSheaf (mathematics)InformationScalable Coherent InterfaceOpen setWeb browserWebsiteMenu (computing)InternetworkingCodeSoftware developerWindowCuboidEmulatorType theoryIdeal (ethics)Software bugData storage deviceSemiconductor memoryComputer animation
53:40
Slide ruleVirtual machineWeb browserMathematicsAsynchronous Transfer ModeCondition numberArtistic renderingObject (grammar)Latent heatSemiconductor memoryEmulatorMachine visionSystem callVisualization (computer graphics)MappingRevision controlInstallation artKeyboard shortcutServer (computing)
Transcript: English(auto-generated)
00:01
Hello, everybody. Hello, that one last guy just coming in. Come in. Thank you. 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,
00:20
and 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 gonna be talking about the kinds of things which are new in the sort of tools. It's not gonna be a 101 necessarily of our tools. It's gonna be showing you the things that are new since the April release,
00:41
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 gonna 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
01:03
and the way that we can use those tools to get to that to optimize it. And then we'll look at some real-world demos and 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.
01:20
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 dev tools have never really been very good up until there was a marked change in IE9
01:41
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.
02:02
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 a IE11 release back in November or something like that, and then they shipped again the tools
02:20
just back in April. So they're shipping the dev tools in a much more regular cadence, which is really interesting. They're adding new features out of band of IE11. So the actual dev tools 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 gonna be talking about today. All of the updating in IE now happens silently in the same way that it does with other browsers.
02:42
So we should set up and see 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 seeing that team sort of working in a more agile kind of way. Has everyone, how many people have not seen
03:02
the F12 tools before, have never opened in Xplorer 11 and seen these tools? One person. Okay, if you've ever seen any other browser developer's, browser vendor's tools, it does very similar things. You can select elements, you can look at the CSS, you can choose to manipulate the DOM.
03:23
There's eight different tools in total. 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.
03:41
And I'm gonna 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 IE 11 will be updateable to these tools
04:01
so you can get these on Windows 7 as well. So this is the NDC website and we're gonna look at this area where we've got this purple section. We're gonna change that background color by just selecting that element and then just change it to 336699 which is hotmail blue. Or we can just choose from the images,
04:22
choose from a different color, sorry. Can choose and settle upon maybe Azure, weirdly it's not Azure, nevermind. 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.
04:40
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, that 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 we originally had in our CSS and this is a sort of diff file.
05:02
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 gonna 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
05:21
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
05:41
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,
06:01
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,
06:24
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 two mice. So what we've done is I give you the ability to scroll over, say on the bottom of the NDC site
06:40
you have these little elements which 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.
07:00
And when you enable a hover element then the CSS changes because it's had sort of the hover state applied to it. So here we can change that background from three through three to something like hot pink. And notice again the color just to the left of background it's changed as a manipulation which has happened here to our CSS. And now that's been applied across the document
07:20
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 her ref links as well. So that's kind of some of the newer features around the DOM Explorer.
07:40
So next up is some of the stuff that 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
08:01
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 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.
08:21
So while we're trying to sort of step through this code and break point 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. Point is actually that the actual team
08:41
which work on IE, the dev tools 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
09:01
whereas it used to be built by Internet Explorer. So for example, here we go, we have in the side of the debugger we have a break point on the NDC website and we put it onto a function called set pop-up. You see as I step through it, I ended up in this library, jQuery 1.8.2, an old version of jQuery. And you'll notice as I step through this code
09:21
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
09:45
and we end up back in jQuery again. Because at the moment, they're not using a minified version of jQuery so that 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
10:01
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'll only step through our code and we won't actually end up inside of jQuery. So you're only stepping through code which is your own code, you're not stepping through other libraries and so forth.
10:22
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, IE is a minified version file, then it will set it automatically as it's not your code. And there's a few other ones,
10:40
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 you know, 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
11:01
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
11:21
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 to be debugging something there. But when you have just my code enabled, all those exceptions are only going to be thrown
11:41
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 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.
12:03
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
12:21
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.
12:43
And for a developer which has never seen the output, it could be quite confusing. TypeScript does an awful 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, it's not a standard but it's a community project
13:00
which was started outside of Internet Explorer. And all it does really is it's 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?
13:22
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 output of 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
13:41
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.
14:02
Okay, don't know why that video's not playing. Oh, there we go. So we've got a, on the TypeScript website, we've got these clouds which are running
14:20
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.
14:41
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 had 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,
15:01
by the TypeScript compiler. And we can step through our code just as if we were using, you know, debugging JavaScript. And this will work with any kind of, 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.
15:21
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 of that content.
15:40
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 file. CoffeeScript, if you're not aware, is kind of like a Ruby-based sort of syntax
16:02
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 original, the output of JavaScript as well.
16:22
So it's really useful if you're a CoffeeScript or a 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 IE 11, the original tools, were you would often get yourself heavily involved in some debugging, and you would have breakpoints set up everywhere,
16:43
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 could start debugging again. One of the things we've added back in there is this persistence.
17:00
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'll 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 big, huge projects, it can be really, really beneficial.
17:20
And also added a few different ways of navigating using the keyboard inside of the dev tools. So one which I commonly use is Ctrl Shift F, and it's kind of just get me out of here. You know, so you are debugging code and so forth, and you've got too far and too deep, and you just want to restart the whole thing and restart the whole experience. You just press Ctrl Shift F,
17:41
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 dev tools. So there's eight different tools inside of the dev tools, and you could say sort of Ctrl 1, it would go to the first one. Ctrl 2, it would go to the second one.
18:00
Ctrl 3, 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 Ctrl 1, contrast to get the DOM Explorer up and so forth. One thing which we've added with a new version
18:21
is Ctrl Brace. And Ctrl Brace allows you to move up one, or Ctrl Closed 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 dev tools out to developers who have been using Chrome dev tools,
18:42
one of the things they would always complain about was our console.log functionality. If in JavaScript you wanna 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,
19:00
or you'd get a full, whatever you pass in, and you would get that as an object. IE previously would convert that into a string literal, and you'd just get object object. And 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 if you've got properties which hand around in the global namespace,
19:21
and you wanna inspect them, you can just console.log, put your object through, and see that. We've went a little bit further than that as well. And we've enabled the ability to add multiple objects. So you can console.log, and then send an array, or a list, sorry, of objects. And this can be two, or it can be three, or it can be four.
19:40
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 got, you don't wanna do a quick look up of a lot of objects at once,
20:01
and just get them all on screen so that you can inspect them. Also, 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,
20:21
where you go console.log, and you pass in a string, and then you have these, sort of %s and %s here. And that relates to the first object and the second object. And what it'll do is it'll just to string those objects and put them into the string. So you end up with this, oh wow, it's %s,
20:42
and I'm reading %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, because I did this yesterday, and I'm reading the document type, which is ndc-oslo. Useful as well, because not only does it give you the string, it also gives you the objects as well.
21:02
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 IE8 and IE9, which was completely different to other browsers, whereas if you called console.log from your website, and the dev tools were not open,
21:21
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 saw that around IE9,
21:41
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, and even if you haven't got the tools open, it's always gonna be logging console.log.
22:01
So if you went to a website and there was a ton of console.logs which happened, 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,
22:22
we're all using jQuery now, right? Everyone uses jQuery, and it's really dull to write document.getElementByID over and over again when you can just use this beautiful little dollar sign everywhere. And if you're obviously working on a website which has got jQuery, you can just, inside the console, put the dollar sign and use the shizzle selector
22:41
to your heart's content. But if you don't, all the other browser tool manufacturers enabled you to still select elements by ID using the dollar sign, and IE never used to. We added, I think, in IE11, so you can just say dollar and then pass a selector or an ID of an element ID, and it's gonna return the object which it matches.
23:02
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 the whole array which is then returned as like this node list here.
23:23
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 the, it takes the last object and then it's the index, the zero index of that last object.
23:42
And then that returns the H1, and then we can say dollar underscore dot in a 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 it all as one long string which would be dollar dollar H1 dot index zero dot in a HTML
24:03
is that there will be no way of the browser to resolve the IntelliSense of the object because it has to evaluate all of those selections up front. So by doing this way in parts, you're evaluating the objects and gradually building them up and then you can still use IntelliSense on those objects. So dollar underscore dollar dollar selection
24:21
and dollar selection have all been added to 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 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 dev tools for, right?
24:42
Like the reason why you would pick up IE dev tools would probably be because someone's reported a bug in IE and it's not happening in other browsers so their dev tools are useless because it's only happening in IE. However, there are a number of features that have been added to our dev tools which actually aren't really about debugging necessarily but also can actually help you improve performance
25:01
in 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
25:24
so that you can deliver an experience which is really good for your users. When we think about network, we have a networking tool and it shows us all of the networky 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
25:41
and you might see that in Chrome. And you can see that in IE as well and it's in Firefox and all the other major tools. And that's really useful because it helps us understand 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?
26:01
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's not performing well. It might be down to some kind of a network problem. If we look at the performance of a website,
26:22
actually we can do an awful lot to improve the perceived performance of a website just by trying to do 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
26:42
from where the browser considers it completely loaded. But in this particular page, the actual time to 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
27:01
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,
27:22
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 having better CPU utilization. One of the biggest problems which happen with specifically single-page applications is memory utilization.
27:43
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
28:04
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 20 meg, most websites. And then you've got this small selection of websites which got all the way to like 180, 200 megabytes
28:22
of use 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
28:42
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
29:01
for this phone and it was like a GPS sat nav kind of application. Okay, so for sat nav you're gonna need to go to the GPS. So you're gonna have to enable the antenna. So that's probably gonna be using like two watts of electricity, something like that. And then you're gonna be taking some images, some map tiles, and you're gonna be loading them
29:20
on the GPU and you're gonna be loading on the website. So you're gonna be using the GPS is gonna be an extra watt, so three watts. And then maybe because there's quite a lot of computation which is going on, you're gonna 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 five watts of electricity, the maximum that a phone can use. And all of a sudden your phone starts getting really hot
29:40
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, 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 do 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.
30:01
And it's fine, but it's not fine because the phone is getting really hot. It sort of enables thermal mitigation. 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
30:21
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
30:41
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 kind of the way that the web works or the way a browser works and what it does.
31:00
So we start off, make a request for a webpage 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,
31:21
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, we'd have to, they would block, we'd do it in batches of six and they would block and block and block. So if you, obviously if you're spreading, you're spreading across different DNS names and so forth, that's useful, a way of improving the network performance, potentially.
31:40
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 parse them. So all your HTML or the CSS files and so forth, we parse all of those things and with the HTML thing, we create a DOM tree,
32:01
a list of all the objects in the DOM. It has no recollection of the styles which have been 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 in the page before we can move on to the next point
32:21
because it could affect the DOM tree. There's DOM APIs which actually, JavaScript is in a sandbox, these DOM APIs might come out of that sandbox and affect things in the system. And then once we've got all 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.
32:41
And then we know where things should be so we can start laying things out. And we lay them out as rectangles on the screen. And then once we've laid 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.
33:00
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.
33:21
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 then 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, vsync we call them. When we get that, we can then paint it to the screen.
33:42
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 if everything from text
34:01
to SVGs to everything's, even JPEGs now, are all being, we're using direct text to paint those things. And then we, and then someone could actually go and edit that document or they could change it by manipulating the screen and so forth or changing, and then we'd have to go through this whole cycle again and again and again and again.
34:20
And obviously this 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's 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
34:41
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.
35:01
As soon as I let go, it goes back to the display tree 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
35:21
and rather than having to do full repaints. And it means that when you're doing things like semantically zoom or moving in and zooming certain in the site, you're not blocking the UI thread from doing other things. Okay, so how do we get some insight into what actually is happening here? That whole tree, how do we figure out what's going on there?
35:41
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
36:01
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. But the F12 tools are the ones that we're gonna look into.
36:22
And I said earlier that the right, the image is 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, we've done on a website called physicsoffast.io forward slash demos. It's called the right size image demo.
36:41
And the top graph is a website which has taken 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.
37:01
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.
37:22
And, oh gosh, that's better. 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 at 60 frames per second and everywhere it dips, these little dips in the middle there and towards the end,
37:44
are all 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 gonna potentially look a little bit jaggy or jumpy because you're not painting enough frames to the screen.
38:01
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
38:21
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's 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. Most people do this nowadays, but most people don't realize necessarily why they do it.
38:42
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,
39:00
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
39:22
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
39:41
whether those peaks are happening. That's us doing our animation. Every sort of 60 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 longer.
40:02
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.ibiod.
40:20
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 modernizer 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 sea of orange.
40:42
And that sea of orange is 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,
41:01
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 sea 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,
41:20
there's just far too many objects 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 we've got these memory problems already. So reducing the number of frameworks can really help. This is quite a complicated one to explain,
41:42
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
42:01
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 the object. That's a very high definition input. There's tons of, every time you scroll,
42:22
which could happen 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.
42:41
So we're creating this displaced 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's actually going to end up being painted on the screen. So rather than using an event for a wheel mouse event, for example, moving up and down,
43:03
we've got to use something like requestAnimationFrame, 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 to the monitor, sorry, we're going to, requestAnimationFrame's going to throw up an event and say, I can paint now, you should create the tree now.
43:22
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 that requestAnimation will fire, say, every 16 milliseconds or whatever the refresh rate of 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.
43:44
And the other benefit of doing that is that we offload all of that animation rather than doing it in JavaScript, we're putting it into the GPU's work. So if we look at the trace of the first element and then the second element, the first element we're doing work,
44:02
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.
44:23
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
44:40
and leave our CPU to run our website. So if we look at the first trace on, this isn't using the dev tools, 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,
45:02
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 requestAnimationFrame rather than sort of setTimeout or timers or scroll wheels and making sure that you have CSS animations
45:24
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 matter of fact.
45:41
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'll have to use PNGs. But in the most cases for just sort of a standard image you should be using JPEGs. And again, that build website we took the one website
46:02
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 allowed 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.
46:22
And then we can take a second snapshot and we can say how many objects are in 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.
46:40
So this tool is very useful 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 take a snapshot using PNGs and we've got 8.6 megabytes of memory, decoded memory.
47:04
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.
47:20
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 557 KB 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 four.
47:40
So that 557 KB 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
48:01
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 it gradually streams in and we start decoding. And then we process that code and then we copy the elements of the GPU.
48:25
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 is wrong I've just realized on there.
48:41
But say the UI thread is meant, it's 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
49:00
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 it to the GPU. Now you might be thinking, well, on a modern laptop that's not really a problem because memory bus is really fast
49:21
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
49:42
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.
50:02
I won't go through any more of this to others to say in IE 11 we've added features to try to improve this slightly, try to 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.
50:22
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 smaller in memory but also in IE 11 specifically we've also got 40% speed increases
50:40
in terms of using JPEGs as well. So there's a really, 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
51:00
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
51:21
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 websites using the memory analyzer how much memory you're using. What's your memory footprint?
51:41
Because it might not sound too bad if you're using only 20 megs of memory but lots of people have multiple tabs open 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 gonna be switching that memory around.
52:01
It's gonna be saving it to disk. It's gonna be bringing it back into memory and you're gonna be thrashing the hard drive and it can be a case of actually reducing the lifespan of a hard drive or of 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 mobiles first when you're developing websites
52:21
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
52:42
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 type targets and then debug Windows Phone Internet Explorer. It'll bring up a dialog box. And then all of the tools that I showed kind of the memory, the Dom Explorer
53:02
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 stop tour of the developer tools and I hope that you kind of will look at those tools
53:22
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.
53:46
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 keyboard.
54:01
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 IE version down to IE seven.
54:21
IE seven emulates. So the question is have we brought back browser mode? Yes, you can emulate IE seven, IE eight, IE nine, 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 an IE seven emulation. But yeah, you can use that.
54:46
So the question is do we support conditional comments? Yeah, I think conditional comments should be included in the dev tools because we stopped conditional comments in IE 10
55:00
to comply with the HTML five rendering specification. And but yeah, I think if you change the emulation mode it will still take in consideration conditional comments. I'll check that but I'm pretty sure it does, yeah.
55:24
I don't know if you, I don't, do you use that? Will you use your dev machine to run? So you wanna run IE 11 on server 2000? Yeah, to get these tools working there's a whole lot of plumbing which requires IE 11.
55:40
So these dev tools 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 dev tools work through that. I don't know. But yeah, you need IE 11 to get these dev tools working. Any more? No, thank you very much.