WPCOM's style variation load in the site editor feels much slower than core's

[dpasque]

Quick summary

When comparing how style variation options load in the site editor (in Global styles, e.g.) on DotCom vs on another kind of self-hosted site (Jurassic Ninja, e.g.), DotCom's feels slower.

Compare this on a Jurassic Ninja site:

To this DotCom simple site:

I noticed this especially because the 15.6 rc-1 adds the style variations to the menu sidebar, and the performance especially stands out there:

Steps to reproduce

Repeat on a Jurassic Ninja site and a WPCOM simple site:

1. Activate a theme with style variations (like twenty twenty three)
2. Go to site editor and open global styles
3. Click on "style variations" and watch them load in

What you expected to happen

They load in snappy-like

What actually happened

They feel more sluggish on DotCom

Impact

Most (> 50%)

Available workarounds?

Yes, easy to implement

Platform (Simple and/or Atomic)

Simple

Logs or notes

No response

[cuemarie]

📌 SCRUBBING : RESULT - Replicated / Could Not Replicate / Uncertain

• Tested on Simple – Replicated
• Tested on Atomic – Replicated
• Replicable outside of Dotcom – No

📌 FINDINGS/SCREENSHOTS/VIDEO

• Replicated as described - the Site Editor > Styles > Browse Styles in both Simple and AT environments feel quite sluggish compared to a self-hosted environment.

Screenshots/Recordings

AT site on left, Self-Hosted Site on Right

https://user-images.githubusercontent.com/27249804/232884375-181275c4-6e80-4ffe-9e13-58750e77766c.mp4

Simple site on left, Self-Hosted Site on Right

https://user-images.githubusercontent.com/27249804/232884724-68fe121c-c377-4cdf-b6d7-d612df02452f.mov

📌 ACTIONS

• Assigned to T-Rex

📌 OTHER NOTES

• I imagine this may be impacted quite a bit by this project: https://github.com/Automattic/wp-calypso/pull/75652

[mmtr]

I confirm that self-hosted sites with Jetpack enabled and connected to WP.com don't experience this issue, so it must be something specific to Atomic and Simple sites.

Trying to identify the culprit, I disabled some plugins and packages in my sandbox that are common for Atomic and Simple sites such as the ETK plugin, the wpcom-block-editor app, or the jetpack-mu-wpcom package. Nothing changed, so I guess something different is causing this. I ran out of ideas though, so I'm going to leave this one to someone else.

[dsas]

When unproxied, the GS API endpoint is consistently at least ~150ms slower on dotcom simple than JN. That's just one part of the story though, because dotcom still takes longer to fire the XHR and longer to render after the XHR is complete

I compared https://public-api.wordpress.com/wp/v2/sites/216170124/global-styles/themes/pub/twentytwentythree/variations?_envelope=1&_gutenberg_nonce=xxxxxxxxxx&_locale=user to /wp-json/wp/v2/global-styles/themes/twentytwentythree/variations?_locale=user

[dsas]

After loading the style tiles for the first time - so no further XHR requests, I went back in the nav and then 'raced' JN (left) and simple (right). I pressed styles on simple first and then switched window and pressed styles on jn. jn finished rendering first by about a second.

https://github.com/Automattic/wp-calypso/assets/93301/0b3f54bb-b26b-4118-b3ee-90d998923f10

[dsas]

Interestingly both sites still do fire lots of HTTP requests, nearly all the results are cached on both sites except the zendesk POST and t.gif. However simple made 48 requests and jn made 25 requests. There are 11 style variations in TT3 which is why there are eleven of many requests. I'm not sure if this is related but it is weird.

simple requests:

