Maximize App Performance by Optimizing Web Fonts

Hello, everyone. Thank you for joining in this beautiful workshop. We're going to be talking about maximizing app performance by optimizing web fonts. So fonts, we need to load them. And there are ways to load the fonts so it doesn't hurt our website, right? That's the workshop about. This is not a follow-along workshop. It's more informative, and we're going to be trying out things. So yeah, feel free to just pay attention. No need to code.

Okay, let's start. My name is Lazar Nikolov. I'm a developer advocate at Sentry. I'm a full stack engineer, been coding since 2013, professionally since 2015. And the agenda for today is first we're going to be talking about CLS, cumulative layout shift in general, and how fonts cause CLS. And we're going to move to CLS minimization strategies or how to minimize the CLS. And then I have a small demo prepared for you with some of the strategies.

CLS and how fonts cause it. For those of you who don't know, CLS is this. It's a layout shift, right? We have an order form. There's a yes, place my order and no, go back button. And just before the user presses on the no go back button, an ad shows up and it pushes the whole form below. And then the user clicks on the place order, which is not really what the user intended, right? That's bad UX. And the appearance of the ad at the top and the pushing down of the layout, that's called a layout shift. Okay. So they're bad. Layout shifts are bad. And on this page specifically, I guess the page will be penalized. Because the layout shift is pretty big. And the penalization happens with a bad CLS score.

And the penalization happens with a bad CLS score. So how does that score get calculated? It is the product of the impact fraction and the viewport distance fraction. So what are these two? The impact fraction, both of these values are decimal values from 0 to 1. And they represent the percentage of the changes relative to the viewport.

So the impact fraction is what percentage of the viewport has been impacted with the shift. So for example, if the header at the top, the title, how is CLS calculated? If that part went at the center of the screen, it got pushed down at the center of the screen, that's like 50% of the viewport, right? Because it moved half of the screen down. So it's going to be 0.5 times the distance that the unstable elements have traveled, and that is the viewport distance fraction. I guess in this case would be 0.5 again. And yeah, that's how CLS is being calculated. And there are tools, there are tools to calculate CLS. During the demo, we're going to use just the Chrome debug tools, and I'm going to show you how to calculate the CLS. But what's important to know...

Yeah, what is a good CLS score? Yeah. This is always better. But your goal should be to stay within 0.0 to 0.1 range, okay? So that is a good score, from 0.1 to 0.25. It needs work. And above 0.25, I just named it oof, because we're not going to talk about that. It definitely needs a lot of work. And what's most important to know about the CLS score is that the one that you see in your tool, for example, in Chrome debug tools, is not the one that your users are going to experience, doesn't necessarily have to be.

So yeah, not every device will give you the same CLS score. Outside factors like internet speeds or the device performance really impact the CLS score. So yeah, it is not the one that you see in Chrome. For example, on a slower internet, or, I don't know, if you're on a hiking trip and you have a 10-year-old Android phone, I guess the CLS will be bigger because the way that the phone loads, yeah, the device is not going to be able to handle that really quick. Maybe the internet coverage is bad because you're on a hiking trip. So the internet will also affect the CLS. And also, to keep an eye on what the actual CLS score is in production, you will need to implement tools like Sentry. You can measure your CLS score while you're in development, sure, but in order to keep an eye on it in production, you do need external tools like Sentry. And also, the side benefits of implementing Sentry in your app would be other performance metrics and web vitals. And you also get crash reporting. And I'm going to show you briefly at the end what you get.

But yeah, the one that you see in your Chrome DevTools is not the one that your users will experience. That is important to know. So how do fonts cause CLS? There are two conditions or situations. They're called FOJT and FOUT. FOJT is Flash of Invisible Text. And that's when the browser loads the page without the text. Or it's, yeah, invisible text. The text is invisible, while the actual font is being loaded. Right, so for example, if your font is five megabytes, while those five megabytes are being downloaded, there is no text on the webpage. And then the browser renders the text. And FOUT on the other hand is the Flash of Unstyled Text, which means the browser doesn't keep the page without text. It renders a system font instead, which is called Fallback Font, while the actual font is being downloaded. So these are the two conditions, the FOUT and the FOID and the FOUT. That's how the fonts cost CLS.

Okay, we can get into the minimization strategies now, and I'm going to explain the FOUT and FOID in better detail and you'll see what they mean. First and foremost, just don't use a web font. It's not really a tip, I know, but I had to mention it. Yeah, if, for example, your page is not, if it's not necessarily for you to use a font, just don't use a font, right? There are beautiful system fonts out there who do not cost CLS. So do yourself a favor, just don't use a web font if you don't really need to, so you can avoid all of the upcoming tips that I'm going to give you, just don't care about them.

And I like this website at the bottom, Modern Font Stacks, because it is a website that showcases 15 different font combinations of built-in fonts that do not cost CLS, but you can just copy paste them. You can just copy paste the font family, I don't know, set it as a CSS variable, use it. You're going to be sure that your pages are not going to have any CLS, it's gonna be zero, which is good. So that is tip number one, if you really don't need to use a web font, just don't use a web font.

Tip number two, host your own web fonts. So it might be easier importing Google Fonts, and there's a research from the HTTP archive that shows like 80% of web pages in this world use a web font, right? So, which means that those 80% of the pages do have CLS, and 65% of them use Google Fonts. I know, it's easier, right? You just copy paste CSS import, you put it in your app and then you have fonts, right? But there are negatives to that and there's also positives on why you should host your own fonts.

And it's not as complex as it seem, like hosting your own fonts. You don't need to spin up a CDN network just to host your own fonts. The number one benefit is that the browser avoids another HTTP round trip because you don't really have a connection to your server, right? It started downloading your websites files. It reached a point where it needs to download the CSS fonts. So there's a branch over here, right? If you're using a Google font, it needs to make another HTTP round trip to authenticate with the Google servers. I think it was like the G-Static servers or something like that. The CDN because it hasn't opened a new connection up until this point, yeah? And that costs, right? It's a whole new HTTP round trip. But if you keep them at your server, it's not gonna do that, it's just going to download the fonts and it'll cache them locally in the browser. And also another benefit is that you don't really need to depend on the availability of the third-party service. Now, okay, yeah, Google Fonts, they don't have any issues with the availability, right? But there are websites and 35% of all the websites who use a web font exactly, they don't use Google Fonts. They use something else. And the availability of that service to serve the fonts to your website, you can't really guarantee that, right? So that's why hosting your own fonts is better. And again, using less font files is another tip. So when you load different weights and when you load different styles, like bold, italic, italic bold, et cetera, you're basically loading a font file, an actual font file for each of them, right? So if you have a regular, a bold and italic version, that's like three files. So the browser will need to download those three files. What you should know is that the browser is also capable of mimicking the weight and style of the font. It's not always going to be correct, just like the font intended to, so it varies. But it's a good idea to check if the full bold, or the fake bold and the fake italic look good enough before you actually import them.

Because, yeah, if it's a simple font, the characters, the letters are bold, the browser will try to make them bolder. If it's not something complex, it's going to look good enough. It's going to look pretty much the same as if you loaded another, like the specific weight, instead of just letting the browser do it. So that's why you should use less fonts, less font files if you can.

Also the format matters, so don't use TTF or OTF. These are system font formats. These are not web font formats. The benefit of the WAFF 2 font file, WAFF, I guess is WAFF. It's the most modern format. It supports subsetting. So what is subsetting? You have a font, right? And it has support for different characters. You have the numeric, you have the special characters, you have the alpha characters. And there's also characters from different languages, right? You have the umlauts from Germany, you have the apostrophe characters from France. Maybe you have support for Asian languages like Chinese, Indian, et cetera. If your page does not, if you're sure that your website is never going to use, I don't know, either umlauts or Indian or Chinese characters, you can actually remove them from the actual font file. And that would, of course, reduce the font file, right? You're loading into the font. If you remove all of the extras, that it comes with, you're going to end up with a much smaller file size, which is good because the browser won't need that much time to download it, okay? And another benefit of using the WAFF 2 format is because it uses Broadly Compression, and that produces even more small file sizes. And it's, yeah, supported by all modern browsers. So just, yeah, just use WAFF 2, it's simple.

