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
0
Comments
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
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
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.
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.
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.
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.