Skip to content

Instantly share code, notes, and snippets.

@csswizardry
Created August 10, 2019 17:10
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save csswizardry/44ead7d606191f68233f1f77c61b63ba to your computer and use it in GitHub Desktop.
Cloud.typography Email

Hi!

I really appreciate your time, so I will try to keep this brief.

I have a few clients who are using the cloud-hosted option of yours, and the pattern looks like this:

  • Link to a stylesheet such as https://cloud.typography.com/[number]/[number]/css/fonts.css
  • That file returns a 302 which points at a self-hosted CSS file such as https://company.com/[number]/[hash].css
  • The second actual CSS file contains Base64 encoded fonts to be used on the page.

Unfortunately, the combination of the above points is having some pretty large knock-on effects performance-wise, so I’m just looking into what I can do on my end to side-step some of the issues. To briefly summarise:

  • The outgoing request headers for cloud.typography.com/[…]fonts.css are for CSS (Accept: text/css), so even though a 302 with a text/html mime type is returned, the entire request sits on the Critical Path, blocking rendering.
  • The cloud.typography.com/[…]fonts.css response has a must-revalidate header, so we take at least the latency hit on every page load, further blocking the Critical Path.
  • When we do get redirected to our self-hosted fonts file, it’s full of Base64 encoded font data, so there’s usually a lot of KB of data that gets moved onto the Critical Path which further delays rendering.
  • In some cases, I’ve seen this critical request chain last over 1,200ms on a cable connection, and up to 4.5s on 3G, all of which blocks rendering.

My zeroth question is: are they implementing everything correctly? If not, then a lot of the rest of the email is moot.

My first question is: does the trip to cloud.typography.com somehow validate the ‘release’ of the self-hosted CSS file? I can’t really see any mechanism in which it could do that, but it’s a working thought. Or rather, is it used to track pageviews for your own metrics (seeing if a customer is regularly going over their quota)? If it’s the latter, would something like this work?

<link rel="stylesheet" href="https://cloud.typography.com/[number]/[number]/css/fonts.css" />
<link rel="stylesheet" href="https://company.com/[number]/[hash].css" />

…parallelising the requests and still providing Hoefler&Co with the relevant statistics.

My second question is: is there an option to have the fonts in a format other than Base64? Base64 hugely inflates filesize, compresses poorly, downloads font data even if the fonts aren’t used on that particular page, and renders font-display ineffective.

My third question is: if we take Tungsten, for example, a year’s usage at 250k pageviews/mo will cost $99/yr with the cloud option, but $219/yr for the self-hosted version.

The cloud option:

  • pushes more cost onto Hoefler&Co (hosting, infrastructure, support, SLAs, etc.) (bad for you);
  • gives the customer access to the entire library (bad for you);
  • is slower than self-hosting (bad for the customer);
  • but is less than half the price of the self-hosted option (bad for you).

The self-hosted option:

  • is faster than the cloud option (good for the customer);
  • only gives the customer access to one typeface (good for you);
  • reduces your operating costs (good for you);
  • is over twice the cost of the cloud option (good for you).

Is there a particular reason you’re nudging customers toward the cloud option when—from my external perspective, at least—it seems to have downsides all round? The self-hosted option is more lucrative for Hoefler&Co, is faster for the user, and greatly reduces your operational overheads. Could it just be as simple as the fact that self-hosted, not-Base64 encoded fonts are easier for people to steal?

More generally, speaking as both a lover of type and a performance fanatic, I’d be fascinated to hear more about some of the decisions that were made, how long they’re expected to be in use for, and any considerations that have been given to performance (particularly where Critical Path optimisation is concerned).

I really, really hope none of this comes across as critical. I’m a man on a mission to make the web faster, and I’m also a fan of Hoefler&Co, so I’m on both sides here!

I’d be really grateful for any and all insights. If it’s quicker to hop on a call, or you need to refer me to someone else internally, please just let me know.

(Also, if you need any help with front-end performance, I’d love to chat!)

Have a great day,
Harry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment