Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[RFC] Automatic Font Fallback for layoutshiftless font-display: swap #24396

Closed
patrickhulce opened this issue Apr 23, 2021 · 1 comment
Closed

Comments

@patrickhulce
Copy link

Describe the feature you'd like to request

I would like next.js to provide fallback fonts by default that enable use of font-display: swap for performance benefits without incurring the cost of layout shifts.

Problem

  • You want to use a webfont on users' first page experience.
  • You don't want waiting on the font to block FCP.
  • You don't want layout shifts.

Today you have to pick two of the three, OR you have to painstakingly use a tool like the font style matcher to find matching font settings, apply a class that sets the overrides for the fallback fonts, load the fonts with the FontFace API to observe readiness, and then trigger the upgrade when the webfont has loaded.

I want an end result that works like this example out-of-the-box for users of common webfonts.

Describe the solution you'd like

Next.js font optimizations already introduced the concept of modifying and optimizing font declarations from trusted parties. I propose extending this concept to building a database of known matching fallback fonts that could be applied using the new overriding font descriptors as part of font optimization. If taken on before the advance-override descriptors are available, it would entail injecting the utility classes and observing font availability to apply body-wide classes as well (Much more work).

The usage pattern for next.js users should be largely invisible and happen by default with a flag to disable (or enable during experimental phase).

Describe alternatives you've considered

  • Ignore advance-override and other font descriptors and stick to letter-spacing workarounds to be implemented at a CSS framework level like tailwind (still an option, though probably more limited in scope and more difficult to use, limits total possible impact)
  • Go straight to the source and have Google Fonts/TypeKit/etc provide sensible fallbacks for every font they offer. (this is ideal, but I'm assuming they'd want validation of the approach before doing so, this seems like a great place to do that 😃 )
  • Do nothing, live with the CLS, FCP impact, and/or brand impact of the other font-display options.

Related Issues
Customizable font display with inlining optimization (#21555)
Dynamic font loading (#20134)
Async font styles (#16065)

Related Resources
Reducing layout shift from fonts article
font-display: swap w/o layout shift example
Chromium issue for advance-override
CSS WG discussion on override inline spacing
CSS WG discussion on overrides for fallback fonts

@rauchg
Copy link
Member

rauchg commented Apr 23, 2021

The quintessential "have your webfont cake and eat it too". I love this. Thanks @patrickhulce for sharing your proposal!

@vercel vercel locked and limited conversation to collaborators Apr 25, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants