Out of date / misleading explanation for why web fonts must be loaded from use.typekit.net?

Hello!

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."

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...

1. Request and parse the DOM response

2. Request, download, parse, and evaluate the CSS response from https://use.typekit.net/*/*.css

3. 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!

Thoughts? 🙂