April 17, 2013
Today’s guest post was written by Jordan Moore, a writer and web designer based in Northern Ireland.
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 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.
Jordan Moore is a Web designer and front end developer from Bangor, Northern Ireland. He is a responsive web design enthusiast with a passion for typography and frequently tweets as @jordanmoore.
August 16, 2012
At Typekit, we’re always working on ways to serve web fonts more efficiently and to improve the performance of our service. To that end, we’re excited to announce some changes to our font serving infrastructure that have significantly improved the performance of all kits.
You don’t need to do anything to take advantage of these performance improvements; all existing kits should already be seeing the benefits. Read on to find out what has changed.
Long cache headers for font data
The result of these longer cache times is that font data is loaded significantly faster on average. There are two reasons for this: first, a visitor who returns to your site is much more likely to load the fonts from her browser’s cache, rather than making a request to the network. Second, if the fonts are requested from the network, they are more likely to be available cached at an edge node in our content delivery network rather than requiring a round trip back to the origin server. In both cases, fonts load much faster.
New font serving infrastructure
So what changed about our font serving infrastructure that has allowed us to increase the cache times for these CSS files? To answer that question, we need to understand how kits were previously published, and the changes we’ve made recently.
Previously, a kit was published with its own individual CSS file for each browser. These CSS files have URLs that look like this:
In this URL,
abc1def is the Kit ID and
g is an identifier for the type of fonts contained in the CSS file. When a Typekit user changed the fonts in her kit and republished, the font data in those CSS files would update, but the URL would stay the same. This meant that we had to keep cache times relatively short, so that a cached CSS file with the old fonts would quickly be replaced by the new one. It was a balancing act between speed of updates and the number of times a visitor’s browser had to check for new fonts.
Now, newly published and republished kits no longer use CSS files that are specific to the kit. Instead, the new CSS files have URLs like so:
Improvements for older kits
We’ve also made the same performance improvements for existing kits that haven’t been republished of late. Since old kits will move to the new-style URLs as they are republished, we can safely increase the cache times on those old kits without interfering with development. All kits, regardless of when they were published, now have CSS files that will stay cached for one week.
Future performance work
As always, if you have any questions about any of this, just drop a line to firstname.lastname@example.org.
July 19, 2012
We’re constantly working behind the scenes to improve performance across our font network. Most of these changes are, by design, invisible to you or your visitors. But today we’re releasing some small but meaningful changes to our recommended embed code that will make font serving even better.
To benefit from these improvements, you need only update your sites to use the new embed code. Note that doing so is completely optional: all sites using the prior embed code will continue to work. But the new embed code offers a few performance improvements which we think you’ll appreciate.
Protocol relative URLs
Without further ado, here’s what the new embed code looks like:
The second change is that we’ve made all kits available at use.typekit.net in addition to use.typekit.com. These hostnames run on the same infrastructure and behave identically. The only difference is that the new domain does not have any cookies set on it, as recommended by both Google and Yahoo performance best practices.
Official asynchronous embed code
Previously on this blog, Sean discussed a variety of approaches to loading Typekit fonts asynchronously. The upside of asynchronous loading is that, if a request for a kit is slow for any reason, it won’t block the rendering of the rest of the page. The downside is that it requires writing custom CSS to hide the flash of unstyled text that can occur while fonts are loading. That said, these patterns have been working very well for sites that need this capability, so we’re now including an option to generate the asynchronous embed code directly in the kit editor.
Using the new embed code
You can find the new recommended embed code in the Kit Editor. There is no need to republish your kits to use the new embed code; simply copy and paste the new embed code into your sites.
As always, if you have any questions about this, please reach out to email@example.com and we’ll get back to you right away.