 Hi, guys. So this is Lucas and Dominic from the Google Office in Dublin. Welcome to our first hackathon on air. The purpose of today's session is to educate you a little bit about sort of the best practice for mobile site development. So like, we've been, you know, like, more and more companies see like the mobile moment like for their website, which means like that, you know, the traffic that comes from a smartphone is higher than the traffic that actually comes from a desktop. And because of that, it's really important that you optimize your site for mobile, that it's really fast and really optimized in terms of user experience. And we just, you know, want to talk you through some combinations that we see across the web and just give you some idea and come to some of that. We are going to be a host today. My name is Dominic and this is Lucas. And we're both mobile UX managers here at Google and maybe Lucas, you want to explain a little bit what we do here on the basis of them when support all the components design as well as no one's speed-optimizing. So we think that speed-optimizing is very crucial as Dominic is just a bit highlighted. So we set up a small system with you guys in order to give you some more insights of what we think and found to be very helpful for and so forth, and how we could make it just faster and as time goes by. Cool. So let's start. And just with a common question, why mobile site speed matters? Well, basically, like, you know, we use our smartphone all the time. Like, in fact, we use it like 150 times a day on average. And, you know, we go to work and we check our phone. We read news. We research products. And in many of those moments, like, we don't have the best mobile connection. So like, while you're at home, you might, you know, your smartphone is connected to the Wi-Fi and everything is super fast. But like, on the go, you like, you have like maybe a 4G connection or 3G connection. And this is where really like, site speed really starts to matter. So like, basically, like, at Google, like, for us, page speed is like, is very important. In fact, it's a ranking signal. And the reason for that is, is because users like deeply care about it. So like, one of the most frustrating things for users is waiting for slow pages to load. So like, we did like a little study and we basically asked what you dislike the most and browsing the web on your mobile device. And answers were like, something you would expect, like unplayable videos, or you're like, you know, getting redirected, or you see like those interstitials, like pop-ups, banners, something you don't really want to see. But actually, 46% said that waiting for slow pages to load is like, like the most frustrating thing on the web. And that's why we really want to focus today on like, how you can increase your page speed in order to like, try to better use our experience. So we want to just go ahead and see what you guys write on chat just to make sure that you have a good sound experience. Okay, I'll continue. But like, please let us know. Lost sound. Just checking if you can hear us now. Okay, I'll just continue. But like, if you experience, okay, if someone can hear us fine, so I'll just continue. And to continue, like with page speed, like it's actually like really critical to get your page or your entire website optimized, because in fact, 53% of consumers will abandon the site if it takes longer than three seconds to load. So if you think about it, if you don't optimize your critical rendering path, that's something that Lucas will pick up on like, like very shortly, then like, you can basically lose half of the people that actually want to interact with your site. So like, it's really critical to get this right. So and for measuring performance, there are certain metrics. And Lucas will now talk you through what metrics actually matter. Okay, so guys, I'm just going to switch to the other mic. And I hope that's going to work for you better. So we want to talk about what measures we at least look at. Obviously, in mobile speed performance, the community has a lot of different metrics that has been historically looked at. And the discussion is obviously ongoing. A low time first started rendering fully loaded page, which exactly, which is also interesting way to look at it, but obviously then speed index speed index is the main metric, I think that we are looking at at the moment, in order to determine on whether we think a page loads fast enough or not. So meaning, if you if you look at basically looking what the speed index means, having a representation of when the first actual meaningful paint is being painted on the on the viewport. And with that, we set our goal to definitely get speed indexes below 5,000 milliseconds. So if you haven't heard about speed index before, it's basically the index that web page test.org suggests, and which you can get as a result of a test there. And we will going to go into detail in a later idea. So that's for the moment, the main metric that we look at, in order to determine on whether we think the first paint is being made quick enough on the viewport for the users so that we don't lose attention or that we don't accidentally increase bounce rates. And so on that's a force. Yeah, and just before we go into the details of the ideas and suggestions that we want to give you from our experience, we just want to highlight the potential of an increased perception of speed that can be done with the different or that can be achieved with the different optimization suggestions that we are going to present. And so in the first case, as you see, on the second, okay, in the second row down there, you see that we have a speed index of 1,500. And by optimizing the critical rendering that we're going to go through in detail now. And further methods that we go through in hangouts, and we were able to basically get the speed index cut in half, getting the first meaningful paint in 0.9 seconds instead of 1.6. And by that, giving the user a much more fancy experience, which in turn, as you've seen at the very beginning from the metrics that Dominic suggested, has made more likely to be to a successful, for example, purchase or conversion for any type of any type of business. So getting that first paint quickly is crucial. And we want to show you what potential there is and what what tricks we look at in order to get that that that time down as as as we can. Just checking if the sound is okay. Yeah, I'm afraid there is not not much I can do at the very moment to improve the sound. Okay, I'm just going to talk very slow. And hope that this makes it. But just think that's better. So continue with the critical rendering path now, which is like really one of the most important issues to optimize on the side. So yeah, we've I've mentioned now a couple of times, the critical rendering path. What we aim for is an optimized progressive rendering, you know, so that we get the first reaction on the screen as first as fast as possible, and from there on build off build on the side, and then quicker ways we can. So in comparison to in comparison to an unoptimized rendering, we then get a reaction to the user much faster, which therefore will lead to the user having the feeling that something is happening on that screen much faster. And without we losing weight less users. I hope that works guys. Yeah, not much I can do. Unfortunately, have you tried? It works better for you, I guess. Okay, I would just I would just continue and hope that the people can roughly hear me. So okay, so talking about the critical rendering path is is basically what we have to do is we have to look into how do we take the path to the first layout and paint the part? How is that path being structured? And how can we optimize along that path? So looking at the right side of the screen, we see that we first have to parse the HTML towards building the DOM, then requesting the CSS, parsing the CSS, executing, sorry, requesting a CSS and JavaScript parsing the CSS, and then even executing the JavaScript, and the CSOM, and the DOM, then sort of result in the in the random tree, which then in turn lets us do the first paint. So everything that we have in that path that blocks this rendering or blocks that rendering path is going to make it much slower to get the first paint on the screen. And so therefore it's really important to focus on optimize the CSS as well as optimizing the JavaScript. So you see here, for example, if we look into our CSS, so that's commands, we see if we the browser basically is going through all the end trying to get the last command, which here tells us that that first the hackathon on air type text being read, then with the next command really turning into green. And the rendering path is basically being blocked until all that JavaScript is being being parsed and executed or used. And yeah, which basically means to us, we have to really take into consideration which which CSS do we really want to load? And what is critical for us? And how do we want to load the CSS in order to optimize the critical rendering path? Same old school for JavaScript, JavaScript needs to be executed fully before the critical rendering path is being finished. And the first paint is being done. Therefore, and we're going to go into a couple of suggestions on how you guys can optimize both CSS as well as JavaScript in order to get that paint much quicker done. Yeah, something you want to add to it? We just try to understand why the JavaScript is an extra render blocking. And it's just, you know, that both can change the document object quality. And that's why the browser has to wait until it's fully loaded in order to continue rendering the site. So like, yeah, there's some of that is really important. Just use a critical CSS JavaScript in the kind of view of your page in order to to make, you know, like the fake to like speed up the first page and get like this speed perceptual right? Yeah, and then just like a little bit of a deeper insight into the JavaScript. I mean, we know that basically downloading JavaScript and executing the script will pause the parsing of the HTML. So therefore, we basically prolong the time of the overall layout and paint creation on that the JavaScript that we decide to download and to execute at the top or at the header, basically will make things slower or will make the first paint slower. So we have to be very, very strict with ourselves in order to put just the right code that we really need and use the right techniques in order to minimize the blocking of the critical rendering class. So yeah, you can see it here. See a very clearly clearly we have an example here, where we get at least the first somewhat reaction on the on the screen of the first of the four seconds. And from there on the page needs to be built up. And we can see in the waterfall very clearly that we have all the CSS being being pulled and loaded as well as the JavaScript and in line five. And all of this is render blocking, right? So we have to really take into consideration, do we need all that CSS and all that JavaScript and do we load it in the optimized manner? And there's definitely room for improvement in this particular example, given that we see the first reaction on the screen after four seconds. Yeah, so I think it just it's another another point to highlight a really important is to think strategically about how you place and how you use your CSS as well as your JavaScript. Okay, so I don't want to just leave you with pointing to the problem and not highlighting a few ways to solve it. So we want to go now through a couple of ways so you can really attacking to optimizing your CSS and JavaScript in order to get a quick paint on the screen. So one option is to place JavaScript files in the footer. Obviously, that only applies if there is no other dependencies in the core in the code down on that JavaScript. But in many, many cases, we can move the JavaScript basically down into the footer. And that has shown in many times very effective and really, really cutting low time down or really cutting the speed index down, I should say, by even by half a couple of times. A couple of things you want to say to async and defer. Yeah, I mean, another option for for JavaScript is to load it like a sit like with async or defer, you can actually use both attributes in the script tech where async will be preferred before defer. And basically, what it means is that the JavaScript is loaded is downloaded while the HTML can still be parsed. And then you only have like a very short period of time when it's executed. That's when the parsing stops. And just right after it continues with defer. It's that you download the JavaScript while you parse the page and the execution only happens after the entire parsing is done. It depends on your side which one you want to use. Generally, we suggest async. But but as I said, you can use both attributes in the script tech. And, you know, it will basically try to use async first. And if it can't do it, it will use defer. Yeah, and just one side note for all of you guys who have the experience of a bad audio, we will definitely obviously fix that for the next time, because that's definitely not going to be the last hangout, as well as checking if we can get a recording done with a better audio. So we hear your feedback. So let's go into CSS and what you can do there. Obviously, one way is one important thing is if your whole CSS file is being loaded in the header at the very head at the very top, it's just going to add to blocking the critical rendering path. Because one thing is for sure CSS by default blocks the critical rendering path. So what we have to do now is try to get as little as CSS in the way of setting up of the first paint. So there is a couple of ways you can do it. And I think some of the guys are familiar already. Before we jump into this one actually, obviously the one is to inline critical CSS. So really get only the critical CSS that you really require for that particular, above the full viewport content and structure and put that inline into your code. There is fortunately a tool that you can basically use through command through terminal. And we can extract basically for every domain that you choose the critical CSS for that particular for that particular viewport. Yeah, and I don't want to go too much into detail about that tool, but you see the link down here. You can post the video. Maybe we just also put the link in the comments afterwards, actually, sorry, the description afterwards. So it's easier for you to find. Yeah, but basically what you can do is choose your choose your domain and extract the critical CSS and place that on all the pages that you consider to be landing pages. Yeah, and make it therefore just much faster to load the CSS. And therefore, having the CSS file that needs to be loaded. I mean, the file doesn't need to be loaded anymore, because we load inline. And by therefore, we getting a first paint much, much, much quicker on the screen. I mean, we have seen many, many things, for example, in the in the CSS files, even the information for the website to be printed, being loaded in the initial in the initial in the head, which is just not necessarily necessary, if you want to just quickly get that first paint, which is so important, and has so much impact really on conversion rate and for the user behavior. So one way for you to get the critical CSS extracted from your code using that tool will save you a lot of time and make users much happier. And what about the rest of the CSS? The rest of the CSS obviously still needs to be loaded. So basically, the non critical CSS that sits below the fold of that particular landing page. This particular CSS code can be as you see here, can be loaded through JavaScript, as in groomed sleep, and placed in the placed in the footer. So we don't block the critical rendering path. And again, freed up the critical rendering path, just a little bit more to gain that couple of more milliseconds, or seconds, in many cases, and get the paint quicker to the user. In order to do that, we also have a link for you guys, check the on GitHub, we put it on the description as well. If you want to dive deeper there, and get your side even faster. Yeah, just to add to to what CSS to the JavaScript function. So like, there are more browsers now that also support the preload markup pattern. This should be preferred to the CSS function. However, you can basically use both like for those browsers that that supports preload, you can just use it and use let CSS as a fallback. I believe the browser that supported at the moment is Chrome, Chrome for Android, the Android browser and Opera. And obviously, in the future, there will be more browsers supporting it. But for all that don't just use let CSS as a fallback. I'm just looking at the question here from Perry, and he's asking, how do we decide what's the critical CSS, when the fold is so variable? Well, I mean, it's a good question. And it's, it's hard to give like, you know, one answer that that kind of like suits everyone. Ideally, you should, you know, just determine what content is most important to, you know, to to drive a conversion, and then see that you place this content above the fold on any device, really. And then this should be record regarded as the critical rendering path. So, so like, really, like, we're talking about the content that drives a conversion for you, whether you want to generate a lead or you want to drive a sale, or you want to, you know, you just want to get signups to your to your web app. So all this should be placed kind of like within the critical area, and it should be visible on any device above the fold. And now we want to jump to the next topic, which is images, like how to optimize loading images on all devices, because on average, the majority of websites weight results from image content. And this is where we see a lot of small mistakes that webmasters, developers do. And this is something that could easily optimize and it has a huge impact on the pain speed of your site. So the common mistakes that that impact the performance of your mobile site is some are the following two commands. It's, you basically set an image to display none, or you set an image to mix with 100%. And what it means, or where it's commonly used is you have a large image on desktop. And then like on the mobile device and say, I don't really need that actually anymore. And so, and then use a set of display none, and then, you know, it's gone. Like you said, I can't see that it's not there anymore. The problem is that it's still loaded. So like why you actually don't display it and it doesn't have like any, any positive influence on the user experience of your user. It actually has a negative influence because it increases the pain speed. And therefore, like the, it might even impact the critical rendering path. If this image is loaded, very early on, but it's basically not even shown. And this, for example, is like, like a typical example. So like, on the homepage, you have like a really big image, and it looks really pretty. You you chose a large area, but like 100, 1800 pixels width. So like it fits most large desktops. And then on on the smartphone, you're kind of like said, well, this image is kind of too big, but I don't really want to use a different one. So I'm just basically set the maximum to 100%. And it looks fine. The problem is that this image is so big. And if you actually try to load that on the 3G connection, it will take a very, very long time until it's shown. And since this image is, it's placed like above the phone, which is what a critical content is supposed to be, this is a real issue when it comes to almost an optimization. And in order to solve that, you can use the source set attribute. So like the source event attribute is is an attribute for the image tag, which basically means that you can you can decide which image to show based on the resolution of your, of your device. So like, you do send a default image that, you know, that that will be shown if none of the media query is actually like has a same, however, depending on the size of your of your device, whether it's like, you know, whether it's like 400 pixels or 640 pixels or 1000 pixels, you choose a different image. And that's a really powerful attribute because basically, you do load the same image, however, you really only look at optimized version of the image based on based on the device type and the resolution. And this really positively impacts the page without your science. And I highly recommend using source set. And then like, if you use background images, then it's really important to use a media query based on like the minimum width, because this allows you to, to look different background images based on what width, like what resolution the user is actually on. So like, again, in this example, you can see that like, at a minimum width of 1200 pixels, we look like a, a background image that's like 2000 in width, which might not even be pretty optimized, but it's just to give you an example. And if you actually look at like, smaller, smaller, smaller resolutions, like, you know, 700, 768 pixels, like, you know, what would be an iPad, for example, you can look like actually a much smaller version of that image. And again, like because it's smaller, the image weight is actually much, much lower as well. And therefore you increase the page speed. So it's really important to get this right in order to optimize your site. And then there's like, actually like a tricky thing if you use a media query with the max width, with the max width command. So like, basically, here, we have a media query and we send like max width 768 pixels, which means up to 768 pixels, do this. And here we say, display not to all the image tags. So there might be, might look like a good idea because, you know, the images don't appear anymore. But the problem is, if you actually look at the network type of pro webmaster tools, which I wouldn't be able to mention to use, you can see that this image is actually still loaded. So like, again, it's the same, it's the same example. You're not showing an image or you're not showing a certain content type. Therefore, it doesn't add any value to the user and to the user experience. However, you still load it in the background, which means like you actually negatively impact the page speed. Like, like we really are just suggest here to like, to like not use those CSS commands, you know, just to like, really get this page speed thing, thing right and improve the loading time of your websites. And this would be a way you could do that actually. So like, basically, you could say that up to 768 pixels, there is no background image. And then like, once you have a user that accesses your side from like, from a device, the higher resolution, you can actually then like, load an image through the background, the background image commands. And another thing is to use image compression. So like, everyone probably knows like how to use image how to save images for the web on Photoshop. But there are like a few things you consider and especially considered the quality percentage that you want to choose because we often see that that images are saved in like, you know, like the highest quality. But the question is, is that always actually necessary? Because if you go to this example, basically, what we did here is like, we save the same image at a different quality level. The left image is 150 kilobytes. The right image is almost half it's like 86 kilobytes. And there's almost no difference here. So like, maybe some of you can say, or can see that the red in the left image is slightly more bright than on the right. But other than that, there's really no difference. So like, what we say here is like, read inside how important is each image for your site? And can you actually lower the quality without losing the impact that has on the user on your site? So it's really important to get it to get it right. Just try to like, you know, like lower the quality on any image as much as possible. As much as you think that you can still use on the site, it still looks good. It still drives the conversion. If the image, if the purpose of the image is to drive conversion, but just try to get the kilobytes down. And another, another great tool to use is actually loading the images on demand with lazy loading. So this is really like another, another big problem on the web that we see all the time. So like, it's basically, you see that you load a mobile site, you load it over three, you only have a certain bandwidth. And then like, all the images on that time are getting loaded at the same time. And the problem what happens then is like, it's kind of like a funnel. So like, you know, all the images like, or like, or take like that, like have like a, like a sad, sad clock, like all the images don't go in there. And now they try to get through like this, you know, like through like this, this little space there. But they can't do it at the same time. So every image gets like a little bit of the bandwidth, and then they just go very slowly simultaneously. And that's really bad. Like, if the images are large early on, like for example, the slider, this really actually impacts the critical bandwidth as a like, like the first, the first paint of your sound. But it also impacts the entire loading time of your side, because, you know, if there's a lot of images, like you have two or three sliders on your side, or you have like those, those galleries where you want to show before after pictures, and all those pictures need to be loaded at the same time, although the user is not actually scrolling down to that, to that part of the content, then you just impact the load time without really, you know, without any purpose behind it. So that's why we, why we really emphasize lazy learning as a great tool to tackle this problem. And you can see basically here, what I just said, so like, here you can see that there are multiple images that are loaded at the same time. And the interesting thing to notice is that each image is probably not even that big. But because they're loaded at the same time and because they fail, the bandwidth of the 3d, 3d connection, it takes in certain cases up to 12 seconds to load a image. I mean, we all know that like, you know, 12 seconds is a really long time, especially on a mobile device, because, you know, people tend to be always, you know, what they're like, on their phone, right? They're not really patient, because they're on the side. And while they're actually viewing the side, someone wants, you know, someone wants that message or something. So like, they feel like they kind of like lose attention very quickly. And so it's really important to get this living time right. And you can see like, quite well here, like you can see basically the bandwidth, and then like the green curve goes all the way up, and then it stays out there. And that's basically what all the images are being downloaded. And here's like a small gif that actually shows you how lazy learning works. So like, basically, lazy learning does not load the image until the user actually accesses the content. So on the right, the network tab, you can see how the images are loaded while the user scrolls down. And really, the idea behind it is, why should we look at an image for a user that doesn't want to access that image or doesn't want to view that image at that point. So it's a really, really powerful tool. It's very easily implemented. And yeah, we just suggest, you know, check it out. We put the GitHub link on that slide and just test it with your site. There's one thing to mention, though. I'm sure some of you will ask a question whether, you know, how does lazy learning work with the whole like, you know, indexing by Google. And it's a really good question. And it's a very tricky thing. So we generally suggest that like, even an image is a main traffic driver to your site. Don't lazy learn it. In this case, just learn it as you did before. Because it is quite tricky whether lazy learning images are indexed as properly by search engines as images that are not lazy learning. So again, don't use that for an image that is a major traffic driver to your site. But for all other images, it's very safe to use. And that's basically just a very quick, you know, very quick example of how it works. So like, basically, you load the lazy sizes of plugging into your site. And then to the image tag, you have the class lazy load. And instead of source, this data source, and then you know, you add the image in there. And that's basically that's that's already how you implement lazy learning. So it's very simple to do. And the great thing is it also works with a source set. And that's the example below. So like, feel free to review it. There's some more examples on the GitHub page. So yeah, it's very simple. And it has a really great impact on the page of your site. Yeah, we also did a live test. Do you want to do that? Yeah. So one of the one of the guys watching right now was happy for us to do a live test on on their site. Like we really pre filtered because I think we both think it's great to like have those examples in such a session. So the site was Missouri Torsch. I hope that was correct French, if not, excuse me. And the web page test, the speed and the score shows that that is at 5000, which is actually not bad. So like, you know, that's that's that's not a bad score at all. And that's something you should actually aim for. However, it would be unfortunately too easy to say, okay, that's all good. And we can stop here. Because there's one issue. And that's the first three seconds of that side. So as I discussed earlier, it's like, that 53% of consumers will abandon the site if it takes longer than three seconds to load. And we can see here from basically, what page test takes images every half second to see how far have we gone with the content in terms of like rendering. And we can see here that the first three seconds and in fact, the first four seconds, nothing is displayed. And that's a real issue. If you think about that, you know, half of the users in the first three seconds and nothing is displayed. So the user access your site wants to get to the content quickly. And suddenly, you know, there is no content. And then you look at one second, maybe two seconds. And I like, you know, suddenly they start to sort of like drop off. And we always like to use an example of like, you know, you're going to the supermarket and the doors closed. And, you know, like you're knocking and you don't see the doors not open. It's not starting to open. You don't hear any steps of someone that's coming to open the door. And you just wait there. How long would you wait? Well, in real life, probably a little longer than three seconds. But on the mobile that went unfortunately, because everyone is in the room. It is really only three seconds for half the people. So it's really important to get this right to optimize the critical rendering path to reduce this high percentage of consumers. Let me see the speed and the sweet spot. So there is quite some research on how this speed and next load and conversion rate can relate to each other. So basically from two seconds and below is really what we want to try to aim for. Correct. So and I wanted to like, basically show you guys how that looks in the video. Because I feel like, you know, once you actually get it, like, like, you basically see it, then you're kind of like realize that you really need to optimize. So like, in this video, basically, we just test the site and just for you to understand, whenever we test mobile sites, we do them a 3G connection. So like, in this case, the configuration on web page test.org was a 3G connection on emulated Nexus 5 Chrome browser and the 3G fast actually 3G fast connection. So the different types of connections you can choose. And we use the 3G fast. And this is how it looks. And you see after 4.2 seconds, actually, that's when the content starts, starts showing. And, and this is like, like, like a real issue, considering so many users leave after three, three seconds. So as Lucas said, we really try to encourage you to get this the rendering of the page going as quickly as possible, ideally under one second just to see that something is building up, that the user's patience is increased a little bit. Second. Okay. And now, what are the issues for, for delaying a critical rendering path. And in this case, it's the JavaScript. So like, all this JavaScript is loaded in the head of the, of the website. And as we discussed before, everything that's loaded in the, in the head, which is not loaded async is brand up locking. And you can see, like, you're loading jQuery, you're loading jQuery migrating, you're loading the easy, the easy plugin. You load bootstrap, you load BX slider. So the question here is, like, do you really need all those libraries, all those flavors, all those plugins in order to render the, the, the first bit of your site? In most cases, actually, no, you don't. So we really emphasize to like, go through the code or go through the different plugins through your CSS JavaScript, and see what do I actually need for that specific page. Don't let's don't just learn everything you need somewhere with a sign of every page. Because it is easy. And it's obviously the most convenient way of doing it. But it's just really negatively impacts a page speed. And it really makes you lose business inside, and it makes, it makes you lose conversions. So that's really important to get that, get that right. And, and this is how it looks, actually, when you analyze the, the web page test results. So like, you see all those JavaScript files, and they're all loaded. And then you actually see, like, you know, like, like, each one of them doesn't mean that might not even be that big. But because again, they're loaded simultaneously, they're just all trying to get a little bit of the bandwidth of the 3G connection. And then it just goes on and on and on. And it's, yeah, again, like, the same analogy I made earlier, it's kind of like, you know, it's this funnel thing, like all the JavaScript comes in there, but there's not enough space for them to get through at the same time. And then they just stack up and then like, it takes longer and longer until they're all through. And while this is happening, the browser is not going to break the page. And that's, that's really critical. And it's really, really, like, we really advise against to work on this. And yeah, last but not least, we use the web page test to do this analysis. And we really encourage you to do the same. The link is www.webpage test.org. In terms of configuration, we'll, we'll surely post in the comments. But for this test, we use 3G fast from Irish server, but you should definitely use the server that's closest to you. So if you're located in Germany, use a German server, if you're located in the UK, in the UK server, and emulated Nexus 5 and the Chrome browser, it really gives you great insights. And yeah, that's, that's, that's essential for today. And I believe we also had some questions that will be asked to send us some questions. And yeah, we want to discuss the few of them. So yeah, I have seen actually a couple of times on the chat that people were asking where to do all these tests, as Dominic just mentioned, I just want to so echo that checking on the web page test.org and making sure that it's actually set to, to a mobile device. So you do that and I think the advanced setting, so the initial settings, but also what we do is to actually run a couple of tests. So don't be content with one test that you're running. So I would say something like at least five tests, you can actually also set that up in the initial setup. So not relying on one particular instance there, and get results that you can be you really be working with. You also get those videos in screenshots, the waterfalls there. And a very great overview on how quick you actually get contents on the viewport. So yeah, it's a particular question if you want to jump in first right now. I'll just pick up on one question that one of you guys asked, it's actually about using Angular and React. So the question was single page sites using frameworks like Angular and React can reduce network usage by rendering HTML client side, but can sometimes introduce heavy CPU load. A mobile network speeds continue to improve faster than battery tag. Is there a trade off to be considered by rendering computationally expensive HTML fragment server side at the cost of greater bandwidth usage on the mobile device? So long story short, or first of all, like Angular and React is like a different animal and we sort of agree to do like a special session about those two frameworks. I just want to basically give you a quick answer to this one. So like, usually JavaScript frameworks like Angular are quite heavy on the first load site. On a mobile device, it's a tricky thing because you first need to download the framework, it can take quite a long time. So it's not ideal for the critical rendering path. We really encourage you that if it's absolutely crucial for your site to use a framework like Angular, please do it and try to get the optimization right. Like you can do like, you know, you can do like some pre some pre canceling server side. But really, if it's if it's if it's not essential to use Angular on your site, don't do that. I've seen a couple of sites that have built on Angular, where it was not required, and it negatively impacts your patient without giving any positive and any positive side to the user. There's no positive impact in terms of user experience. So really decide carefully if you need it. It must be decided on case-by-case. I just want to give a quick side note. What we're going to do is, I mean, we definitely have the audio situation in mind and we fixed that for the next hangout. So we hope to have somewhat regular sessions with you guys. But on the second note there, we're going to send out a quick survey as well. It would be great if you could just reply to that. We're just going to send that, I'd say, by tonight. So to just, yeah, if there's further issues for the topics that you want to dive into deeper, if we should focus on one particular issue like all this type of stuff we would like to collect from you guys so we can make it even more, more actionable, more helpful for you guys. Yeah, it's a particular question. I think the next question was just about HTTP 2. So HTTP 2 is quite powerful. It's obviously the newer protocol. And the great feature it has is the so-called server push. So like basically, you ask the server for the page, for like page content, and then the server anticipates what else you might need next, and then just pushes this to the browser without you asking again. So like basically what it means, you don't need as many HTTP requests, which really like speeds up the whole rendering of your site. One prerequisite of HTTP 2 is HTTPS. It needs to be like an SSL certificate needs to be implemented. And we tested HTTP 2, it's not like something that you can just sort of like set up on the fly, but we really encourage you to do it on your local server, test it, see how it impacts your site. There are also some CDNs that already offer it. So it might be a good solution for you to host your, for example, your image content on the CDN that uses HTTP 2, and basically make use of it this way. There's no one answer for everyone, but it's definitely a great way to improve your site. Just go out test it. Yeah, if you have any further questions, just post it in the comments later on and we'll try to help in the best possible way. And I see another another question here or more like a comment, and it's leveraging browser caching. Yeah, we only encourage you to do that. It's a really great way, especially for for resources that don't change very often. So for images that don't change or you know, for JavaScript, resources that that don't change, definitely enable that effort, definitely leverage browser caching because, you know, users that might come back to your site, again, will have a much faster experience. And today, because the customer journey is, you know, so long it's not anymore that someone comes to your site once and does all the research and then drives the conversion. But like, you know, users tried like like to inform themselves like over a longer period of time, it can be like the accessor site in the morning. And then they go to work and then there's some more research. And at night, they access your site again. And in this case, if you do the browser caching right, like the user has a much faster experience the second time. And this will really positively impact your user experience, your page speed and ultimately, increase the conversion rate. And yeah, another comment I see is WordPress. That's quite, it's really quite simple. And it's like one thing I can probably mention here. So like, what WordPress does is like, by default, it loads jQuery and jQuery migrate. So jQuery migrate is not always necessary. The only reason WordPress loads this plugin by default is because, you know, typically the typical WordPress user uses a lot of plugins to get the site going. And if a plugin is not compatible to the jQuery version, then it makes migrate in order to make it work. So like, basically, WordPress noticed the migrate plugin to give like an overall better experience to WordPress users. So like, if you don't install the plugin, then the plugin doesn't work because it doesn't work with the jQuery version. If you're really serious about optimizing your site, I would just encourage you to look into the plugins that you use, always use as little plugins as possible. Just because you don't list, like, you know, there are a lot of plugins that do a lot of things, but you maybe only need a fraction of it. So I wouldn't suggest, you know, to negatively impact your site by it's only too many plugins that may only serve very little purpose. But if you use plugins, make sure or check with what jQuery version they are actually, you know, able to work with. And if it turns out that they don't actually require jQuery migrate, you can disable it. Again, it's just one plugin, but it will still have an effect on the page load. And other than that, yeah, the general suggestion is whether it's WordPress, whether it's any other content management system or any website, just try to minimize the amount of resources you use and download, especially for the critical above the full content. We definitely hear a lot of questions on various Google clients about the different content management systems as well as the different shop systems. So maybe having a deeper look there could be a topic for a further Hangout Session in the future could be one thing. So feel free to highlight them in the survey. If that's something you would like to look into more in more depth. Yeah. So again, I want to highlight we sent out a quick survey where we would like to to get your feedback. Again, this is sort of our team. And this I actually want to shout out Olga and Antoine that you find in the chat also part of our team members who try to like if you some advice through the chat as well. And yeah, so we hope to stay in contact with you guys, share ideas, share tips feel free also to share tips obviously amongst each other so that we all together can get the mobile web much faster. Great. So let's say that's it for now. Yeah, thanks very much guys. If there are any more questions, just please put them in the chat and we'll try to answer them. And I just saw one more question on AMP from our own technologies is AP methodology? Well, I guess it means can the AP methodology help increase page speed? It surely can. AMP is really powerful. It's also limited. So like it's not yet available for every type of website. So you basically need to dig through the documentation and see if it works for you. But for sure, it's really great. It really speeds up web pages. And we can see like, really, like really good results. In fact, like over the last year, I think we index over 600 million pages that already work with AMP. So definitely look into that. Yeah. So what I'm also going to do is I put another article for you guys in the, in the description of the video, where actually one of our team members, Malta, from the AMP team goes through all the details on how AMP actually becomes AMP and how you can use those methodologies, maybe even partially to just get your speed faster without like leveraging the whole sort of setup. Yeah, but definitely AMP is another topic again, that we can maybe look in much more depth in the future. So for today, we really looked into the critical rendering part, image optimization, and hope to get you guys working on that so that we all can see faster sets for you guys, more success than for your, for the organizations that you're working in. Great. So yeah, we put the links in the description. And we thank you all for, for showing up, even though some of the invites were a bit short notice. So thanks a lot for that. We appreciate that. And I hope to see you, see you next time, guys. Just one more thing, like please on the on the feedback, don't hold back with, you know, any suggestions of how we can, you know, improve sessions, because we want to run them way more often in the next year. Okay, the microphone thing, well, I think we got that. We'll, we'll try to work on the tech here, but anything else, just, you know, let us know, and we'll make sure that like, we'll, you know, improve the sessions further for, yeah, for 2017. So yeah, Merry Christmas and good luck optimizing your sides. Bye bye.