
Making Cloud.typography Faster - csswizardry
https://csswizardry.com/2019/08/making-cloud-typography-faster/
======
andrethegiant
Awesome post. I worked with cloud.typography for a client once too, and was
surprised to discover that they shipped two base64-encoded data strings for
each font, each one containing only one half of the font's glyphs – that is to
say, their CSS had two @font-face rules for each font: one that had the data
for e.g. A-M, and the other that had data for N-Z. The `font-family` rules of
the body text specified both FontA and FontB, leaving the browser to piece the
font together. Of course, this made extra bloat in the base64 string, because
it's essentially two encoded font files instead of one.

I assumed this was for anti-DRM / licensing purposes, so that if someone tried
to download the font shipped to the client, they wouldn't get the whole
alphabet (even though it's fairly trivial to stitch fonts together – you can
use FontForge to copy/paste glyphs from one font to another). Do you know if
they still ship fonts with a split alphabet?

~~~
jfk13
This is a _terrible_ idea, and I wish sites/foundries would abandon it.

For fonts with features like ligatures or kerning, it'll break these when the
adjacent glyphs that should interact happen to come from separate sub-fonts.
But even for simple fonts that don't have any such features, it can result in
terrible rendering because it's possible the font rasteriser (e.g. freetype),
which sees the two parts of the font as completely independent entities, will
end up applying hinting in quite different ways based on separate analysis of
the disjoint glyph subsets.

I've seen real-world examples where the end result is that half the glyphs
"snap" to one x-height value, and the other half (from the other sub-font)
snap to a value that's a pixel taller or shorter. The font rasteriser has no
way of knowing that it should have auto-hinted "globally" across the two
separate resources.

~~~
crazygringo
Son of a gun. I've actually seen that before (the different x-heights) and,
debugging it, couldn't figure out what the _heck_ was going on. And it was
with one of those split-into-two-fonts thing.

So that definitely is real. Thanks for finally solving the mystery for me
years later.

------
tux1968
That trick of marking a stylesheet for print media use only, and setting it
for use with all media only after it is fully loaded, is very clever. Worth
the read for that little gem alone.

~~~
csswizardry
Neat, huh? :D

------
social_quotient
Great write-up on this topic. in the demo video near the bottom can you make
the links to those each available. I tried to go to
[https://csswizardry.dev/typography.com/fixed.html](https://csswizardry.dev/typography.com/fixed.html)
and am getting a page that says "sneaky" I was hoping to run these demos
locally to really see the magic firsthand.

~~~
csswizardry
~~Hey! OP here. I’m currently sat on a flight so I’ll try my best to push it
back live. __N.B. __At some point, my client will de-whitelist my
csswizardry.dev domain from their Cloud.typography account and these demos
will stop working.~~

UPDATE: I’ve had to go the opposite way and pull the whole lot. It outs my
client and I really don’t want their name against anything. Email me and I’ll
fire you a private demo.

~~~
social_quotient
john @ curtisdigital.com , thanks and have a good flight!

------
bytematic
I love harrys posts, you can tell he really knows this stuff inside and out
(plus we share an uncommon name). That font pop-in does such suck and I can
see some execs agreeing that the extra time is worth the cost. I agree that
the initial rendering being faster would be much nicer.

~~~
csswizardry
Thanks, Harry!

------
a_t48
Side note: This was really hard to read for me. The font was way too thin. Any
vertical lines get smeared across three horizontal pixels (I assume because of
subpixel AA) making everything thin and hard to parse. This is the second or
third site I've seen this happen on, I wish I knew why.

~~~
csswizardry
You’re not the first person to mention this—I’m sorry. Does font-weight: 400;
on the body copy help? (Sorry to make you do the legwork but for me the type
is perfectly legible as it is, so I need someone else to verify.)

~~~
a_t48
It does, a lot - [https://imgur.com/o4cE1id](https://imgur.com/o4cE1id)

For reference, I'm on Chrome, Win 10. The above image is at 125% zoom in
Chrome, magnified 16x to see the pixels. I don't mind testing though, this
helps me a lot - now I know what property to change or suggest if I see
another site that does this to me.

~~~
paulddraper
font-weight:400 made this readable for me as well.

The best thing monitor manufacturers even did was see 4k monitors to
designers.

~~~
a_t48
I only run 1440p, though on a very nice monitor. In a couple of GPU revs I'll
pick up a nice 4k.

------
qznc
Not showing anything for 1.5 seconds is considered acceptable?

~~~
csswizardry
s/acceptable/an enormous improvement

From the article, wihch presumably you read:

> Yes, we do have a FOFT, but we are getting text in front of the reader much,
> much sooner—this is _an enormous improvement_.

Emphasis mine.

