Join Maximiliano Firtman for an in-depth discussion in this video Optimizing the rendering, part of Learning Enterprise Web Application Performance.
First, it's a good idea to announce DNS queries as soon as possible. So, if we have a resource that is going to be downloaded from a different host, it can be a web font, it can be a CSS file, it can also be eMesh or any other resource, we can tell the browser as early as possible in the HTML that we are going to use that domain later. It's a link type with the rel dns-prefetch, and on the href we are going to set the domain without the protocol.
But for CSS, we need to get the CSS as early as possible, because the browser will not render any pixel on the screen if all the CSS was downloaded and parsed. So, put the CSS at the top, as top as possible, because it will defer the rendering. Add the link as top as possible, don't use @import. That is when you have a CSS that will import another CSS, because the browser will realize later that there is another CSS file to be downloaded.
Try to keep only one CSS, at least for the ATF content, the above the fold content. Try to use only one, and define it as soon as possible. Also, if you're serving on HTTP/2, you can start pushing that file from the server. When the client with the browser requests the HTML, the server will answer with the HTML, but also with the CSS, even if the browser didn't ask for that CSS yet. You need to check on your server, on your cloud-based solution how you are going to set that CSS as a push.
If you are rendering too much content in our enterprise web application, just render above the fold because we need the user to see that content in one segment. Remember, that's our above (mumbling). Forget about what's below the scroll. We can download that later, but at least we need the user to see the main content as soon as possible. Render first ATF, and after the load, render the rest. What about the problem of FOIT, flash of invisible text? Sometimes you are in an app, like the one you are seeing on the screen, you see eMeshes, you see sounds.
For example, rectangles, but you don't see the text. What's wrong there? Because the text in HTML, by default, is not blocking the render. When you have text, the text appears as soon as possible because it's just text. The problem here has to do with web fonts when you're using your custom typography file. When we are doing this, this is what's happening. The browser requests a page, so the browser gets the HTML. When it has the HTML, it's building the DOM, and it realizes that there is an element that has custom fonts but also it's getting the CSS file, and we also know, it's blocking the rendering.
So, the browser gets the CSS file, and when it has the CSS file it realizes, oh, there is a font there. The font file, the actual typography file, it's not in the CSS, it's a different file. Then, the browser needs to get that font, and at that point, it's ready to paint the text. The problem is that that happens, usually, after the first paint. The first paint happens when the browser has the CSS. It's not going to wait for the font.
That's why you usually see the page being rendered but without text, because the problem is here, the problem is that the browser still needs that font to render the text, so this is the problem. Let's see how we can solve this or at least how we can help the browser to reduce this problem and to render the text also as early as possible. We need to help the web font load first. We should try to reduce web font usage in the ATF content as much as possible.
Remember, we have one second only for the (mumbling). Anyway, if you need it, at least use WOFF 2.0. It's compressing the files and it has a better compression algorithm than all the other typographies, so that means it will be transferred sooner over the network. You should also reduce glyphs and non-used characters. That means that sometimes, font files are optimized for printing a billboard on a highway.
On the web, sometimes we don't need that quality. We can reduce the glyph, that will make the file smaller, and also we can remove characters we're not going to use. Some font files include, for example, Greek characters or French accents. Sometimes even Japanese characters. If we know that our web app is not going to use those characters for sure then we can remove the characters.
There are tools that will let you remove those characters from the font file and then the file will be smaller, and then we can run the text sooner. Also, and this works on every browser, if the file is small enough, we can embed it in Base64. We can convert that font file in Base64 format and embed it inside the CSS directly, so at that point, the CSS will be bigger, but at least it will appear before because there will be no need for another HTTP request.
We already mentioned that the browser realized that there is a font file to be downloaded later, so we can try to say to the browser, "Hey, browser, you know what? "Later, you will need a font, so if you want, "can you start now and download the file?" For that, we're going to use a new link element with the rel preload. We're going to say these as soon as possible, as early as possible in the HTML, and we're going to say, "Why don't you load these as a font?" Because it's a font, the browser will create a high priority for the file and it will try to download that file as soon as possible, and of course, a couple of milliseconds later, it will parse the CSS and it will realize that that file will be needed, so at that point, that file is already being downloaded.
This usually, on compatible browsers, can help the timing in around 10%. We can reduce the initial paint time around 10%. Also, you can respond with an HTTP header. Instead of adding this in the HTML, the server can respond the HTML with an HTTP header saying, "I want that WOFF file as a font." Then, the browser will know, even before parsing the HTML, that that file will be needed.
Finally, we have a new API that is coming. It's already available under flag on some browsers or on the latest versions. It's called CSS Font Rendering Control. The good news is, we can start using it today, and in the future, it will be available automatically. The idea is to define with CSS, how do we want to manage the font problem? We can specify that we want the mold block to show an invisible text until the font is loaded.
This is basically the default behaviors that we have right now, so we see nothing until the font is loaded. We also have swap mode. In this case, it will use the alternate font, so on CSS you can specify with commas several fonts, until the font is loaded. This is known as F-O-U-T, FOUT, flash of unstyled text. You will see a text with a different font, and after a couple of milliseconds or seconds, that text will change, it will flash.
We'll have fallback. That is kind of in the middle between block and swap. It will wait a short time, and it depends on the browser, but it's typically 100 milliseconds, before rendering the text with alternate fonts. If the web font appears within 100 milliseconds, it will render the text with that. If not, it will go to an alternate until that web font is loaded. Finally, we have optional. This is like fallback, so similar to fallback.
It's between block and swap, it will wait a short period of time before rendering that text with an alternate font. But if some conditions are met, conditions defined by the browser, the browser will never download the font. For example, if you're roaming, if you're in (mumbling). If the connection is not working properly, it's really slow, then the browser will say, "You know what? "I'm not going to download that web font." That's why it's optional. If we have good conditions, then the browser will download that file.
This is how it looks from a CSS point of view. It's inside the font face attribute with all the other properties. We have the new font-display, and here for example, you are going to say, I want to use the swap mode. If a browser is not supporting the property, it will just ignore the property, so it won't do any harm to start using this today in our enterprise web applications.
- Web performance optimization (WPO)
- Charts and metrics for measuring performance
- Measuring performance on different platforms and networks
- Measuring tools
- Optimizing networks, parsing, rendering, and images
- Improving recurrent user performance and interactions