[wp-trac] [WordPress Trac] #65215: Connectors: REST API responses on the Connectors screen should be preloaded

[WordPress Trac]

#65215: Connectors: REST API responses on the Connectors screen should be preloaded
--------------------------------------+------------------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  rest-api, performance
--------------------------------------+------------------------------------
Description changed by westonruter:

Old description:

> For screenshots and for what this backports, see
> [https://github.com/WordPress/gutenberg/pull/77353 Gutenberg PR].
>
> == What? ==
>
> The Connectors screen (`options-general.php?page=options-connectors-wp-
> admin`) fires several REST API requests after hydration, delaying the
> Largest Contentful Paint.
>
> Specifically: `GET /wp/v2/settings` (site entity), `OPTIONS
> /wp/v2/plugins` (the `canUser( 'create', 'plugin' )` check), a hardcoded
> `GET /wp/v2/plugins/ai/ai` used by the AI-plugin callout, and one `GET
> /wp/v2/plugins/<basename>` per registered connector — five sequential
> round-trips with the default connectors.
>
> == Why? ==
>
> These responses are all trivially knowable at render time on the server,
> so they should be embedded in the initial HTML via
> `createPreloadingMiddleware` rather than re-fetched by the client after
> hydration. This also reduces the number of requests on the server,
> reducing server load.
>
> === Measured impact (median LCP over 10 runs) ===
>
> || '''Scenario''' || '''Trunk''' || '''This PR''' || '''Δ''' ||
> || Fast 4G || 1523 ms || 1150 ms || −373 ms (≈24.5%) ||
> || No throttling || 743 ms || 518 ms || −225 ms (≈30.3%) ||
>
> == How? ==
>
> Adds a `{page-slug}-wp-admin_preload_paths` filter to the `wp-build`
> `page-wp-admin` template so any generated admin page can register page-
> specific preload paths. Hooks it in the Connectors loader to preload the
> five paths listed in '''What?''' above (the existing hardcoded preload in
> the template only covers the root site fields, not the settings entity
> the UI actually resolves, so `/wp/v2/settings` is added too).
>
> After the change, none of the connector-related REST requests fire on
> page load — they are served from the preload middleware.
>
> The two remaining requests come from `@wordpress/core-abilities`, which
> Gutenberg enqueues on every admin page — out of scope here, but a
> candidate for similar preloading.

New description:

 For screenshots and for what this backports, see
 [https://github.com/WordPress/gutenberg/pull/77353 Gutenberg PR].

 == What? ==

 The Connectors screen (`options-general.php?page=options-connectors-wp-
 admin`) fires several REST API requests after hydration, delaying the
 Largest Contentful Paint.

 Specifically: `GET /wp/v2/settings` (site entity), `OPTIONS
 /wp/v2/plugins` (the `canUser( 'create', 'plugin' )` check), a hardcoded
 `GET /wp/v2/plugins/ai/ai` used by the AI-plugin callout, and one `GET
 /wp/v2/plugins/<basename>` per registered connector — five sequential
 round-trips with the default connectors.

 == Why? ==

 These responses are all trivially knowable at render time on the server,
 so they should be embedded in the initial HTML via
 `createPreloadingMiddleware` rather than re-fetched by the client after
 hydration. This also reduces the number of requests on the server,
 reducing server load.

 === Measured impact (median LCP over 10 runs) ===

 || '''Scenario''' || '''Trunk''' || '''This PR''' || '''Δ''' ||
 || Fast 4G || 1523 ms || 1150 ms || −373 ms (≈24.5%) ||
 || No throttling || 743 ms || 518 ms || −225 ms (≈30.3%) ||

 == How? ==

 Adds a `{page-slug}-wp-admin_preload_paths` filter to the `wp-build`
 `page-wp-admin` template so any generated admin page can register page-
 specific preload paths. Hooks it in the Connectors loader to preload the
 five paths listed in '''What?''' above (the existing hardcoded preload in
 the template only covers the root site fields, not the settings entity the
 UI actually resolves, so `/wp/v2/settings` is added too).

 After the change, none of the connector-related REST requests fire on page
 load — they are served from the preload middleware.

 The two remaining requests come from `@wordpress/core-abilities`, which
 Gutenberg enqueues on every admin page — out of scope here, but a
 candidate for similar preloading.

 ----

 To achieve the following, REST API responses for `404 Not Found` need to
 be served to the preload middleware. This is a follow up to r44123 and
 r44172.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65215#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform