Font display on page load #54

Open
opened 1 year ago by sexybiggetje · 9 comments

Since the stylesheet issue was fixed and deployed (hurray!) I'll open a new one for this;

Whenever the page loads, and the given font isn't served fast enough (I think the treshold is 100ms or so) the font renders the fallback font until it's there. This makes both the body font and title fonts jump around (which is irritating for the eyes, and causes the page to recalculate layouts).

This behaviour can be fixed by either caching the font better, or set font-display: fallback; or font-display: block; on the body. This causes the text to be non available until the font is there properly or if 100ms has been reached. When choosing block this removes the 100ms limit. Which is fine as well, because it's a better solution as long as the font gets served.

A side effect is that the site looks like it's loading slightly longer (while the timing is exactly the same, but the rendering isn't). But since it's a documentation site and the page load is still fast, this is (to me) an acceptable loss.

I'm curious what you think of this;

Everything you'll want to know about font-display: https://css-tricks.com/font-display-masses/

Since the stylesheet issue was fixed and deployed (hurray!) I'll open a new one for this; Whenever the page loads, and the given font isn't served fast enough (I think the treshold is 100ms or so) the font renders the fallback font until it's there. This makes both the body font and title fonts jump around (which is irritating for the eyes, and causes the page to recalculate layouts). This behaviour can be fixed by either caching the font better, or set font-display: fallback; or font-display: block; on the body. This causes the text to be non available until the font is there properly or if 100ms has been reached. When choosing block this removes the 100ms limit. Which is fine as well, because it's a better solution as long as the font gets served. A side effect is that the site looks like it's loading slightly longer (while the timing is exactly the same, but the rendering isn't). But since it's a documentation site and the page load is still fast, this is (to me) an acceptable loss. I'm curious what you think of this; Everything you'll want to know about font-display: https://css-tricks.com/font-display-masses/
Owner

@sexybiggetje

Thanks for bringing this up.
For now we set caching times to 3 minutes wich will at least mitigate the problem and also reduce load on the server.

For proper revalidation if resources changed we would need a proper fix including etags.

@sexybiggetje Thanks for bringing this up. For now we set caching times to 3 minutes wich will at least mitigate the problem and also reduce load on the server. For proper revalidation if resources changed we would need a proper fix including etags.
Poster

Hmm a 3 minute cache is quite low for fonts. Maybe for some JS/CSS that's feasible, but if you read the docs, and navigate around while also following along 3 minutes will pass quite easily. And thus maintain the issue.

Maybe a quarter of an hour is a more relevant caching time, but fonts don't change much, they could just as easily be a full day, week or month. There is always the possability of adding a version to the filename to bust a previously cached version if the need occurs.

Hmm a 3 minute cache is quite low for fonts. Maybe for some JS/CSS that's feasible, but if you read the docs, and navigate around while also following along 3 minutes will pass quite easily. And thus maintain the issue. Maybe a quarter of an hour is a more relevant caching time, but fonts don't change much, they could just as easily be a full day, week or month. There is always the possability of adding a version to the filename to bust a previously cached version if the need occurs.
n commented 1 year ago
Collaborator

Google Fonts caches the font stylesheet for a day, and the font for a year (source). If possible, Codeberg fonts should be configured to behave similarly.

Google Fonts caches the font stylesheet for a day, and the font for a year [(source)](https://developers.google.com/fonts/faq#what_does_using_the_google_fonts_api_mean_for_the_privacy_of_my_users). If possible, Codeberg fonts should be configured to behave similarly.
Owner

We now use etags which contain the latest commit hash, so that files are only transferred when repo contents change.

We wanted to combine this with a cache validity, but it seems that firefox does not send etag headers anymore when there is a cache lifetime set. At least we didnt figure out how... Chrome worked.

So, for not etags, but the server will stil be contacted and send a 304, but no content for cached files.

We now use etags which contain the latest commit hash, so that files are only transferred when repo contents change. We wanted to combine this with a cache validity, but it seems that firefox does not send etag headers anymore when there is a cache lifetime set. At least we didnt figure out how... Chrome worked. So, for not etags, but the server will stil be contacted and send a 304, but no content for cached files.

@sexybiggetje - Good catch, thank you for pointing this out 👍👍👍

I will have a look at font-display and especially the article you linked to and I will then apply a solution immediately.

Concerning font caching: I have started thinking about font versioning and caching in the context of Codeberg Fonts (and, in extension, fontJAM). I'm not quite sure yet which solution would be the best. For Codeberg Fonts, we can rely on HTTP-based cache control including etags. For fontJAM, the planned future basis of Fonts, compatibility with all kinds of static hosting services would be great, so combining HTTP caching (where available) with semantic versioning (for fonts that use it) would be good.

Planning for fontJAM will start soon and I will open up an issue in fontJAM/fontJAM for caching then as well. Everyone is invited to join the discussion or to contribute :)

