 Hello everyone, thank you very much for joining us this afternoon for this talk I'm extremely pleased to introduce Peter Hedenskog who is actually just joined the performance team yesterday Peter is a Very experienced web performance engineer. He runs the web performance meetup in Stockholm, Sweden And is the creator of several Popular and highly useful open-source tools for analyzing web performance Chief among which is sitespeed.io, which has gained quite a lot of traction and publicity recently Peter is going to be talking about web performance Unsurprisingly, so without further ado, I'll pass it over to him. No, it works, right? Yeah. Okay Perfect. So my name is Peter. It's me when I was little I'm from Sweden, you know, and you know Sweden, right? Yeah, and I'm from a small town called Uppsala and in the HBO series called the Vikings This is actually Uppsala. It doesn't look like that Really, but it's quite cool, right? It looks something like this the old base And I'm from Sweden and it's we don't have one really really cool thing We have that Twitter account Sweden, you know about it So each and each week a new user will have the account of Sweden as we and we'll talk about Sweden and this week, you know Louise is talking about San Francisco from a sweets point of view. So that's kind of cool. I think and The last thing about Sweden We are really good explaining things in pictures, right? You know that so let's see how I will do today I've been working with web performance for quite a while. I've been helping different companies to become faster and One thing that is really really really super important. I think you know already you've seen this, right? The muscle's hierarchy of needs and you see that Down below we have fast websites. It's super super important and you or you know that so that's it really Yeah, one thing you can pop me a question whenever you need whenever you feel something that you want to question me about so So we know that fast web says it's really super important, right and One thing that not everyone know I think you know but maybe not everyone it is the speed happens in the front end, right? And it was like this There's a guy like the godfather of web performance called sees others that did a study Many years ago where he tested the websites that I think it was top five fifty thousand websites and Compared how much time is spent in the front end and how much spend time is spent in the back end for a user Yeah, and he His summary was it eighty to ninety percent of the time is spent in the front end So it's really important how we How we create our problem And he called us the performance golden rule. So It is not that eighty to ninety percent of the end user's ones that we spent in the back end No, it's in the front right and what does that mean to us with Wikipedia? So have you seen this before you know what it is? Oh Okay, so it's a waterfall graph it describes how the browser is actually loading loading all the assets of a page so What happens first is that it loads the HTML page and then it starts to go through the all different assets that are going to Be loaded on the page or the images or the slide sheets or the outfits, right? So I did a couple of red things on the top. I don't know if you see them I'm trying to explain What is back end of what is front end so the first one you see the first request to the main page? Small one that's actually the back end when we generate or send out the HTML All the other things to the green line the green line in this example It's when we actually put something on the screen for the end user and the blue line there is when we do the Unload event happening So in the old study that Steve Souters did he waited on the unload happen, but for us It's probably better to have to compare with our First paint and for us that is yeah, maybe 15 20 percent spent in the back end and there is plenty there right Yeah This is a image explain how the actual page is Displayed by browser or Wikipedia That's cool. If you see it takes in this example when it has it takes a little bit over 1.2 seconds, but then we almost display 90 percent of how the page So it happens like mine So we know that it's really important with the front and right So what does that mean to us front-end developers? You know We have the power right? We can make things happen. We are stronger than people long stocking When we do things we can make things happen. We can make pictures really really fast for the end user Yeah, we have really really power But when we have great power, you know Yeah Perfect. Thanks. We need to have responsibility Yeah, so we need to understand how the browsers work and I think you already know this but I'm going to repeat it Because it's really really good to you know how it works So we need to understand how a browser render page because if I understand that then we can make sure That we deliver the content in a good way so that the browser will display the content really really fast for the end user Okay So it happens like this You know when you type in the URL in the browser window and you click return The browser will first guess the HTML and when it gets the HTML the browser needs to create a document object model that displaying how What kind of tags we have on the page now it looked like but we actually be able to display something also need the start sheets, right? So in the best case scenario, we got the HTML Download or inline the CSS we can create the CSS object model and we can match them to the render tree And when we hand have the render tree we can put out the layout and paint the The page on the browser, right? It's super simple but You will have one problem That's JavaScript and It works like this, you know in JavaScript you have the ability to change the document of an object model with a document right So if you load the JavaScript synchronously that you usually do You will tell the browser. Okay, you have the ability to change the document object model so until we have loaded all the JavaScripts and Round them we can when that is finished we can create a document of a big model so If we just include the JavaScripts the whole standard way We know that we need to wait until the JavaScript is loaded until we can create a dome and we cannot display anything before We have created a dome and created a CSS object model because then we can create a render tree and then JavaScript can also look into the CSS right you can check what kind of how you What kind of layer to have and and and so on so JavaScript is waiting on the CSS that's the old thing that you know I've got to mention it, but I think you know that already the old Weisler rules that Steve Souders created it's a Bunch of rules that tells how what kind of rules we need to follow to make a page load really fast and In that these rules was that One of the rules is that you need to load JavaScript at the bottom of the page That's because you want to have that CSS load as fast as possible To generate the CSS and then you can execute the JavaScript instead of loading the JavaScript on top You know that the browser will need to wait to execute the JavaScript until the CSS is loaded Am I right Ori? Okay, so but this there's a trick, you know If you tell the browser to load the JavaScript asynchronous asynchronously you will You will tell the browser that I will not change the document object model the JavaScript. So it's It's a rule. So if you If you load the JavaScript synchronously you will not change the document object model And that's what the changes we have done now. Okay so You know the document object model and CSS and one cool thing Just to visualize it, you know how the These are different HTML tags, but you maybe I've seen it before in Firefox So you can see how deep is your page because you know, we have the CSS and you have the HTML and browser need to merge it together and when it merged you your smaller Your document object model is the easier it is for the browser to actually merge the page so if you create a page for For example, if you use you have a page on a mobile browser and a mobile browser has Very little CPU. It's good to have try to have The styles or have the object model as flat as possible So we know that we need the CSS and the HTML To generate the page, right? But then we also have one thing called the lookahead free parser Each browser has it and what it does It's go through the when when you download the HTML the browser has the HTML and before it starts executing anything It will have a thread that will go through each and every line and trying to find the object that The browser knows that will be important to the page and start download it, right? so So for example, each browser knows that if you put JavaScript inside of head it will block So it will try to find this and try to down start down with it as fast as possible Also, if you have important images or Or whatever it will try to find these kind of things as fast as possible and start down on it and each and every browser has its own implementation of the lookahead parser So it could be that Internet Explorer looks for one thing and prioritized one thing Chrome prioritized another thing So so it's really important to try in different browsers because different browsers will download assets in different orders and The lookahead parser will look for objects that are Like the standard way of doing things So for example, if you have an image source tag If you have JavaScript tag or if you have a CSS tag if we look for these kind of objects and download it, right? So I have an example here of a page That looks like this So we have a big big big image there first and then you have a couple of small images and Yeah Twitter and LinkedIn Logos and this is how the browser actually downloads it and I will explain some So you see it will start with a couple of minutes and then it will take all the different Images that are from the logos and then almost at the end. It was actually download the big images that we had first on the page and This happens because of the lookahead parser So it will go through the HTML on this page and try to find things. Okay. What is important for this page? the only thing If I have built this page, I would say okay The main picture at the top is the most important picture, right? So we want to browse it to download as fast as possible So if you check at HTML This is actually the image that they download You see it's not a regular image tag, right? They have a JavaScript that will hook in when the JavaScript is executing and will start downloading the image So this is like a big image from So we have built in this case We have built something That breaks the lookahead parser because the lookahead parser don't know that this is actually an image that we can download because it's not Not a regular image source tag, right? So instead needs to it would start download all the images that are real image tags so so for example You see that The logos here down below almost at the end of the page or downloaded much faster than The big Hero image right and that's because these images are regular image tags So it will be found by the lookahead parser and the other two images there on top on yep, so we can be really nice to the browsers to to To tell them you standard HTML to make it easier for lookahead parser download things and bring the parser And then we have one third thing that is really important and that's with the performance you is for mobile browsers We have proxy browsers and there's two kind of proxy browsers, right? So we have the best practice proxy So that's really really easy. So we have you know, we have there a couple of rules that will make the web page really fast We need to and compression content. We can create And We can combine images, etc. So in the mobile world We have these kind of proxies that do all the kind of best practice rule so when you surf on your mobile you will access the URL and the the proxy browser where the proxy will collect the data from the server and Do all the best practice rules and send it back to the end user so that the mobile browser is is Have less data to take care of and it's it's can generate the page faster, right? and from a Performance in your perspective that's quite quite hard because we don't know exactly what they will do But we will talk about more more about that later So I had the best practice product proxy and then we have the distributed remote browser that's really really hard to To Understand or to measure the thing is The first example then we send HTML the JavaScript and the style sheets to the browser But we fix it a little to make it faster in the distributed browser world We actually execute all the thing on the server side and then have our own protocol and send over Whatever data we want to the browser So for example, if you are in a country where you have only 2g connection And you have an old phone could be better that you have our own protocol where we send only the data that we show The screen and that's really hard for us to actually see what is happening and understand if it's possible Because that is happening all on the browser side. Yeah Okay, so we know Now that it's really important to to understand how the browser is working, right? So and we have a couple of best practice rules today How we actually should do to to deliver the content as fast as possible to their user So how do we make the pages super fast and One thing that everyone talks about today is about the fold so You know a lot of pages are really really long right and you deliver all the content to the browser and the browser starts to render it But what's important to the end user is the thing that you actually see on the screen, right? They're above the fold so in best case scenario. We should try to aim to give the CSS and the HTML and the images that we need to start to render the The content above the fold right so if you have a way of prioritizing it, we should start with that first So what people do is that they inline the CSS and that's good for mobile phones For example when every request costs on something extra and then they Asynchronously load the rest of that such is later Okay We know how the browser will create the page right and we know that we also want to measure and keep track of a page And how are we do that so One thing that I really like is performance regression test and that is to jack in something in your continuous integration to make sure that you keep track of the performance over time and Have you heard about the story or the fairy tale about the emperors new clothes Anyone I can tell it so there was a fancy emperor in the old old days That really like clothes and he wanted to look really really good right and there were people that's trying to They might want to outsmart him and said okay We have really really really fine clothes and it's super super expensive and the thing with the clothes is that if you buy them Only people that are really smart will see them right so stupid people will not see the clothes They will think you are naked right So that's the emperor And of course All the people in the country wanted to be smart right you don't want to send out and be stupid So they said oh Emperor you have so fine clothes. It's really really great, right? But one day there was a kid that actually Saw the emperor and said oh damper has no clothes, right? And that's our web performance tool that we have in a continuous integration We need to have that to tell us when Things are going bad and preferably if we can do it before we do a release But at least so we can keep track of things when we do commits and so on and it could be like we can do it Depending on the system we have it will come once an hour once a day or something like that. It depends So there are three ways of keeping track of performance or like the best practice way of doing today The first one is to do it in a continuous integration, right? The second one is that we do today. That's really cool that we collect data from the users Using from the user measurement so in the browsers from the users we Become back data how fast the page or our servers The thing is it's really good for us to do that to keep track of things over time and that's perfect But it's hard or at least I think it's hard to actually pinpoint real problems Because we have it we can see trends and see if you are going faster or going slower. That's really good But all the different users has different latency and hardware and connection types It's hard to actually say what's wrong, but we can see trends over time. So that's good But to be able to more pinpoint what it's wrong and what we should change We can do something called synthetic testing And that is actually running a browser in a controlled environment and testing Performance so we test one page or many pages and It's good to actually test with different browsers because As I said before different browsers has different implementation So we don't know what if our html and our JavaScript and our CSS will be fast in this browser So there's an example from a site that actually was used in Google ad service. You see there on line 7700 26 they are loading the JavaScript all following the Weisler rules putting the JavaScript synchronously late, right? But in some browsers, I don't know which browser You see that actually the second request that the browser do when they load the page is actually collecting the Google ad server JavaScript, so Each and every browser will prioritize in their own way what they want to load, right? so it's important to test with different browsers to know how our page are doing in different browsers and The next thing is It's good to test a couple of pages from our most important pages because it can be hard to find things Or keep track of many many pages, but it's also good to kind of trying to crawl page and try to find by pages that ordinary users had edited and and added data to because I Don't know which site but one site had a picture of a Saucer with 14 megabytes. That's a content editor has uploaded So it's important and the only way to find that Was that doing actually testing in production because the content management content manager could only add content in production And so that's why we need to test things in production find things if we have bad content so We know We take the browser and we parse the HTML and the JavaScript and CSS And we want to test before we release preferably and we want to test the data or the page in production But what kind of metrics do we want to test right? Because we want to know If the page feel fast and that's really the hard right, but that's the thing that is really important because if the user Feel that the page is fast and it is fast so What we want to do is we want to measure about the full content when is the content that are Visible to the end user in the browser in the browser window finished So the end user can start reading it So we need to find a way of measuring it and the browsers today have a couple of different APIs that we can use So we have the navigation timing API that we use today and here you can see what kind of browsers that actually support it The navigation timing API tells us things like okay now the JavaScripts hold the JavaScript for the page is parsed And the CSS or big model is finished But it's from the whole page It doesn't give us any information about the above the full content It's still quite good because you see a lot of browser support it and we can collect data and we can see things over time and Then we have the user taming timing API That's Another API that we can use that we actually can create our own metrics. So for example we can We can add the timing on each and every page when something is happening. So for example when our Our first image has loaded because nothing else supports it And we can make it we can add the JavaScript actually collect the data and let the browser report it You see and that's good because then we can kind of wave Think of things that are important to the end user. Maybe our logo or some images or something like that But still you see not every supported browser supports it's not Safari And then we have the resource timing API and the source timing API is telling us things like when are Each and every source on a page loaded right so we can find out when the JavaScript is loaded different JavaScripts different Style sheets and different things and that's a good because then we have the whole picture of when the page is loaded But still the browser cannot give us the information of when is actually actual the browser windows Finished above the full content So we have a couple of different things in the browsers that are really good that we can use to collect timings But we don't have the really really good stuff that we need right because we want to measure when the things that the people see are So and then we have the speed index and that's a Thing that was created by Pat Menon for a web page test. That's a tool that can measure things and The speed index Will Will measure when a page the above the full content is actually loaded So you will get the number that says say in millisecond When the above the full content is loaded and the way they do that is that they create a video of the Page on the page load and then analyze it when it's finished and when it starts to load it And what's really cool about it is that You've had two different pages that are finished at the same time if a page actually are Delivering content before the other page. So you see things much Faster than the other page. You will have a lower speed index. So it's also good that you can see things You will get a better number if you deliver content really really fast depending on user And you have probably seen this before yeah So what they do they analyze a video of the page when it's loaded and then they can give us a number What's good about it is that we have a tool that we can get that number The bad about it is that it's only in one tool, right? So we cannot get it from our real users and It's odd combined with other things, but at least we have a tool that we can't find of measure things Okay, but Metrics is not the only thing right so we have the numbers, but do the numbers really tell a real story No, it depends on the context of the user, right, you know this guy It's a Swedish Prince Prince Daniel So you see here. He's got his fighting face on. He's going to play basketball, right? Normally looks like this really fine glad happy people But he's got his fighting face on and depending on the context, right? so for end user if I Serve a couple of pages I will compare the page. I'm on right now with other pages. So if I'm really and fast I Must be faster than or at least the same Speed as the couple of other pages that I am used. I've been using the last couple of minutes or something like that, right? So it depends on what kind of context the end user is and in this example It's Daniel. It's actually playing basketball with a kid, but it still has his fighting face on and that's quite cool Okay So I'm actually at the summary, right if someone has questions we can take it or you can take it after So there's three really important things that we need to remember, right? This is how the page are created and it's painted on the screen. So and I think you already know that, right? So you the HTML need to be need to create a document object model, right? The CSS need to be CSS object model and then we parse it together the render tree and then the browser can stop So we need to minimize the time until we can start creating the render tree and create a layout and create a page and then We have the lookahead parser, right? So something in the browser We start to look for things and try to download as fast as possible and We need to make sure that we do things in a good way so the lookahead parser can find them and the last thing is There is no magic metric we can use, right? We have a lot of different metrics in the Browser today. We had a navigation timing API and that it's good, but it's not perfect So we need to combine the metrics we have use tools and use Their metrics in the browser then we can find that at least a quite good way to measure things Yep, so do we have any questions? Crystal clear, right? Hi, I have a couple of questions It used to be where There were companies that would you would pay them and they would sort of monitor the performance of your site from sort of all over the world Do you think this? Are you am I guess a real user monitoring has that kind of replaced that or is there still a role for? You know paying some company to tell you how you're doing in Istanbul and how you're doing in So yeah, so the companies that I have worked with have actually used like all the different tools to To do that because it's a different way The real user measurement is good because then you collect data from the real users, right? But collecting data from different points in the world It's good in a way because then you can keep track of is your content as the end provider is actually work, right? So most of the companies or at least the largest one I've worked with are using these kind of systems to make sure that the content the Syrian providers that they use really Deliver content in different places, right? So they use it in that way So they use both yeah, yeah, I mean because I guess the foundation has an advantage that we can sort of reliably assume We have users all over the world. We don't have some I'm sure get tons of data, but Do you think there's still a role for I mean those services so I think That kind of service is good to just keep track of things or how things are going but to be able to understand If we're if we will be how we can be better and how we can increase the performance of a web page We need to put it on a lower level because these kind of tools will not help us So it's good to collect a real user measurement So we can keep track of things over time and keep the trends as if we're going faster or going slower But to be able to actually do things better We need to have tools on our level on now Development Because these kind of like the keynote may version name names, but They are good, but they will not help us I think it's better to keep keep things at the developer level to see how Thanks, and my other question. Well, it's more a kind of thing. I've noticed Do you think there's a risk if you just focus on the time to paint above the fold I've noticed on my phone. There are a lot of sites where I'll see it But I can't actually do anything I'll be clicking buttons and nothing will happen and even like you know zoom gestures won't work This is kind of dead zone for like sometimes a long time so I wonder if people are so focused on on Presenting that above the fold and then the interactions kind of completely screwed up for like 20 seconds Yeah, and that's what's important for us I think we need to find the metrics that we think is really important on our pages, right? So we need to find okay. Okay, maybe the About the full content is important But we need we need to find the measurement that are important to us and to our users. So it's like It could be that people are focusing like on the wrong thing But for us, we need to make sure that what do we think is the right thing for our our pages and make sure that we can Measure that because it's really important to measure things that are really valuable to us like Call to action or something like that. So and yeah Thanks anything else. All right. Thank you so much Peter. Thank you appreciate it. Thank you