We had an awesome question by Pamela Fox for our Google IO talk - Mobile Web Development: Zero to Hero. In summary the question is "How can you use the Google Fonts API on mobile while optimizing performance? (Both visual + # of requests)" - which is interesting because on the Desktop it is not something you particularly worry about, but in mobile it is one of the most important things you need to consider - bandwidth, latency and visual aesthetics.
From the Aesthetic point of view, we specifically chose two fonts that had been designed to work on the mobile context, that is Droid Sans and Lato. So they looked pretty nice.
On the number of requests front, we used App Cache. If you look at our source code for the project
, you will see that the App Cache
includes 3 remote objects, namely the request for the CSS of the fonts and then the two physical fonts. The first load of the application will download 3 files, but all subsequent later runs of the app will use the data from the App Cache and thus will be blazingly fast. A caveat to mention is that the number of files requested is directly proportional to the number of fonts in your CSS src.
To get the true URL of the fonts isn't amazingly easy, the Web Font API is designed to abstract away some of the detail. We determined the URL of the fonts by delving in to the response of the request to the CSS file.
The AppCache and Web Font API work well together because the physical font file is determined at the time of download and since we won't change browser we know we are getting the correct font file and keeping it permanently cached (until the next App Cache update).
On the subject of ensuring that the file size is a small as possible, it is possible to download a subset of the font file
by specify only the characters that you need for your page. We didn't need this level of control purely because it is possible that a set of News articles will require the use of every single character in a given font (or a very large portion at least).
So, in summary that is how we optimised our font usage for the mobile context.
About Me: Paul Kinlan
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without
having to install a native app or produce content in a walled garden.
Our team tries to make it easier
for developers to build on the web by supporting every Chrome release, creating great content to support
developers on web.dev, contributing to MDN, helping to improve browser
compatibility, and some of the best
developer tools like Lighthouse, Workbox, Squoosh to name just a few.