@ashimokawa Thank you for implementing etags in record time - that's magnificent! 👍 🚀 Will the current approach to etags also work to repos like this one where the pages repository is wiped before each deploy? Otherwise I would change the deploy script to work more like the one of Fonts, which does incremental commits to the pages repo.

@n If there are no technical reasons against it, and with proper versioning of the fonts, I'm absolutely for long-time caching of fonts, seeing as this will likely speed up page loads while reducing traffic - win-win! :) Let's move discussion about caching duration for fonts to codeberg-fonts/codeberg-fonts#6

@sexybiggetje - Good catch, thank you for pointing this out :thumbsup:👍👍 I will have a look at `font-display` and especially the article you linked to and I will then apply a solution immediately. Concerning font caching: I have started thinking about font versioning and caching in the context of Codeberg Fonts (and, in extension, fontJAM). I'm not quite sure yet which solution would be the best. For Codeberg Fonts, we can rely on HTTP-based cache control including etags. For fontJAM, the planned future basis of Fonts, compatibility with all kinds of static hosting services would be great, so combining HTTP caching (where available) with semantic versioning (for fonts that use it) would be good. Planning for fontJAM will start soon and I will open up an issue in fontJAM/fontJAM for caching then as well. Everyone is invited to join the discussion or to contribute :) @ashimokawa Thank you for implementing etags in record time - that's magnificent! 👍 🚀 Will the current approach to etags also work to repos like this one where the `pages` repository is wiped before each deploy? Otherwise I would change the deploy script to work more like the one of Fonts, which does incremental commits to the pages repo. @n If there are no technical reasons against it, and with proper versioning of the fonts, I'm absolutely for long-time caching of fonts, seeing as this will likely speed up page loads while reducing traffic - win-win! :) Let's move discussion about caching duration for fonts to codeberg-fonts/codeberg-fonts#6
lhinderberger added the
Kind: Bug
Status: In progress
labels 1 year ago
lhinderberger self-assigned this 1 year ago

After reading the article, my suggestion is the following:

  • Let's not use font-display: block, because that will annoy anyone with a slow mobile connection (like when trying to use your phone on a train in Germany 😁)
  • font-display: fallback would be a good option, as long as we'd be able to serve the font under 100ms in the majority of cases. Here in Europe that should be no problem, but for people connecting from overseas I'm afraid that could cause them to never see Codeberg Documentation as it's intended to look like.

So in my opinion we should concentrate on better caching and discuss whether font-display: fallback would be acceptable.

After reading the article, my suggestion is the following: - Let's not use `font-display: block`, because that will annoy anyone with a slow mobile connection (like when trying to use your phone on a train in Germany :grin:) - `font-display: fallback` would be a good option, as long as we'd be able to serve the font under 100ms in the majority of cases. Here in Europe that should be no problem, but for people connecting from overseas I'm afraid that could cause them to never see Codeberg Documentation as it's intended to look like. So in my opinion we should concentrate on better caching and discuss whether `font-display: fallback` would be acceptable.
lhinderberger added
Status: Needs feedback
and removed
Status: In progress
labels 1 year ago
Poster

Font loading isn't aborted after 100ms (tested in Chrome), if it's cached proprly thy will still see it on next pageload when font-display: fallback is set. Looks like the combination has the most desirable effect.

Font loading isn't aborted after 100ms (tested in Chrome), if it's cached proprly thy will still see it on next pageload when font-display: fallback is set. Looks like the combination has the most desirable effect.
lhinderberger added
Status: In progress
and removed
Status: Needs feedback
labels 1 year ago
lhinderberger added
Status: Blocked
and removed
Status: In progress
labels 1 year ago

Thank you for testing - I will implement this over in Codeberg Fonts, once Inter 3.16 has been released.

Thank you for testing - I will implement this over in Codeberg Fonts, once Inter 3.16 has been released.
Owner

@lhinderberger

Will the current approach to etags also work to repos like this one where the pages repository is wiped before each deploy? Otherwise I would change the deploy script to work more like the one of Fonts, which does incremental commits to the pages repo.

With every commit or every recreation, the etags will be different as they are globally the hash of the last commit, so cache will be invalidated.

It is not perfect but I think it is far better than before, doing etags on a file by file base would require more costly git stunts on server side which are probably not worth it in my opinion.

@lhinderberger > Will the current approach to etags also work to repos like this one where the pages repository is wiped before each deploy? Otherwise I would change the deploy script to work more like the one of Fonts, which does incremental commits to the pages repo. With every commit or every recreation, the etags will be different as they are globally the hash of the last commit, so cache will be invalidated. It is not perfect but I think it is far better than before, doing etags on a file by file base would require more costly git stunts on server side which are probably not worth it in my opinion.
fnetX added
Part: Generator
and removed
Status: Blocked
labels 5 months ago
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Depends on
#7 Enable font-display
codeberg-fonts/codeberg-fonts
Loading…
There is no content yet.