5 ms·
I typically embed the font into the CSS using base64 data URIs. Even typically large CSS files compress with gzip extremely well and if you have one style sheet
by gvkhna 5y ago
I typically embed the font into the CSS using base64 data URIs. Even typically large CSS files compress with gzip extremely well and if you have one style sheet to load your page will load the fonts and styles in one go very quickly.
I don’t know why more websites don’t do this. Even having one large CSS file with everything compressed is much much faster then the waterfall of more files/connections.
I recommend postcss-import that takes your file paths and embeds the files during build. Use responsibly.
- Dylan16807 5y ago> I don’t know why more websites don’t do this. Even having one large CSS file with everything compressed is much much faster then the waterfall of more files/connections. I could make a similar argument to say not to use CSS files, just embed everything into the page. Unless you have a ton of files, listing them all in the html will make them load just about as fast as a single file listed in the html.
- markdown 5y ago> I could make a similar argument to say not to use CSS files, just embed everything into the page. Then the poor user has to download heavier html on every page as the browse the site.
- michalc 5y agoI actually think there are cases for this. Say, you have a small amount of CSS and/or the user will in all probability just look at the one page on the site.
- markdown 5y agoThere absolutely are, and I've done it myself. But it's a rare site that would really benefit from the method.
- grenoire 5y agoWebdevs usually forget that neither practically unlimited bandwidth nor quotas should be take for granted. A lot of people have slow internet connections, don't make 'em suffer.
- Dylan16807 5y agoYeah but the first load is faster!
- michalc 5y agoI've done this a few times as well. Another benefit of this is that there is neither FOIT nor FOUT.
- Ayesh 5y agoMore often than not, base64 encoding has a negative net-impact. - base64 encoded strings are larger than the real file size. - It blocks browser rendering. Browsers can still render a page while it's downloading the fonts. Not while it is downloading CSS. - Makes cache busting hard. You will update CSS files more often than fonts. Fonts, served with right headers, can stay longer in browser cache. - Base64 encoded strings don't compress well. I go as far as sorting the attributes/combined classes to increase the compressibility of the CSS, but base64 strings hardly compress. You won't see FOIT/FOUT because the browser is outright blocking the rendering until the CSS is completely downloaded. That is arguably a worse outcome.
- eloisius 5y agoThese are valid points, but in non-perf benchmark terms, what is the benefit to rendering before fonts load? I have never appreciated getting to read for a couple of seconds before the screen repaints and I lose where I was and just start over.
- greggman3 5y agoI have never appreciated being on a slow connection and not being able to view the info I need because fonts are downloading for 30 to 60 seconds.
- maccard 5y agoIf your font I'd big enough that it's causing a "couple of seconds" then you should just use the system fallback font rather than leaving me staring at a blank screen
- deleted 5y ago[deleted]
- silverwind 5y agoWeb fonts with limited glyph sets are like 30kB before base64, it's certainly worth it to block for a few milliseconds more to prevent FOUC/FOIT altogether.
- SquareWheel 5y ago> I don’t know why more websites don’t do this. Simply because it's not very performant. base64 will make the file about 30% larger, and web fonts are already too big. It'll also block the rest of the CSS file which can delay layout calculations, and the font-display property won't work either.
- o_m 5y agoI agree that one CSS file is often faster, but the thing you say about waterfall isn't true if you are using HTTP/2. You are better of serving multiple files for the fonts.
- theandrewbailey 5y agoWhether that's better depends on the user's RTT to the server, and if there's already a connection in place when the browser requests the font.
- zamadatix 5y agoSeems less efficient and harder to maintain than preloading the optimally precompressed font file before the CSS statement as per step 3 of this guide. Not to mention this method preserves the flexibility offered in step 2 of the guide.
- Theodores 5y agoBrotli. Brotli. Brotli. Chomp 25 percent off the CSS. Use static compression so there is no gzip going on before the file is served. Combined with embedded fonts in the CSS, stripped to the glyphs could be the speediest. Woff2 has its own compression, would be good to have that uncompressed in the font and compressed in the Brotli.
- rdsubhas 5y agoOut of curiosity, how did your LCP in Chrome timeline [1] look like before/after inlining? If LCP is lower with inlining, then the approach works beyond doubt! 1: LCP – Largest Contentful Paint – a core web vital metric representing time for the visible viewport to be stable. This is better than the old "document ready" because document ready is technical, hundred other things like reflows can happen after document ready. Whereas LCP represents from a user perspective when the viewport is ready. When fonts create reflows, the viewport becomes unstable and LCP will be higher. Lower LCP = Better user-perceived loading time. https://web.dev/lcp/ https://web.dev/lcp/