
How Changing WebFonts Made Rubygems.org 10x Faster - rtcoms
https://www.nateberkopec.com/2015/11/30/how-changing-webfonts-made-rubygems-10x-faster.html
======
csense
> As developers, our job isn't to tell the designers "Hey, you're dumb for
> including over 500KB of WebFonts in your design!"

Yes. Yes it is. I want to browse the web of 2006 with an Internet connection
of 2016. I really wish websites wouldn't require me to download hundreds of
different JavaScript libraries, fonts, Flash, video files, and who knows what
responsive AJAX nonsense. I really like minimalist websites that do what they
need to do without tens of megabytes of cruft. Like this one.

~~~
seanwilson
To give a suggestion in the middle, a good approach is to inform the designers
about the technical implications of their designs and present options that
work around the technical issues so a compromise can be found.

~~~
50CNT
Loading times/responsiveness are certainly a design constraint, and designers
need to be aware of this.

Imagine a print designer that didn't know about bleed, DPI or colour showing
through paper. They may not personally be in charge of printing things, but
they absolutely need to have domain knowledge or work with someone that does.

------
dwightgunning
_" As developers, our job isn't to tell the designers "Hey, you're dumb for
including over 500KB of WebFonts in your design!"

... As performance-minded web developers, our job is to deliver the designer's
vision in the most performant way possible."_

Design is all about trade-offs. Performance is part of the experience and
that's something all designers should care about.

Developers should definitely raise this type of issue when it arises (albeit
without the name-calling and in a collaborative manner).

~~~
matt4077
Well, in this case he replaced the designer's vision with Arial(!) because
"Fonts all look the same below H3". Without ever talking to that designer.

I'm sure a collaborative effort would have resulted in simply removing the 10
unused font variants and leaving the two that are used. That would save 416kb
of those 500kb without being tasteless.

This is a good ressource on what designers think of his choices of Arial and
Helvetica: [http://practicaltypography.com/helvetica-and-arial-
alternati...](http://practicaltypography.com/helvetica-and-arial-
alternatives.html). Quote: "I try to keep the lit­mus tests to a min­i­mum,
but this must be one: you can­not cre­ate good ty­pog­ra­phy with Arial."

~~~
tux1968
Can't follow that link for some reason. Firefox says:

Firefox has detected that the server is redirecting the request for this
address in a way that will never complete.

uses security technology that is outdated and vulnerable to attack. An
attacker could easily reveal information which you thought to be safe.

~~~
j_koreth
Redirect Loop Error on Vivaldi Browser for me

~~~
therein
Same in Chrome.

------
robgering
I've worked with numerous projects using Typekit or Google Fonts, and a few
that used typography.com by Hoefler & Co. Google Fonts has far and away been
the best experience, both for development and for the users. Kudos to the
Google Fonts team.

I wonder if Google plans to add a paid collection of premium fonts to its
library – while I prefer open source fonts, I know a number of designers who
use very specific fonts outside of what's currently available for free.

------
lifthrasiir
> Is WOFF2 just _that good_?

Regardless of the following paragraphs (which give a primary reason of
`unicode-range` CSS property), it is _that good_. Brotli, a compression
algorithm used by WOFF2, is a very good fit for regular-looking but non-
repetitive data---that includes many binary formats including OpenType. I have
seen at most 10--20x improvements over uncompressed TTF.

------
comex
It might be nice if browsers automatically kept a running estimate of
connection speed based on previous page loads, and exposed it to new pages via
JavaScript or even as a CSS media query. That way sites could serve their
fancy webfonts (and other large assets) to users on fast connections who won't
notice the difference, and omit them for slower users without making them wait
for the load to time out.

Of course, the speed estimate could be wrong if the bandwidth bottleneck (on
either previous sites or the current one) is further than the last mile,
especially for e.g. Chinese users whose Internet speeds are drastically slower
with international peers than domestic ones. Or alternately if the user is on
a mobile connection and is moving quickly between areas with good and poor
reception, going on and off Wi-Fi, etc., although in that case the browser
could incorporate signal strength data from the OS. Still, on an Internet
whose users have wildly varying connection speeds, I think it makes sense to
allow leveraging the difference somehow.

~~~
nateberkopec
Hm, you could probably hack something together with the PerformanceTiming API,
which makes a lot of these timings available to JavaScript:
[https://developer.mozilla.org/en-
US/docs/Web/API/Performance...](https://developer.mozilla.org/en-
US/docs/Web/API/PerformanceTiming)

------
technicolor
FWIW, Typekit has an async loader script that doesn't block the rendering.
Same is the case with Google web fonts. Both services use the open source
WebFontLoader[1] library behind the scenes (which is mentioned in the
article).

Typekit has a feature they call language subsetting which reduces the file
size of a particular typeface family by removing language support based on
user selection. This can reduce font sizes quite a bit.

>Google Fonts doesn't use any JavaScript (by default, anyway), which makes it
faster than almost any JavaScript-enabled approach

