Boris' Bookmarks
Variable fonts reduce the overall combined file size and automatically reduce the number of network requests by simply being a variable font.
Even if you consider the slightly larger file sizes, when combined with improved font compression formats like WOFF2, font subsetting and font loading techniques likefont-display: swap;we end up in a situation where we can still get smaller overall font file sizes as well as a significant increase in stylistic opportunity.
And there you have it, a way to change the
font-displaysettings of a page when using WebPageTest. No need to manually update the code to see what effect the property has on a pages perceived performance.
Yes it's better to self-host as the performance gains are substantial […] However, Google Fonts is not just a repository of hundreds of free fonts - it is also a clever delivery mechanism […] There is some complexity involved in this (which Google Fonts handles for you) but with WOFF2-only being a realistic option now, and good support of most techniques with inbuilt fallbacks, this is easier than it used to be.
The crossorigin attribute, when used with rel="preconnect", doesn't describe where the target origin is but rather what kind of assets will be downloaded from that origin. If the assets use CORS, crossorigin is needed. If CORS won't be used, crossorigin should be omitted. If both types of assets will be present, two resource hints are necessary.
Browsers don't always behave as we would want or expect them to, but we do have tools at our disposal to steer that behaviour towards the result we want.
If you're using a web font, you're bound to see a flash of unstyled text (or FOUC), between the initial render of your websafe font and the webfont that you've chosen. This usually results in a jarring shift in layout, due to sizing discrepancies between the two fonts. To minimize this discrepancy, you can try to match the fallback font and the intended webfont’s x-heights and widths [1]. This tool helps you do exactly that.
Google Fonts are easy to implement, but they can have a big impact on your page load times. Let’s explore how we can load them in the most optimal way.
This is a small explainer that I built for a talk on web fonts and performance. […] For example, if you're rendering the main body text on a site, you should use
font-display:optional.
Given the issues I outlined earlier, should we even consider preloading fonts?
I suspect even with Chrome’s current sub-optimal behaviour there’s a case for preloading one or maybe two critical fonts.
But don’t take my word for it, test it for yourself as your traffic mix e.g. Safari vs Chrome, the choice of server and your page make up will influence the outcome:
Yes because :
- Group Repaints (better performances)
- Adapt to User Preferences (a11y and UX)
- Adapt to User Context (better performances, UX)
- Using Third Party Hosts for fonts
"Web performance is an intricate topic but well worth the effort. Cutting down initial network requests through progressive enhancement and lazy loading is useful to make initial rendering as fast as possible. Showing basic content first, and then loading enhancements like fonts, media, and scripts later, brings the user experience in harmony with aesthetic designs and business goals."
Web fonts are awesome. They make your sans-serifs slabby, your headers special and your website look gorgeous. But fonts are a resource, and downloading resources always comes as a cost — if you don’t load web fonts efficiently, what you get instead are phantom underlines, blank pages, and user rage. Let’s talk about ways to avoid this, and what new platform features are here to help us deliver pretty (but also!) fast experiences to everyone.
Web fonts are difficult to get right. An often overlooked and disruptive piece of web performance, web fonts can slow down your site and leave your visitors confused and agitated. No one wants agitated visitors. In this talk we’ll discuss useful methods to render web fonts quickly and without disruption so that visitors can do what should be a simple task—read the text. After all, web fonts are not rocket science.
subfont – a command line tool to statically analyse your page in order to generate the most optimal web font subsets, then inject them into your page. Now listed on Perf Tooling.
So which method should you use to load your webfonts? Unfortunately the answer is it depends:
- If you’re looking for a quick and simple method you can have working within an hour, use Amazon’s method
- If you want something a bit more thorough and are alright with the limited browser support for now, try using font-display: optional
- And if you really want to make an effort to optimize your webfont loading, take the dive and look into the localStorage technique