
Web Fonts Performance - nnx
https://speakerdeck.com/bramstein/web-fonts-performance
======
captn3m0
While we are discussing web fonts, I think I should point out my Chrome
extension that disables Web Fonts on all websites (or tries to). Uses Request
filters, and I made it because I was trying to minimise bandwidth usage on a
metered EDGE connection long time back. (Opera Turbo is best for that, but
Chrome is a better browser).

[0]: [http://github.com/captn3m0/disable-web-
fonts](http://github.com/captn3m0/disable-web-fonts)

[1]:
[https://chrome.google.com/webstore/detail/olmabeadgbpmhllgdk...](https://chrome.google.com/webstore/detail/olmabeadgbpmhllgdkemfdnmkngkbkeg)

~~~
mmahemoff
Wouldn't this break sites using icon fonts (e.g. Font Awesome)?

~~~
paradite
Maybe one alternative is to have fonts like Font Awesome built into the
browsers, although I am not sure if that is practical.

~~~
adsche
I liked this comment [1] from earlier: Use ligatures. That way, a meaningful
text could be displyed when the font is not loaded, but fuses into a symbol
with the appropriate font.

[1]
[https://news.ycombinator.com/item?id=10326630](https://news.ycombinator.com/item?id=10326630)

------
buro9
Use preconnect headers: [https://www.igvita.com/2015/08/17/eliminating-
roundtrips-wit...](https://www.igvita.com/2015/08/17/eliminating-roundtrips-
with-preconnect/)

That is all you should do, it will land in Chrome stable shortly and is
already in Firefox.

~~~
ck2
Maybe a year from now:

[http://caniuse.com/#feat=link-rel-preconnect](http://caniuse.com/#feat=link-
rel-preconnect)

------
signaler
There is a switch in Chromium where one can disable remote fonts entirely.
Obviously not for the average user, and more of a power-user thing, but still
handy:

    
    
        --disable-remote-fonts
    

You can find a tonne of other optimizations you can do to Chromium here:
peter.sh/feed/chromium-command-line-switches

Also if you want fonts that load faster than Google Wenfonts, have a look at
[http://brick.im/](http://brick.im/)

I use Brick on a tonne of different side projects, and there is a marked
decrease in loading time. Brick uses Fastly, which is (arguably) a faster CDN
than Google Webfonts and other webfont initiatives like Adobe Webfonts.

Also using Brick is another chance to ban Google from your web traffic as many
are doing...Google is like a barnacle that is stuck to the web and is hard to
remove entirely without them slurping some of your data

~~~
tadfisher
Unfortunately, this is a Tragedy of the Commons issue, where the ever-
expanding list of webfont hosts results in a detrimental experience for users,
where otherwise a single popular host would result in a much higher likelihood
of cache hits.

Not saying you shouldn't use the best solution for you. In fact, I ship code
that hits the Hoefler & Co. webfont CDN because it's the only source for the
fonts we use.

------
ivan_ah
The OP mentions font loading starts as soon as a .css directive using the font
is encountered, which makes me think the initial html page load could include
a tiny snippet of .css with the font defs and a dummy styling instruction that
use the font. The idea is to load the rest of the .css in parallel with the
.woffs. Would this work?

I guess prefetch does exactly that, but wondering if the "hack" would work.

~~~
jrochkind1
That seems worth pursuing. I'd want to verify that when the font is loaded
this way, it's loaded async, and doesn't stop further asset loading until
complete. Or else it might not be a great solution.

------
ck2
Too much work for 30ms speedup.

However link preload seems to be golden.

But what is preload vs prefetch?

Ah firefox will only prefetch when the browser is idle.

So we have to wait for preload support.

[http://caniuse.com/#feat=link-rel-prefetch](http://caniuse.com/#feat=link-
rel-prefetch)

[http://caniuse.com/#feat=link-rel-prerender](http://caniuse.com/#feat=link-
rel-prerender)

[http://caniuse.com/#feat=link-rel-preconnect](http://caniuse.com/#feat=link-
rel-preconnect)

(doesn't work as of 10/2015) [http://caniuse.com/#feat=link-rel-
preload](http://caniuse.com/#feat=link-rel-preload)

[http://www.w3.org/TR/preload/#introduction](http://www.w3.org/TR/preload/#introduction)

------
ksec
Can we not have a way to count, the most used Javascript, and Web Front in the
most popular worldwide 500 Website in one And these will always be cached by
one Repository, and all browser maker will constantly check and update a same
copy of cache within the users computer?

It will save lots of Request, and latency.

~~~
jordanlev
Not a bad thought. But I wonder if the "political problems" would be too much
to overcome. For example, I'm sure some of those most-popular fonts require a
license, and I don't know how TypeKit/fonts.com/etc would work if those
weren't hosted from their own servers.

~~~
ksec
We could leave out the non-free stuff for a start. What other political
problems are there?

In a perfect world, these most popular website would have their Script and
Fonts in CDN and be cached already. But what we are seeing is that still lot
of the same stuff used around still not being cached.

------
mrmondo
I've found the performance of web fonts to become more of a problem over the
past year or so, I guess this is as their popularity has increased.

1\. Privacy

It's well known that companies such as Google and Adobe use web fonts to track
users that may not even (knowingly) be their customers.

2\. Performance

Just last week I logged a bug with our developers when our monitoring started
picking up that one of their staging / demo sites was taking a long time to
render, turns out they were using a web font provided by Hoefler & Co's
'typography.com' which is incredibly slow to load, here's the waterfall of the
page load: [http://i.imgur.com/riNT3hH.png](http://i.imgur.com/riNT3hH.png)

~~~
dingaling
3\. Readability

My enjoyment of the web improved immensely when I disabled font selection on
web pages and imposed my own serif font over them all.

Occasionally this does result in breakages when a particular site relies on
icons embedded in a web font but I accept that as the cost of my choice.

~~~
chrisan
Speaking of readability, I cannot stand these 200 weight thin fonts that only
look good on a "retina" device places choose to use sometimes

~~~
knight17
I also have the same feeling that thin fonts look ugly on my humble LCD screen
with dismal resolution and low ppi.

I was once complaining to a friend how ugly site X is and he said it looked
right to him; later when I saw his machine it has a nice display that made
site X look twice as better on my shitty display.

Lots of sites are designed on (and for?) high density displays and it ends up
looking awful on low resolution screens like mine.

~~~
9248
It's baffling for me that designers/coders don't realize that desktop and
laptop display panels are probably the first thing a manufacturer will look at
when it comes to cutting some corners and lowering the overall price of the
product.

Also most 'normal' users will never pay the x4-x10 premium price for some
fancy IPS display and calibrate its colors.

------
vortico
I'll admit I didn't know about the HTML link preload feature. This
presentation does a good job at emphasizing (but hopefully not exaggerating)
its effectiveness.

However, may I suggest a completely radical alternative at optimizing your
webpages? Don't just avoid Web Fonts, avoid CSS altogether. Take a look at my
website. Did you notice how fast it loaded, despite not using a CDN? Of
course, this is a bit tongue-in-cheek. There are many legitimate uses of
styling web pages, but for websites whose purpose is simply to convey
information (the main reason people were excited about the WWW in the 90's), I
personally think unstyle'd, or mostly unstyled HTML is the best way to go.

~~~
sotojuan
A little CSS goes a long way:

[http://bettermotherfuckingwebsite.com](http://bettermotherfuckingwebsite.com)

~~~
discreditable
> A little CSS goes a long way

But don't overdo it:

[https://bestmotherfucking.website](https://bestmotherfucking.website)

------
jrochkind1
These seem like good techniques.

But I still don't consider reliable FOUT a victory -- it's still annoying as a
reader. I'm not sure if the final slide cross this out because his design has
a solution to it, or because he decides not to consider it a problem. I
_think_ the latter maybe? (Slidedeck without the accompanying narrative can be
hard to interpret sometimes!). If so, I disagree, reliable FOUT with otherwise
quick loading may be the lesser evil in the present environment, but it's
still annoying.

------
BillinghamJ
For Safari, I made this user style sheet (set on the Advanced tab of Safari
Preferences):
[https://gist.github.com/billinghamj/d789c0bbfe97131da04e](https://gist.github.com/billinghamj/d789c0bbfe97131da04e)

It disables web fonts for all uses except icons.

------
evmar
Caveat: the slides indicate you can indicate prefetching via an HTTP header
but in my local testing (and subsequent Googling) it appears that doesn't work
in Chrome (perhaps it's Firefox-specific?).

Edit: found the relevant bug:
[https://code.google.com/p/chromium/issues/detail?id=58456](https://code.google.com/p/chromium/issues/detail?id=58456)

------
dingdingdang
OK, here's the breakdown from all those slides to get parallel loading (on new
browsers) and avoid FOUT (flash of unstyled text) each pageload:

[http://piratepad.nl/ep/pad/view/rirCTCqTPZ/HFjj5IyqJD](http://piratepad.nl/ep/pad/view/rirCTCqTPZ/HFjj5IyqJD)

~~~
kuschku
By the way, as someone who often uses mobile connections: _I will skin you
alive if you hide text before the fonts loaded_

Seriously. FLOUT is NOT in any way bad. Stop trying to hide the unstyled text,
I don't have 20 minutes to wait for your shitty webfont to load. If you do
hide your unstyled text, I'll instantly leave your website again.

------
jeremyw
Note this is also relevant to any external dependency, re degraded performance
and outright failures of third-party hosting. Apply to all vendors.

(See sibling comment about typography.com failure mode.)

------
DiabloD3
Prefetch is interesting, but with Google Fonts, the target URL will be
unpredictable due to browser detection techniques.