And the last tip, and when all of the strategies will fall into is the font display property, okay? There is a way, there's like a smart way of using the font display property. And the whole workshop is basically just for that, okay? So the default value is auto, and the font display is basically CSS property. I'm gonna show you like a code block at the end where you see how it's implemented. But the default value is auto, right? That means let the browser choose what strategy it's going to use, yeah. Block is... It has a short block period and infinite swap period, okay? So block period means I'm not drawing any text. That's the invisible text, that's a void if you remember. So the page loads. Initially, there's no text because there is a block period. It says short, it's three seconds, it's not short by today's standards, but yeah, the name stuck together. So we still call it short, but it's not really short, it's three seconds.

And the infinite swap period means that when the web phone loads, the fallback font will be removed and the actual web font will be used. That's the swap period. So that's like infinite, right? Short block and infinite swap. I have a chart prepared on the next slide, which will make things much clearer, but let's just go through them now.

There's the swap, from display property, which means no block, and infinite swap. No block means the browser immediately renders a fallback font. And whenever it loads the web font, I don't know, 20 seconds later, it's going to swap it out. And that swapping of the font, that makes the, yeah, that makes a lot of difference because the difference between the fallback font and the web font will cause the CLS. And there's a tool for that I'm gonna show you later.

Then we have fallback and optional. I'm gonna treat this as like pretty much the same thing, but there's like a small difference at the end. Extremely small block, which means 100 milliseconds. That's extremely small. 100 milliseconds of block time. So no text for 100 milliseconds. And then in the fallback case, we have a short swap, which means three seconds swap period. The browser has three seconds to download the web font in order to swap it out. If the browser doesn't load the font in three seconds, it's never gonna happen. We'll just keep using the fallback font. While the optional is a bit more aggressive, it still has the same extremely small block periods of 100 milliseconds, but it has no swap, which means if the browser does not load the font within the three seconds, but within the 100 milliseconds, it's just gonna keep using the fallback font. Okay, so these are the values and this is how they look like. Okay, so as you can see, we have the gray color or circle here, which represents the invisible, the block period. We have the orange, yellowish, orange, which represents the fallback font. That's the system font that the browser would use. And the green one is the one that we want, right? The green one is our custom font that we're loading. So here's the extremely short period of 100 milliseconds and the short, which I mentioned is not really short, of three seconds. There we go. So block means wait for at most three seconds, if not, show a fallback font, if the font is not being loaded. Which means if your font, you know, you should pretty much at all times, just avoid block, right? It has way too big of block periods, three seconds. That means if the font that you're trying to load doesn't load for three seconds or more, the user will just sit there looking at your page with everything on it except texts.

And the user won't be able to read your website, right? But that's what they came on the website at the first place. So yeah, just avoid the block. There's our swap. As you can see, there's no block period. It immediately starts drawing the fallback font, but then whenever, because it has infinite swap period, whenever the web font loads, whether if it's between the 100 milliseconds or three seconds or even it's like 10 seconds, it's just gonna do the swap then whenever the font loads.

And we have these two, the fallback and the optional. As you can see, they start off with invisible text for 100 milliseconds, but then this is where the changes happen. After 100 milliseconds, the fallback font, if the web font is not being loaded yet within those 100 milliseconds, the fallback is going to render the fallback font and it's going to start another time and timer for 2,900 up until the third second for the web font to load. If it doesn't, it'll just continue using the fallback font. While the optional font-display property, as we've mentioned, is a bit more aggressive. It only allows 100 milliseconds, this small window of opportunity for the browser to download the web font. If it doesn't, it's just going to use the fallback font until the rest of the session.