• zendesk post (not cached 243ms)
• t.gif (not cached 25ms)
• 11 GETs to https://s0.wp.com/wp-content/plugins/gutenberg-core/v15.8.1/build/vendors/inert-polyfill.min.js?m=1684864133h&ver=6.2.1-RC1-55769
• 2 GETs to https://fonts.wp.com/s/inter/v12/UcC73FwrK3iLTeHuS_fvQtMwCp50KnMa1ZL7.woff2
• 11 GETs to https://s0.wp.com/wp-includes/js/dist/vendor/wp-polyfill-inert.min.js?m=1677063259h&ver=3.1.2
• 11 GETs to https://s0.wp.com/wp-includes/js/dist/vendor/regenerator-runtime.min.js?m=1677593243h&ver=0.13.11
• 11 GETs to https://s0.wp.com/wp-includes/js/dist/vendor/wp-polyfill.min.js?m=1666876734h&ver=3.15.0

jn requests:

• 11 GETs to https://overseas-duck.jurassic.ninja/wp-content/plugins/gutenberg/build/vendors/inert-polyfill.min.js?ver=6.2.2
• 2 GETs to https://overseas-duck.jurassic.ninja/wp-content/themes/twentytwentythree/assets/fonts/inter/Inter-VariableFont_slnt,wght.ttf
• 1 GET to https://overseas-duck.jurassic.ninja/wp-content/themes/twentytwentythree/assets/fonts/source-serif-pro/SourceSerif4Variable-Roman.ttf.woff2
• 11 requests to https://overseas-duck.jurassic.ninja/wp-admin/load-scripts.php?c=1&load%5Bchunk_0%5D=wp-polyfill-inert,regenerator-runtime,wp-polyfill&ver=6.2.2

[dsas]

Each style tile is an iframe. on simple sites each iframe includes this CSS:

<link href="https://s0.wp.com/wp-content/plugins/gutenberg-blocks/jetpack-layout-grid/style.css?m=1643200914h&amp;ver=1643200914" id="jetpack-layout-grid-css" rel="stylesheet" media="all">
<link href="https://s0.wp.com/wp-content/plugins/gutenberg-blocks/jetpack-ratings/style.css?m=1576278967h&amp;ver=1576278967" id="jetpack-ratings-css" rel="stylesheet" media="all">
<link href="https://s0.wp.com/wp-content/mu-plugins/achievements/widgets.css?m=1395358578h&amp;ver=6.2.1-RC1-55769" id="widget-achievements-css" rel="stylesheet" media="all">

on JN, even after connecting jepack, it does not.

[dsas]

Oh maybe this is the problem - each of the eleven style tile iframes on dotcom simple include a style#wp-fonts-jetpack-google-fonts element which has manylots lines of fonts related CSS. Each iframe on simple weighs about 900kb, on a JN site each iframe is about 5kb.

[dsas]

That ID comes from the jetpack fonts provider.

If I change the superclass to use an empty string rather than calling get_css then the performance on dotcom is drastically improved.

[dsas]

Oh, to spell something out, the jetpack fonts provider is inactive by default but is loaded on wpcom via a google-fonts mu-plugin, so that causes the discrepancy.

---

I think that the Jetpack fonts provider works as it's supposed to according to the gb fonts provider class.

Style tiles need a font, the 'Aa' and style variation name are displayed in the heading font for that 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.

This is a long way of saying that the main cause of the slowness is the way that Gutenberg loads iframes. I'm unsure if we can do anything differently in wpcom/jetpack. This iframe slowness probably explains some other wpcom GB slowness.

[dsas]

This is very similar to an upstream issue, however I'm not sure that this fixes it from the style variation previews and it's blocked from merging to 15.9 by another active issue.

cc @tanjoymor @hellofromtonya - does the iframe fonts issue you're working on stop fonts css being included from the style variation preview iframes?

[dsas]

After talking to @hellofromtonya, that upstream PR won't affect this one, and this one is wider - being all assets rather than just fonts assets. I filed a new issue: https://github.com/WordPress/gutenberg/issues/51175

[annezazu]

Noting that this does still feel quite slow on WPCOM:

https://github.com/user-attachments/assets/bdb13044-5a05-4e36-b976-39321e1005cf