Font display on page load
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/
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.
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
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: fallbackwould 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.
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.
Thank you for testing - I will implement this over in Codeberg Fonts, once Inter 3.16 has been released.
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.
Deleting a branch is permanent. It CANNOT be undone. Continue?