Okay, so yeah, this is how they go. I guess you would decide to go with this swap strategy if fonts matter to you. Right, if the branding is strong, you do need to use that specific font size. You would go with this swap strategy, right? Because you have a fallback and you have an infinite swap, which means even if it takes more than three seconds, the user will look at your custom beautiful font because that's what matters to you, right? I guess you would go with the swap strategy. In that case, it's a really good idea to invest some time fine-tuning the fallback font because the difference between the fallback font and the actual font will cause the CLS. There are CSS properties like the size adjust, a std override, the std override, line get overrides. You can use them and fine-tune the values to minimize the difference between the fallback font and the OG one. The OG one, yeah, the web fonts. There is a, I'm gonna try to copy this link. There is a tool. There we go. There is a tool that allows you to preview your OG font and the fallback font. It overlays them one on top of the other and you'll see how big of a difference it makes. And then there's also this other tool that is going to generate a fallback font and also the values for you, which pretty much your job is done, right? Even from the very beginning. And this is how everything looks like. We have the, let's say we're loading the IBM Plex serif font at the top. This is from my website. So I'm loading this on locally.

I keep them in public slash fonts, slash the font name. I set the font display to swap. But then I'm also defining the fallback fonts. And the tool that I shared with you, let me know if you got the link. I think you got the link. The tool that I shared with you told me to use Times New Roman. It's like the fallback font because it matches the IBM Plex serif pretty well. And also links don't work. Okay, I'm gonna try to fix them. At the end, if we have, say 404, that's not good. I'm gonna try to fix them at the end. If we have like a Q&A section, if you have any questions in the meantime, I'll try to fix them. But yeah, it gave me these values for the size adjust and the ascent overwrite. I didn't come up with this. I could fine tune them though. I have the option to maybe 0.2 makes more sense. I don't know. I have the option, but this is the fallback font now. And I just post fixed it with dash fallback. I can just use fallback, for example. It's my, you know, it's ours, how we call our fallback fonts.

Then at the root, I register a CSS variable where I put the actual OG font, the web, the actual web font as the first one. Then I set the fallback font as the second one. But just in case, I even went to Modern Font Tags and picked a good default. That pretty much looks like the IBM Plext. Not really close, there are differences, but just in case, I just added these values as well. And then I just use the font family, the new CSS variable, just as you would. So this is how you would define a fallback font, okay?

And now we have some time to do the demo. This is the demo app. I have listed the six different scenarios for using Google Fonts, if you're using the modern font stacks, and all the four different font display values here. So I'm going to open, I'm gonna open the performance insights tool in my DevTools, and we're gonna use this to measure the CLS to see how the page loads in all the different scenarios. And see basically, I see the difference.

Okay, so we're gonna open the Google Fonts page. And let me just make sure, yeah, we have the cache disabled, that's good. I'm gonna do a measure page loads. There we go, and I can stop this. And now we have a timeline of everything that happened while the page is loading. We even have a little screenshot thingy at the bottom. Okay, so we can go back and this is what happens. We see the default. I don't think this is part of the loading, but it starts off with the, yeah, basically it starts off with the fallback font, which in our case, we didn't actually define it. Browser just uses a random font, a random serif font. A random serif font. And then it loads and when the actual font loads, it swamps it out. See that? There's the font at the center of the screenshot here. And this is where you can see in the chart here that this is where the FCP happens and the actual layout shift happens here, right? That is a layout shift. We have the content at the center, right? But then it spans even larger than the actual viewport because it scrolls now. And that's because the previous font, the Fallback font, is not well defined, right? So it doesn't really match the specifics of the actual font And that's why we can see the content layout shift. So if there was a button at the bottom and if the user wanted to click it, just before it does, you know, just before they do, the phone will get loaded and they'll just click on the text, right? That's the... There's the content layout shift here. Sorry, cumulative layout shift.

