Rendering style variation tiles is really really slow when the site has large assets

[dsas]

Description

The style variation tiles can be really slow to render if your site includes lots of assets. This is similar to #49645 but this issue is not specific to fonts.

Step-by-step reproduction instructions

1. On your test site, activate the TT3 theme and Gutenberg plugin.
2. Install and activate this test plugin too use the GB-native way of adding lots of fonts thus generating a large asset.
3. Open the site editor
4. Open the list of style variations in view mode or in the global styles sidebar
5. See that they take a long time to open

If you right-click on one of the tiles and inspect it with your browser tools you will see that each style tile is rendered by an iframe and that it includes lots of different assets. Most of which are overkill for a style tile. Notably it will include <style id="wp-fonts-jetpack-google-fonts"> even though it only ever renders one font - the h1 font for that style variation.

The style tile is displayed by the StylesPreview component, which renders a GB iframe. It's the GB iframe that outputs the styles it gets from __unstableResolvedAssets in the block-editor store. This comes from the script-loader settings.

Screenshots, screen recording, code snippet

Screen.Recording.2023-06-01.at.16.05.57.mov

Screen recording shows asset-heavy GB on the left, and vanilla GB on the right. Notice that despite a ~2 second headstart, the asset heavy GB finishes rendering after the vanilla GB.

The aubergine tile for the asset-heavy window is about 950kb, the aubergine tile in the vanilla window is 35kb, comparing the two sources, it seems that difference is basically entirely in the fonts asset downloaded in the asset-heavy window.

Environment info

The site is using WordPress 6.2.2 using GB 15.9 and TT3

I've reproduced on chrome 113.0.5672.126 and firefox 113.0.2

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[hellofromtonya]

Thank you for opening this issue @dsas. I'm sharing our conversation here for contributors.

Each of style variation tile is in a separate iframe. Each iframe runs _gutenberg_get_iframed_editor_assets() which collects all of the styles, fonts, and scripts. But these particular iframes do not need all of the assets that the iframed editor does. For example, each of these iframes only needs the singular font to render the font preview for that specific style variation.

Currently:

• _gutenberg_get_iframed_editor_assets() does not differentiate which iframe is making the request or what assets are needed for it. It invokes wp_print_fonts() passing true to it to indicate the request is for an iframed editor.
• wp_print_fonts() also does not differentiate which iframe, but rather uses the true to denote all iframes. When true, all registered (for the Site Editor) or enqueued (for other editors such as a Post) fonts processed.

The issue is not the Fonts API itself, but rather adding the context of which assets to collect for their respective iframe. I'm thinking for these style variation tile iframes, they also don't need all of the style and scripts.

🤔 I'm wondering: Is there a way to identify which type of iframe is being built? Then for each iframe type, an asset list can be added to build only the assets each type needs.

[dsas]

Each iframe runs _gutenberg_get_iframed_editor_assets()

Is that true? The only extra HTTP requests I get when loading the iframes are for /wp-admin/load-scripts.php?c=1&load[chunk_0]=wp-polyfill-inert,regenerator-runtime,wp-polyfill&ver=6.2.2 and /wp-content/plugins/gutenberg/build/vendors/inert-polyfill.min.js?ver=6.2.2

I think that _gutenberg_get_iframed_editor_assets is called for the iframed editor, that's then stored in a __unstableResolvedAssets and each of the style variation tile iframes then has that asset list copied from that block editor setting into the style variation tile iframe by the iframe component.

I agree that the asset list ought to be filtered depending upon the type of iframe but in this case I think that means that _gutenberg_get_iframed_editor_assets needs to provide some metadata on the asset type and the filtering needs to happen in JS.