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.