And we can see the value here, it's 0.096. Let me zoom in. Yeah, it's 0.096 or like 0.1. We're still in the range of good, right? But this is a simple page. It just has a text. If it was a bit more complex page, we could have more consequences because we're not actually handling any of the CLS. We're not actually implementing any of the strategies here. Okay? That's Google Fonts.

Let's check out the modern font stacks. I am going to disable. Yeah, the cache is disabled. So let's do another page load. Click stop. And as you can see, when we go to settings, layout shifts, there are no layout shifts, right? Because that's the thing. We're using a system font from the very beginning. And it's already loaded. If you check out the screenshots and scrub, we can see that nothing changes. There are no layout shifts, right? But it's not using our custom font. I know it's not using our custom font because we don't have a custom font in our case. But if this look works for you, this is the case where we just don't use a font, right. So we don't really need to care about CLS. In this case, even if we put this website on an old device, old smartphone, and I don't know, put it on a Starbucks network or a WiFi, it's still gonna perform the same. Because the browser doesn't spend a millisecond loading a font. It immediately draws the text and the users are able to start reading from the very beginning. So that is the modern font stacks.

Let's check out the block now. Check out the block and I'm going to... You know what, I'm gonna throttle the network. I'm gonna put it to fast 3G. So we simulate a bit slower network than I have at home.

So it's gonna be a fast 3G network. We can wait for a minute until it loads. But this will give us more time and more space between the events as the page loads.

Let's go back. Actually, let's go back to no throttling. We'll figure it out. There we go. Page is loaded. Click Stop.

Okay, we have a CLS as you can see, 0.0952. And it happens at this point right here. The screenshot is blank. Which means there's no text, right? This is FOIT. This is a flash of invisible text. The one that we mentioned earlier, right? Because the block time is super huge. And then the font loads. And look at how the browser renders it. It renders the title first. Cause it's top to bottom as the element. And then it renders everything else. You see? So imagine if you had a button or a form and you needed to press something or like interact with a certain element. And then this happens. As a user, I think you'll be lost, right? You'll be like, what happened? Like where is my form now? Where do I go? Should I scroll down, et cetera? So yeah, that's not good, right? We don't want to impose that to our users. So this is how the font display block actually renders text.

Mohamed, hello, can you please share the reference resources? Yeah, I will at the end. I think I have an issue with the fonts. I'm gonna try to fix them at the end. And yeah, and I'll reshare everything. Okay, that was the block. Check out the swap, the swap, the swap with the font display properties.

By default, when we're using Google fonts, if you didn't know, I guess we have time to actually show you. There we go, you see the CSS? This gets loaded when we add Google Font, and this is the actual URL. Of the, as you can see, it's WAV2 format. And the font display is by default set to swap. You can change this by adding boolean parameters to the import URL, but by default is swap, okay? So Google fonts prefer swap.

Let's see, let's go back now, and measure the performance of the swap. Did we do the swap? Yeah, we did the swap. Okay, here's how we start with. This is the fallback font, and here's how we end with. This is the actual font, and of course it's going to cause the CLS. This is pretty much the same as the Google fonts way, because in both cases, we didn't invest, or we didn't do anything to try to match the fallback font with the one that we're loading. So that's why we have the CLS, and we can clearly see. I don't even need to zoom in for you guys to see, but yeah, it is clear that we have a layout shift. And it's on the border of the acceptable 0.097. If you run that out, it's like 0.1, and that is the, you know, that's the border right there. That's the edge.

