How Changing WebFonts Made Rubygems.org 10x Faster
> 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.
"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).
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.
> 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.
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.
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.
For those curious, the relevant PRs/issues appear to be:
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.
- 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. ;-)
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.
Even faster: not using any.
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.
Funnily enough replacing a 61 byte gif with a 168 byte png reduced loading times of one of my sites by 150ms.
This is why i just force my browser to use comic sans for everything.
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?