Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fonts aren't applied when the network speed is low #313

Closed
Crocmagnon opened this issue May 15, 2020 · 2 comments · Fixed by #774
Closed

Fonts aren't applied when the network speed is low #313

Crocmagnon opened this issue May 15, 2020 · 2 comments · Fixed by #774
Milestone

Comments

@Crocmagnon
Copy link

Crocmagnon commented May 15, 2020

Describe the bug

When displaying the site on a device with a low network speed, the custom fonts are loaded afterwards and aren't applied.

Steps to reproduce (if necessary)

Use the dev tools of your browser to throttle the connection quality to 3G-like.

See this screencast.

Expected behavior

Either fonts should be applied after being downloaded or they should not be downloaded at all. Right now it's just a waste of resource.

Application configuration

  • Single mode or Multi-user mode? Single
  • Database? [mysql/sqlite] sqlite
  • Open registration? [yes/no] no
  • Federation enabled? [yes/no] no

Version or last commit: 037fc40

@voidanix
Copy link

I am aware this is an old issue, but just noticed this today while refreshing a post: because the custom CSS had several font fallbacks it was really noticeable how often the wrong font was used.

This does not only apply to slow networks, though, but even extremely fast ones: if caching is disabled e.g. while logging network activity in the browser's network panel, then the issue is almost consistently reproducible (Firefox even gives a handy downloadable font: font-display timeout, webfont not used in the Console).

The issue, as the log above suggests, comes from font-display, added in 059f0d4: reverting the commit locally fixes the issue on all the devices/browsers I have tried so far, possibly making it a candidate for a revert.

@thebaer
Copy link
Member

thebaer commented Sep 25, 2023

Yeah, I think at this point it's worth reverting that. I went ahead and did that in #774 and will get it merged. Thanks for the input!

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

Successfully merging a pull request may close this issue.

3 participants