: Optimizing (reducing) web font requests My homepage currently uses 5 web fonts--I'd like it to be 6 due to spotty support for Helvetica Neue. One of the fonts is 'FontAwesome' icons, the other

@Hamaas447

To follow up, I ended up using the advanced options of the @font -face generatorto subset my fonts, so I only loaded the characters needed.

One of the options was to Base64 encode the fonts (which allowed me to embed them in my CSS file). If memory serves, it Base64 encodes the .woff and the .ttf font.

While I like to support as many users of as many browsers as possible, I decided it wasn't worth slowing down the users of modern browsers with extra, likely redundant, data so I used Modernizr (which uses yep/nope.js) to asynchronously load a separate CSS file with references to all the font formats as per the hardened bulletproof font face syntax.

I went back and forth between Base64 encoding the .woff font and including the rest of the font declarations in the primary CSS file or only including the Base64 encoded .woff in the primary CSS and then including the other formats in a CSS file which I loaded asynchronously via Modernizr.load.

I prefer fast load times to aesthetics so FOUC wasn't a big concern but I will note that most browsers sort of 'blinked' on the fonts when they loaded (which was after the Base64 encoded fonts in the CSS had loaded) async.

On the plus side, once the fonts were loaded and stored in cache (long expires headers set on server) the 'blink' was eliminated and I was able to load extended sets of the fonts so that users who spoke other languages (and used the Google translate widget that was included) would still see stylized text.

Since this was my own site, I was able to experiment but I was largely doing it to "show off", I am more conservative with client sites.

Another technique I implemented was putting all the .svg fonts into a single file and identifying each with its own ID rather than having each in a separate file as the @font -face generator produces.

Vote Up Vote Down

@Jessie594

Using non-standard web fonts have a significant performance impact on page load times compared to just using standard web-safe system fonts. This is the case regardless of whether you're using JavaScript or @font -face.

One should always carefully analyze whether or not non-standard web fonts should be used.

Some questions to ask yourself when considering using non-standard web fonts:


Are you using them just to show that you can and know how to?
Does it server a purpose in executing a better design and provide
a better user experience?
Is the method used to implement the fonts cross-browser compatible?
Could an image suffice, especially if it is only a few words on a
single page or just a few pages?
Is the font different enough from the web-safe fonts to make it worth-while to use?
If the font is used as body text, is it easily readable, or is the
font designed for headers?


Make sure you at least understand the fundamentals of typography and how it impacts your design, and use that to your advantage.

Vote Up Vote Down

@Angie530

the other 4 are only used for a word or two


Is that a literal statement?
If so why are you bothering to embed these fonts at all, subsets or not? You shouldn't even be optimizing in this case, just removing. Make images of the text you need and use your favorite text-replacement technique. You're adding HTTP requests and download time to your site for the sake of a few words.

Vote Up Vote Down