Okay, let's swap. Let's check out the fallback, because personally, I'm interested in these two. So let's go ahead and measure this page load. There we go. We don't have a CLS. See that? We started off with a blank screen, and if you remember, the fallback and the optional, they start off with invisible text, but within the 100 milliseconds, our web font actually loaded. So it immediately showed that there was no swap period. And there we go. There is no content layout shift. The idea is that even when we are in the empty page state, I'm not sure you can see from the screenshot, but there are scroll bars on the screenshot. Even if there's no content on the page, there is, but it's invisible. It's not that it doesn't exist, that's the point, flash of invisible text. There is text, it's just invisible. But there is no CLS because we're not changing the width or height of any of the elements on our website.

We have these paragraphs, which are all separate elements, and we have the H1 at the top, which is a separate element. But we're not changing the size, so it pushes down the rest of the content. That's why we don't see any CLS, even though we have visual differences before the font gets loaded and after the font gets loaded. We still don't get CLS because the browser actually reserves the space that's required for the content to be rendered. And then it just flashes the styled text or the actual web font, okay?

So I'm going to try to throttle the network here just so we can try to push the actual font loading more than 100 milliseconds. And hopefully we'll see, hopefully we'll see the swap period. There we go. Something did happen, okay? Let's check it out. So we start off with an empty blank screen and then we can see some differences, right? Look at the title at the top. See that? Look at the paragraphs. It's pretty short, let me zoom in. It's pretty short, but there are differences, right? Well, we still don't have a CLS, why is that? Because nothing gets pushed around, right? The size, maybe the size changes, especially the title, right? Because the title, I'm not sure if I set it to, no, it's full width. So yeah, no sizes gets changed. The font does load in a different, you know, like, gradually. So first we have the, there's the reservation of the space. If you can notice the scroll bars, then we have the default, the fallback font, after 100 milliseconds, and then the browser, as it loads the font, it starts replacing the fallback with the actual font. So it loaded the regular font first, and then we wait a bit more, and then, where was it? Okay, I zoomed in too much. There we go, then we load the bold font, right? I could have make this bolder. Actually, I could have make this faux bold, just like this is a bold font, so the browser can try to render that for me, but not in this case, right? The fallback font is, I think, way too different than the one that we're trying to load, so it's not gonna produce good results. Yeah, and that's the fallback. If we try to throttle it, we can see that, it started off with a blank screen. It used the fallback font, and then it started replacing or swapping the fonts whenever they load. That's the fallback. And if we also check out the optional, I'm not sure if we can see that, but the optional was if the browser doesn't load the font within the first 100 milliseconds, it's not gonna swap anything. So let's see if we can actually catch that. I still have the font throttling, I think the page loaded. Let's see. What's happening? I can grab this. There we go.

There we go. Yeah, here's the fallback font, right? This is not the font that we wanna render. I recognize that because it's more slabby. There's like, the title is way bolder than this one. But the browser didn't succeed into loading the actual font within the first 100 milliseconds. Because if you look at the time right here, let me just try to trigger that. We are way past the one second. You see that here? We are way, or at the bottom here actually. At 1.14. 1.14 seconds, we still don't have the font loaded. So the browser is gonna use the fallback one. And I don't know why it takes like two seconds for it to load. I think there's a, it's not... It's not 100 milliseconds when we hit refresh. But I think it's 100 milliseconds when we get the DOM content loaded event. So 100 milliseconds later, that's when we see the fallback font.

But it actually didn't manage to load the font because the fast 3G throttling is too slow for the browser to load the font. See that? There is no content layout shift but there is also no swapping happening all throughout the seven seconds. If we remove the throttling, let's see if we can actually see the swapping take place. It actually doesn't, yeah. Maybe the font is way too big for it to be loaded in that time. So yeah, optional will never swap. If the browser doesn't load the font within the first hundred milliseconds, it will never swap the font, okay?

And that's all the strategies we have. I mentioned you can use Sentry and here's how it looks like in production. So this is my old website. And yeah, you see all these measurements? This is the first paint. This is the first Contentful paint, right? And there's the CLS score at the bottom there. As you can see, there's like 12 measurements here within the zero, but there's also 0.031 measurements. So it kind of gets like a median or average value and it tells me that the average value in production is 0.01, right? So I don't really need to worry about CLS on my website, right? But yeah, here's how, here's all the measurements. And as you can see, we have some red values here, right? 5% of the sessions on my website have been terrible.

