Out of date / misleading explanation for why web fonts must be loaded from use.typekit.net
Good day, I'm a lead developer at Penn State Outreach Marketing, and I have a proposal for helping improve certain web vitals metrics for users of Adobe fonts. We have found that the use of Adobe fonts is presently a bottleneck for our continued LCP/CLS tuning efforts.
Adobe's documentation at https://helpx.adobe.com/fonts/using/use-typekit-net.html claims that...
"The CDN allows your fonts to be cached at many locations around the world, to ensure that they can be delivered to your website visitors as quickly as possible."
However this isn't always true -- at least not nowadays...
The use of using an Adobe hosted CSS file in order to load @font-face
information will add an additional HTTP roundtrip to the critical rendering path. In order for first paint to occur, unless a font is set to font-display: swap
, the user agent must...
Request and parse the DOM response
Request, download, parse, and evaluate the CSS response from https://use.typekit.net/*/*.css
Request, download, and apply the font assets
For users that are literally optimizing for milliseconds in order to meet Google's Web Vitals thresholds, that extra round-trip is sometimes a deal-breaker.
Wouldn't a better approach be to eliminate step #2 and allow end-users to embed the @font-faces
directly in their DOM responses? That would completely remove font loading from the critical rendering path for users that are using font-display: swap
, and greatly reduce the layout shifting impact of users who opt to use font-display: swap
.
HTTP roundtrips on mobile data plans can easily "cost" 600 milliseconds. By offering users the ability to embed the @font-faces
directly in the DOM response, still keeping the fonts hosted by Adobe, this seems to be a best of both worlds compromise. The fonts wouldn't need to be "self hosted" by end-users, and end-users wouldn't need to regress on performance in order to use Adobe fonts.
What would be needed from Adobe? Font binaries hosted on Adobe's servers that have backwards-compatibility guarantees -- meaning that the path to the font would not change.
What would be needed from End Users? Nothing! It could be an opt-in feature!
-
Jen Gfeller commented
Thanks for posting this. I'm at the end of my optimization process on a build, and Typekit render blocking is the only issue I haven't been able to get sorted. While my performance scores are good on desktop, it's preventing optimal load speeds on mobile - which is obviously critical these days. I'm surprised Adobe hasn't addressed this before now.