Webfont services: JS vs CSS

Stephen Coles

What are the advantages of a webfont service that specifies external CSS as opposed to JavaScript? And vice versa. I don’t have the web dev chops to know the benefits of either method. I am looking for both the provider’s and the user’s perspective. Thanks!

For reference:

Webfont services that offer CSS implementation
Typotheque
Fontdeck
Just Another Foundry
Google Fonts
Webtype
Cloud.typography
WebINK
Fonts.com Web Fonts

Webfont services that offer JS implementation
Typekit
Fontdeck
Google Fonts
Fonts.com Web Fonts

Stephen Coles

I guess the list above would be more useful if I simply noted which services require JavaScript. As far as I know, that is only Typekit.

kupfers

Also Linotype used to require JavaScript, at least according to their press release. But maybe they changed that and it’s now an option.

kupfers

With pageview tracking via CSS, the page might have to wait with loading until the tracking-CSS is loaded (slow service > slow pageload). With JavaScript, the page and the tracking-CSS can load at the same time (not the default Typkit code though) but might then be faster than the fonts (> FOUT). More here. But loading can be finetuned with webfont loader tools. Also, if I remember correctly, with JavaScript, the decision what font format is required can be made on the browser side instead of the font service server-side > less server traffic when you get millions of requests. But I’m no dev, other people can probably explain this better.

Jack Jennings

The biggest benefit that you get from using the JavaScript version is that you can hook into different events related to loading the potentially large font files. Some of these services (maybe many/all) use googles web font loader JavaScript library (https://github.com/typekit/webfontloader), which allows you to supply a function to run when the we font load starts, is loading, and is loaded (etc.).

That can be useful if you want to make sure something on the page is not displayed until the fonts are loaded. Sometimes you'll want to wait for fonts to load to measure the height/width of an element on the page, or some other esoteric problem.

Edit: looks like its fontdeck, fonts.com, google and typekit that are currently supported by the Webfont Loader library: https://github.com/typekit/webfontloader#modules

Thomas Phinney

I answered this question at some length on Quora, where Stewf also asked: https://www.quora.com/Web-Fonts/What-are-the-advantages-of-a-webfont-service-that-specifies-external-CSS-as-opposed-to-JavaScript-And-vice-versa/answer/Thomas-Phinney?__snids__=300241083&__nsrc__=1

Matthew Butterick

Since TypeDrawers will outlive Quora — which, despite its preening, is just another aspirant in the stalker economy — perhaps it's good policy to post full answers here as well, so future generations will be able to find them. Free of ads. Free of Helvetica.

Stephen Coles

Quora’s policy for hiding answers until you create an account is just dumb. So, yes, I agree that posting the answer here is beneficial.

TypeDrawers will outlive Quora

While I am hopeful that TypeDrawers will have a long life, and I am grateful for what James has built, the story of Typophile does not leave me much faith in any forum.

Marcos Ojeda

i'm going to attempt to address the original question.

in terms of pure performance, css hosting should be the winner but it truly depends on how aggressively the font provider is cache-invalidating the client css they send. most services, strictly for what appear to be accounting purposes, force clients to redownload the same css file every thirty days. the css file almost always points to the same set of edge-cached fonts which are set to expire, usually, after a year.

still, it's strange, i assume that the rationale is that it's easier to count monthly unique css loads than font-package downloads, but i think it's a bummer of a tradeoff considering it imposes an added roundtrip etag-check for frequent visitors once a month even though their cached fonts haven't been invalidated. i'm guessing most providers look at their cloudfront or akamai numbers and the burden of redownloading a 1k css file each months seems like a wash. i suppose it makes it easier to cut off customers that stop paying, so there's that. still, in an ideal setup, most css-based font setups should appear to behave much faster overall, at least for the next thirty days.

i'll echo jack's point about the js hooks being somewhat valuable, although i never really got behind them. intentionally stalling page display always felt like a web-regression rather than an improvement.

as i understood it, the choice to use javascript on typekit was to enable some typeface obfuscation (via a set of randomly subsetted fallback fonts), to enable the typekit colophon banner, to add-in some google analytics tracking and, the biggest legitimate value add, to handle edge-cased browsers down the line most efficiently. still, it imposes a real performance hit: in order to make your site feel snappy, you need to put the typekit code at the bottom of the page, loading asynchronously after your dom is ready to paint. so this adds in a greater burden of FOU[CT], so now you have to add in some js-events to mitigate that with more stylesheet hacks which have presumably been loaded in the head. maybe i'm missing out on some performance hacks there, i haven't looked down the wire for typekit since ~2010, but it doesn't seem like much has changed.

in terms of benefits for the provider, i suspect that the css-hosted option is much easier to implement (especially if the css is statically generated) and in cases of display faces which are unlikely to be subsetted, allows you to theoretically serve the same precached webfont on disparate domains. this results in an apparent web-speedup for end-users because they've likely come across this font elsewhere and now have 'got it for free' by hitting a small 1kb css file which references a file already in their cache for the next year. you can witness this effect if you've ever had a google web font load very quickly for you.

in terms of benefits for js-based font providers, i suspect the wins are primarily in accounting and better metrics from clients and the lure of font file obfuscation, but i'm more hazy on this and haven't really thought about it as much. it seems to add many variables that i'm a bit wary of.

happy to expand on any point, although i suspect this post is too long already. sorry

kupfers

What does the image analogy, font formats or shifting this towards a discussion about hosting vs. self-hosted to do with Stephen’s initial question: “What are the advantages of a webfont service that specifies external CSS as opposed to JavaScript?”

Jack Jennings

Having the page hidden while loading the typefaces is definitely a regression. Sometimes it's the less-bad option among various trade offs. I've found that JavaScript hooks tend to be necessary on sites that depend more on JavaScript to begin with, and/or use JavaScript to build layout.

Marcos Ojeda

What does the image analogy, font formats or shifting this towards a discussion about hosting vs. self-hosted to do with Stephen’s initial question

it's certainly an uncomfortable analogy: consider the stock image market. Because image formats converged much sooner than webfonts and at the same time, bandwidth was more expensive, the online stock image market didn't even remotely attempt a subscription model. Or if they did, it seems to have been a shortlived experience.

in contrast, webfonts services clearly benefit from a lack of format standardization and the presently relatively inexpensive nature of third party hosting and content delivery networks.

i can guarantee you that if it had been viable and performant at the time, we would have seen stock image services attempting the same sorts of hosting: domain-restricted hotlinking and some js wizardry to 'make images work consistently.' However, i suspect that image sizes being about ~1-2 orders of magnitude larger than fonts is still part of the reason that option is not viable. as it is right now, it's pretty clear that hosted webfonts are a profitable business, even just on margins, but i would be surprised if that party doesn't end at some point.

an aside: if hosted webfont services do persist, it will either suggest that webfont formats and type rendering engines failed to converge or that (more likely) bandwidth and cdns have grown so inexpensive and reliable enough to make these kinds of subscriptions more alluring to font/image/etc providers, content publishers and end-users.

it's not immediately obvious that the js approach is a failing proposition, either. consider 'lazy loaded images.' we can now elect to use javascript to intentionally delay loading images until they're near the browser viewport to provide better experiences for visitors. combine that with scripts that do responsive/@2x image fetching and you're practically headed into typekit territory for your self-hosted images (with retina and different devices, images have started to diverge in subtle ways...)

i think it's valuable to consider of all these things in weighing the pros/cons of each service. it's not at all stupid to use images (and their attendant issues, even now) as an analog when trying to understand hosted font services.

kupfers

Sure, but I don’t see how the world of images has settled on one file format, at least not on the web (“4 jpeg files”). I rather want to use several file formats, or versions of one image depending on which one is best for a given case, for instance SVG with GIF fallback, or PNG, or JPEG, and the latter in different resolutions, not even speaking about responsive image sizing. Savvy developers and large websites have the means to build their optimal image thing that will automate deployment. Lay people with smaller sites, who might not even have their own server, will struggle to see through and maintain it all, or don’t want to devote the time and effort.

This was a question about the advantages of accessing hosted things via CSS alone or with JS – fonts, images, you name it. It was not a question about unifying file formats or if hosting things is a viable idea to begin with.

Marcos Ojeda

i think we both agree here, my main point in those two time-cube-esque screeds is that there's insight to be gained for end-users by understanding the issues content providers are tackling. you've summed it up well yourself in countering my ridiculous image-hosting example:

css-based performance is predicated on savvy backend developers at font hosting services (& also browser developers) 'doing the right thing.' it almost certainly a better option for infrequently updated or smaller sites that reap those benefits via a single css include and wait for technology to uniformly catch up.

js hosting sacrifices some client-performance but offers detailed events and deals better with edge-cases by handing front-end developers more control throughout the page-rendering process. for larger sites with dedicated frontend teams, the overhead is likely negligible (and may be preferable). this may also be your only option if you have to support blackberry browsers or something exotic like opera mobile (probably something only large sites care about anyway).

i'm sorry if i came off like a hawkish neckbeard, i was trying to make sense of the situation rather than wildly asserting one technique was better than the other (why should you believe me in any case?). i think it's more nuanced, but my 2¢, i lean towards a cdn-hosted long-future expires css-based technique myself and embrace good ol' font-family fallback standards like sans-serif, cursive and monospace.

kupfers

No no, not at all, at least not to me. Your posts are very insightful and I look forward to read more from you.

Stephen Coles

I welcome our hawkish neckbeard overlords! Thanks, Marcos.

John Hudson

css-based performance is predicated on savvy backend developers at font hosting services (& also browser developers) 'doing the right thing.' it almost certainly a better option for infrequently updated or smaller sites that reap those benefits via a single css include and wait for technology to uniformly catch up.

This is very well stated. There was a huge amount of discussion on the W3C CSS list last year about font load events, so much so that I stopped reading after a while, but the impression I came away with was that there should be a fairly simple default behaviour that we'll eventually be able to rely on. As someone who has spent twenty years waiting for technology to uniformly catch up, this seems oddly comfortable and very familiar.

Thomas Phinney

A short version of my answer from Quora:

JavaScript is way more useful to the hosting company than the end user.

For WebINK we chose a CSS-only solution because it allows us to support more options to our customers, and better performance for most. Our clients can add JavaScript on top of our solution if they want to, including an anti-FOUT script we provide, or even use the Google Web Font Loader JS—but the fonts will show up even for viewers who do not have JavaScript enabled, and no JavaScript is required.

> [JavaScript] may also be your only option if you have to support blackberry browsers or something exotic like opera mobile (probably something only large sites care about anyway).

Nope, we support both those on WebINK, with a CSS-only solution.

Marcos Ojeda

i stand corrected! thanks for clarifying!

Marcos Ojeda

this is comically off-topic for this forum, but i'm posting here because that thing i said earlier in this thread about a stock image company using hotlinked/embedded images for the ancillary benefits they could provide has happened.

timbrown

David Demaree explains why Typekit requires JavaScript to serve fonts.