You know, and like 43 has been meh. So if you put these two together, my old website was like so-so, right? But as you can see, these are all different sessions. These are two sessions that took three seconds for the first pain to occur and et cetera. So these are all production values, right? That's what you get.

And that's it for the workshop. We can move into a Q&A section if you'd like. Here's the repo, by the way, if you wanna clone it and check it out locally. There's the link to the demo app that I just went through. You can check it out, you can play with it. We also have a sandbox. So if you wanna try out Sentry and you're not sure if you wanna register, you can try out the sandbox. We have a view page, which tells you how Sentry and Vue work together and what you get for your Vue website. You can check out that link. And also, yeah, if you're convinced and you really wanna check out Sentry, then here is a sign-up link for you.

We're planning to go with loading our own font. Is using fallback font the best way to reduce the CLS? Yeah, I use the fallback because I don't mind the first 100 milliseconds. At least, for example, in my case, on my website, I'm pretty fine with it, right? But it all depends. So you would either use the fallback or if you have to do the avoid, if you have to avoid the blocking time, then just go with swap. But make sure that the fallback font matches the OG font as much as you can. Yeah, this is the automatic font matching tool, I'll just bring up the chat. This is the multi-OOBL tool and here's the link to it.

Is there other tools, Aaron says, is there other tools that can be used to monitor the CLS score? I think there's depending on where you deploy, like the platform that you're deploying might or might not have the CLS monitoring. What else is there? I think like the page speed could give you if it has the data, but I think these are like the three types of apps that you can use. Here's the automatic font matching. I'm gonna zoom in for you. Let's say we're using, I don't know, Ruthie. Man, this is a terrible font to pick. Yeah, in this case, you have no option. If you wanna show this font on your website, then there's definitely no fallback font for that. But let's say, I don't know, maybe this one, right? You see the straight font actually, Arial is much more suitable.

If you remember in my case, it was Times New Roman. In this case, maybe use Arial because the size, as you can see, is pretty much the same. If this was an inline element, here's the remaining size. It is here in this case. So it's really, really close. You still have the opportunity to round these up.

So yeah, this is the automatic font matching. Put your desired font right here, and then it'll give you the fallback. Then you can get this and place them in the FontFace descriptor playground. And this is the other tool that I mentioned. Here's the link to it.

See how two of the fonts are overlaid, one on top of each other? You'll see the difference here, right? You see this red line? I'm not sure you can see it, but there's like a red line that's just a little bit above the gray line. That's where the actual one of the fonts' size ends. And this is the other one. So this will cause some layout shifts, right? Because the red font doesn't need that much height as the gray font in our case. So it's gonna push out or remove the space after it loads. And if you do the flash, you can see the difference. And this is what the users will see, right? They'll be looking at for example, the red font, and then immediately it's gonna be changing to the black font. So this change will... Yeah, this change will actually just confuse the users.

Okay, we have a new tool, let me check this out. Similar to the one you're showing, you can upload your own font. Oh, that's cool. There we go, you see that. And now we can actually play with the values. This is awesome. I like it. Yeah, you see that? So you can really zero in and try to bring the, try to bring your font as close as the, you know, as close to the OG one as you can. Really cool. Yeah, thanks for sharing. So yeah, these are the tools. Let me try to find the sentry.io slash four, or view, this is the Sentry for review link that I attempted to share, but it didn't work. This is where you can see how you can implement Sentry in your view app, how to install it, implement it, and what it can do, what can it bring you, you know, bring you in terms of superpowers. And yeah, I believe we are at the end of the workshop. Again, thank you, thank you everyone for tuning in. I hope you liked it. I hope it was informative and yeah, thanks for joining in. See you, see you around. All right, take care.