The use of fonts in web development plays an important role in how a web application is presented. Different types of fonts have different meanings and areas of usage.
To ensure a consistent presentation of applications using fonts, there are options to consider, each with their own pros and cons.
In this article, we’ll learn:
To use fonts in web applications, we would have a referenced CSS file with codes similar to this:
body {
font-family: Helvetica, Arial,...
}
The use of several fonts separated with commas for font-family (as seen above) is called font stacking. It’s a technique where multiple fonts are provided (as fallback) for systems where the preceding font is not installed. That is, Arial (for the code above) would be used on systems where Helvetica is not installed.
Usually, more than one family is specified (though similar in style, weight, and so on) to ensure, as much as possible, the same presentation across many devices. But the truth remains, you can never get a perfect cross-browser feel. This is because such usage of fonts depends entirely on the system the browser is used on. It would be very difficult to ensure a consistent appearance of your web applications across many systems unless you stick to the most common fonts.
This is the problem web fonts tries to solve.
Hosted fonts are web fonts. Web fonts is a technique that is already used in many browsers. It allows the developers to provide a font that all browsers use. In this case, the browser would install the font (not permanently to the device) for the period in which the website would be viewed by the browser. In some cases, it would cache the fonts for future requests.
Fonts like this would be hosted somewhere in the application’s server or a third-party server. Any reference to it by CSS would activate that temporary install (or caching) by the browser.
Let’s say the font is stored in the application’s server, in a directory called fonts, we could have the following:
@font-face: {
font-family: 'MyFont';
src: url('./fonts/myfont.woff2') format('woff2');
}
body {
font-family: 'MyFont', Arial, ...
}
One important thing to note in this technique is that fonts exist in various formats. And, not all browsers support the same formats. For the example above, only systems that support .woff2 would be able to use this font, else, they’ll fall back to using the fonts available in the device.
To achieve similar presentations across browsers, we’ll have to specify various font formats of the same font.
For example, say we had a woff font, the @font-face rule would look like this:
@font-face: {
font-family: 'MyFont';
src: url('./fonts/myfont.woff2') format('woff2'),
src: url('./fonts/myfont.woff') format('woff');
}
Here, the browser would use any of the formats it supports.
Using this approach means that for every font we want to include in our application, different formats must be available for cross-browsers. This is where font services like Google Fonts come in.
Google Fonts provide the CSS configurations necessary to use any (free or paid) font that they have. All you have to do is import it like so:
@import url("https://fonts.googleapis.com/css?family=font-name");
font-weight, font-style as well as a few other properties can be specified in the URL to get the style we need. You can find the documentation of these options on their website.
Note that the CSS file imported is similar to the @font-face declarations we have above. Here’s a screenshot:
You might notice that only .woff2 format is specified in this screenshot. The reason is, Google Fonts does a good job of delivering the required format based on the user-agent. Here’s an answer on Stackoverflow that proves that.
However, Google Fonts (and similar services) are third-party services. The caveat here is that browsers would need to make extra requests – one for your server, and one for the third-party server – to get all assets (including fonts) loaded for your application. Due to multiple external requests, this can affect performance.
If you head back to the image above, you’ll notice that Google Fonts is also making a request to another third-party server – fonts.gstatic.com. This will also affect performance as explained in the last paragraph.
This is one issue that self-hosting fonts solve.
Just in case you think copying the font-face rule is the solution to reducing the extra third-party servers — it’s not! It won’t work. Like I stated a few paragraphs above, Google Fonts deliver only the fonts the user-agent needs. This article by Chris Coyler goes into detail.
I mentioned earlier that fonts can be saved in your application’s server. This is also related to self-hosting fonts. Your server hosts the font stylesheets (containing the @font-face rules) in this case.
You would want to self-host fonts to avoid those multiple external requests. A request is made to your server and all fonts assets are provided immediately from that server without the need of going elsewhere.
A better application of self-hosting fonts is self-hosting Google Fonts. This is because they provide numerous configured stylesheets for fonts. This will save you the hassle of setting them up yourself.
Note that, you would need to ensure that the license of the fonts (that you want to use) permits you to use the font outside Google’s server.
Best Support provides a configuration that supports old and new browsers while Modern Browsers configures only for modern browsers. You can choose which one you want.
You’ll also see the fonts path field below in the image. This will help modify the fonts’ reference. You can leave it as is, but note that you would have to correctly specify the path to the font (in the @font-face rule) depending on the directory you place the stylesheet.
When extracted, you’ll have fonts of different formats that you can store in the right directory.
With all these setups, all font requests will be made to your server alone. This improves performance, which is our main goal.
You can check out this article for more information.
Hosted fonts services solve the difficulties of trying to ensure uniformity of fonts across web browsers as well as providing us with various fonts.
Self-hosting fonts is another technique that allows our applications to ensure performance as well as leveraging the ease in using fonts and stylesheets that hosted fonts services provide. This, as stated in the article, would depend on the policies behind using the fonts.
You made it to the end, and now I believe you have a better understanding of how fonts work and what differentiates self-hosted fonts from hosted fonts like Google Fonts.
As for which is best to use, it comes down to your needs The trade-offs are little. While self-hosted fonts reduce third-party servers and give you 100% font control and management, you can trust Google’s services to deliver the best as quickly as possible. Performance in such cases might be minimally affected.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Bypass anti-bot measures in Node.js with curl-impersonate. Learn how it mimics browsers to overcome bot detection for web scraping.
Handle frontend data discrepancies with eventual consistency using WebSockets, Docker Compose, and practical code examples.
Efficient initializing is crucial to smooth-running websites. One way to optimize that process is through lazy initialization in Rust 1.80.
Learn more →
