Navigation: Discuss/implement splitting variable font

Should we be using a variable font (I'm thinking maybe not).

You can see the background behind the decision already taken to use Inter font and in its variable form in #3388954: [PLAN] Discuss using Inter font for the navigation. On a design and UI perspective, even on a UX perspective to help give deep and differentiate typography styles, a variable font is the tool we need for a modern UI. It's basically one of the most important UI elements we have, since a UI is mostly built by text and surfaces.

That said, happy to find a way to decrease its weight.

@kostyashupenko mentions splitting italic and the different font weights out, and that seems like a good start. Can still ship them and define the rules, but if they're not used by default, they wont be loaded - can also only pre-load what we use by default then.

Imo before that splitting we need to calculate amount of possible benefits.
Cause if we will have lot of font variations this variant (one file for all styles) looks much better.

Even if 3 font types will be used it will be more or less same with that `huge` 346Kb

@catch
this suggestion about different files was made before than Kostia became familar with https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_fonts/Variable_font...

Cause if we will have lot of font variations this variant (one file for all styles) looks much better.

There's a limit to how much text can be shown in the navigation bar at once, how many variations can there be?

@catch for now only 2 types as far as i remember.
so 110kb + 110 Kb against 346Kb
in 2024 ;)

Just checked we already have 3 types

So this ticket is about ~15Kb overweight.

Argh. 4 types ;)

So we want to grow assets size here.

Still a waste to load the italic variation if it's never going to be used.

The ckeditor team wrote up how they optimized their variable font: https://ckeditor.com/blog/optimize-font-size-with-variable-fonts/ - like separate italic and non-italic variations (where there's apparently no benefit to a single file at all).

We don't load italic:

Yes, seems it is one option that we have.

I've checked fonts on websites listed in
https://github.com/rsms/inter?tab=readme-ov-file#notable-projects-using-...

Seems that
https://www.flughafen-zuerich.ch/en/passengers
uses variable font with smaller file-size. Others uses separated files or same file size.

So probably we need to

1. define Languages we want to support https://rsms.me/inter/#languages
2. Check pyftsubset as recommended https://rsms.me/inter/#faq

As Ivan mentions in #11 we aren't aren't shipping the italic font yet (since we don't use it, and I think we won't until the new design system is used more broadly on the UI), so that's something we can't remove.

So I agree with him on that the only way to decrease the file size: removing initial Language support to split the glyphs in different subsets. Do we have any guideline for Language prioritization already?

I could do some tests to see if we could, perhaps, eliminate one of those weights and get it down to 3 weights without greatly affecting the overall visual hierarchy. I'm not certain if limiting to 3 weights would make that significant of a difference? I'd be open to testing though if you think it's worthwhile.

I think it's worth knowing the answer to #15 even if it turns out to be a dead-end.

In general thanks for the answers above, it's good to know the low hanging fruit are covered even if that means there's not much low hanging fruit to get things down under 300kb...

Splitting by glyphs sounds like it could reduce size a lot, and in general single users don't load lots and lots of different languages that much even if sites have them - so duplication would be less of an issue than other ways of splitting. However, I have no idea how to split a font by language/glyphs - we wouldn't want to arbitrarily remove support for various languages since in theory we support anything, so it'd be a case of taking them out by default but adding them back when needed?

Related to this has anyone tested what happens with this font and CJK languages, arabic, farsi?

Re to #15 and #16:
We're using a variable font: it means that all weights are built in one file, so it really doesn't matter if we use 1 weight or 4. That's the magic behind variable fonts and why we decided using them. A variable font size might be twice a regular font, but you get way more :)
So there is no need for any redesign/design exploration. But thanks @jponch for being open to it!

However, I have no idea how to split a font by language/glyphs

There are several tools out there. @finnsky 's links have a few of them. But the question still is which languages.

About other languages, then it defaults to the system's font. I've tried it with Arabic and Japanese.

Had a look at Mercury's font situation, it also uses Inter.

Mercury isn't using a variable font (but probably could/should), however it is splitting the glyphs - they're added back via separate CSS declarations using unicode-range (https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/unicode-range) which answers #16. This is done for cyrillic, greek, and vietnamese.

So I think for Navigation, splitting the variable font by glyphs then adding them back with unicode-range might end up being the most efficient. Visually it would end up exactly the same, a smaller default font size for everyone, an extra file for pages that need extra glyphs.