With webfonts it is extremely easy to use very pretty fonts that make your websites look astonishing. What many people don't realize though, is that webfonts always affect performance, in some cases making them load very inefficient and slow.
First of all people often simply load too many fonts and secondly, fonts delivered over the web from external source like Google Webfonts, Typekit, Fonts.com, etcetera, always require additional network connections, similar to the external connections required by social networks to display counter- and share buttons. Luckily there are several ways to deal with this issue, from pretty basic to more advanced. Let's start with the basics and then dig deeper:
Running a performance test on tools like Pingdom and GT-Metrix can easily show how fonts affect your site. Look at this example where we can recognize 6 font-resources loaded from Google Webfonts from the domains fonts.googleapis.com and fonts.gstatic.com:
The example above shows a site with 2 fonts: a header font and a body font. In this case they both use Lato, but for the header font the weights 700, 400, 300... are used, while a separate call is made load the font again for the weights 900, 700, 400, 300... etcetera. Of course this is not efficient. Also, the combined weight for the fonts is around 120 - 130 kB.If you realize that you should aim to keep the combined weight for a page under 1MB, the fonts alone already use of 12-13%! Sometimes, you can even recognize a true bottleneck for the speed of your website where you can actually measure a font as a blocking resource and I have even seen websites where I can see the site freezing while downloading its remote webfont.
Using this knowledge, we can now make some decisions. If no issues are found, leave the situation as it is. If we do, let's do something about it:
Making wise choices can already make it very easy to reduce font-weights and database calls:
Having made these choices, it is time to get a little more technical:
This statement is a little bit bold, but what I mean is that you can still use webfonts, but should avoid loading a web-service to retrieve them. Services like Google Webfonts, Typekit, Fonts.com and similar services usually provide the fonts by offering them from their own CDN's. This makes you dependent of their services. While often they do this pretty efficiently, offering the font from your own site is often more efficient, especially if you have efficient webhosting and also use your own CDN. If you don't use a CDN, the difference will be less obvious. It also depends on how efficient your hosting environment is.
So, the solution for slow font-services can be to use your own local fonts. Let's see how to achieve this.
Fist of all, where do we get our webfonts? For this you need fonts in several formats for full browser support, but .woff or even .woff2 alone files will get you a long way in most modern browsers (otherwise load .eot, .ttf, .svg as well). Many people use Fontsquirrel services for their fonts. They have a large variety of fonts that you can use, often for free. Still, many of you may want to use the fonts provided by Google Webfonts as you are already familiar with these. The problem is that Google Webfonts does not offer an easy way to download these fonts, you are supposed to use remote font-embedding, of which we just found we don't want to use it.
Luckily though, there is way around this that many don't know: The Google Webfonts Helper service. This service makes it possible to download any font you want to use on Google Webfonts to your PC. Simply choose your desired font and the weights you need and off you go:
There is more stuff that you can customize if you want to make it even easier to include the fonts in your CSS. You then receive the full CSS syntax to use them. Another service that allows you to download Google fonts is www.localfont.com.
The best supported mechanism for local webfonts is to use @fontface embedding. This technique is widely supported across most browsers and devices and is very efficient. Also, the technique is very easy to use in your CSS. It involves:
This gives you an example like this:
/* lato-regular - latin */
src: url('../fonts/lato-v11-latin-regular.eot'); /* IE9 Compat Modes */
src: local('Lato Regular'), local('Lato-Regular'),
url('../fonts/lato-v11-latin-regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
url('../fonts/lato-v11-latin-regular.woff2') format('woff2'), /* Super Modern Browsers */
url('../fonts/lato-v11-latin-regular.woff') format('woff'), /* Modern Browsers */
url('../fonts/lato-v11-latin-regular.ttf') format('truetype'), /* Safari, Android, iOS */
url('../fonts/lato-v11-latin-regular.svg#Lato') format('svg'); /* Legacy iOS */
You may not use the full-code, but the comments in the code already may tell you which ones you do not need. If you build your own templates, this is usually very easy to include in your own CSS. But what about commercial templates?
We face a challenge if we want to use this technique in commercial templates from template clubs like Rockettheme, Yootheme, Joomlart, etcetera. They usually make it very easy to select your font of choice from a font-picker that usually hooks into Google Webfonts. Deviating from this is not always easy. Luckily some providers recognize the need for this and provided documentation for local fonts, but if they don't, you will have to code around it, often facing issues with template updates. I checked for the 3 big providers that provide clear documentation for this procedure:
There is an advanced technique that makes local font usage even more efficient: base64-encoding. I already wrote an article about using this technique for images, but just as well you can use it for fonts. Using this technique means that you do not actually use a file for our fonts, but you provide an insane string of plain-text-code that corresponds to a font. You use this code in your CSS instead of the path to the font-file and from there you can use the font as you would in any other situation.
Converting fonts to base-encoded fonts is actually done quite easily. The people from Fontsquirrel have provided a conversion mechanism for this, the Webfont Generator. This tool converts an .otf font-file that you supply to the webfonts formats you want. For our purposes, we need to go a bit more advanced, so we have to select the Expert-options:
Having selected the Expert-option, a whole range of additional parameters opens up. Scroll down until you see the CSS-options:
Make sure you select the Base-Encode tickbox. Also make sure you accept the license agreement and then you can click the Download your kit button to download your files. If you open up the provided css-file, you will see the styles for the whole font embedded, something like this:
Actually, this string is much longer, but I guess the principle is clear. Only use this technique if you are really pushing for performance. And preferably, only use 1 font. The browser now does not have to download the font-resources, but it does have to internally process the base-encoded string into something it can use, which takes processing time. Using more fonts requires more processing time, and also this can be hard, especially on older browsers and devices. There are some more small downsides to this technique, but in many cases, it works perfectly.
So, I hope you have some ideas to make your own fonts load a lot more efficient now, have fun ;)
Joomlaseo.com is fully built and written by Simon Kloostra, Joomla SEO Specialist and Webdesigner from the Netherlands. I have also published the Joomla 3 SEO & Performance SEO book. Next to that I also sometimes blog for companies like OStraining, TemplateMonster, SEMrush and others. On the monthly Joomla Community Magazine I have also published a few articles.