This involves a stylesheet which means the rendering is blocked until it is
downloaded and processed and the users will see a page with blank text until
that happens. Sometimes it is better to show the content (even in a fallback
font) instead of a blank page.

1:
[https://github.com/typekit/webfontloader](https://github.com/typekit/webfontloader)

------
swanson
For those curious, the relevant PRs/issues appear to be:

[https://github.com/rubygems/rubygems.org/issues/1095](https://github.com/rubygems/rubygems.org/issues/1095)

[https://github.com/rubygems/rubygems.org/pull/1109](https://github.com/rubygems/rubygems.org/pull/1109)

------
Throwaway14530
I disable web fonts for all my browsing. For the most part, it's fine and
speeds up responsiveness. In rare cases, I run into problems when a website
has decided to replace its icons with fonts, but generally, those sites are
overly designed and I usually avoid them.

If I absolutely need to visit a site that uses mission-critical webfonts, I'll
just open IE, do my business, and get out.

------
iamleppert
\- Using Google for your fonts has been proven to be a nightmare for me in the
past. Google does a good job at serving their own interests but don't expect
them to put up a consistently good effort for their free shit.

\- The OP makes some weird kind of pedantic performance argument about moving
script tags around in the head for some possible optimizations. Anyway, it
wouldn't make any difference and your page would still be blocked if Typekit
failed to load.

\- The text parameter to Google web fonts would render any prior cache-ability
gains moot and could potentially change the unique ID of the resource as the
text of your site changes.

I'm not trying to be too negative, but I don't see what all the fuss is about
with this article? Yeah, someone added a big bloated third party font service.
You found it, and removed it.

Shouldn't Rubygems be using some unicode or built in serif font anyway?
They're going to need all the perf improvements they can get when their time
to first byte is 300+ ms. ;-)

~~~
elaus
> Using Google for your fonts has been proven to be a nightmare for me in the
> past.

How so? I had only good experiences with Google fonts, especially compared to
other services or just plain self-hosting of font files.

------
losvedir
Are there any good resources for what fonts are loaded by default in different
versions of Windows, Linux, OS X, iOS, Android, etc? Do people have good "web
safe font stacks" that specify relatively similar fonts that are commonly
installed in the different browsers out there?

It seems like a nice middle ground to provide a somewhat unique and nicely
styled experience, without forcing the user to download a bunch of extra
stuff, and also possibly keeping it a little more "native" looking in whatever
browser they're using.

~~~
rangibaby
I have started using just system "sans-serif" as much as possible. You can get
far better returns from having correct _for your specific design_ font sizes
and leading, rhythm, etc. than using the current trendy not-Helvetica.

------
J_Darnley
Even faster: not using any.

~~~
err4nt
Faster to load, but expensive to support. Using the same font everywhere cuts
down on a lot of cross-browser layout bugs which stem from different fonts on
different systems.

I use web fonts everywhere and can't imagine trying to build any kind of
layout relying on system fonts alone. When doing CSS I have to use a giant
wishlist like this to try to target a 'nice' font on each system:

    
    
        font-family: "Source Sans Pro", "Open Sans", Roboto, "HelveticaNeue-Light", "Helvetica Neue Light", "Helvetica Neue", "Myriad Pro", "Segoe UI", Myriad, Helvetica, "Lucida Grande", "DejaVu Sans Condensed", "Liberation Sans", "Nimbus Sans L", Tahoma, Geneva, Arial, sans-serif;
    

Or I could supply the font via @fontface and know it looks identical
everywhere :)

~~~
tomc1985
What's with this "it has to look identical everywhere" mentality? Do your
margins really need to be precisely 10px on every single display? I've always
thought one of those most beautiful things about a well-designed layout was
how adapts to a variety of viewing scenarios, yet it seems the majority of
conversation on the matter is about making sure things are _absolutely
identical_.

Your fonts and even colors could change. Webfonts are great and all til the
idiot designer picks some "nice" ultra-thin that, while probably looked real
sweet on his/her fancy Retina Cinema Display, looks like ass on mine.

~~~
RandomBK
I agree with your dislike for thin fonts, as they're unreadable on my screens.

However, the web is more than just text articles, and the precise positioning
and display of text is quite important for web applications. It's important
for me to know if the text on a button is wrapping or being cut off, and even
more important for me know that my application will look the same on every
screen.

~~~
bzbarsky
You mean except for the screen of the user who has weak eyesight (e.g. due to
being over the age of 40) and has set a 16px minimal font size in their
browser?

I set a 13px minimum font size in my browser (the smallest size I can read
comfortably on my screen) and I constantly run into web applications that try
to go for the level of control you describe and totally fail because they
think 10ps fonts are a good idea. Of course my usual response is to close that
tab and never use that web application again if I can help it.

~~~
RandomBK
Then what would you suggest? Tradeoffs have to be made between font size and
information density. If I was writing a web app for seniors for example, then
yes, font size is a major concern. However, the vast majority of people do not
set minimum font sizes. From my experience, most users tend to zoom the entire
page if they need a larger font, which scales all UI elements (almost) evenly.

Ultimately, web applications (particularly enterprise and other B2B services)
are designed to replace a lot of functionality normally relegated to native
applications. While it is important to present a nice, clean interface,
material design UIs with nice, large fonts and generous margins won't let me
show what I need to show without making the user search through menus or
scroll across a massive page.

~~~
bzbarsky
> Tradeoffs have to be made between font size and information density

Well, sure. My personal suggestion is to have lower information density if the
higher one can't be achieved without going below the 16px default font size of
browsers and allowing scrolling as needed. After all, that's what you end up
with _anyway_ if people full-page-zoom. Except now they typically need to
scroll in two directions, not one, if the page hardcoded some widths in.

> However, the vast majority of people do not set minimum font sizes.

This is through lack of knowledge, not lack of desire. All the people I've
showed this feature too were incredibly happy to see it. All of the older
relatives I've set up computers for have minimum font sizes set up.

Keep in mind that as of the 2010 census there were about 309 million people in
the US, of whom 74 million were under 18. Of the remaining 234 million, 40
million were over 65 years old: that's about one in 6 adults. Another 59
million were 50-64 years old. Another 22 million were 45-50. So over half the
adults are over the age of 45. Oh, and another 21 million were 40-45. See
[http://www.census.gov/prod/cen2010/briefs/c2010br-03.pdf](http://www.census.gov/prod/cen2010/briefs/c2010br-03.pdf)
page 4 or so.

Age-related problems with vision start in the early 40s. So unless you
yourself are already experiencing them (and hence can evaluate how usable your
web app is), or unless you know your web app will only be used by Silicon
Valley startups all of whose employees are in their 20s or something, you
should probably assume that a large fraction of your users can't read smaller
fonts.

I appreciate that this is a hard problem. I'm just saying that browsers allow
users to override whatever styling the web page is doing, they will continue
to do that, and as the population ages even further I expect it to become more
and more common for users to do just that.

Note that generous margins are not as important as not too small fonts (not to
be confused with "large fonts"; the default 16px font of browsers is not a
"large font" in any reasonable sense, and yet people keep insisting on having
text that is _much_ smaller than that) for purposes of readable text.

------
stegosaurus
This article is a good example of just how bonkers the 'modern web' is.

In a reasonable world my browser would instantaneously load the content (text
fits in a couple of TCP packets) and I'd have an option to choose Shiny Mode
(or a bar to toggle it on permanently with).

Instead, half of the 'articles' I come across on the web don't work without
animated full page transitions, pop-ups within the page, blah blah. I
preferred the MARQUEE tag, quite frankly.

------
b1530678
Funnily enough replacing a 61 byte gif with a 168 byte png reduced loading
times of one of my sites by 150ms.

------
matt4077
Oh wow. This guy changed the font to Arial(!) because "Using WebFonts for
"body" text - paragraphs, h3 and lower - seems like a loser's game to me. The
visual differences to system fonts are usually not detectable at these small
size".

It's not just the font that's grotesque here. Of course a 'normal user' isn't
usually noticing the fonts a website uses. In fact, they shouldn't. But fonts
still influence how people perceive the website.

Using this guy's insane logic, we could get rid of all craftsmen, because
nobody notices the details anyway.

Even more tragic: Rubygems was apparently loading 12 styles&weights of that
font and only using two. He could've thrown out the 10 unused variations and
gotten almost the same result without resorting to violating someone's design.

Why exactly is Rubygems giving idiots access to it's source code?

~~~
schneems
> Using this guy's insane logic, we could get rid of all craftsmen, because
> nobody notices the details anyway.

Hyperbolic much?

> Why exactly is Rubygems giving idiots access to it's source code?

It's open source
[https://github.com/rubygems/rubygems](https://github.com/rubygems/rubygems)
all idiots have access to the source code, even you.

I think the words you're looking for are "Thanks for taking the time to make
Rubygems faster, and for doing a write up on it to show the costs and benefits
of using a webfont. Now I see that style can come at the cost of performance.
I'm curious what the speed differences would have been if they had gotten rid
of the 10 unused font variations and kept the current webfonts."

Even better would have been "I ran the benchmarks for my suggested change and
found it to be nearly as fast, I don't think we should sacrifice all visuals
for the sake of performance, here's a link to my PR to Rubygems to re-instate
the webfonts with a script on how to reproduce my findings. Thanks everyone
for all your free open source work, and for sharing what you've learned."

I get what you're trying to say, blowing it out of proportion and being highly
critical of people doing free work for you in their free time while doing
nothing to remedy the situation isn't going to help anyone.

~~~
Angostura
No, what he is trying to say is that the approach that was taken appears
misguided. The speed improvement is largely gained by not downloading unwanted
font variants. All the work mucking about with the designer's body copy style
isn't going to have much effect - unless I'm missing something.

