 Hello. Welcome everyone. Welcome to this first session of the afternoon, which is a regular talk that will last until 2pm. I kindly ask you before we start that if you need to leave the room, please be mindful of the events going on in the other rooms next to us. So please try to exit the room quietly and make sure to close the door. But now, to our speaker for this session. With us, we have a true performance expert with 17 years of experience under the belt. Please give a warm welcome to Peter Daalder, who will be walking us through how to build for performance. A warm welcome. Thank you all for coming today. As you might hear a little bit, my voice is not exactly what it should be. So I hope that it lasts the entire session. I won't be taking any shortcuts, but maybe I need one of you to step in for me and do all the talking. But we'll see how everything goes. The title for this presentation is another something first framework and let's talk about performance. The idea behind this is that we have a lot of frameworks when it comes to development. We have accessibility first. We have a couple of others as well. Slipping your mind, of course, right now. But those are mostly focused on front development and you have barely nothing that is more focused on the back end development. I'm introducing a framework and methodology today. You might have heard of it. You might have understood or learned about parts of it in the past. But I'm just going to easily take you through the entire process. A development cycle, so to say, for websites just to make you a little bit understand, maybe make you a bit curious about how this whole process goes. A little bit about me as well. Like was said in the introduction, over 15 years of experience in hosting. I'm currently working as a solutions engineer with the sales team at Surfbalt, a Norwegian hosting company. Usually I prefer to go bouldering, climbing on a wall instead of just hanging out on a couch, and any time coffee always beats tea. So, enough about me. First, a very quick question for you people. What is performance? Or what is web performance? Any ideas? Anybody? In the back. That kind of makes sense. Any other takers today? Speed? Yes, okay. So let's just keep it very simple. We're focusing on the whole broad spectrum of web performance. That is, it's a objective measurement. And also the perceived user experience for a website or application. You can build an application to be fast that can still look slow to a user. You can make it look fast to the user while the application itself is still slow as hell. So when we're talking about web performance in the way that we're talking about it right now, we're talking about the whole broad spectrum. So it's not just the performance of the application. It's not just how the user perceives it, just the entire package. Also wondering how many of you people are developers? I see a lot of hands. Do we have any business owners? A few as well. Okay, so for the business owners, this is something that you can implement with your development teams. Developers, this is something that you need to convince the business owner of. It's good to implement and just to get things going. Just keep that in mind. So topic is actually performance first as a framework. First question that always comes to mind is why this performance first framework? I already did a short explanation, but there are a few key points to keep in mind. These are just four. I can of course always come up with more, but we need to keep time a little bit limited. So by building a performance application, you will reduce the carbon footprint of your website, especially nowadays, that's a huge thing. The end product that you're delivering is way better in quality. Just because you're using a better quality code, which is more performance, will give you a better end result. Your hosting costs, they might go down or the hosting costs of your client because your application all of a sudden doesn't need 8VPS scores. It can run on two. So that can help you scale that a little bit. The last is one that might not be instantaneously, but you will also start to experience shorter development cycles. And that is because when we are currently developing, we're building a website and after that we're going to start working on the performance, which means that when you're actually already having a finished product, you start dissecting it again, taking it apart. Why is this slow? Why is that slow? So that way by combining that, you will just shorter the entire cycle. That is of course profit for your boss or for yourself, depending on who's paying the bills. So how does this work? It's a relatively simple five or six steps that you need to take during your entire development process, your entire development cycle. That's if you take those steps each and every time that you're delivering a product or when you're building upgrades, everything will go faster. And by doing so, eventually you will get better code. So when we're talking about this performance first, especially about this framework, we're keeping in mind two parts. First one of those is your performance budget. Is anybody familiar with the term or terminology for a performance budget? See one finger, a finger is still a thumb bramcus. So a performance budget is basically a budget that you set for yourself, for your website or for your application, which is basically everything that you have to spend on that site. So you can have a performance budget say I want it to be within two seconds and I want a maximum page size of two megabytes, for example. That's basically the budget that you're setting. The second part of this whole thing is your performance testing. Because it's fun when you're setting a budget, but if you're not testing it, you don't know what you're actually doing. With these two parts, we have one rule and one rule is to rule them all. And that is that your performance budget is absolute. So whatever you do, you are not allowed to go over the budget that you set for yourself at the beginning of your development cycles. Now next up is the fun part. I'm going to do a quick rundown of how such a development cycle would look. I'm just going over the steps one by one, just showing you how this can be done. Here we have the performance budget again. For this specific example, taking just two factors, you can use more factors if you want. But these two are usually good enough to start with. The first one is time. How many time or how many seconds can I spend? Do I want to load my website in two seconds? Do I want to load in three seconds? What is the budget that I have time-wise? Now the second constraint is my size. Given my time slot that I have, how many time do I have? How many kilobytes or how many megabytes can I send in that same time frame? These are a bit abstract. So for measurement, it's usually useful to measure them using KPIs. Calling term KPI, anyone unfamiliar with that? Nobody. That's good. Given these two factors, I've set up four KPIs. The first one is an easy one, time to first byte. If I want a performance website or a performance application, the first thing to look at is time to first byte. The second one, total page size. If you have a huge bloated website that will affect the performance that your visitors will be experiencing, so getting that down to a normal level is always a good thing. And then we have two more. That's the time for the dump content to load and the time for fully loaded. They might not make direct sense in this example with these two factors, but the reason I've added these two is that if you are doing this in an iterative way and you need to figure out why is my website suddenly going over my performance budget, you want to know what aspects of your website you're looking at. So time for the dump content to load and the time for fully loaded are two aspects which really could capture that specific metric. So you can see if my time to first byte, for example, increasing so much that I'm going over my budget, or is it something else in the process? So you know at least where to look in your code. The second step, that's the step that most developers like, code and deploy. So you make your changes, you put them on a staging environment just to see what it does. This process will get easier over time because when you are not just doing this once, but you're using the same code base and you're doing it again and again and again. In the end, what will happen is that your code base that you have or parts of the code base that is being reused in different projects will become more optimized. So you don't have to do those optimizations again. So the whole process gets easier. It's just that simple. The third step is to test our performance and for that we first need to determine what kind of scope do we need with the test that we are running. So the scope that we have is a function or a fraction of your code. For most use cases, the scope is completely useless. This is usually done somewhere in the CI pipeline and it doesn't need to be run on changes that you deploy to your live website because there are much better ways to measure that. First one being a single page. This won't happen often because mostly when you deploy changes it will be something that has effect on the entire website. So just testing one page will not tell you how it will affect other pages. So if you do happen to have something that you're deploying on just one single page and you're 100% sure that no other parts of your code are being affected, then you can test a single page. There are various online tools you can do for that. You can run for that. It's very easy. You can even do it in the browser. Just run some quick tests, get the KPIs that you want and make your decision based on that. But in most cases you will be running a full site analysis. You can use tools for that, streaming frogs, side bulb. There are a couple of other tools as well. If you want to go really fancy, get it into your CI pipeline just as a final step. Run a couple of tests for me and get me the results. You just set it up once. You don't have to do it again. It's very, very, very convenient, sorry. Then we get to the fourth step. That's a easy one. That's just a question. Did it affect performance? So whatever I did, I deployed my code. I've tested it. I've got a set of KPIs. I also have a set of KPIs for my last deployment. So what happened there? Did it get better? Did it get worse? And that one is also very easy to answer because that's not a grayscale question. It's just a very simple yes or no answer. Either it got faster or it got slower. Or in most cases, it got slower. And that gives us a very nifty way of looking at what we should be doing here. So given the previous question, that is, did it affect performance? In most cases, it will be yes, but we'll start at the bottom first because that's easier to follow. So we have deployed something and it did not affect my performance. Woohoo, I win. But did it increase my page size, for example? If it didn't, then the third question, are you above the overall budget, still should be no. So that means that we can deploy. We can put stuff live. That's good. But what if it did increase the page size? Then we need to start considering is the changes that I'm making, it increases my page size, is that worth it? In most cases, it will be. In other cases, it won't. But that's a decision that you as a developer should be making yourself. Is it worth it? Yes. Again, are you above the budget? Let's hope not because that means that we can deploy. If we are going over the budget, we need to start reworking because we have one golden rule to live by. And that is that you can never exceed your performance budget. So say we answered the question we had, yes, so performance was the fact that my performance is getting worse. Is that worth it? Again, it's the question you need to ask yourself. You need to make an answer for yourself. Is it worth it? Yes. Are you over your budget? No. Perfect. Let's deploy. But again, if it's not worth it, you need to rework your code. And that does not mean that you need to rework the code that you've just added to your project. Because at some point everybody will hit this limit. If a change that you make, for example, makes you go over your time budget, that does not mean that that change itself is the factor that causes that. There might have been a change a half year ago that added way more time and is much easier to fix than that small perfect solution that you just implemented on the website that just tipped you over. So also keep in mind what part of my code can I refactor the quickest and easiest to make sure that everything that I have grows to within my budget again. After that, we're up to the sixth and final step and that is deploying to life and enabling caching. And why are we enabling the caches now? Because everybody always tells me that I should have caching on my website. Because that makes my website go fast. It doesn't. It makes it look fast. Caching is something that you always enable as a past and final step. There are many, many hosting companies out there telling you exactly the opposite. If you want to perform the website, you need caching. What you don't. What you need is performing code that works good and works fast. Once you have done that, you can add caching to improve it even more. But don't rely on that cache for speed. Because it will make you a very, very lazy developer. By using this method... By using this framework what you're basically doing is you're forcing yourself to improve your coding skills, to improve the quality of code you're producing. You're just making a product that you're building better in a way that you can do if the first thing you do is enable caching. Because you don't need to fix it. It's already fast. But there's one thing that's very very very sure about caching. At some point in time someone will not hit that cache. And if that happens they won't have a performance website. Because what's behind that caching layer is just slow as hell. So like I said, without cache what needs to improve? That's the only way to get better. Thank you. And thank you Peter. So exciting talk. But do we have any questions for Peter? Show of hands. And I will walk around the room and take you in order. Is it acceptable to have a different performance budget for different use cases? For example... This is a big report page. They can wait longer because less people get to that page but other pages can be fast because a lot of people come there all the time. So if you're just building one application we will set one performance budget for that. But just limiting yourself or increasing your performance budget just because there are not so many people there in my opinion is the wrong decision to make. So of course you're free to do so but regardless if you get 50 visitors a day or maybe 50 visitors per second you should have scalability available. A colleague of mine did a presentation on work at Lens a couple months ago where he also showed a use case of a website that he helped develop in his early days as a developer and they were usually doing maybe 50 100 visitors a day so nothing wrong. But then the Dutch government used some of their data in one of their reports that got picked up by a local newspaper and all of a sudden they had thousands of visitors a day and at that point if you still need to improve your code when your visitors are already peaking you're too late. So it's always best to just keep the performance in mind regardless whether you have 5 visitors 50 or maybe 50,000. Does that answer the question? We have such a big peak because we also struggle with it we have like sometimes many visitors in one peak short moment of time isn't it impossible to code against that? Do you need more like horizontal scaling or something to add capacity to your server instead of coding? That would really depend on the kind of traffic you're getting hit with but I don't think that doing a traffic analysis on this specific case would be beneficial for the rest of the audience but hit me up right after this talk and we can talk about it. I believe I saw a hand somewhere over there as well. Questions, anyone? What tools do you use for testing? For testing? What kind of testing? You told some tools you mentioned for the site analysis. That would be site bulb Screaming Frog or you could implement it in your CI pipeline. Yeah, so the continuous integration pipeline in your development process. If you don't have it, look it up. It's really interesting. It can save you lots of headaches and do lots of automated stuff for you. Thank you. The performance budget that we have is okay or how do I know if it's too large or too low? So the performance budget that you have should be set up by someone that knows what goals you want to achieve with your website. For example, many clients they just run online tests to see how their website is performing so just page speed insights, things like that. They will already give you certain numbers like what is good, what is not good. Based on that you can make an analysis for yourself like well, okay, two seconds it works for me. Or you can be optimistic and you say well, I want to improve so I'm putting it down to one second. The same goes for the total amount of data you're setting. So it really depends on who we're serving, who we are, how we want ourselves. It's not set in stone somewhere. If you're having a performance budget this is what it should be. It's always on a case by case basis something that the development team needs to figure out for themselves. What are the goals that you're setting for this specific project? Thank you. Any more questions? Don't be afraid. My voice is still working. I have one. I'm a web hosting industry and as a fellow web I would like to know how web hosting companies can accommodate your framework and similar goals. Don't set limitations. What we see a lot is that hosting companies are setting limitations that would basically force you to hire plans as soon as you're having a lot of traffic at the same time. It doesn't really help with the framework itself but it does allow you to make more use of the performance that you have available. Specifically to the framework itself it would really help if a hosting company has GitHub integration, stuff like that. You can connect your own CI pipeline to your hosting environment if your running tests get deployed to a staging environment. It's done with that and it's all cool. You can automatically deploy it to your live website. That stuff can really help. That was a very good answer. Do we have any more questions in the room? No more questions? Well, in this case I will say thank you Peter. Thank you very much and we have a small gift for you to thank you for your very interesting talk. Sweet. Thank you.