Make the Web Fast: Google Web Fonts – making pretty, fast!


BILL LUAN: Shanghai
GDG is a very interesting developer community. SUSANNAH RAUB: I’m
glad somebody has asked this question. RETO MEIER: This is where
the magic happens. JENNY MURPHY: This is primarily
a question and answer show so if any
of you out there would like to ask questions. ILYA GRIGORIK: Hello everyone. And welcome to our Make the
Web Fast episode here on Google Developers Live. Today we have an exciting
episode about web fonts and Google web fonts. But before we get so that, my
name is Ilya Grigorik and I’m a developer advocate for
Make the Web Fast team. DAVID KUETTEL: And hello. I’m David Kuettel, an
engineer from the Google Web Fonts team. ILYA GRIGORIK: Awesome. So, David, as I was reflecting
on the title of this episode I said, “making pretty fast.”
And I think in retrospect, that actually kind of created
a false dichotomy. Because it almost gives
a message of, it’s one or the other. It’s like, if you make
it pretty, you can’t make it fast. And I think as we were working
through the material that we’re going to cover, certainly
one thing that I realize is that’s definitely
not true anymore. In fact, there are many cases
where you can use web fonts to make your site perform
faster and perform really, really well. DAVID KUETTEL: Absolutely and
we’re really eager to get the message out. ILYA GRIGORIK: Yeah, exactly. So you guys are doing a
lot of exciting stuff. And we’re going to go pretty
deep today on formats, how the data is served, and many
other questions. I often get questions about web
fonts so I think this is very important. Let’s share the screen here. I think the first message that
both of us agree on– and I say I hesitate to call myself a
designer, but in the past I have actually done a little
bit of web design– and one of the things I’ve
learned is that topography is probably the best tool that you
have at your disposal to make something pretty. It’s that idea of simple
and elegant. And you can do a lot with
just a simple web font. And unfortunately, web fonts in
general have not been very accessible, historically,
for a long time to us. So on the web, most of the
content is actually text. So having access to fonts and
being able to do a great job presenting that content is
very, very important. Right? DAVID KUETTEL: Absolutely. ILYA GRIGORIK: So because we
had these problems with web fonts, historically, developers
are an innovative bunch so we worked out
interim solutions. And one of those was, well,
let’s take our text. Let’s use the font that we want,
and then put it as an image on our webpages. And that actually has a lot of
downsides as we’ll talk about. But historically that’s actually
been probably the most prevalent way to get
fonts on the page. This is probably from
2000 to 2007. That is the only real way for
you to get fonts onto a page, which is frankly not very good
for a number of reasons, performance included. So I think because of that,
there was a lot of companies that came to be. And I’m curious to learn a
little bit about the history of Google web fonts. How did you guys get started? DAVID KUETTEL: Sure. Well it’s fascinating. The project started over five
years ago when we were attempting to get more fonts
into Google Docs. We learned a lot
along the way. At first, it looked like it
was going to be really straightforward. We tried them in Firefox. They just worked. We thought, well that’s
very simple. ILYA GRIGORIK: How
hard could it be? DAVID KUETTEL: How
hard could it be? But then when we tried to get
them working across all browsers, platforms, we realized
that there’s actually a lot of complexity. That was something
that we were very excited to make easier. So to back up and answer your
question, are web fonts a future technology? Are they real? Are they going mainstream
today? And we have some numbers. So we launched in 2010. We’ve topped over one billion
font views in a day. We’re on the verge of serving
that on a regular basis. Google Web Fonts are being
used on over 10 million integrations and well over
100 million webpages. We’ve made over 521 web
fonts available. They’re all open source, free
to use, and we have a very simple and straightforward
[? pay scale. ?] ILYA GRIGORIK: 521
font families– I think that’s more than what I
have installed on my system. It’s a very deep library
already. DAVID KUETTEL: That’s
very true. In the past developers have
been limited to the set of web-safe fonts which has
been a set of four. And so you’re absolutely
correct. This is a huge improvement. ILYA GRIGORIK: Right. And it sounds like there’s a lot
of other companies working in this space as well. So does Google Web Fonts work
with any other companies? Or what’s the difference, maybe,
between some of the alternatives? DAVID KUETTEL: Absolutely. Well what’s really exciting is
there’s so much innovation in the space today– from different business models,
to better tools, making more fonts available,
improved rendering, everything. We’ve been very fortunate to
have the opportunity to work with all the major web
font services. We’ve worked with Typekit,
Fonts.com, Extensis, et cetera. And we all want to accelerate
the adoption of web fonts and improve the technologies
together. I also have a few other
key points that I wanted to get across. So for Google, why web fonts? Why would we care? The way I think about it is,
the web is core to Google. There’s no doubt about that. And fonts are a core
of the web. And so we see web fonts as a
really exciting technology that we could use to improve
all our products– from Search, where websites that
use web fonts are easier to index, to display ads,
where they could become richer, interactive, work better
on mobile, to apps, to devices, you name it. And in addition to that, we
really want to help move the entire web forward. ILYA GRIGORIK: So I think that
aligns really well with a lot of the other efforts like CSS3
and others where we are putting a lot of effort into
enabling developers and designers to build
rich experiences. So the kind of thing that you
would have in a magazine before, with a beautiful layout,
and selectable text, and all these things
come together. So let me actually– I think a lot of people have
used Google Web Fonts before, but I just want to show a quick
demo of what does this actually feel like. So I have Google Web
Fonts here open. So we have 521 families. And I think you guys just
recently added this new poster view, which I actually love,
because it’s a very nice visual way to get the
look of the font. DAVID KUETTEL: Great. And Ilyan, I’m going
to time you. Can we do this in 30
seconds or less? So go. ILYA GRIGORIK: Sure. OK. So I’ll pick the first
font here. Quick use– and so a couple of options– for
this font they’re actually two different weights. So normal and bold, so I
can select each one. There is Latin 1 or Latin
Extended for the character sets, which I think
we’ll talk about. And then I just copy this
link right here. DAVID KUETTEL: Absolutely. ILYA GRIGORIK: I think
that’s all I need. So I actually have an example. So I have a GS bin file here,
which if you guys haven’t used before, it’s a very
awesome tool. On the left here I have
just a sample page. And any time I modify something
in here, it just updates the preview
on the right. It is just a very quick
visual way. So I can paste in some
text in here and it’ll include the font. So I’ve actually– I’ve prepared a few
things earlier. So let me just un-comment
this. Whoops. That’s not what we wanted. Let’s go back. So we’ll just un-comment
this font family here. And I’ve created a couple
different rules. So this is just a completely
un-styled page. And what I’m going to
do now is just, for example, style the H1. And all of a sudden you can see
a much nicer looking page coming out on the other end. So just five lines and
this page looks dramatically different. DAVID KUETTEL: Yeah. How easy is that? ILYA GRIGORIK: Right. Exactly. So let’s go back. I actually want to ask you a
few questions on this page because I think we breezed
right by it. DAVID KUETTEL: OK. ILYA GRIGORIK: First of all,
this dial right here is very interesting to me because
it references page load. And any time I notice that
when I add a new font the number goes up. And it tells me that I don’t
want to be in a red zone. So what does this
actually mean? DAVID KUETTEL: So more than
anything, we wanted to just convey the message that
web fonts do lead to an additional download. And so it’s something to think
about something to be conscious of. Of course, it all depends. So if your sites leverages a
lot of images, you’re very likely to not even notice
the extra download. But if it is just a simple HTML
page, the font could end up being the majority of
the download time. And so the indicator is more
of an approximation. It’s a range. It’s not an exact number, for
the reason being that we have a lot of very platform-specific optimizations. So for example, we serve up
smaller files to Mac, larger files to Windows. And so it’s more just
an indicator. ILYA GRIGORIK: And we’ll
talk about that later in more detail. DAVID KUETTEL: Definitely. ILYA GRIGORIK: But I guess the
broad message here is, the more fonts you include,
the more data you will have to download. So if at all possible, it makes
sense to omit things you may not use. Because I’m certainly– I know that I’ve been
guilty of this. Where I’ve come here and– in the early stages my design
I would say, well I probably need the italic version, and
the extra bold version, and these five versions, and just
include them all and then I’d leave them there. And I’m actually
not using them. So that’s a gotcha. Then there’s the
character sets. So this is for different
languages? DAVID KUETTEL: That
is correct. ILYA GRIGORIK: So different
fonts will also have different support for different languages,
I believe. DAVID KUETTEL: That
is correct. Our goal is to expand
coverage over time. But for most of the fonts
there’s largely just Latin coverage today. ILYA GRIGORIK: And then this
last bit here is very interesting to me. So by default, you guys give me
the link to [? act ?] to a CSS file, which I can then
include on my page, right? DAVID KUETTEL: Correct. ILYA GRIGORIK: But there
is two other options. So there’s the Import Statement,
which is also something that I can copy and
paste into my CSS file– DAVID KUETTEL: Correct ILYA GRIGORIK: –and
a JavaScript way. So why would I prefer
one or the other? DAVID KUETTEL: Well for the
first two, we would recommend that you be consistent
with other resources on your website. So if you’re using stylesheet
links, just continue using stylesheet links. If you’ve been using @imports
throughout the CSS, just continue using that. There are some performance
tradeoffs that are good to be aware of. And Steve Setters has an
excellent write up on it. Regarding JavaScript however,
this is more of an advanced feature where you as the
developer can take control over the web font loading
experience and really fine-tune it. ILYA GRIGORIK: So I think
I looked at the– [COUGH] sorry– documentation earlier, and it
gave me a series of callbacks that say, the font is loading,
the font is active. So I can define different
behaviors in that case. DAVID KUETTEL: Yes. And basically you can do
really advanced things. So you can specify– I mean, you can completely
control the behavior. You could have the text
fade in once the font becomes available. You could always flash
un-styled text. You could never flash
un-styled text. ILYA GRIGORIK: So
interesting– You just mentioned an
interesting term there. So un-styled text– so I think in the web font
community this is fairly well understood, but I think
it’s worth spending a few minutes on this. So the problem in general
is, as with any CSS or presentation format, if we show
the un-styled content before the CSS is applied and
then we apply it after the fact, the user may actually see
a jarring experience where the page may completely
re-layout at a certain point, and maybe even shift and change
in look and feel. So in general, browsers
try to avoid this. And we defer displaying the
content until we have all the necessary information. So that’s what you’re
referring to here. And it sounds like with the
JavaScript loader, I could actually define my
own behavior. DAVID KUETTEL: That
is correct. ILYA GRIGORIK: So if you’re
really performance conscious, maybe that’s something that
you could look into. DAVID KUETTEL: Absolutely. ILYA GRIGORIK: So that’s good. And we’ll actually come back
to the import statement because I think this
has some gotchas. A lot of people today use
Build Steps in their infrastructure where they will,
for example, concatenate multiple CSS files together. And they’ll even in-line import
rules into the file. But that could actually
cause problems. Because if you in-line the wrong
file format, as we will see, you may actually break
some of the web fonts. DAVID KUETTEL: That
is correct. ILYA GRIGORIK: Some stuff
to be careful about. So let’s go back to our
presentation here. So we did the 30 second demo
on some backup slides here. Web fonts are really exciting. I wanted to show a few demos. Before we get to the
meaty, technical part, I want to motivate. Why do we care? Right? Because I think there are
obvious use cases like, I want to make my pages pretty. But there’s some other use
cases which are not immediately obvious and they’re
very, very important. So let’s go back here. And the first one that you
shared with me– which I think is awesome– is the web font
award site which contains a lot of very good demo sites
using or leveraging web fonts. So if you go into the gallery–
we’re not going to go through it here– but if
you guys are curious, I encourage you to check out
webfontawards.com. Many, many different sites,
great demos for the kinds of things you can do
with web fonts. DAVID KUETTEL: And
many of these are actually real-life sites. ILYA GRIGORIK: Exactly. DAVID KUETTEL: So they’re
interesting demos for us but real-life sites. ILYA GRIGORIK: So I was actually
on it earlier. And I picked out a couple. So for example, Bay
State College. All of the stuff here– so
very clean, very simple. But all the stuff is text. It’s selectable. It’s easy to read. I think it was very,
very well done. DAVID KUETTEL: Great choice. ILYA GRIGORIK: Another
example– believe it or not, this is
all selectable text. He’s just using web fonts
for this stuff. And it’s got this like grunge
feel and look I think. Until very recently, this would
all have to be images. DAVID KUETTEL: That
is correct. ILYA GRIGORIK: So I think this
is another awesome demo. And then this example. I just stumbled on this. So this is a developer
called Chad Mazzola. He is actually demoing what
you can accomplish with Google Web Fonts. So this is something that you
can use on your own site. So he just put together a couple
of different styles, different looks. So for example, here’s your
two column paper format, a nice quote using Google
Web Fonts. Another font for
a newer look– and you get a sense for the
things that you can do. This example I love. It’s got a feel of
a older book. And this is using nothing but
web fonts and some CSS markup to make it happen. So lots of very cool examples
for what you can do with web fonts. So let’s go back. Another example that I want to
show you, because I really love this example,
is Sean McBride. So he’s actually an engineer
on the Typekit team. And he was actually
an ex-Googler too. And he put together this– he’s given a couple of different
presentations on how you can combine CSS3 and
web fonts to make really awesome effects. And the one that I love is
this hand-painted sign. So this to me looks
like an image. DAVID KUETTEL: Surely that’s
an image, right? ILYA GRIGORIK: Except
that it’s not. It’s selectable text. So what he’s doing here is
he has just regular text. He’s using CSS transforms
to get that– DAVID KUETTEL: The rotation? ILYA GRIGORIK: –yeah,
the rotation. He’s using drop shadows. He has a border. He’s applying a texture on top
to make it look like it’s painted on top. And all of this stuff
is just text. And in fact, here’s a quick
and an awesome tip. There’s a great extension for
Google Chrome called WhatFont. So what you do is– I have it enabled here– you
can just click on it. And then you can hover
over any piece of text on your page. And just click on it. And it’ll tell you what is the
font being used, and by whom it’s being served. In this case, we can see that
the font is being served by Typekit and the name of the
font is Corner Store. And then for this text right
here it’s actually a different font that’s called Bello Caps,
also served by Typekit. So if you’re ever on a page that
has beautiful typography, it’s a very handy extension– DAVID KUETTEL: Extremely
handy. ILYA GRIGORIK: –to just
click and view. Of course, you could also dive
deep into the CSS and figure out what’s happening, but this
is much, much easier. So I love this example. The first time he showed it
to me I was blown away. And I still– every time I look
at it I’m like, I can’t believe that’s actually
the case. So nonetheless, that’s also
more of a design use case. Another case that I came across
as I was researching this, which is very important,
is Wikipedia is actually using web fonts to enable better
cross-language support or multi-language support
on their sites. The problem being
for example– let me go to the site here. I’m loading this
Wikipedia page. And this is not the
actual language. There’s no language
with blocks. It just that Chrome can’t render
this because Chrome doesn’t have the right– it doesn’t support this
encoding format. So to enable this I would have
to go into the system settings and install some font pack
or language pack. I’m not even sure what I need
to do, to be honest. DAVID KUETTEL: And it’s not
always an option on devices like the Chrome [INAUDIBLE],
or tablets [INAUDIBLE]. ILYA GRIGORIK: So if I’m using
some public terminal I may not have access to install
this kind of thing. So what Wikipedia is doing,
is they’re actually leveraging web fonts. They are just starting
to do this. I think they have it for
about 30 languages. This is not one of
them, obviously. But what they’re doing is
they’re pulling down the web font with the proper characters
or the proper glyphs, such that you don’t
have to install anything. It just downloads into your
browser and it’s available immediately, which I think is
a very, very cool use case. DAVID KUETTEL: Absolutely. And they’ve also scoped
the opportunity. And I think they’re targeting
bringing the next one billion users online. So there are quite a few users
that will benefit from this. ILYA GRIGORIK: So multi-language
support is actually a very, very
important use case. And then another one
that emerged recently is icon fonts. So I believe Google Web Fonts
doesn’t actually serve any icon fonts. DAVID KUETTEL: That
is correct. ILYA GRIGORIK: But
there are good reasons to use icon fonts. So for example, one of the
techniques that’s very popular is spreading where you take
a lot of small images– so downloading small images, many
of them, is very expensive because it requires a
lot of connections. So generally we recommend that
you combine small images into a larger image that is then– using CSS positioning–
you can put on a page. What icon fonts do is, instead
of downloading that PNG or some other image format with all
the images, you download one web font and then the icons
themselves are basically characters. And the benefit you get
out of that is that fonts are vector formats. For example, all of these icons
here cycling through are just scaled up versions
of that vector. So they’re friendly for
retina screens. You can zoom them in, you
can zoom them out. They always look beautiful,
which you can’t say with images. So very good– [? reuse ?] and it’s actually
very efficient for this kind of stuff. So Font Awesome which
is an awesome name. DAVID KUETTEL: Which is
absolutely correctly named. ILYA GRIGORIK: And there is many
of these where you can actually customize them and
build your own fonts. I think this font has 200 plus
icons which is crazy. I probably don’t need
all of those. So you can actually customize
it yourself. Let’s take a step back. We talked about Google
Web Fonts. We talked about how
you can use it. But before we dive
into the tech, let’s look at the history. And the first point I’ll make
is that fonts have been with us since the beginning
of the web. We actually had a font tag in
the early HTML versions. And if you guys remember
GeoCities, we saw a lot of Comic Sans. And a lot of images too because
people were trying to put new fonts that platforms
did not have on the web. So that by itself was proof
that fonts have been there all along. However there’s been a
number of issues with using platform fonts. So first of all, the font tag
is non-deprecated ever since the CSS specification came along
because fonts are more a presentation format. They’ve been moved into CSS
such that they support the same functionality, but
it’s the same problem. And the problem is that
depending on which platform you’re using, you will have, as
you mentioned, system fonts on your system. So that may be Arial and Verdana
and a few others on a Windows machine. And a Unix or Linux– let’s
say in Ubuntu– may not have all those fonts,
or historically may not have had all those fonts. So if you are assuming that the
user had Comic Sans, they might have gotten a completely
different experience if they came on a different platform. So because that you were limited
to, I think you said, for web fonts– DAVID KUETTEL: Well and even
less these days– so tablets, like the Android tablets
only come with one, same for Google TV. Chrome has even fewer. ILYA GRIGORIK: Just one. Wow. DAVID KUETTEL: For the Android
tablets and Google TV– Chrome I believe has
three or so. ILYA GRIGORIK: So there, if you
want to have a different look and feel you really
have to use web fonts. DAVID KUETTEL: Absolutely ILYA GRIGORIK: You can’t
rely on system fonts. And the CSS spec does not
address any of this. It would just move it from
the font tag into CSS. But what I think a lot of people
don’t realize is that web fonts have actually existed,
technically, they’ve existed for a long time. Maybe we couldn’t have used
them for a long time. But back in 1997 both Netscape
and Microsoft added web font support into their browsers– as far back as IE4. It just seems that historically
they didn’t, for some reason, get much adoption
back in 1997. DAVID KUETTEL: And there
are reasons and we’ll talk about that. ILYA GRIGORIK: And then in 1999
we had even the W3C web font specification. But it seems like it took until
2007 to get anything off the ground. And in the meantime
I think we’ve– as much as we talked
about earlier– we had to come up with
some solutions. So I think a lot of the web
has migrated towards using images, which is not a very good
solution, which involve either doing manual encoding,
if you will. So putting it into Photoshop
and then cropping it and putting it on your site. Or if you were doing a lot of
these you could actually use service-side plugins. For example, I was a WordPress
user for a long time. And I remember seeing a couple
of plug-ins where, for example, PHP would render the
image on the fly using the graphics library. But to be honest, I remember
spending a day trying to configure it, and I failed. And I gave up on it. So it was complicated. You needed a lot of dependencies
and all that kind of stuff. And then around 2005, another
technique came along, which was Flash replacement, which
is the one I ended up using on my site. And a lot of people gave
me grief about it for a long time. But the idea there was that you
would have your regular text, and then you would have
kind of a combination of JavaScript and Flash, where
once the page loads, the JavaScript would swap out the
text with a Flash movie, and the Flash movie had the embedded
font, which is crazy when you think about
it, but it worked. DAVID KUETTEL: It did. And it was an improvement,
but we still could do so much better. ILYA GRIGORIK: Right, right. So let’s talk about some
problems with these approaches. And there’s a lot
of notes here. So I figured we’re actually
better off just looking at a real example. So I have the CSS
Zen Garden site. And we’re not trying to pick
on CSS Zen Garden. I think many sites are going
to have the same characteristics. DAVID KUETTEL: Rather, we’re
trying to show that this was state of the art, just
two years ago. And it’s how you would create
a beautiful site on the web. ILYA GRIGORIK: Right. So here we have the site. So the first problem that I’ll
highlight is, I have the web developer extension here. So I’ll just disable images. So I’ll hide all of the images
on the page, just so we can see how this page will look. So, Make Images Invisible. And let’s look at
this page now. So all of a sudden, a lot of the
content has disappeared, which is actually how, let’s
say if I’m a crawler– so if I’m Google search
or somebody else, this is what I get. So all of a sudden, the headers
are missing, the paragraph that describes the
site is missing, all this content is gone. DAVID KUETTEL: And a lot of the
elements that disappeared were actually the most
elements on the page. Your headings, your title. ILYA GRIGORIK: Exactly. So if I’m writing a blog post
or authoring an article, I probably want the title of the
article to be searchable. And unfortunately,
that’s gone. Now you could probably use Alt
tags on some of those images, but nonetheless. So if you’re using a screen
reader, it’s still not a great experience. DAVID KUETTEL: And even with Alt
tags, a lot of information is lost, like size, emphasis. ILYA GRIGORIK: Right. Exactly. So that’s kind of problem
number one. The other problem is, of course,
if I zoom in– and this is especially a problem
now with retina screens and other things, where you can
see as I’m zooming in, the quality of this page
is not very good. And the quality of the image
just degrades, whereas the text looks fine, because
that’s actual font. DAVID KUETTEL: Exactly. And it’s worth calling out
that in order to have the image appear sharp on the
newer high resolution displays, like retinas, you’d
actually need to serve up an image that could be
twice as large. So your page would become
slower just to support your devices. ILYA GRIGORIK: Whereas if I
was using a vector format, just zoom in and there’d
be no extra requests. DAVID KUETTEL: Yes, yes. And zooming in is a major use
case on tablets today. Pretty much the first
thing I do. Maybe I’m growing old, but– ILYA GRIGORIK: You’re always
pinching and zooming and scrolling, and trying
to figure what you’re trying to do. So that’s a very good point. And then the other case
is translations. So I actually have the Google
Translate extension here. And what I’m going to do is
I’ll translate this into, let’s say, Korean. And look at that. The content is translated. Everything looks good, except
that all the titles are still in English. So it’s the same problem that
we saw earlier, but it just highlights the problem
once again. DAVID KUETTEL: Absolutely. It’s a major fail. And this is a use case that’s
only going to become increasingly common
going forward. My aunt, for example, English
isn’t her first language. And so she configured Chrome
to automatically translate into her native language. And she surfs the web. And anything that’s text as
image just doesn’t translate. And so, major [INAUDIBLE]. ILYA GRIGORIK: So accessibility, not a good story. And then the last one that I’ll
show here is, I have my inspector open here. And I’ll switch to
the Network tab. So I’ll just reload this page. And this page is about 181
kilobytes, as Chrome tells us. And if I go into the images
part, we can see that 171, which is like 95% of this page
is actually all images. And if we look at some of the
assets in here, for example, this title here, 11 kilobytes. And there’s a whole bunch
of these titles. So most of the weight of this
page is actually in images that contains text, which is
probably not a very efficient way to encode text
to begin with. DAVID KUETTEL: Absolutely. I mean, you might think
they are small, but clearly they add up. And here we were only
looking at one page. So if you imagine browsing
through a website, going deeper in, the images
just add up. ILYA GRIGORIK: So instead of, I
could have maybe downloaded a 20 kilobyte font and that just
would have been reused across all the pages. DAVID KUETTEL: Absolutely. And there’s also another
use case. So for example, what you’ve
listed here, the first one, selecting, copying
and pasting text. Where with images, that’s
lost as well. ILYA GRIGORIK: That’s true. Yes. Right. So if I’m trying to share
something on Google+ or Twitter or Facebook, I can’t
just copy the title and paste it in, right? I’d have to drag over an image,
which is a nightmare. DAVID KUETTEL: Absolutely. ILYA GRIGORIK: Or more likely,
I would have to remember what it is and retype it, which
is not good, not a good experience. With that out of the way, I
think it’s just a good time to pause and talk a little
bit about the history. Like, what happened between
1997 and today. It’s a long time. DAVID KUETTEL: OK. Great. Yeah. And I love this diagram. It really shows that between
2009 and mid-2010, it seemed like all the planets aligned
and web fonts really did become an option for everyone. And it was sort of
a few things. So it was a combination of all
of the major browsers adding support for web fonts. You have Safari, Firefox,
Opera, Chrome. In addition, it was the
development of an open source tool, TTF to EOT, that allowed
your average website developer to create the OT files such that
they could support EOT. Before that, there
just weren’t any really easy to use tools. And so it was very cumbersome
to support IE. And then in the same time frame,
all of the web font services popped up. And so we went, in the course
of just roughly over a year, from basically web fonts,
practically zero to close to 100%. So very exciting. ILYA GRIGORIK: And I think
today, most every browser supports web fonts. I think there’s some outliers. I think last time I checked,
Opera Mini still did not support some of the formats. DAVID KUETTEL: That’s right. ILYA GRIGORIK: But basically,
every other platform is already there. And I think that that leads into
a good point, which is there are many different file
formats, which something I didn’t really appreciate. I was aware of it, but I
didn’t understand the difference between them. So can you tell us a little
bit about this? DAVID KUETTEL: Sure. And one thing that I like is how
you’ve highlighted, under each different font file format,
the percent of web browsers that each
one supports. And the first takeaway is that
none of the fonts, file formats are supported by
100% if the browsers. So if you’re self-hosting today,
you pretty much need to serve all of these font file
formats in order to support closely 100% of the
browsers today. ILYA GRIGORIK: So this
goes back to the how hard can it be? I’ll just throw up a file on my
server and I’m good to go. DAVID KUETTEL: Yeah. Yeah. Unfortunately, there’s a lot of complexity under the scenes. The web is moving forward,
things are getting better, browsers are evolving. Down the road, maybe we only
will need one font file format, but we’re not
there yet today. And so that has been
one of the goal of the web font services. Paul Irish with the bulletproof
at font face syntax to get to the point where
we could just hide all the complexity. ILYA GRIGORIK: So when I was
pasting that CSS style sheet into my page, my demo page, I
didn’t have to worry about any of the stuff, which is great. So I assume that you guys are
taking care of figuring out the font formats and
all the rest. DAVID KUETTEL: That’s right. So if you use a web font
service, all of the complexity is hidden. It looks really simple,
easy to use. If you are self-hosting, it is
more involved and you do need to stay on top of it. ILYA GRIGORIK: Right. OK. That makes sense. DAVID KUETTEL: So jumping
ahead, one thing that we wanted to talk about today is
basically what are some of the interesting architecture
decisions and optimizations that [INAUDIBLE] web
fonts has made. They only make sense, however,
if we sort of step back and look at them all in context. And so here are some
observations that we’ve had, and especially looking ahead. In a nutshell, the web
is the new platform. It’s growing exponentially. More users are coming online. The number of web fonts
is rapidly exploding. For the web safe
font formats– I’m sorry, the number of web
safe fonts is just so history. Online content is becoming so
much richer, to the point where it’s beginning to mirror
offline content. And if you think of offline
content, where newspapers, magazines, books, they’re
all so rich. To date on the web, they’ve
all been very lacking. And we think that that’s been
holding people back from moving to the web. ILYA GRIGORIK: I certainly think
there are good examples where we’ve already gone way
beyond that, where we’re getting much richer experiences
on the web while not sacrificing the look and
feel and the beautiful kind of experience that you
get out of it. DAVID KUETTEL: Yes,
absolutely. And so we see it all
snowballing. As the content becomes richer,
more people are being drawn to the web, et cetera. Another interesting observation
is the number of devices per user is growing. So I, for example, I
have five devices. I have a phone, a tablet,
laptop, desktop, and a Google TV. And all these devices have a web
browser that are used to browse the web. Increasingly, a lot of
the sites that I’m viewing use web fonts. ILYA GRIGORIK: And as you
mentioned, some of these devices only have one font
on their system. DAVID KUETTEL: Exactly. ILYA GRIGORIK: So web fonts is
really the only option there. DAVID KUETTEL: Right. Right. I mean, the web just doesn’t
look that great if you’re only looking at it through
one font. ILYA GRIGORIK: In a console
font, right? DAVID KUETTEL: Yeah. Could you imagine if
it was Comic Sans? ILYA GRIGORIK: So in
2 to 10 years. DAVID KUETTEL: So these
are some predictions. Take them with a
grain of salt. But I really, seriously, do
think that within this time frame, we could see
one trillion web pages using web fonts. We could see a billion active
users on the web viewing these sites. One million websites
using web fonts. We could see larger font files,
largely as the fonts grow to support more
languages. And we could see an explosion
of fonts. Maybe in the 100,000 range. And then pages will become
richer, more typefaces will be used, more styles, weights,
the number of devices is exploding. ILYA GRIGORIK: So this sounds
really exciting. But this also scares me, from
a performance point of view. It’s like, OK, so if I’m
downloading two to four typefaces, one megabyte each,
man, that’s going to be not a good performance story. DAVID KUETTEL: That’s
absolutely correct. And in addition to that, band
with does cost money. Hopefully in time, the
cost goes down. But say it was $0.10 a gigabyte,
your manager would come and knock on your
door as well. ILYA GRIGORIK: So thankfully,
I think we have some techniques to address
these issues. DAVID KUETTEL: That’s right. But in a nutshell,
we at Google, we really like large problems. And we see this as
one of them. And at the same time, it’s an
excellent opportunity for us to help move the web forward
and make it faster. ILYA GRIGORIK: That
make sense. DAVID KUETTEL: So some
goals that we have for Google Web Fonts. Basically, we wanted to have a
really simple, intuitive and easy to use API, to really help
accelerate the adoption of web fonts and to get it to
the point where people were very willing to just try them. We wanted to make sure that our
architecture would scale to the opportunity. And as we’ve talked about,
we think it’s huge. And then, this may be
counterintuitive, but we also wanted to see if we could
basically come up with an approach that would become
increasingly faster as the number of integrations grew. ILYA GRIGORIK: This is very
important, because it’s not something I appreciated
until we kind of went through this in detail. Google web fonts should
get faster, the more they get used. DAVID KUETTEL: That’s
our goal. And we think we’re seeing
early data. And continuing this, we wanted
to make sure that we could enable transparent and ongoing
optimizations. So as the web font technology
improved, better compression algorithms, better way of sub
setting fonts, we could roll out these improvements,
transparent to all of our users, and they would just
seamlessly benefit. And then, as we’ve been talking
about throughout the session, there’s a lot
of complexity. We wanted to hide all of that. ILYA GRIGORIK: So let’s dive
into some of the complexity. I think we’ve spent a
lot of time talking about why this matters. Now convinced, let’s take a look
at, so what’s the problem we’re trying to solve? DAVID KUETTEL: Great. Great. So so this is basically the
biggest optimization. One thing that we realized is,
fonts are one of the most reusable resources on the web. And what we’re seeing is
that many websites are using the same font. So for example, here, you can
imagine there’s [? end ?] websites. They’re all self-hosting,
Open Sans. And so when we, as users, go
and browse all these sites, what’s happening behind the
scenes is the browser’s downloading Open Sans, the exact
same font fights, over and over again. And as you can imagine, the end
result is not the great experience. ILYA GRIGORIK: Especially on,
let’s say mobile platforms, where the amount of available
cache space is also not very large. So if I’m downloading one of
these, let’s say 500 kilobyte fonts, and I visit 10 sites, and
they’re all using the same font, I have 5 megs worth
of font data. DAVID KUETTEL: Yes. Or you’re constantly evicting
the exact same font, just to be downloaded over again. And so the observation that we
made was basically, we wanted to enable cross site caching
of web fonts. So for these end websites, if
you’d imagine, they’re all using Google web fonts. They’re all using the same
API to import Open Sans. What the end result is for end
users is when they visit the first website, they would
download Open Sans, but from then on when visiting the next
website, they would just pick up Open Sans from the
browser cache. And so basically, there wouldn’t
be any latency heads in visiting all of the
other websites. And the net result here,
it’s very different. I mean, we see lowered latency
across the board. It’s sort of amortized
across all websites. And bandwidth drops, in
particular for the web fonts– I’m sorry, for the website, as
we’re surfing the fonts. And as we’re mentioning, with
this approach, as the number of integrations increases,
it could become faster for everyone. ILYA GRIGORIK: That makes
perfect sense. So I think it’s also important
to just call out one quick thing here, which is there are
many different ways how to serve web fonts. And I think some of the
other providers may have a different model. So for example, it
also depends on your business model. So for example, I know that the
early implementations of some of the platforms– I’m not sure what they’re
doing now– actually wanted to make sure
that they serve a specific font per site, because that’s
how they would bill you or charge you, or even know how
many fonts they’ve served. Because maybe you get
charged by page use. So in that case, you would
download the same font every single time. But that was kind of a business
reason to do that. Whereas here, we’re saying
the more people use Open Sans, the better. And that Open Sans is the same
URL across all of the sites. So if CNN.com uses Open Sans,
and somebody then comes to my site using that, I don’t have
to download that resource, which is awesome. DAVID KUETTEL: Correct. So here’s some early numbers
which show this in action. So here’s a graph of the
top 255 font families. And for each, we’re seeing the
number of integrations. And so the high-level takeaway
is that the most popular fonts are very, very popular
and widely used. ILYA GRIGORIK: There’s a reason
why we keep using Open Sans as an example, because it’s
actually being used on over one million domains. DAVID KUETTEL: There is. And that’s just so exciting. I mean, if you step back and
think about it, as a web user, you could potentially browse one
million websites and only download Open Sans once. ILYA GRIGORIK: Yes,
that’s right. And you still have the
beautiful, rich experience of using that web font. DAVID KUETTEL: Yes. And then after that,
it does drop off. But we still see the top 40
fonts, for example, are used on over 100,000 domains. The top 300 are used on
over 10,000 domains. And these numbers
will only grow. Over the past year and
a half, we grew 10x. And it’s very likely that
that could happen going forward, as well. ILYA GRIGORIK: That’s
a great point. And then, I think we’ve covered
this a little bit, but font’s going to be
quite large. This number shocked me when you
first shared it, which is Ariel Unicode for all languages
is 22 megabytes. DAVID KUETTEL: Yes. ILYA GRIGORIK: It’s massive. DAVID KUETTEL: Yes. And the reason being
that it supports nearly every language. But as the language coverage
expands, font files will grow in size. And to the point where they’re
going to be getting closer to Ariel Unicode. And so one thing that we wanted
to talk about on this slide is the smaller you
can serve fonts, the faster it will be. And so there’s a few different
approaches that we’ve taken. And I’ll walk you
through them. So the first thing we did– and let’s start with Open Sans,
which is one of the larger fonts that we serve. ILYA GRIGORIK: So that entire
thing would be 217 kilobytes. The whole set. DAVID KUETTEL: Yes,
uncompressed. And currently it supports
well over 20 languages. The first thing that we did is,
we took the font and we created static subsets. One subset per script. And so if you’re creating a
site in North America, you would just use the
default script or subset, which is Latin. However, if you’re creating a
Russian web page, you’d want the Cyrillic subset. Now for convenience,
all of our language subsets include Latin. And we’ll come back and talk
about that later, how we could optimize that further. But in just subsetting per
script, we reduce the file size significantly. So we drop from 217K to on the
order of 36K for Latin. ILYA GRIGORIK: So that was
that toggle when we were demoing the Google Web fonts
interface, right, when you could select the different
languages. Or I guess, in different
subsets. That’s effectively what
I’m picturing. I’m declaring which languages
I will use on my site. DAVID KUETTEL: Exactly. Yeah. But we didn’t stop there. So there are a few other
optimizations that we’ve made. One thing that we realized is,
for many platforms, the platform doesn’t need hints. Hints are additional
instructions in the font to help improve the rendering, in particular, on Windows platforms. As Mac and mobile do not need
them, we’ve been able to completely strip the hints
from those fonts, thereby reducing the file sizes
even smaller. ILYA GRIGORIK: So that’s
interesting, because that implies to me that the font
being served to a Windows machine, as opposed to let’s
say an iPhone, are actually different files? DAVID KUETTEL: That
is correct. And I’ll show you how we do
that on the next slide. But basically, we try and serve
the most optimized font file that we can– ILYA GRIGORIK: For
the platform. DAVID KUETTEL: Exactly. ILYA GRIGORIK: Interesting. DAVID KUETTEL: Exactly. So going further, after
stripping hints, we apply compression. And so with just simple GZIP
compression, we’re able to reduce the font file size
by another 50%. And then we can do even better
by applying MTX compression for EOT, which reduces the
file size by another 50%. ILYA GRIGORIK: So this is
on top of the GZIP data? DAVID KUETTEL: Yes. And going forward, there’s a
new compression format that we’re looking forward to WAF
2, where we’re seeing even further improvements,
like another 30%. ILYA GRIGORIK: So it sounds
like this is a very active area of, I guess,
improvements. DAVID KUETTEL: Yes. Yes. And we’ll talk more about WAF
2 later, but it’s sort of a cross industry collaboration. It’s very exciting. And then also, to just sort
of continue this, you can actually go further. So if on your site, you’re
just rendering– I mean, you want to see the
font just for a few characters, like the title
or navigation elements. Using the text equals parameter,
you can specify those characters, and what we’ll
do behind the scenes is we’ll dynamically
subset the font. And so for example, for ABC in
Open Sans, you’re looking at a file size in the 3k range. ILYA GRIGORIK: So If I was to
use this and apply it to say Open Sans, instead of
downloading the 217K let’s say I’m coming on a Mac, so I would
get a font that is hint stripped, so it’s already
smaller than, let’s say, the Windows version. It would be G-zipped and
compressed, obviously. But then you would also generate
a dynamic font for just my title, with maybe like
10 characters that are needed. So likely, it’s going to
be a very small file. DAVID KUETTEL: Correct. Correct. And it would remain small, even
as Open Sans continues to grow in size. ILYA GRIGORIK: Right. So that’s a lot of toggles
that I have on my site to tweak the performance. DAVID KUETTEL: And so one
takeaway is our average font file size that we
serve is 35K. And so they are very small
in comparison to the original file size. ILYA GRIGORIK: That
make sense. DAVID KUETTEL: So here’s
how we actually do it. So if you look at the Google
Web Fonts API, for example, for lobster– ILYA GRIGORIK: So this is the
import rule that you guys give on that page that can copy. DAVID KUETTEL: That
is correct. Yeah, so you’d copy and paste
that URL into your site. And then when someone visits
your site, the browser would request that. And in response, what we do is
we dynamically generate the most optimal web font CSS
for your user agent. And so here, for example,
this is the web font CSS for Chrome on Mac. What you can see is in the web
font CSS, there’s sort of a pointer to the font file. And here, this pointer, it’s a
mapping to Open Sans regular WOFF with hints stripped. And that’s what we
serve for Mac. If you’re on Windows, it
would include hints. It would be a little
bit bigger. So here, what you’re seeing
is really like the power of the API. It’s very simple. It’s very intuitive. ILYA GRIGORIK: I was never
aware of this. I just put an include rule. And all this stuff happens
under the hood. So I don’t need to
worry about this? DAVID KUETTEL: Right. ILYA GRIGORIK: And
then I guess 30 variations per font file. So if I want to serve this
myself, I would have to have a directory of 30 files and
then somehow figure out which one to serve. DAVID KUETTEL: Yes, yes. And basically, we wanted
to push the envelope of what’s possible. So currently, it’s
30 variations. But going forward, it’s going
to be more, so even more with WOFF 2.0. ILYA GRIGORIK: Wow, jeez. This starts to get complicated
under the hood. DAVID KUETTEL: But under the
hood, but remember it’s all– ILYA GRIGORIK: Right. That makes sense. DAVID KUETTEL: So this is
sort of a simplified architecture diagram. It might look complex,
but the key takeaways are, we have two paths. There’s a dynamic serving path,
a static serving path, that also gives us a
lot of flexibility. So for example, we do support
older versions of iOS, which they expect the fonts to be
served in SVG format. We don’t get that
many requests. It’s on the order of half
a million per day. ILYA GRIGORIK: Just
half a million? DAVID KUETTEL: Yeah, just
half a million. It’s all relative. But basically, those
requests come in through a dynamic path. We generate the SVG font
and send it back. So we have a lot of flexibility on the serving side. But the main takeaway is
basically we have to really leverage the Google
infrastructure and the Google CDN. And the two are amazing. So for example, the Google CDN,
we’re seeing our font served from well over 100
cells and satellites. ILYA GRIGORIK: So it’s 100
locations around the world where these files are
being served? DAVID KUETTEL: Exactly. And so what’s really exciting
for the typical web developer is, odds are the font’s being
served much closer to the end user than the website itself– ILYA GRIGORIK: Which helps you
with the latency and the faster download. All of those things come
together, which will hopefully lead to a much better and faster
browsing experience. DAVID KUETTEL: Absolutely. And then the fonts that we serve
are heavily cached, so both the server inside
Google and then caching proxies and whatnot. And the angle is, basically,
you’d be downloading fonts from down the street,
like your ISP, or your telco, or whatnot. ILYA GRIGORIK: Yeah, that’s
an excellent point. So let me see if I can put
all of this together. DAVID KUETTEL: We went
through quite a bit. ILYA GRIGORIK: Yeah, so I’ll
come back to the actual font that we used originally, which
is this [INAUDIBLE] font. Not sure if I’m pronouncing
that correctly. But I got my link tagged,
and I put it on my page. So when the browser comes and
requests this CSS file, this is what I’m going to
see in this file. And in this case, it’s actually downloading a WOFF file. And because when I was doing
this, I was doing on a Mac, I guess the API figured out based
on my user agent that WOFF is the most optimal format,
and it’s going to serve it from the Google CDN. And then kind of one other
optimization that there is in here which it says if you have
it locally installed, and you can locally install these
fonts, then use that. Otherwise, there’s a fallback. Use this WOFF file
and download it from the Google CDN. DAVID KUETTEL: Correct. ILYA GRIGORIK: Right? So that’s the reason why we
don’t see that EOT file is another, because this file by
itself is a dynamic file being sort of format platform. DAVID KUETTEL: The
CSS is dynamic. ILYA GRIGORIK: Perfect. And then I look at the headers
of this request, and it actually tells me a couple
of interesting things. First is this request– oops, going back there– has cache-control private, which
means that this resource is customized to this host, and
it should not be cached in some intermediate proxy because
if I then connect through the same proxy on my
mobile phone, that may be the wrong file to download
to begin with. Right? DAVID KUETTEL: Correct. And so specifically, this
is for the CSS. ILYA GRIGORIK: Right, exactly. This is just for the CSS file. But nonetheless, you tell me
to cache this file, this dynamic CSS file for a day. Now, why for a day? DAVID KUETTEL: Well, basically,
as I mentioned earlier, we’re rolling out
continuous improvements and optimizations. In addition, we continue to
improve the fonts themselves. And so we want to make sure that
as the fonts improve, as they get smaller, you pick them
up as fast as we’re able to roll them out. So with this approach, when we
roll out a better font, users pick it up within a day– ILYA GRIGORIK: Within a
day, within 24 hours. And then, I notice that when I
download the actual font file itself, that file is
cached for a year. Right? So if I come to, let’s say,
CNN and CNN is using this font, it will be in my cache for
a very long time unless it gets evicted. And the more sites use it, the
less likely it gets to be evicted because it’s usually
least recently used cache. So that gives you a lot of
optimization, which leads me to a couple of different
scenarios. So a lot of people ask me
questions about, well, why does Google Web Fonts request
a CSS file and then does another request? And that’s the reason, right? We’re betting on the fact that
the more people use Web Fonts, the more likely that font
is to be in your cache. And it’s even better to have it
in your cache and not make that request than to serve it
in line in that CSS file? DAVID KUETTEL: Correct. ILYA GRIGORIK: So a couple
different scenarios to work through here. First one is you’re
coming to a site. Let’s assume you have an empty
cache, and you’ve never been to this site. So what’s going to happen is,
you’ll request the optimized CSS file, or you’ll request
the CSS file which will be returned optimized
to your platform. And then, you’ll go out
and download the font. So that is your most expensive
case, so 2+ requests. And plus because if you’re using
multiple fonts, it’ll make multiple requests. On the next page view, we know
that the CSS file will be cached for a day, so that
doesn’t have to make a request, and the font file
is cached for a year. So in my next page view, zero
request, which is nice. And I still get the
nice experience. And then, let’s say,
24 hours later, I come back to the site. I may have to refresh
that CSS file. And if the underlying font has
not changed, then that’s all I need to do, because that’s
still likely in my cache. But even there, the 24 hours,
I put a couple of stars in there because let’s say I’m
using Open Sans, chances are I visited something some other
site in between those 24 hours, or I was forced
to do that refresh. DAVID KUETTEL: Exactly. One of the other one
million websites. ILYA GRIGORIK: Exactly. So the most frequent
case is actually likely to be zero request. DAVID KUETTEL: That circle. ILYA GRIGORIK: And I think this
is important because when you are, let’s say, in your
developer tools, and you’re just hitting refresh, and
oftentimes, you’re forcing a hard refresh on your page which
means don’t consider the cache and re-download all the
resources, you’re seeing that performance hit of
re-downloading the fonts all the time. And I think a lot of people
get scared of that as they should be, because you’re
downloading these external resources. But they’re forgetting that
the whole premise of the services built on the fact that
there’s a CDN behind it, and we’re trying to
reuse the cache. DAVID KUETTEL: Exactly. And as the number of
integrations increases, it should all just go faster. ILYA GRIGORIK: So there’s
definitely a cost, but we’re doing a lot of things to make
sure that that cost is minimized DAVID KUETTEL: Absolutely. ILYA GRIGORIK: So this is– I think we just covered this,
but I had this question from Eric, which I think is very
important, so I’ll just read it out. So I’ve noticed that Google
Web Fonts link tag or the import fetches the CSS file with
font fact declaration, which is true, as we saw, which
then makes another round trip to get the font file. Is there any reason I should
not just include the font face myself? And the answer to this is you
could, but we’re doing a lot of stuff under the hood to pick
the right file type and optimize for the cache
on your machine. DAVID KUETTEL: Correct. And then, also, in addition, as
we roll out new versions of the font, we come back and
clean up older versions. And so if you do copy and paste
the direct link to the font, eventually, your
site will break. And so we really do encourage
people to use the API. And remember, everyone wins
when you do that. ILYA GRIGORIK: That
makes sense. So that’s a lot of stuff
that’s going on now. What’s coming in the future? DAVID KUETTEL: Yeah, and as
I mentioned, it’s such an exciting time. It’s such an exciting space. And so there’s continuous
improvement. One thing that we’re all looking
forward to WOFF 2.0, which is a new advanced web
font compression format. It started as a collaboration
between Google and Monotype, where Monotype open source
their MTX compression algorithms. And WOFF 2.0 took all the best
ideas and just built on them. And so it pushes the limits of
web font compression, where we’re seeing 30% smaller font
files over GZIP with WOFF 2.0 all the way up 50% smaller font
files for CJK and other Korean, Chinese, Japanese
font files. It’s very exciting. Where we’re up to day, it’s
under consideration by the W3C web font working grid. And we would really encourage
everyone to help support it, help [INAUDIBLE] the adoption. ILYA GRIGORIK: So if we had
to kind of gaze in sort of crystal ball, would you say this
is a year, a two-year, a 10-year endeavor? DAVID KUETTEL: Well, standards
do take time. We are hoping to begin serving
WOFF 2.0 on our early access page soon, within
a month or so. ILYA GRIGORIK: Oh, wow. DAVID KUETTEL: I mean all of us,
we want to see these new technologies rolled out
as fast as possible. They do take time to bake. But we’re really looking
forward to this one. Another thing that we’re going
to explore going forward is the app font face
Unicode range. Here, as we mentioned earlier
when we were talking about the language subsets, for all our
subsets, we include Latin just to make it simple for
the integrations. But going forward with Unicode
range, we could actually break the subsets up. So we could have just Latin,
just Cyrillic. And with Unicode range, the
browser could intelligently figure out which one
to download. And this would allow us to
make internationalization support more transparent. ILYA GRIGORIK: Right. What that tells me is I wouldn’t
necessarily have to declare this upfront when I’m
customizing the font. The browser could actually look
at the content of the page, and say, hey, this looks
like Korean content, and that’s the font I’m
going to download? DAVID KUETTEL: That’s right. The integrator would say, I just
want to use Open Sans, make everything happen for me. ILYA GRIGORIK: So basically,
it just means less work for me, the developer? DAVID KUETTEL: Yes. And then, it gives us more
room for optimizations. We can create smaller subsets. There’s a lot of things that we
can do behind the scenes. ILYA GRIGORIK: Very cool. And that’s independent,
obviously, of WOFF 2.0. What’s the state of this? DAVID KUETTEL: At the moment,
not all browsers support Unicode range. And so that’s one thing that– it’s been holding
us back to date. But maybe, we’ll explore
it later this year, maybe early next year. ILYA GRIGORIK: Interesting. Very cool. So we covered a lot of stuff. So I just want to have a couple
of slides just to recap and talk about what
we’ve covered. So I think it’s obvious, at
least it became obvious to me as we were going through this
that using Web Fonts has a ton of advantages. So anything from smaller file
sizes to being retina friendly, zoom friendly, search,
accessibility, there’s so many benefits to using Web
Fonts in general, which is part of performance, because
you get better engagement, better user retention
and other things. And the other thing that I think
a lot of people don’t realize is combining CSS3, as
we saw with this flat land example, it can create some
pretty fantastic things, which I did not expect. And then the other tip is, we
didn’t show it in the original demo, but all the fonts on
Google Web Fonts are open source, which means that I can
actually download them on to my local machine, all 531 of
them, and either use them in my design workflow, or in my
text editor, and in any other way for that matter. DAVID KUETTEL: Correct. ILYA GRIGORIK: So in fact, if I
downloaded all the fonts, I wouldn’t have to download
those fonts from the Google CDN? DAVID KUETTEL: That
is correct. And that’s via the local hint
that we use in the dynamically generated web font CSS. One note, however, if you do do
that, please make sure you keep them up-to-date such that
you benefit from all the hinting improvements
and whatnot. ILYA GRIGORIK: Yeah, I love to
see a font manager that can just do that automatically
for me on my machine. DAVID KUETTEL: Yes, that
would be fantastic. ILYA GRIGORIK: But I don’t think
a lot of people realize that you can actually download
them and use them locally, which is quite nice. And then we, I guess,
talked about the different font formats– so EOT, WOFF, SVG, and others. And Google Web Fonts manages all
of those variations based on a platform. And it sounds like iOS 5 versus
iOS earlier version may even have different kinds
of preferences for which fonts to use. So all that is hidden away from
you, which is quite nice. DAVID KUETTEL: That
is correct. ILYA GRIGORIK: So nothing
stops you from hosting your own fonts. And I think, in some cases,
a lot of people have been recommending that. But now that we’ve gone through
all of this, I’m personally on the side of like,
you know what, I’ll just let you guys handle
all of this work. Because it looks like you’re
doing a pretty good job. And there are cases
where you would want to host it yourself. So for example, if I have an
offline app, which I still want to look nice if I am on a
subway or something like that, I could download the font,
serve it as my offline resource, but then make sure
that I have some update mechanism, as you mentioned,
to make sure that I’m still getting the benefit of the
periodic updates that you guys are rolling out. So it’s not either or. But if you’re getting into the
I’m going to roll my own solution, make sure you
understand the complexities. Because if you just grab the
WOFF file, as you saw, it’ll be 78% of the browsers. So some platforms
will not work. Or they will work, you’ll get
the page, but it just won’t look the same, which is probably
not the experience you’re looking for. DAVID KUETTEL: Exactly. And then, you’d want to make
sure that you go back and update your page when
WOFF 2.0 comes out. ILYA GRIGORIK: Exactly. So just keeping tabs
on all that stuff. So you can do it, but
it’s your own call. And then the other point is,
as you mentioned, these are static assets. They don’t change usually
all that often. I mean they change, but most of
the time, they’re the same. So using a CDN is a very good
strategy for accelerating this type of content. And I guess Google Web Fonts
leverages the Google CDN which does a lot of this work under
the hood, which is quite nice. We talked about some of this
stuff here, but I’ll mention a few other things. So in the original workflow that
we demoed, we picked one font, and we picked different
versions of the same font. But you could, in fact, speaking
of this dynamic capability of serving the CSS
file, if you’re using multiple different fonts, you can
actually still have one CSS file that includes
all of those. DAVID KUETTEL: That
is correct. ILYA GRIGORIK: So to do that
in a web interface, you add fonts to a collection, and
then you get kind of a customized CSS file. Or you can just use the API and
just kind of use this pipe symbol here, and say, I’m
looking for Open Sans and Lobster, which is
another font. So that’s one optimization. Instead of downloading multiple
CSS files, you can just download one,
which is nice. So that’s a good tip. Another one I mentioned earlier,
I know I was guilty of this, which is, oh yeah, I
want to use the Ubuntu font. And yes, I need the bold, and
the extra bold, and the italic, and all of
these things. And I think the font was
like 100 kilobytes. And I didn’t actually end up
using a lot of those things. And some of the browsers are
smart enough not to download the weights and the fonts that
are not being used in the page, but some are not. So if you are including files
which are not being used, then you probably downloading
resources which you frankly just don’t need. DAVID KUETTEL: Right. And that was an excellent catch,
Ilya, and it just sort of reinforces that we’re
far from done. There’s constant improvement. And so, for example, WebKit
is addressing that now. ILYA GRIGORIK: Yeah, and then
last tip you mentioned, there different subsets to each fonts,
so we have [INAUDIBLE] here. And you can include different
languages. For example, in this
case, we’re including Latin and Cyrillic. So this tells me that maybe this
is a page that is both in English and Russian, or mixed
content, which is nice. You can customize
that yourself. And then the last one, which I
think not a lot of people know about is something you mentioned
earlier, which is this character subsetting. So this is like a custom font
just for these characters, from just for Hello world, which
is great for titles and other things. So you can handcraft this CSS
yourself to be like the exact perfect number of bytes,
minimum number of bytes for your page. DAVID KUETTEL: Definitely. ILYA GRIGORIK: Awesome. All right, so I think we’re
already way over time. But let’s see if we can take
a few questions here. Let me refresh this page here. Actually, I probably didn’t
need to refresh the page. So we have four questions. So one from Steve Setters. Are you working with browser
vendors to get better font caching consistent behavior with
respect to using default fonts than [INAUDIBLE] content, higher priority
caching for Web Fonts, et cetera? DAVID KUETTEL: So that’s
a great question. And our biggest advocate
actually has been Steve Setters. ILYA GRIGORIK: Go Steve. DAVID KUETTEL: Go Steve. We’re very fortunate. And so Steve’s been reaching out
to all the browser vendors like IE, and Firefox, and Chrome
to encourage them to have larger caches and
cache resources for longer amount of time. But it’s not just Steve,
it’s all of us. We all want to move the web
forward and really accelerate the adoption of Web Font. ILYA GRIGORIK: So I think one
example that we discovered as we were preparing this is we
actually found a bug in WebKit, where it was downloading
font weights that we’re not being used. So I think we actually have
a patch for that. So it’s not out there yet, but
that’s an example of work– DAVID KUETTEL: Exactly. ILYA GRIGORIK: –That
we’ve done. So let’s take another
one here. So we already answered
Eric’s question. So another question
from Steve. Are you working with
browser vendors– no, wait. That’s the one we already had. One from Joey. To maximize browser
compatibility, we have to specify many different file
types for each font. So we saw EOT, WOFF,
et cetera. Are browsers smart enough to
only download the file that applies to them? If browser understands multiple
types, are there priority order? DAVID KUETTEL: So
there absolutely is a priority order. And you can list the fonts in
the formats that you prefer, and the browser will
go through it. We’ll look at the format, and
we’ll treat it as a hint. So if it supports WOFF,
it will download that file and use it. There are few caveats. So all of the modern browsers
do the right thing. But some of the older ones don’t
parse the format tag. And so here, we would highly
recommend reading up on Paul Irish’s book, Proof at Font
Face Syntax, to make sure you’re aware of some
of the caveats. ILYA GRIGORIK: If I’m
handcrafting these files myself, I can just specify one
URL for the WOFF, one URL for the EOT, et cetera. For Google Web Fonts, when you
download that CSS, it’ll likely include just one, because
you guys are already figuring out the right format
for this platform. DAVID KUETTEL: That
is correct. And there are a few
hedge cases. So for example, to support
Chrome Frame and Internet Explorer, we do use a
small variation of the bulletproof syntax. So we serve up both embedded
open type file and WOFF file. But in general, we try to
keep it as simple and straightforward as possible. ILYA GRIGORIK: So as usual,
there are a lot of kind of nitty-gritty details to make
every platform work well? DAVID KUETTEL: Yes, today,
Hopefully, 10 years from now, it won’t be this complex. ILYA GRIGORIK: Right. Sure. OK, so we have another
one from Daniel. So many developers are changing
icons for Web Fonts or techniques that uses it, like
Font Awesome, which we talked about. How you believe it could impact accessibility screen readers? So I think this is an
interesting question. I’m not sure if this is the
right answer, but I don’t think it makes any worse. So if I previously had a home
icon dot PNG, and I’m replacing that with– usually, the way that Web Fonts
work is you’ll actually have like a span element. And then in there, it’ll declare
a class and say, like this is my home icon or
something similar. So technically speaking, that
actually gives more information to the crawler. I’m not sure that modern
crawlers understand these kind of concept well enough today. But in general, I think the more
we could put in text, the better as opposed to images. Because in general, I don’t
think crawlers or screen readers are very good at
interpreting images. DAVID KUETTEL: Absolutely. ILYA GRIGORIK: OK, so I think
there are a few more questions, but we are
running out of time. So what we’ll do is we’ll
follow up online. We’ll respond there. And then, also, please feel free
to ping myself or David on Google+ or an email. And we’ll be happy
to chat with you. I think that’s it for today. Also, thank you guys. DAVID KUETTEL: Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *