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.