 Hey, guys, and welcome to another session of Hangouts on Air. If you're expecting Lucas with me, he took on another role. So we have a fantastic replacement, and that's Dennis. So it's us two that's going to be talking about the more improvements for the mobile web in the next months. And today, what we thought is we're doing a little deep dive on e-commerce sites. I mean, everyone knows it's the holiday season is coming up. You want to be ready for the holiday season. And at the same time, e-commerce sites are quite tricky to optimize because you have a lot of things going on there. You have a lot of maybe JavaScript files. You might have slideshows. You have pictures. Yet, at the same time, product pages and e-commerce pages in general are very important because ideally, you want to convince your users to buy the items you offer. So we thought we do a little session on the benchmarks as in what you want to achieve. And then, to make it a little bit special this time, we're going to present some practical examples. So we dig a little bit into the code and show how does things work and how can you actually make a real impact on the performance of your site with just a few little tricks. So it's nothing too complicated. It's easy to follow. And of course, you can replay that video as many times as you want or chat with us, follow us on Twitter. And yeah, we're happy to help. So yeah, I mean, as I said, my name is Dominic. Some of you probably know me. This is Dennis. And we're both mobile UX managers at Google. We're based in Dublin. And we have other team members that are based in Mountain View. And this is really our daily bread. So we literally look at the mobile web each and every day and try to come up with improvements. So I think that's it from my side for now. So I will hand it over to Dennis and he will discuss a few benchmarks with you and just show you what's going on globally in the e-commerce world. Cool. Thank you very much, Dom. Yeah, as Dom said, we're starting off with a few benchmarks and case studies since you guys gave us that feedback that you would be more interested in benchmarks and also some thresholds where I can optimize towards too. So let's just jump right into that and see what kind of benchmarks we brought for you. And of course, we brought some for Christmas. So this is our very first stat you might want to take with a pinch of salt. But I think you might have had an idea that it looks like this because usually it's that moment when you walk into a store in a supermarket in September, in September, and you wonder why there is all this gingerbread, why is this Christmas decoration already here. So this is practically the stat that offline purchases, retailers have known for a long time. So actually starting the purchases or the first ideas of purchases start in September. And we can also see, and I put the source for you there as well, people start actually buying Christmas presents in October already. So this is actually a perfect time to start optimizing your site or keep on optimizing your site if you already started because people will start shopping for Christmas presents or any other holiday presents soon enough. And this is where you want to be there for them. We're a really nice user experience in terms of speed and of course in terms of search, in terms of pages and navigation. And yeah, so that's the perfect time now. So let's have a look at other implications. Speed in particular has on your mobile user experience because that's what we usually focus on in this series. And of course, we will also focus on it mainly today. So I guess you have seen the stats before just to remind you again, speed is critical for user experience. Why is that? Because we will lose 52% of customers if our site takes over three seconds to load. I'd say also take this stat with a pinch of salt. It might differ from vertical to vertical. But even if you only lose 30% of our customers, it's still way too many customers or visitors to lose at this critical first step in the user journey. And all those stats kind of relate to measuring speed on 3G, right? Yeah, that's true. So when we're talking about speed, usually we recommend to optimize toward 3G, which has quite an implication of how fast your site will be. So please also keep that in mind. And usually we are optimizing towards new users because as you can see on the very right side there, it is especially crucial for new users because one in five users or one out of five users won't return to your website if the experience for her or him was bad. So this is where we usually say we're trying to optimize the upper funnel, getting new people in or on your site and getting them engaged with your site is crucial, especially if you will pay money for these users if they advertise your site. And it's especially crucial if you're in a highly competitive environment as well because as you can see 29% of smartphone users will immediately switch to another site or app. So if you're in a very competitive field, which is usually the case for retail, it is crucial to be lightning fast because this is where you get your new users and where you get your new users to stay. I think it's also important to think about the word of mouth. If you have a great experience on a website, you probably tell your friends about it. If your friends are like, oh, where can I buy shoes or soccer ball or jerseys? You probably recommend a site where you had a good experience. So it's not only that a dissatisfied visitor might not return to your site, but he will also not recommend your site to their friends. So you're really losing out in the long term. So I think that's always also quite important to keep in mind. That is true. Cool. So just to show you some other implications Speed has or to bridge the gap between user experience and your, well, retail business, your online revenue, Speed has a very direct correlation with bounce rate. So you can see that here. That's Sausda Sausda in Google case study we did. And we could prove the direct correlation between Speed and or loading time and bounce rate. So and as you can see, it is very significant even in the lower bracket. So we're looking here at 2.4 seconds to, and let's say we increase that 2.4 seconds by 1 seconds to around 3.4 seconds. The bounce rate will increase from around 13% up to 20%. And these will be very good loading times. I don't know. I'm not sure what you're seeing, Dom, but I'd say around these times it is very fast sites, actually. Yeah, I mean, you spoke about it earlier that you lose about 50% of your visitors in the first three seconds. So kind of like the 3 second benchmark is sort of like the goal we should all aim for. But you can see that even in those first seconds, as we said, we lose, in the worst case, every fifth customer or potential customer. And if you look at the graph, it's just increasing by each tens of seconds. So I think that graph is really good to just show the urgency and should kind of get you to invest time and money into improving the mobile speed and not kind of like take it, kind of like put it on the back burner so like, yeah, I might get to that later. Yeah, I think what is crucial here as well, I mean, maybe you say, OK, bounce rate, but I'm not really interested in bounce rate because I'm a CMO, I'm a CEO, I care about revenue. I think it's a very easy argument to make because as you can really use it at balance, you usually don't shop or sign up on your site. So of course, in the same study, we also can see that loading time directly correlates with online conversion, so with your mobile conversions here. And as you can see, these were only mobile conversions, so that's why the number is not super high, but that's pretty much what we see for retail sites on an average, might be higher for you or might be lower. But as you can see, it's crucial that just one second more loading time will decrease your conversion rate by 20% from almost 2% to 1.5%. And that is quite a lot if you think in revenue, depending on your average car, it could be a lot of money for you. Yeah, and I also think what's quite important, what we hear quite often is that e-commerce, like website owners, just accept a low conversion rate on mobile. And I don't think that has to be true, right? Because we do see higher conversion rates, and it really correlates with the user experience. I would really recommend to not just take a low conversion rate as a given, but rather really focus on what can I do to increase the conversion rate. Mobile speed is one thing, but there are other things, like improving the general usability, how easy is it to put a credit card number. So I think that's really important as well for the holiday season when a lot of people shop and people buy a lot of presents and buy more than they would usually buy, that you really get the checkout funnel right. And we actually have another video on that, how to optimize the checkout funnel. So if you go to our website, which we will post in the comments, you can browse through the videos, and we discuss that topic as well. Because there are quite a few things you can do to really increase the usability of your e-commerce site. Yeah, that's a very good point, actually. So usually we say speed is our conversion, and that's why we're focusing heavily on speed in this series. But as Tom just said, it's also important to focus on the more, I'd say, traditional UX parts as checkout funnels, search on your site, clear CTAs. So yeah, you should definitely browse through our repository and see, especially the one on checkout funnels might be very helpful. But to end on a positive note here, this also means that it's rather easy to really increase your conversion rate as well. Because if you read it well from a positive mindset, it means that if you decrease your page loading time by one second, you can increase your conversion rate by up to 27%, which also might be a lot of money for you. So to round this up, what we always say is page speed is not like a nice to have, and performance not a nice to have. It's a feature, it's money at the end. It's your online revenue, which you can control with rather easy optimization techniques, I'd say, right? Yeah, exactly. I think that's our goal as well. So when we host these sessions, we're not trying to do some rocket science here and discuss the most complicated topics that might not be achievable on your side or might take months to achieve. Because if you have a large e-commerce site, you have a big infrastructure. So it's not just easy to change things. So we really try to focus on the low hanging fruit of things that you can easily implement, but that have a big effect. So again, some things we discuss, you probably like I know that. And definitely, you probably do know that. I mean, you're all great developers, and there's so much stuff out there to learn. So it's definitely not the most advanced techniques, but it's really the techniques that have a big impact. And as Dennis said, with every second, you potentially increase bounce rate and lower conversion rate. But it doesn't matter if you don't the two seconds or three seconds low time. I mean, if you're at 10 seconds and you even bring it down to six, you will see a difference. So I'd say that if you don't think you can achieve three seconds, it's not a reason to not try. Even if you achieve a four second improvement from 10 to six, that will make a big difference. And you will see it in your stats and in the end on your return on investment. That is true. So let's jump into the benchmarks and status scroll, because I think that's one of the main questions I get from my customers. And I'm guessing you two, Dom, is like, where should we optimize towards to give us some stats? We can, well, we need some rough guidance. It's always difficult, but that's why I think it's really cool that you're actually discussing that. Yeah. So let's have a look. First of all, this is basically the status scroll right now. So what we see and we analyzed a lot of sites is that sites take around on an average 22 seconds to load. This is fully load time. So this is fully load time. Keep that in mind, which is higher than other speed metrics we usually use. We'll talk about another metric speed index you might have heard of in a bit. But this is fully load time. I'm pretty sure you're familiar with that as a developer. And it is quite high. And you can see, again, we showcased it in this graph before already, you lose out on people. Because just seconds will really increase your bounce rate here. So after giving you the status scroll, let's look at what a mobile site or your mobile site maybe should look like. Please also keep in mind, these are average numbers. And we know that usually retail sites are heavier than other sites because you need to show your customers what you are selling. So you need to have high quality pictures. You usually need a lot of JavaScript because you have stuff like A-B testing, et cetera, on your site. So be aware of that. So keep that in mind, especially if you look at the page weight and the total requests. But having that said, even if you have a rather heavy site with a lot of pictures and a lot of JavaScript and CSS maybe, there's still a lot of techniques you can use towards above-the-fold content. So basically giving the perception of a very fast site, although you're loading, actually, a very heavy site. So it is more about prioritizing what to show first, keeping your site very ideally you would do that as well. But some techniques later on how you can prioritize content. So here are the stats. I think the main stat here we already talked about. It's Speed Index. Speed Index is a metric we would recommend using as the only metric. And it's always good to have a look at certain metrics, I'd say. But Speed Index basically measures the perceived speed for users. So it measures how long does it take in milliseconds to display the above-the-fold content, so the visible content for your user wants to see. Also, usually, we already talked about this, recommending a progressive display of the bulk of the. Because earlier it can show something like the feeling for speed will be for the site. And just quickly, maybe not everyone is familiar with Speed Index. What tools can we use to actually generate the Speed Index score? That's a good question, yeah. So we use a regression here, WPT. It's a web page test. You might know it. It's a very handy tool. It's webpagetest.org. We can also link that in the comments later. It's a nice tool. And for example, it has this Speed Index, which gives you a first idea of the perceived speed. It has a lot of other nice features. I think you will show some screens later on, or we will also jump into the tool. Yeah, I mean, exactly. I also tested the one site we're going to discuss. I tested it on a web page test, because as I said, it's a great tool. It's free, most of all. So you don't have to pay a dime for it. And I think the greatest thing is that you can actually test your site in different scenarios. So you can actually say, how does my site perform in the UK or in Ireland or in Germany on a 3G connection or 4G connection or Wi-Fi connection? So I think it's really handy, for example, if you have a lot of international traffic and you want to say, OK, I think my site is performing well in the UK, but what happens if someone from the US visits my site? How is it looking then? So I think that tool is great for that. And it's free. And you can play around with it. And it doesn't only give you the Speed Index score, it gives you information about what are you loading, when are you loading it, what's the weight of a particular file type, like what's the weight of JPEGs compared to the rest of your site. So I think it's a really great tool to utilize. That is true. OK, let's jump into the benchmarks. That's probably the second question I usually get. So how does it look like in my vertical and in my market? So we decided here to take Germany as a benchmark market to somehow showcase that even a mature market like Germany can stay behind its potential. You can see that here. So we have picked out the same three stats here. So in yellow, you see the Speed Index, in blue, the average request count, and in red, the heaviness of the page, the weight. And you can see that retail is rather, well, bad. There's not a way to put it in most of these stats. But it's kind of like what you said earlier, right, that retail pages tend to be a little bit heavier than other sites? Exactly. So that's why it's good to have a look in your vertical as well and not compare yourself only to other verticals. Because let's say for a lead gen business, it is way easier to have a lighter site than, for example, for a retail side. You can see automotive is also rather slow here. That's usually because they also use a lot of pictures showcasing their cars, where you have a car configurator, stuff like that. So there's stuff on your site you will always need. And that's, well, fair game. But we will show you how you can display at least, well, the above default content faster, as I said before. So also, if you're interested in other market stats, I think we have these stats at least for the UK and the USA. I think we have probably some views from the UK as well. You might want to type in this short link we put there for you. This will guide you to, I think, with Google site. We can get more benchmarks for your own market. So I'll leave it up for a second. But I think we will also put this in your comments later on. Yeah. And I mean, once the video has finished, you can obviously go back and have a look at the slides. And just get back to any slide you thought was interesting to get some more information about. Exactly. So I think to finish this, we are aware. And you should be aware that retail is, well, in terms of speed optimization, it can be tricky because you have to have a lot of stuff on your site. But it is doable. So you can definitely go closer to that five seconds we talked before, and as Tom already mentioned before, even if you go from like 10 seconds to six seconds, it's still a great improvement. And you will see that in your other business metrics. OK. Well, and to finish this now, before we really jump into our live coding sessions, let me show you two case studies I brought for you very quickly to really showcase the impact you can have if you will really optimize towards performance and speed. So the first one is called Modernisa. It's a big retailer for women's cloth with its headquarter in Turkey in Istanbul. And they partnered with us and conducted a usability workshop where we focused heavily on data-driven decisions. So we looked at the stats we had. We also came up with new ways of measuring. We integrated Google Analytics 360 and Google Optimize, which is always a good idea. If you don't do that already, you might want to consider do AB testing because that is very crucial for retail sites, I think. And their main goal was to understand the customers' cross-device behavior better to, well, in general, come up with a better mobile strategy or a new mobile strategy and to improve, well, user experience and simplify for all their customers. And they made a lot of changes, actually. I don't want to go too much into detail here. But you can see the three business stats we put up there, it is really impressive. They had a 91% growth in mobile conversion rate. And they decreased their mobile site bounce rate by 9% and had a massive increase in their mobile site revenue. So that basically ties to what I said before. It is not a nice to have, it is a feature. You can really turn that performance optimization into a lot of money at the end into revenue and then put that, again, maybe into new and nice features. So this was our retail or direct customer example. And I figured maybe some of you are working for agencies and tuning in today. I also wanted to give you a brief look on how you can help your customers if you're an agency and help them improving their MSI speed. So I brought that second one, that second example with me. This is buyautoautoparts.com, I'm a US company. And they worked with their agency, ROI Revolution. And they focused a lot on making their mobile website faster and more user friendly. But they also had very, very nice stats in terms of improvements. So they improved their mobile site speed by 50%. So that is quite a lot. And you could, well, pretty much instantly see that they also improved their bounce rate, which ultimately ended up in decreasing their cost per conversion and also increasing their mobile conversion rates. So basically, again, what we saw in the stats before. What I'd say now, after seeing the general business impact we can have, and we're hoping you're already hyped for our live coding session. So I'd say, Dom, should we just jump into the coding examples and techniques you brought? Sure. So what we're going to do now is I just run through a few slides to just very quickly explain, actually, how certain elements, the critical rendering path, select the speed perception. And then we look at what we can do to actually optimize elements like or files like CSS, JavaScript, images. What happens if I have a dependency? For example, a slide show in the critical rendering path. How does it impact the speed of my site? What can I do to maybe move some of the stuff that I don't need further down the line and download it at the very beginning? So we're looking at a few things. And then at the very end, I would say we have a look at the comments, maybe, like at the live chat. Maybe some of you have some questions and we'll try to answer a few questions if we don't run out of time. If we do run out of time, we do have a lot of sessions already on our website, so please feel free to have a look and browse through the videos. But we will try to do our best to address all your questions and concerns. So the critical rendering path, optimizing for speed perception. Dennis already touched it very briefly earlier when he said that it's not really that important necessarily to reduce the overall load time or the overall weight of your site, but rather do something that makes the render like the loading appear very quickly. And that is what we call speed perception, and a lot of other people call it speed perception as well. So really what we're trying to focus on is to optimize the critical rendering path, which is basically what happens in the first three, four, five seconds when someone visits your site. And as Dennis mentioned earlier as well, we're focusing on the new user. So it's not the returning customer that has already a cached version of your site and therefore doesn't really run into those issues. We're focusing on the first customer, and we're focusing on the first customer that comes through a 3G connection. Because our approach is, if we optimize for the worst possible case, we sort of covered all cases. And I think that's what we all want. I think it's also worth mentioning that part of our last hackathon earlier, we had a deep dive on how speed is perceived for a user. So if you're more interested in that, then we're touching more psychological aspects of how you perceive speed and how annoying does it get and when it's the most annoying. That might be interesting for you as well. I think that was actually a really interesting session. It was Luca's last session. And we talked about, especially, the psychology and active waiting time and passive waiting time and how users or humans in general overestimate waiting time. So let's say you, I think the passive waiting time is overestimated by 18%. So if your site loads in five seconds, you can add another 18% because that's what actually users it takes to load the site. So it's actually a really interesting session and definitely worth checking out. From that session, I took one slide that I want to just very briefly discuss because I think it's always great to get into this topic. And that is the following. Basically, what I like to say is busy people are less impatient, which basically means keep the user occupied. So those are three pictures from the real world. On the left-hand side, that is the traffic light button in New York. You've got 6,500 of them. And 4,500 don't work. But the city still doesn't take them off because the pedestrian walks up to the traffic light and pushes this button, believes that while pushing this button, the traffic light switches to green much quicker, even when it doesn't. And the middle picture is sort of the same idea. So you've got the underground in London. And you've got the button to open the door and to close the door. And I lived in London for seven years. And I know that those buttons don't work. So the driver is doing that anyway. But you leave it there because people like to push buttons and to think that things go quicker. I think we've got the same phenomena in elevators when you've got the button to close the door. And most of them are not actually functional. I think the greatest example is the picture on the right. It's used in the airport where passengers complain that it takes too long for their luggage to arrive once they have exited the plane. And logistically, it was impossible to speed it up. I guess there are a lot of processes and maybe additional screening. So the airport thought, OK, we need to come up with a solution to satisfy our passengers. But we don't really have a way of doing it. So what they did instead is they increase the time it takes from the gate to the luggage area, increase it by six. So when the passenger arrived there, it took him over six times longer. But the luggage was already there. And suddenly the feedback was, oh, wow, it's great. At Houston Airport, the luggage is always there when I arrive. So I think this is the idea of you don't actually win any time. But you keep the passenger, the user occupied. And while the user is occupied, it doesn't feel like they're waiting. And I think that is exactly what we want to achieve. So we pretty much want to turn passive waiting time into active waiting time. And that lets us dive into the critical rendering path and looking at how is it actually affected. So as I said, I'll run through the slides. And then we go over to the code and have a look what we can do. So this is basically what happens if someone visits your site. So a browser, like a client, requests your page, like let's say your product page. And it sends the server, and the server returns the HTML. And inside the HTML, the browser detects other files that are required in order to render the page and put it on the screen. So basically, you get the HTML, you build the document object model. But now the browser hits CSS and JavaScript. And now what happens is basically that everything is blocked. So the browser doesn't do anything at that point anymore until it has received the CSS and the JavaScript, like the full response, and build the CSS object model. The reason simply is that the browser says, well, I don't really know how I should display the content. So I'd rather wait until I have everything. And once I'm sure how to display it, then I build the CSS object model, then I run the JavaScript, then I build the complete document object model, and then I render the page. So that is the typical way of how it works. And usually there's no issue, because we do need CSS, and we do need JavaScript. So we're not saying get rid of all of it. That would look rather ugly. But what we're saying is you got to be aware of the fact that it does block the parsing, and therefore it blocks the rendering. So what we try to achieve is we want to get rid of this block as much as possible. And what you can do is you can work with asynchronous loading of resources. So most of you probably have heard of adding async to a script tag, to your JavaScript tag. That's pretty common for tracking scripts or pixels. But you can also do that to any other JavaScript file. And so while back in the day, not back in the days, but a lot of optimization techniques, they focus on putting the JavaScript maybe at the very bottom of the page. And I think that's a great start. But you run into an issue which we'll see later is that if you optimize that way, you put the JavaScript at the very bottom, and then you start rendering the page, but then in the critical, in the buff default content, you actually require the JavaScript that you put at the bottom because maybe you need it for a slide show. So you're not really optimizing it because you still need it, and you still need to wait until the browser has parsed the full document and executed the script in order to display the content. So async and defer are great ways for JavaScript to handle that. And I have a slide later that tackles that. And another great thing is which maybe not every one of you have heard of is loading CSS non-random blocking because that is also possible. And the idea is pretty much the same. So if you think about it, you're having a page and you have a lot of CSS, obviously, a lot of CSS. For the product page, for the home page, for the checkout page. And in most cases, you don't require all of the CSS at the very beginning. So the idea here is to say, well, hold on a second. If I don't really need all of that, why do I load it in the later rendering for the user? Why don't I just load what I actually need and load the rest asynchronously? So I do load it. I do put it in cache. So I have it for either the loaderful content or for the next page. But I don't actually delay the rendering initially. So this is what we want to do and where we're going to show you some coding examples of how to load CSS asynchronously and what to do with JavaScript and how to get rid of JavaScript, how to maybe replace it with pure CSS. Because many times you use JavaScript because there are some handy plugins that make things easy, but actually with a few lines of CSS you could achieve the same. And we're having a look at that later as well. So as you can see here, in this example, the CSS and the JavaScript is completely loaded asynchronously. So the difference is that you built the document object model, and then you immediately render the page, and then you build the CSS object model and run the JavaScript. So this is an ideal example. As I said, you definitely need some CSS and JavaScript. You don't want to render basically a blank page. But you get the idea. And one way of loading CSS asynchronously is to use what is called load CSS. So that's a great JavaScript function. There's a short link on there. You can go straight to the GitHub page. And basically what it does is it lets you define a non-critical CSS resource and then load that CSS resource while you actually display other stuff. And I think that's really great. And while we're at it, I'm just showing you quickly what I mean. So I'll just switch desktops. So sorry for interrupting, but I think it's very interesting to just have a look at that. So we're here, basically. And you see that we have white text on green background. And this is a really, really simple example. So it's rather ugly as well. So don't judge me on that. But basically the idea is we're testing, how does load CSS actually work? So here we have this page. We added a CSS file. And we put a sleep function in there to say, well, don't do anything for five seconds. Just to basically simulate a really, really, really large CSS file. Usually what would happen is you would not see any text before this CSS is loaded. Because as we said earlier, CSS and JavaScript is completely render blocking. But here what you will see when I reload it, you will see that you can see black text on gray background. And then once the CSS is loaded, as in like we were past the five second mark, then suddenly it switches to white text on green background. I'll show it just quickly. Just reload it. So you see it here. It's gray background, black text. And usually you would not see that because you're loading CSS. But you do see it because we're loading the CSS asynchronously. And now it switches to white text and green background. And the way it works is I'll show you that quickly. It's pretty simple. It's pretty much copy-paste. So all the work is done for you. So we're going in here, going to the testing. And I'll just quickly show you the CSS file so you can see here the sleep function five seconds. Again, we're just basically simulating a large CSS file. And then we have the load CSS function in here. So you can see that initially we say body is, the background is gray, ccc. And then you got the function which you're just going to copy and paste. You're required to put the href in there. But it's optional, for example, to put a value for the media tag. And then what you do down here basically load your CSS file. So this CSS file would obviously not be slow CSS.php, but that would be your non-critical CSS. So all the other CSS you would load just as usual. But then you would put this function in the header and then you would define the non-critical CSS here. And then the result, what you will get is that you're only loading this CSS, or you're loading the CSS while you're loading other stuff. And then once it's actually loaded, then it will be applied. So this is really handy. I know that CSS it's quite a tricky subject because especially if you started a long time ago, it might have gotten a little bit messy. So it's hard to actually extract the critical CSS. But it's really worth it because, again, CSS is fully render blocking. And if you have a very bloated CSS file, it will have an impact on your balance rate and your conversion rate. Cool. So back to our slides. As I briefly touched earlier, what you can do with CSS, you can do with JavaScript, and vice versa. So the first screenshot is how JavaScript is executed or handled usually. So you see the HTML parsing is going on. And then you hit the JavaScript, you stop the parsing, you download the script, you execute the script, and you continue with the parsing. And again, that's the problem. We're blocking the rendering and the parsing, and therefore the rendering at that point. So what you can do is two things. You can use async or defer. And there are two benefits. The async one is that you do execute the script as soon as you have it. That's why you usually use it for tracking pixels and stuff, because you don't really want to wait until everything is loaded, because maybe the user has already navigated. So you don't want to have incorrect tracking results. Or you can use defer, which is for JavaScript files that are maybe not that critical. So you download it just as you would do with async. But then the execution happens after the parsing is completed. Another reason when to use defer is that defer makes sure to keep the order of your JavaScript files. So if you have dependencies, let's say you have a jQuery plugin that obviously depends on jQuery, you want to use defer rather than async. Because if you use async, you cannot guarantee which script will finish first. And if it's the plugin, then obviously, since the dependency is not there yet, it won't work. So this is really important to think about using defer and async at the right moments. As I said earlier, ideally maybe don't use JavaScript at all. If you do use it and it's critical for the above-the-fold content, then don't async it, because you don't really want to wait any longer for it if you want it immediately. So there are a few things to consider and we'll get into that in a little bit. And then we're also having the problem, not a real problem, but the impact of custom fonts or web fonts on quick rendering. Web fonts are beautiful and great and we all love them. But the problem is they're also quite slow, because a web font comes with two components. One is the CSS and one is the actual font file. Now when you have multiple variations, what happens is that you need multiple font files. And what happens a lot is that maybe you find some nice font in our Google font library and you say, oh yeah, I need one on a load, like a few variations, like 300, 400, 600, 700. I might need it somewhere. Maybe the italic versions as well. And then what happens is like you're loading CSS and CSS, as we said, is render blocking initially. And then you're loading the font files. And the font files, what they generate, is the flash of invisible content, which means the text is already there, but it's not seen. So I think on, and Dennis, correct me if I'm wrong, but I think it's on Chrome, we have a three-second timeout that if the web font is not loaded, then we will use a fallback font anyways. But I think on Safari, that timeout is much, much longer. So every effect is even worse. Yeah, I think it's like something up to 20 seconds. Don't quote me on that, but it's much, much longer. And I think we all agree if we don't show text for 20 seconds, it's going to be an issue sooner or later. So again, there are some ways, which you can do to avoid this. And some of you probably guessed it, and there is also a way to load web fonts asynchronously. There are actually two great quick links that are very easy to follow. So I won't really touch on that too much. It's web font loader and it's font face observer. I just quickly explain what it actually does. So you're having a bit of JavaScript and you're defining which font you want to load. So in this case, you say, I want to load the Laura font from Google. And then you have different CSS classes, WF loading, WF active, WF inactive. And basically, what you do is you define what happens when. So when I'm loading the font, I do what? I have a fallback font and it styles my text in a certain way. When I have loaded the font, then I basically the class, which might be attached to the body tag, is swapped to WF active. And there you have the styles for the custom font. And then you have the class inactive, which is that you fail to load the font. So the class gets swapped to WF inactive. And there you can say, OK, if everything fails, I do that. I think it's really great because you don't have to miss out on web fonts. But you can sort of define what happens in between. What do I do while I'm actually loading the font? I don't want to wait for it. I'll do already something while I load it. So those are two great ways. What I'm showing later is actually a way to load the font on the unload event, which is basically you're having a fallback font and once the document is loaded, then you start loading web fonts, and then you swap it out. That is, in certain situations, even better because you don't take up connections for the font files, but you rather do that at the very end. Which way to go, it's up to you. You can play around. Definitely recommend to visit the short links and just get a feel for it. And I'm sure that what we hear quite often, what some people will now say is, oh, well, but if I do that, we run into this flash of unsold content. And people don't like that. And designers, especially developers, often don't care. And well, it's a fair point. It's not great. But there's also ways to sort of circumvent that. And one of our colleagues at Mountain View came up with a tool called font-style-metre. And what font-style-metre does is it actually allows you to match a fallback font with the web font and then play around a little bit with line hide, font weight, letter spacing, work spacing to make it as similar as possible so that when you actually swap out the font, you don't even notice it. Well, you notice it a little bit. It's a flicker. But it's not too bad. And I think it's sort of like an agreement between the people that hate flash of unsold content and people that say, well, but we really need to improve speed. This is a great way of saying, OK, let's do that. And we sort of meet in the middle. I might touch it later because I want to make sure that we're having enough time for the coding examples. So just bear with me for that. Otherwise, visit the short link. It's self-explanatory, fallback font. You can define which one you want to use. Web font, you can define which one you're using. And then you're basically just playing around. But if we have time, I will give you a live example of that as well. I think that also just a quick note on that. I think that also ties a little bit into our recommendation that progressive display of content is always better than showing everything at the end super-styled. There's pretty much one very good example in Brata. Show an un-styled text and show nothing like an invisible text because the user doesn't want to wait and Brata has something un-styled, I guess. I think that's exactly it, right? I mean, we're talking about turning passive waiting time into active waiting time. And it's give the user something. It's better than having users stare at a blank page because I think it's always important to note that while you might know what's going on in the background, the user doesn't. The user just sees a blank page and says, OK, maybe it's broken. I think it's safe to say wide-screen is probably the worst experience you can offer to the user. Probably, yeah. I mean, if you don't show anything for a long time, then users might think, well, that side is broken. That's bad experience. I'll just never come back. And that touches what Dennis talked about earlier. One in five users, if they have a bad experience, never return. And that's quite a shame. Cool, cool. So I would say we go to some coding examples now. And I still have some slides on saturating your bandwidth, which is quite easily done on 3G. So let's just have a look at a couple examples and then just see the results. So this is an example page which sort of checks most boxes when we're talking about an e-commerce site. So take this as a very abstract example. So obviously, some other e-commerce sites way more complicated and complex. But I found this quite good because you have a few elements here, like you have obviously the logo. You've got your message on top. You've got a background image, which you might question if that's actually needed for your breadcrumbs. Then you have the slideshow to showcase your products, which probably for this type of thing is quite important. Then you have the title. You have the price, some ratings, postcode check, et cetera. Got some more description. You've got like this little accordion here, which is done with JavaScript, which is very common as well. So I think you already know what we're getting to is that such site has a lot of things that are nice. But now we need to see if all of them are actually necessary. And just going further down, you've got some more like future arrivals. And here you have this very cool animation. Maybe it adds to conversion. Maybe it doesn't. So again, it's a pretty good site. And I run a test on it. And usually when you run a test on something like that, you see something like that. So this is what I've had tests as we discussed earlier. So what you want to do is, in our case, I tested it from Ireland on an emulated Nexus 5, the other one I did on an iPhone 6, just I don't want to be biased. And then as we said earlier, on a 3G connection. So what you see here is you get a lot of information, fully load time, first bytes, start render. And the one thing we want to focus on is the speed index that we discussed. So speed index of 6,300, which is measured in milliseconds. So basically in 6.3 seconds, the important content should be loaded, is not even that bad. But when we now look into the waterfall, we actually see that there are still some things that are not ideal, especially if you go back to what Dennis talked about earlier, how it actually affects bounce rate and conversion rate if you delay the loading process. So let's have a look. Here, film script view. Now, we see what's going on here. So this is the timeline. So it basically takes a screenshot every half a second to show you what is displaying in 3 seconds, 4 seconds, 5 seconds, 6 seconds. And you can see here that we generated this nice render block, which is basically in the first five seconds, we're having this blank page. And Mark Dennis' words, Mark and blank page, is not ideal. You really want to reduce the amount of time it shows a blank page. And so that happens for four and a half seconds. And then we start rendering. So then we slowly start with the logo. And then you see a black bar here. And you see the white screen. And now you're thinking, why is that white? Not the flash of invisible content. So we're loading a web font. The text is already there. But we can't show it because we're still waiting for the web font, which is not ideal. So now, after six seconds, we're having the text. But we're still loading this really, really, really large background image that you can barely see. Yet it takes multiple seconds to load. And then we continue. We continue now at 6.57 seconds. The speed index actually believes the site is complete because it looks sort of complete. But not knowing that we're actually still waiting for the slideshow. So look, we go further down the line. And then at 10 seconds, that's when actually the product picture appears. And if you think about it, you try to sell shoes. And for the shoes, the most important thing is to show the shoes. But you don't see the shoes until I have waited 10 seconds. And that is obviously very unfortunate. So let's have a look what that is caused by. So just a quick note on that as well. I think it also showcased very well that it's not a good idea to just focus on speed index. But it's a good first metric to use as a first compass or whatever. But it can be tricky, right? Because as you just showed us, around 6.57 seconds, speed index thinks the site is visually populated, which is kind of it is. But at the end, as you mentioned, you want to sell a shoe, and there is no shoe on the side. So we would probably recommend to always do that visual analysis if you just did as well to see how much of a progress you made after you implemented some stuff. Definitely. Yeah, definitely. I think it's a really, really good point. You know, no tool is perfect. No index score is perfect. So if you have a speed index that seems all right, always double check if that's actually the truth, or if there's something you can still optimize. So going back into the waterfall, so what's happening here? No, I just build it up a little bit like how it would usually be. So you would have the first connection to your site. I just ran it on a subfold of my own domain, so there's no S-cell certificate implemented on the initial request. Usually, it probably would be. And then you start loading some elements like maybe CSS, like a logo. And now you can see here, here's the first thing what happens is the browser hits the web font, and it says, OK, well, I need to request that. So it starts requesting the CSS because, as I said, the web font is based on two components, a CSS and a font file. And now I just basically grab those files from third party side. And there's no judgment. The only reason I did it is because that's what we often see is that very critical files are hosted on a CDN. So CDNs are great. And if you have international traffic, it's very important to serve the content to the user from a very close location. But don't forget that when you request resources from CDN, you make an additional connection. So you have to resolve the DNS. You have to do the socket connect. You have to do the S-cell negotiation. And then you have to actually request the resource. And so what happens here is you see we have the initial connection. We start with the CSS, the logo. And now, which is very common for an e-commerce site, we're having more CSS files. Bootstrap, Flex Slider, Font Awesome, responsive tabs, go back here, this type of thing. You're loading an extra file for these responsive tabs. And then once you're done with the CSS, you have some JavaScript. Because basically, for this slideshow here, you need JavaScript in the critical rendering path. So now you're going to get jQuery. You get modernized at custom.js. You have a JavaScript file for the mini-card image zoom, which is handy on desktop, probably on mobile. You don't really hover over and zoom. You sort of use your fingers to pinch. So questioning, is that actually necessary? Then you have the JavaScript file for the responsive tabs that I just showed you. So for this very small element of having three tabs in an accordion, you're loading maybe an extra CSS and an extra JavaScript file. And now what's happening, you're loading those web fonts from our server, which you declared in the code. I'm showing you that in a little bit. So now you're requesting the different variations of different W of FF2 files. And then you're moving on to images that you need. And one of the image being, for example, as you can see here, the inner 1.jpack image, which is basically this background image here. So it's rather unimportant, yet it blocks one connection for like 3.3 seconds. And this is something you really want to avoid. So if you have something like that, especially something rather unimportant, it's very crucial to optimize it as much as possible. And then you continue with the further images. So as you can see, the reason why you don't show the shoe image until the 10th second is because you're kind of busy doing other stuff. You're kind of busy using loading JavaScript. The JavaScript was put at the very bottom. So you're delaying the process even a little bit longer. And then you're loading resources like our fonts, which are great, of course. But you might not want to load them at this moment. You kind of want to free up space to load the critical resources. So right now, this is 44 requests, as I said, is very abstract. Usually there would be way more requests because you maybe have more products. You have some tracking pixels, et cetera. But just to give an idea where do actually the problems come from, although the site is very nice and it is already optimized, but there's still stuff that we can do. So now that we looked at this, let's talk about what we can actually do. And also over to this screen here. So we had this file initially. And the first step you want to do is critical resources host on your own server, unless you're very sure that you get a better performance out of the CDN. So definitely do a quick A&B test and make sure that if you use a CDN, you're not actually delaying the process. So usually it's used to help you. So make sure that it does. So this would be the first thing you do. You host the resources yourself. But that's how the site basically that just showed you basically looks like. So you're starting the document, and then you have multiple CSS files. So you're building your site on Bootstrap.css, which is very popular. And there's nothing wrong with Bootstrap. It's a great framework. But what you also need to remember is that Bootstrap is built for a kind of like vast selection of sites. Like it's kind of like this one size fits all thing. So you potentially load a lot of CSS that you don't really need for your site. So keep that in mind when making decisions to use a framework rather than code your own. And then you load more CSS like Flex, Slider, Font Awesome, the responsive tab CSS, some style CSS. And here I added a custom CSS to make some overwrites. And then you go down the code, go on the code. That's all familiar to you. And then at the very bottom, what you do is go here. So that's when it starts working with the JavaScript. So like suddenly here you're starting to load jQuery, which you load at the very bottom yet you actually need it for the above default content. So also keep that in mind. You're loading the Modernizer, you're loading MiniCard, you're having Image Zoom, what I briefly explained as well. Do you really need Image Zoom on a mobile device? Probably not. You're loading the easy responsive tabs.js, which is its own file, which all it does is it toggles between the accordion elements. And I'll show you that you actually don't need JavaScript for that. And then you basically define the ID, like the diff with the ID that you want to use that function on. You've got the flex slider, which is your slideshow for the shoes. And now you've got stuff like move top.js, which is basically, it allows you to do something like let's move over here, like something like this here. Click here, and then it moves up. This is like, it's rather a gimmick because people are used to scrolling on a mobile device. And it flows quite nicely. So having such button is rather unnecessary, especially if you load an additional JavaScript file for it. Then you've got the easing jQuery plug-ins like smooth crawling. And then you maybe have bootstrap.js down here. I actually tested it. It's not even necessary to display what we're displaying there. So as you can see, you're loading a lot of resources, a lot of CSS, a lot of JavaScript, and not all of it's necessary. And now, basically, what we want to do is we want to optimize that. So I basically created just copy and paste that HTML file and then just call the index underscore optimized. And now I'll just quickly summarize what we can do here or what I've done, what could give you an idea, what's maybe possible on your own side or page. So first is extract the critical CSS. And I thought about it quite a long time to see. And I was thinking, OK, how should I actually show those optimization techniques? Should I go all in and basically create something that's almost impossible to replicate? Or should I really work with what I have and say, OK, maybe I don't optimize it to maybe down to two seconds or one second, but I work with what I have and I don't delete too much stuff because as you know, it's easier said than done to just delete parts of your CSS, follow and delete parts of your JavaScript. So what I've done instead is I really kept everything that was on the initials page. I kept it. I just optimized it a little bit for speed because I think this gives you just a better understanding of it. So again, extract critical CSS. What do I mean by that? I didn't go through bootstrap CSS and now try to extract the critical CSS because that might not be possible in your situation. Rather, what I did is think about, what do I really not need in the above the full content? And that would be, for example, I go here, just go up the code. It would be easy responsive tabs or font awesome because font awesome, what do you load it for maybe to display one or two icons? Is that really necessary? I would say no. Easy responsive tabs. Do you really need this? Well, the responsive tabs are not shown until like later, like below the fold. So you don't really need to load it at the very beginning. And then I just browse through the other files to see, OK, is there anything very obvious that I don't need to load? And then basically what I did is I created a critical CSS file and I used the load CSS function. So how does it look? The critical CSS file I basically moved over all the stuff that I believe is critical to display the page the way it was displayed before. And then I minimized it. Very important. A lot of files we see are not minimized. And you can really save a few kilobytes on that. So put it all on one line. This is now the critical CSS. And it's actually based on bits and pieces of bootstrap, flex slider, style CSS, and my custom CSS. Put it all on one line. That is your critical CSS. That's all you load. So if we go back in the waterfall here, we don't do this anymore. We don't want to load four different files anymore. Instead, we want to load one file. Now, I still want the rest of the CSS. And I don't want to delay the process further down the line. So now, all I did, again, that's what you should do. You copy-paste the load CSS function. You put it inside the head part of your page or website. And then you go down here. And here I defined CSS, because it's sitting in the CSS folder, non-critical. So this is basically holding all the CSS that I don't think is very critical at the very beginning. That's here. And again, I put it on one line, because you want to minimize CSS, JS, and HTML, because there's no reason not to. So the result that will come from this, and I'll show you the waterfall in a bit. We first run through all the things we've done. The result will be that we only load the one CSS file in the critical rendering path, is as will be loaded asynchronously. Now, what is the next thing we need? Well, if we look at the page, you see that we have the slideshow here. So in this case, I didn't want to get rid of the slideshow. And basically, not having a slideshow is definitely much quicker, because you are not relying on JavaScript. But it would be just easier to set them down, because for example, if you have shoes, you really want to show probably different angles. So we kept it in there. And to optimize it, what we did is we just moved up the jQuery and the Flex slider to put it at a very early point so that we get it done and that it's ready to actually load in the images of the shoes. So that's what we did here. So we basically split up the JavaScript files that we had at the very bottom, moved two up, and the others, we basically left where they were. So now we go all the way down. And what you will see is that I left the modernizer here and the mini card, because you will need it on that page. I deferred it, though, so that we don't load it early on. And now I got rid of a few JavaScript files, because if I just move quickly over here, I, for example, thought it was unnecessary to have the responsive tabs built with JavaScript. And I also think that the move to top JavaScript was, I don't think that's necessary in mobile. So we got rid of that. I also got rid of the image zoom because I think, again, on mobile, it's not really necessary to have that. So I reduced the number of JavaScripts that we needed. And I moved two up, I deferred two. And now you might say, okay, but what actually happened with the responsive tabs? So what we did is we just build it in CSS. So this is the other version and you can see it here. This was the initial version, where basically you have the responsive tabs built with JavaScript and it looks nice. And now we build it with CSS. I think it also looks nice. It looks very similar and you can obviously style it. It doesn't flow as nicely, but it does the job, right? So this is purely built with CSS. So you can actually get rid of the JavaScript and therefore get rid of resources you don't necessarily need. Now, the other thing that was happening or that happened in the initial page was this. So we had the font files. So basically we needed probably somewhere the OpenSense font 300, 300, italic 400, 600. So that's a bit exaggerated, but now the idea is that what we discussed earlier in length, we want that, but maybe we don't need it straight away. So instead, what we did is we moved it all the way to the bottom, just go here with this little function. Basically what it does is it loads the OpenSense, the OpenSense font actually here, I loaded two, I don't know why I did that, let's just do it quickly. It loads the font, but not until we're done with the rest. So like it does it on the unload event and the result is that it basically pushes down the font files until we're actually done with the more critical stuff. So this is a very, very quick function and you only need to define a fallback font, you can just use Sansarive for example, put this just before the HTML tag and then you're basically prioritizing other more important files. Now, next, what do we need to do? The next thing we want to do is for example, we want to optimize the images. So like we saw in the initial test that we load images for three seconds or 1.9 or 1.5 seconds and we kind of want to improve that as much as possible. So what you can do is, you can, let me just move over and move over here, you can just take all the images and go to Photoshop and see is there anything I can actually improve? Can I reduce the size, do I maybe load sizes that are too large for my screen? You can work with media queries to load a specific image based on the screen size, you can work with a source set and then what you should always do is compress the images. So like in this case, I like to use image optimum, it might not be your tool of choice, but basically you just take all the images, throw them in here and as you can see, you have savings of like 91%, 95%, 50%, 41%. So you save on a lot of bytes and kilobytes which will in the end really speed up your site. And now if we go back, so going back to the top, so what have we done? So we extracted the critical CSS, we're loading the non-critical CSS asynchronously with load CSS, we're loading the web fonts on the unload event, bear in mind that on the previous slides we showed you other ways of doing it, font face observer for example, so up to you if you wanna do it, how you wanna do it. We only loaded the necessary JavaScript, so we for example got rid of the move minus top.js and we moved up the jQuery and the flex slider. We optimized the images for quicker load times just because on a 3G connection, we have reduced speed so we wanna get done with each picture as quick as possible. And then last but not least we minified the HTML, CSS and JavaScript just to save down in kilobytes as well. Now, the site functionality is not different. You can still move the slider, you still have your little accordion here and you can play around with the design, you still have the images, like you have everything you had before so it's not like that it's a completely different site but it has a big impact. So just to have a look again, previously we were at five seconds so we had a render block for roughly five seconds and we didn't show the image until 10 seconds, right? The speed index was 6,300. Now we optimized with a few things so like as you saw it was not a lot, it was by no means difficult and now we basically brought it down to a speed index of 3,200 which is great because you basically cut it in half with very basic things. And as you can see here, now we're suddenly loading critical stuff after two and a half seconds rather than five, we're having the logo and the critical text after three seconds and then we're having the shoes after five and a half. So we cut down the time it takes to display the shoe by five seconds, which is a lot and you can see it here because we're only loading the critical CSS, we're loading the jQuery and the Flex that are early on because we need it, we say, okay, we really need this to display and then we're basically done after like just under two and a half seconds and we got time to actually load the images. So this is really great and as you can see what happened here as well is that we're loading the non-critical CSS down here and we're loading the custom, the modernizer JavaScript and a mini-card JavaScript just further down the line because we deferred it, right? If we go back here, it was up like just further up the waterfall, right? So it was, you know, the 11th request and now it's the 23rd request. What happens as well is that before we had 44 network requests and now we cut it down to 29. And I apologize that I got a 44 on the web on the font awesome font file. I will fix that. So you can see like that we also cut down the total amount of network connections which is great when we're talking about crawl budgets and you know like how much your server can handle and then how much the Google crawler will come by and all this stuff. So you can really see that it makes a huge, it makes a huge difference and it is not very difficult. So I hope this was kind of like a good way to give you an idea of what you can do. Now we had a look at some of the comments we will move over there right now and I just briefly glanced at it and I saw optimizing for speed is not everything. And you're completely right and I think we mentioned that, you know, many times optimizing for speed is not everything. And by no means we're saying that and that's why, you know, we're not saying, get rid of slideshows or get rid of this or that. It is really important to have certain elements on your side and have high quality images on your side. But what we are trying to give you an understanding of is that with a few little improvements you can shave off five seconds of showing a product image and you're not losing out on the usability, you're not losing out on design. It's the same page, it's just as functional but it's just slightly better optimized. I think it's also important to keep in mind an idea of an performance budget. It's always like, what do I pay for this feature in terms of speed and what might the extra seconds cost me in terms of online revenue? For example, like we touched upon this briefly before, A-B testing tags usually have to sit in the head, right, it's JavaScript, you have to have them there and they will probably slow down your site, you can also optimize them, but still they will slow down your site. But the gains you get from that, like the benefit you have from an A-B testing tag, if you really use it properly and use it a lot, I mean the insights you gain is way more work, we would say probably than it is to have like two extra seconds or one extra second of loading, right? Absolutely, I think it's a really good point. It's really important to gather data and to understand your customers and to understand what makes my customers convert. And if you find that your customers convert better when your site takes two seconds longer to load but you have maybe four high quality images, that's great, you can A-B test around. What we're saying is that's what we see globally that speed is a very crucial thing to use users are very impatient, so everything we suggest is take it with a pinch of salt and think about it, how to implement it on your side, but I think the examples we just gave you are very quick examples that you can do, have a high impact and don't reduce the usability of your site and I think that's the key message we want to get across. Any one question before we jump into the viewers question? Yeah, from my side would be, so let's say our customers have to prioritize because they can't optimize every product side and every landing page because as we saw before Christmas business or holiday business is starting soon, how would you recommend to prioritize that? Yes, I would probably try to really find the low-hanging fruit, so like, don't rely on one score, check your website with PageSuite inside, then you test my side with web page test and just see, like what is really the main problem? It can be as easy as not having G-SIP enabled. That could be one thing if you spot that, that's a very easy thing to fix. It could be that you haven't optimized your images and the image or one or two images sit in the critical rendering path, so optimizing both images might have a good impact already. Other than that, a focus on render blocking resources is obviously a good idea, CSS and JavaScript. I do understand it's not always easy. It depends how long or how many people have worked on the file and how well optimized or how many comments you have, so you know exactly what part is doing what on my side. So obviously this is really important to optimize the render blocking resources. That will depend a little bit on how much resources do you have to allocate to optimize your site. I would say another quick win might be the web fonts because I feel like that's a very easy thing to actually fix, it has a great impact. I mean, as you saw, not having text for three seconds is not great by just using a fallback font at first and you actually show text after, like immediately, I think that's a great improvement of the usability. Okay, let's quickly check if we can jump into one or two you viewers questions. Okay, so, could you explain the German labels? Ooh, I don't actually know where the German labels were. Let's go to the next question. I have a look and see if I can spot what was actually by that. Or maybe if you're still in the chat. Oh, it was probably the time before Christmas here, so it was the time line under the very first graph. So sorry for that, there was a German study. So there we had some German. It's basically the time before Christmas here. It's one week before Christmas, two and three days before Christmas. So thank you for pointing that out. A little bias here. Well, other than that, it looks like we don't have too many questions for now. Well, I think that's good. Maybe we touched upon everything. If not, as we said before, please keep in mind that we have a lot of videos already in our repositories. So I'd highly recommend going there, have a look. There's like a whole video on fonts. There's a whole video on slideshow, so you can improve them, which I think is very critical. The video on the purchase funnel and the checkout funnel, which might be very interesting, especially for retail. And yeah, lots of other stuff. So if you have more questions, I'd say go there or comment in the comments below. Definitely, and I would say, yeah, write a comment or else we'll see you probably, not probably, we'll definitely see you next month. So if you have anything that, you know, in mind, just take it to the next session, pop it in the live chat and we'll try to address it. And yeah, I would say thanks for listening. Thanks, Dennis, for your first session and thank you for two more. And yeah, I hope it was interesting. I hope the examples were somewhat practical. As I said, or as we both said, it's a rather abstract example. So it might not be applicable on all of your sites, but we hope that you got the idea of what we're trying to do. And I think the key message to take away is that, you know, improving performance is not always as tricky and complicated and time-consuming as it looks at first glance. That's true. Cool. With that, have a good day and let us know what you thought. We're thinking, send us some feedback and bye-bye. Bye, guys.