 Good day, guys. Sorry for the small delay. And we're looking forward to start the hackathon on air today with you guys. So let me quickly introduce ourselves so that you guys know who we are and what we'd like to talk with you, chat with you about your ping us questions, try to learn a couple of concepts today. So I'm Lucas from the mobile site transformation team from Google. And what we do is we meet Google clients across the different verticals, across the different markets and try to optimize and suggest optimization techniques for the mobile websites to get them faster. And with me, I have today my colleague Dominic. Hi, guys. I'm Dominic. I'm basically also mobile UX manager at Google, doing the same as Lucas just for a different market. And we basically put together a presentation and just basically running through it together, answer all your questions. And yeah. Yeah. And because we see various clients basically on a daily basis, and we've seen the topic of fund optimization using web funds or using system funds in whichever way people are using funds to as an interesting topic to actually use it as a deeper insight in order to just gain a couple of, maybe a million seconds a second, and also different sort of loading perception for the user. And yeah. Therefore, we want to dive deeper into that topic, but I just want to quickly recap maybe for the ones who haven't been there last time, just as sort of as a framework for this, we run those sessions about once a month. And I just want to recap a little bit about why our team cares so much about mobile speed and why our team sees speed not so much as a nice to have but as a core feature of basically every mobile website. And I mean, there's various different reason, obviously. From the different angles that you look at the topic of speed and speed performance, there's various reasons to clearly show us that we should focusing on mobile speed. The one is obviously the user experience, right? So people just really don't like to wait for slow loading pages. And basically, or in fact, is what they dislike the most about their experiences on the web on the mobile device. And that reflects back into various metrics being impacted by speed load. And what is an interesting thing, an interesting insight that we just like to share with basically the teams that we're meeting is just that this really top of mind is that a Google wide study across, let's say, nearly 4,000 anonymized accounts. The actual end was a 3.7K. The study showed that 53% of users will leave a site if it takes longer than three seconds to load, right? And therefore, we think it's really important to look into all the different ways how we can get content quicker to the screen, how we can get the first paint tester on the U-Port to basically catch those people and to not let them run away while they're seeing, in worst case, the purely white screen. Yeah, and I think I just want to give a couple of words on how we in this team measure performance, speed performance, and sort of then we can dive in a little bit more in detail what we wanted to talk about today. So, obviously the world of performance has a lot of metrics to look at. What we take as a guideline to look at is looking at the speed index of the tool, webpagetest.org. I'm not sure if everybody of you guys have been playing around with webpagetest. I'm gonna show a couple of details on how you can, or basically how the Google team sets it up for the testing baseline to test for speed. But what we look at is really speed index, which gives you sort of an average of how quick you get basically the visual progress of the first U-Port being painted on the screen. So, if we have, for example, the speed index of like in this case, 2,309 sort of across various tests in that average we have the first sort of the screen filled to a large percent. Anything you want to add? Oh, we covered it, cool. And yeah, basically the goal is keeping in mind this idea that 53% of the users tend to leave sites when they don't load longer than three seconds, the goal is to really get that speed index as low as we can. There's different challenges, obviously, to that. There's different approaches on how to make that happen. Last week, sorry, not last week, last month, we, or last session, I should better say, we spoke about the critical rendering path, which is obviously a huge contributor to how quickly you can actually render something on the screen there and get the U-Port filled. So, if you're interested in that, there should be the link around for you guys. We will be happy to share that afterwards so you can go into that and see how we look into the critical rendering path. And, yeah, today we want to focus more on the web front or front optimization in general. Quick word, just to webpagetest.org, it's actually a tool built by a Googler, so we might be a little biased, but we think it's definitely a great tool to have a good testing baseline, given that you can emulate, I mean, always taking the caveat of it being a synthetic testing environment, you can basically get your testing environment set up the way it suits you sort of the best. So, you go for the URL that you want to test, you go for the test location that you want to pick, you can choose the browsers, obviously, you can choose the devices that you want to emulate, and we usually test on a baseline of 3G fast, given that we see that to be sort of a fair experience that we can, I mean, the fair experience that we want to test against, because there might be users that are having a better experience, but there might also be a lot of users that have much worth experience, and therefore we consider 3G fast to be the baseline that we aim to test against, and sort of say 5,000, what we see, 5,000 speed index should be the maximum that your page will be loaded in order to be able to deliver the experience in terms of speed that we think, or did the numbers suggest not so much that we think, did the numbers suggest that it suggests to be the most beneficial, having the most beneficial repercussions on conversion rates, bounce rates, and so on. I think just to add there, so like there are a few sites that you can find online where you can test the network coverage in your region or in your country, and we would highly recommend to do that and just see what's the network coverage with 4G, 4G Plus, or 3G, because you will be really surprised as surprised as we were. So if I look at the markers I usually focus on, which is Germany, for certain providers, it's really like amazing how little 4G coverage there is, and that's kind of like why we say, we test on 3G this way, we kind of like use the worst case, and if we optimize for the worst case, we kind of create a better experience for like the entire user base that's visiting your site, so that's the idea behind it. Great, if the chat opened up just in case that we see something coming up, and feel free to guys to post questions on the chat, we try to answer that because we got the feedback from you guys last time that we went a little bit sort of to quick through the different topics, so we want to quickly pause after the different things that we raised so that you guys have time to ask your questions. There should be also, at least last time where there are a couple of team members entering and totally taking on some questions. Just type away your questions, we'll try to pick them up as good as we can, and there are probably some guys in there, and so we'll really try to like just answer all your questions in the session, so. Okay, so again, that you can achieve a lot by optimizing your speed index, is basically what we see here, right? It's nothing, I guess after what we just discussed shouldn't be coming as a surprise. The lower you get your speed index here, the much faster the loading, I mean the perception really is that the user has a better the perception is because the user gets much, much quicker content being pushed on the screen, and today we really want to talk about not so much for example as we talked last time on how you stopped the rendering be blocked, but how quick do you get, especially text contents or fonts, text that is written in the various font versions that are out there on the screen, and how can you optimize so that the user for example does not have the big orange page with no text coming up or just a headline coming up and the body text being loading much later after. So we really want to focus on the different ways that we identified to be helpful in order to optimize that experience so that the user actually not just gets something on the screen, but gets the key message that your fonts wants to transmit. Yeah, so like let's dive straight in there. So basically what we want to cover in this session is kind of like web fonts, system fonts, what's the best way of using both? Can you avoid it? Can you avoid web or custom fonts? Can you not avoid it? And obviously if we talk about web fonts, the you know like if you need, if you don't need web fonts or if you don't require a lot of web fonts or if you can kind of like cut down on characters, it's always better. Like the less resources you need to load, the better that the faster your site is and you know, the faster the rendering can happen. So basically we would just want to start and say, can you avoid web fonts? If that's the case, that's awesome because if we actually look at web fonts then we quickly realize that while they do offer like a great way of providing some uniqueness to your site and some great user experience in terms of like look, they're also like limitations. So we're actually looking at one of the Google fonts which obviously we think is a great font. So like the Lado font for example, but the problem is that if you load for example, different styles, so like you load the bold version to have like a, she's as a headline, you use the regular version for your body tags, use a lighter version or an italic version to like show some quotes. The problem what happens is like if you add all those different styles and load it on your site, the load time is going to be slow because you just need to load more resources. And if you now think about it that you're not just only load Lado but you maybe have a different font for headlines and a different font for the body tags, then you kind of can multiply that by two. So that's why we always say if you can avoid web fonts, if it's not crucial to your corporate identity, the corporate identity of your site, then really go with system fonts. And we kind of like to show you guys an example here. So system fonts actually when you style them a little bit they don't even look that bad. So in the case that's showing on the slide right now, we're basically using the Apple system font and we just show you what's possible by styling like the system fonts. Like we use a different font weight. We obviously increase the size. You can even use a bit of letter spacing to create some space in between. So like if you're like kind of like a bit creative with the system font, you might be able to actually skip the web font. It's what we see often is like that web fonts are used kind of like out of a bit of laziness. Like, oh yeah, I don't wanna use Times New Roman so I just use a web font not knowing that you can actually, you know, kind of like work around it a little bit. So that's kind of like the first step. If you can avoid a web font, please do it. Your website will definitely render much, much quicker. Maybe just one point to add is also because obviously we see that discussions about that. Certain type of web fonts are also from an aesthetic or from a design perspective being required. But for example, is one way that has been interesting or it's just a small sort of hint is basically if you have quite a lot of body text on your site when there's a larger chunks of text, might be worse to just to consider to load that particular text that is making sort of the most part of the screen being loaded in a system font. Whereas for example, headlines that might be more important to be driven by a web font that is particular to your brand to be relying then on web fonts. So basically trying to maybe also progressively try to use more system fonts if possible. Yeah. Yeah, and then like obviously there are cases where you can avoid a web font and we totally understand that. So in this scenario, we basically need to think about how can we actually use web fonts but optimize them and ensure that it doesn't negatively impact our site and the rendering of our site because as Lukas explained earlier on the first three, four, five seconds are like the most crucial ones in terms of like conversion in terms of like getting people to your site, keeping them on your side. So you really want to make sure that just using a web font doesn't actually negatively impact that. So what are actually the complications with web or custom fonts and actually quite a few because we obviously have different platforms and with different platforms there are different requirements. So like we got like Internet Explorer, we got iOS like Safari browser, we got Chrome, Firefox, Opera and not all of those browsers supported the same file format. So basically what you get from that is like that you have different loading times on different browsers, in different browsers and on different platforms and based on that you get issues with the rendering, the file sizes are different. You have the latency issue, especially over 3G networks and as a result from all that you get like this flash of invisible text and we basically come to that later on and this is really kind of like the worst scenario and that's something you really, really should avoid and basically the whole session that we're doing right now is kind of like trying to re-emphasize that flash of invisible text is just really not a good practice. So it's really important to kind of like get down to like, you know, in what format do I need my web font in order to render it on all platforms or browsers? There is already some improvement. So you got like WOFF2, which is much, much quicker to load than the other file formats. However, it's not yet usable on all platforms. So for example, Internet Explorer, it doesn't support it. And if we just swap to this next slide, you can basically see the difference in size between a WOFF2 font and the original one. So like you can see like the red line is the optimized font and you can really see the decrease of weight, which is basically, we're talking about kilobytes here and I think that's always the misperception that kilobytes is so small and you're sitting at home on your mobile device and everything renders quickly. That you say like, okay, it actually doesn't impact my site, but really on 3G, what we really want to reemphasize is like it really matters, every kilobyte matters. So like if you can use WOFF2, definitely do it because you're really having a chance to make a positive impact. Yeah, and there's, I mean, very simple converters just online that you can't find very quickly where you throw in the WOFF file and get a WOFF2 file. So, okay, so there is two ways that we want to look at today. Working with local storage and then into a little bit more depth looking into the different web fonts. So basically we opened up the discussion. Okay, can you avoid the web fonts at all? But now we want to, if you can, great, if you can. Okay, let's go deeper. Now we want to look into the first step, which is a technique that we think is quite interesting and has been working very well in our tests, as well as with different providers who have that life, like Smashing Magazine or The Guardian at the moment, which is looking into leveraging local storage to get your font much quicker on the screen, basically, plus saving it in local storage so that for any further visit, we have the font being ready. And so basically the idea is that you store, like I said before, the web fonts in local storage. So we take basically the code of the font and declarations which is encoded as a string through base 64. And there is a tool which basically does all the work for you. So local font basically converts your font family files into a ready to use solution for that, which basically gives you the CSS as well as to activate the CSS through the JavaScript. And yeah, so basically that code is being, that code that local font creates for you is being placed in the CSS. And after the load event being then stored in local storage, so that means we have, in most scenarios, we have a small invisible of unstyled text, flash of unstyled text. So we see a system font for short-term have a switch from the system font to the web font that is now stored in local storage. And then for any further visit, we have the particular font that you've been choosing and encoding ready for the user in local storage. So, and I think the two crucial tools are really local font. The link is also in the explanation which basically lets you take your file, throw it in the tool, you get the CSS code in the JavaScript that actually makes that possible as well as font style matcher could be a good tool to use here to play a little bit with the system font so that you, the system font as well as the font that you're using to upload to just try to minimize the flash of the unstyled text. We're gonna go into this idea of flash of unstyled text in much more depth, but here's sort of just a couple of pointers if you're aimed to leverage local storage to number one, get the font files quickly because there's fast access for them through CSS. And to save the file request, especially for future visits given that we have them sitting in local storage. There's much more details on this obviously. I'm gonna happy to share like, but even there's like a nice session on that online and the two tools are linked in the comments. Yeah, I think that's just a rough overview of how you could do there. Be curious to hear from you guys, how are you leveraging this? Again, some providers leverage already, leverage it already. Our tests here, you see it on the right side. We've been able to get the font much quicker up then than even Google fonts and which is another story that we would like to go into, but that's been working really well. Yeah, so let's just swap to the web fonts then. Just again, like there are some of our colleagues in the live chat, so if you have any questions to what we just said, just type it away and we're trying to pick it up in the session. All right, so let's go to web fonts and basically we would like to split that quickly up into the Google fonts and Google Notar fonts and I will be covering how to work with Google fonts and how to optimize Google fonts in terms of loading time. And the first thing is that many sites on the internet use the same font. So basically what happens is you visit maybe one newspaper and they might use OpenSans and then you go to some network side and they use OpenSans and basically while this is really good like you can also ensure that you use this coverage of the same font across multiple sites to optimize because if you don't actually load the Google font, like let's just stick with the example of OpenSans, like you can use the link that's provided by Google and you can load it through our link onto your site or you can use the font, post it yourself and then load it. And the problem is if you load it yourself is that even if a user visits your site that has visited another site that used OpenSans before, he will still have to re-download it because the browser doesn't actually recognize that this font is already in the cache. However, if you do use the Google link to implement the font, then you get like this effect that the browser connects to your site and says, okay, I already have that font in cache. I don't need to download it again and obviously the benefits are quite clear. You don't need to download it several times. You reduce the amount of bandwidth needed to render your site, there's less latency and therefore your site renders quickly, like more quickly. So we really, really recommend that like if you use a popular font such as OpenSans or Roboto use like load it through the Google link because chance are really high that it's already in cache. And I wanna talk about that a little bit more. So basically, that's kind of like the way you would enable it, the cross caching. So instead of like using your URL, you use the fonts that GoogleAPIs.com slash and then whatever font you would like to use. It really is the better way of doing it in any case. So like even if you don't use OpenSans or one of the guys in the comments said like he's using Ubuntu, like even then there are higher chances that someone visits your site and has Ubuntu already in cache. Then if you just serve it from your own server because then most likely the user visiting your site has to download it. So that's basically just the way we would recommend you to do it. And yeah, definitely like highly recommended use the fonts at GoogleAPIs.com URL in order to load the font. And in terms of caching, what I wanted to touch is that like really Google provides one of the most widely used fonts on the internet. And if we actually look at the numbers here then we see like that the top 100 families are used on like more than 300,000 domains and the top 400 on more than 50,000 domains. Like we're really talking about large, large numbers and those are like really the top sides of that use the fonts. Among those, we really recommend if you can and if you wanna use a web font that OpenSense and Roboto is a really good choice just because we are looking at really, really high cache rates. We don't have exact numbers yet, but it's like, you might be lucky inhabit like north of like 50, 60 or even 70%. Don't wanna go too specific here as I don't have like exact figures here but like OpenSense and Roboto are like really, really widely popular fonts. And if you load them through the official Google link there's a really high chance that the users don't even have to download it. So that's really like just one recommendation we can give you to do it that way. And I mean, that's just like a quick slide on like how to actually use it against like, we obviously created Google fonts for like simplicity. Like how can you enable to implement custom or web fonts with like two, one, two easy steps. Just for those that are not familiar with it, I suppose probably most of you are, but so basically, yeah, all you have to do is like you add a single line of reference code into the head part of your website. And then in order to style the font, you choose the font family that you're actually importing and that's really it. And I mean, as you can see, you get the results quickly but yeah, always keep in mind, only use web fonts if it's really necessary. Don't just play around with it. Don't just use it for the sake of having multiple fonts on your site. If it's not required, we still recommend to not use it. Yeah, and if you do try to leverage as much as you can of the opportunity of cross-site caching, right? That's what we really see to be the big win in the end. You can optimize a lot, but if it's already there then you have to optimize just a tad less. OK, just a quick note in case that you're working with sites that serve across various countries. I have to be basically, I mean, probably all you guys do, but just if you have to cover quite a bit of various languages and according characters, there's the project of no-toe fonts. Actually, funny the name coming from no-mo tofu so we don't want to see these little nice squares on the screen anymore if the characters are not identified. So if you're working in an environment where it's important to keep sort of the same experience for the users so having an equally strong experience across all the different languages in terms of aesthetics and as well as then obviously in them being loaded, I think it's good to have a look at no-toe fonts. I'm going to go much more in detail for this at the very moment, but just have a look at that project. Might be beneficial for your team or for your particular project. OK, so we've been talking about the flash of the invisible text a little bit and basically the core issue is that the browser is kind of thinking, OK, there is a font coming, but it just takes time to get it. And it might even render a couple of underlinings or in this case, a couple of bullet points before and depending on which network the user is on and what basically in the situation of the user, we might actually have that experience for a couple of seconds going on, so the user seeing lines on the screen and a couple of bullet points while we actually want to transfer a message to them and give them content. And basically we want to look a little bit more in depth into how we can avoid that flash of invisible text. Yeah, just a quick comment on that. There's also another pitfall here. So for example, if you basically build on the method of invisible text that you're waiting for the web font or the custom font to render, you might face the issue where the browser waits forever because, for example, the Chrome browser has a three second timeout. So for three seconds, the browser waits for the web or the custom fonts. If it doesn't load within that time frame, like a fallback font will be displayed anyway. But that timeout doesn't exist in all browsers. So there are other browsers that if your web font or custom font doesn't load, the browser is waiting forever. And if there is some server connection error and you have to go through a few round trips until you load the font, you might be waiting for 10, 20 seconds because the browser is waiting for that font. So just think about it, like how that would hurt your conversion rate if you put all the effort into getting the people on your side and then because of such a little glitch, no content is presented to the user and at one point, the user bounces. So that's why it's really, really important to optimize more for the unflashed text rather than the invisible. Any comments in the chat? Yeah, I've been already answering. So like, yeah, thanks for the comments so far. And if you have more, please just let us know. Yeah, so basically just switching from invisible text to unstyled text. I know from a design perspective, it's not great. So I know for myself or I would do a little side or something, I would kind of not like this flash. I would load a beautiful side and then after like two, three, four seconds, you have suddenly this flash and it looks different. So we understand it's not ideal. But I think you always need to kind of find a middle. So if you use web or custom fonts, you're sort of battling with either unstyled or invisible. And we just believe that the screenshots we see right now, like the GIF, that's a better scenario than the one before. Like I'd rather see some unsyled content and then have it beautified later on than like just see like bullet points and underlines and basically nothing because I think that just looks just as weird. So yeah, we really like highly recommend Fout Overpoint. And yeah, so like basically, and that sort of will answer a Kant's question. So yeah, thanks for the questions, Kant. So how do you actually achieve loading a web font efficiently and without a render block? And our suggestion here is to do a sync chronously. So like as we said, Fout is better than Fout and what you can do is like that you load the web font on the unload event. Like you start with the rendering of the page, you load the page, then you load the web font and the custom font and then basically you replace it once it's fully downloaded. So while all this is happening, you can use a fallback font and there are some neat features there or some neat tools that you can use to match the system font as closely as possible to the web font that you're using. It's linked in the comments as well or in the description of the YouTube video, you find the font style matcher stunned by another Googler as well. We're actually at the same pain trying to match, to minimize the actual fault as good as possible. Yeah, exactly. So that's really cool to use. And again, like I think you will see like once you try it out that it's not even that bad and you can really just focus on delivering the important messages to your user straight away because this is in the end like, if I visit a website or if I build a website and I put the most important content above the fold because this is what I wanna transport to the user and it's just really important that the user sees that content. So this is just a small example of how it could be done. We will post links to the article, we said it's in the comments. So check out the article, it's a really cool article that explains how you can do it. Obviously there are different ways of how to lazy load fonts. So like you don't have to choose the way that we are suggesting here but definitely focus on that like load assistant font and then swap it once the custom font is downloaded. And yeah, basically just wanna show you one example we ran and we basically performed this test on the side where like before we were loading a custom font there and after we basically will be removed the custom font and then we compare the speed index of the same side. And it's quite significant. So like just by removing custom fonts from like blocking the render, you see like an improved speed index by like 2,000 and that's pretty significant. So you can really see that like if you just optimize the font, obviously you should still focus on other things. You should still focus on optimizing other resources like CSS, JavaScript or whatever it might be. But like just by optimizing a web font, you can speed up the rendering of your site like the very important first paint by like almost two seconds and that's really huge. So like, I think that just like shows how important it is to focus on font optimization and choose the unstyled text over the invisible text. Yeah, and basically the flesh of the unstyled text being I mean sort of a trade-off decision because obviously there is a lot of pushback into loading system fonts at the beginning but I think it's exactly as Dominic went through in the scenario. It is really the goal to get content as quick to the user as possible. Please taking into consideration the actual network experience many users will have which might result in yeah, the web font, a beautiful font will load at some point but when is that point and is that a point where the user is even still there? And given the numbers that we're seeing, it's really important to take into consideration that they might not be there anymore and reload that font as quick as possible. Good, do we have some more comments or other questions? Yeah, just waiting for comments right now. If you have any questions to what we said right now just please type it away and we're happy to answer it. It would be definitely very interesting to see what you guys, which kind of experiences you guys have looking into more depth than this. We definitely gonna be running further sessions. So also leaving for example in a chat further topics that you would like to discuss in more depth in the future could be one thing that is very helpful and also just letting us know if you need or deeper insights on very specific issues because definitely our goal here in Google is to try to to make that as hands-on for you guys as possible so that you can basically sit down, take the tools and try a little bit. So we link the techniques or the description of the technique for the local storage technique already in there the tools are already in there so you can play with them. Obviously a Google web font is easy to find and just did the article that Dominic just mentioned where we go through, where one of our Google Sphere goes through the sort of different ways of implementing the flesh of unstyre text. We put it also in there so that you really have something hands-on to work with. And we would be, so we're gonna be running the next Hangout in about four weeks. And we would be very curious to hear your experience in the next couple of weeks with this particular topic sort of which conversations you guys have with your teams if there's any pushback from design which is very understandable. And yeah. Are you curious about that? Yeah, and like obviously like what we're really interested to learn is also like if you decide to go ahead to day or tomorrow and actually implement like one or two of our recommendations, just really let us know like, maybe run test yourself or just post the URL where you did the test on. We're just really curious to learn how it works for you, what the improvement is in terms of speed index. So like definitely like, get in touch with your results and yeah, we were always eager to learn more and maybe like maybe you face certain problems that we couldn't think of right now and like, please let us know as well and we might be able to do a follow-up on that or something. Yeah, we will send you a quick follow-up survey actually where you can let us know and where we can try to optimize further sessions for you guys because the goal is really to share what we in Google see as a strong approaches and what we see success with our clients with. Yeah, and we just have one question. Is it possible to see the speed index value somewhere inside Chrome console? The speed index value, no. You can see the rendering in the load time but like to get the value, you need to go to webpagetest.org, run your site through that tool, use 3G fast as a connection type and use a server that's close to you. So like if you're a base in the UK then you should choose for example, the London server or the Southampton server and that's where you can get the speed index value from. And there's another question. Would you suggest moving away from font icons in general? Again, one thing is definitely to chop the file just to the icons that are relevant. So Fontalo is a good tool to leverage because what we see very often with clients is a huge set of icons being loaded that are not being required. So that's one thing I can say. Yeah, I mean, just as you said, like just try to limit and minimize the amount of resources you wanna load. Another question is, does declaring the same multiple fonts and different style sheets decrease the side speed? So if you have different style sheets and you declare the same font, then basically you will download it once and the browser will cache it. Obviously only if you use the same link in each style sheet. If you're talking about multiple fonts and different style sheets, then we're talking about, you just need to see it like this. Once a font is downloaded into the browser of the user, it's cached for the browser session for example. But if you use different fonts and different style sheets, each time it's a new font that the user's browser hasn't downloaded yet, it will be downloaded. So you basically increase the rendering time. Sunja is asking how to load async. So let me just post a link because I think we only put the link to the font cell matcher into the comments. So, and any other link that is mentioned that not in there at the moment will obviously be added straight after the session of stuff that just came up in the conversation. Exactly, so I'll just post it quickly in the comments so you can have a look right now. Okay, we'll add it to the comments because it doesn't actually let me post a URL at the moment. So we'll add that to the comments so you can have a look there. So yeah, just reading through if there are any other... Yeah, and sort of apart from this again, we're gonna send out a little, small little survey to just here because we really try to make it the best experience for you. So, and really hear back from your experience, your conversations that you have in because the ultimate goal is not to share knowledge only but to implement on the sides, get the text being visible quicker to the user. And we hope to give you a couple of pointers in the right direction there. Anything left Dominic? That's all from our end. And again, we will take our time now and read through the comments and the ones that we didn't have time to answer will, we will post links in the con section of the video. And yeah. We appreciate everybody who took the time. And yeah, it's just nice getting a lot of us together caring about speed and going really into the depth of this, this so vast and interesting topic at hand. Yeah, cool. Guys, thank you. Thank you very much. And see you next time. Next month. Bye. Bye.