[Fonts API] Performance: Cache dynamically generated @font-face rulesets

[hellofromtonya]

Part of #41479.

Problem Statement

Currently, the API dynamically generates the global @font-face rulesets on each web page request. But these global typography web fonts do not change on each request. Rather, they change with an event such as through user selection (via global styles UI), theme change, plugin change, and possibly programmatically in a specific template or web page (such as a forum, landing page, etc.).

Dynamically generating the rulesets each time is wasteful.

Scope

This issue proposes caching the @font-face rulesets and then clearing the cache when specific events happen.

Part of this scope then is to identify the "specific events" while providing a way for extenders to manually clear the cache.

[aristath]

Dynamically generating the rulesets each time is wasteful.

I agree 100%
Even a 1-minute transient would be beneficial... and it wouldn't be the first time we do that either. Global-styles also get cached for a minute to avoid issues on high-traffic sites 👍
Ideally we'd cache for longer periods and reset the caches on specific events as described in the OP, but an addition could be to also disable these caches if SCRIPT_DEBUG is true, to allow theme-developers to work easier.

[colorful-tones]

an addition could be to also disable these caches if SCRIPT_DEBUG istrue, to allow theme-developers to work easier.

This is a great suggestion. ❤️ 💯

[peterwilsoncc]

As part of WP#6531, WordPress 4.9 introduced caching of the templates dropdown in the editor on the basis that it was work that shouldn't be repeated on each page load. It was reverted in WP#42573 for WordPress 4.9.1 as it became problematic when themes were updated.

With this in mind, I'd suggest the following:

• a hash of theme.json be part of the cache key
• for fonts enqueued via the PHP API a hash of all the arguments used to for the individual font be included in the cache key
• Along with SCRIPT_DEBUG, consider the effect of WP_DEBUG(_*) and WP_ENVIRONMENT_TYPE -- caching on local environments probably isn't helpful

I'd also suggest using the object cache rather than a short lived transient. Sites that get enough visitors for a short lived cache to provide a benefit are likely to be using object caching, a short lived transient will add database calls that may slow the site down as short lived transients are not autoloaded in the options table.

[hellofromtonya]

The Fonts API is being replaced by Font Face to work with the new font management direction and Font Library. I don't currently see a need for caching @font-face rulesets as it would introduce complexity into the new design for tracking which font faces were printed for which fonts.

I'm closing this issue. In the future if there is a performance issue with the generation and printing of @font-face rulesets, then a new issue can be opened to address those specific issues.

Thank you everyone for your contributions!