Recently, I was working on a project where the font kit was starting to get rather heavy due to the number of fonts we had painstakingly chosen to reflect the voice and tone of the brand. The kit was weighing in at around 300–400kb, which was a massive handicap on our target page weight before we had even added a single piece of content.

This realisation forced me to rethink my approach to the typography in the project, especially for users on poor connections—who we generally assume to be mobile users. My next plan was to use web fonts only as typographical flourishes, and the default system fonts would provide a stable baseline for the bulk of the typography. Headings would be web fonts served from Typekit to retain the link with the brand identity.

This was before I discovered that relying on default system fonts in responsive design is a fool’s game.

Modern web design has, without a doubt, become more complex when compared to the environment in which we started out as web designers—particularly in regard to typography. Before the introduction of web fonts, and the added challenge of the varied device landscape we face today, we relied on a select few system fonts to either display common typefaces across different platforms, or to fall back to the nearest common font in the font stack. System fonts in the past were the foundation from which we built our typographic decisions, but today’s device landscape is a wildly diverse space and requires a more nuanced approach. Our desire to present a smooth, consistent aesthetic across devices must be balanced with the principles of responsive web design for an optimal user experience.

I learned through my own experience that a font stack based on system fonts is no longer as safe as it was before the mobile device boom. Where system fonts in the major mobile operating systems are concerned, there is barely any consistency at all. For example, the Android operating system only comes packaged with 4 system fonts — none of which appear on iOS or Windows Phone, and those two platforms only share a handful of fonts between themselves. In the process of creating a compatibility table of shared default fonts across these systems for my own reference, what I ended up with was actually more like an incompatibility table. There is no safe native typographic foundation on today’s web.

Fortunately, web fonts do provide consistent typography across major mobile and desktop operating systems, but they come with the caveat that good typography isn’t free in regard to page loading cost.

Web fonts are like any other asset when it comes to responsive design: they carry a variable weight that changes depending on the number of fonts you use. A heavier page weight results in a longer page load due to the time it takes the browser to download the assets, and as a maker for the web it makes sense to shoot for the lowest common denominator in terms of performance matters like page weight.

“Loading only the necessary” is a mantra for responsive designers. For responsive projects, we want to keep the page light in anticipation of the next user coming from one of any number of devices, and on a completely unpredictable connection speed.

If we think of web fonts as assets on the page—like images or any other asset—then we can use media queries to load different assets for different displays. For example, we can load high definition images for retina displays; why not do something similar for web fonts?

I applied this thinking to my own project by producing two separate font kits: a “full” font kit containing all the typographical styles I originally intended to use, and a “light” kit containing fewer fonts (and, consequently, weighing significantly less). I loaded the kits via JavaScript depending on the width of the user’s screen, with the value based on the smallest breakpoint. Smaller screens received the lighter kit and subsequently took less of a bandwidth hit; larger screens received the full kit, and enjoyed the complete spread of selected typographic styles.

I am loading the “full” kit when screens meet or exceed one of the larger breakpoints, on the assumption that such a screen is a larger device—like a laptop or desktop—and more likely to be on a faster internet connection than a smaller device. Many techniques in responsive web design require developing assumptions like this for the purposes of decision-making. It sounds like a lot of parameters, but this is how we work with other assets—such as images—in the meantime until other methods like the Network Information API become available to us to make more informed decisions. In this case, the decision resulted in a much more reasonable page loading experience, specifically for devices on poorer connections.

If multiple kits aren’t an option, then I would suggest revisiting your approach to typography based on responsive principles. Aim for the lowest common denominator serving only the necessary assets. Establish your font kit by adding fonts and families only when you need them—this works best when you are working in the browser with real content. By evaluating which font assets are necessary with a mobile-first mindset, you’ll be less inclined to bloat a font kit with unnecessary typographical assets that will lead to an underperforming page.

I have a real passion for responsive typography, specifically for mobile. These small, incredibly powerful little devices provide immediate intimacy, and what I love most about them is that their beautiful high density displays allow web fonts to really sing. From a typographic design context, responsive design allows us to have fine control over our typography, using media queries to create different typographic rules to address different screen properties where appropriate.

Responsive web design has allowed us as web designers to become more flexible and embrace the inherent fluidity of the web and the diversity of devices that access it. We don’t have to sacrifice beautiful typography for the sake of developing a page that performs smoothly across multiple devices; indeed, responsive design and typographic design go hand-in-hand.