Context

The block editor uses preloading middleware that outputs API responses onto the page as JS objects to prevent the need for an XHR request once the editor is loaded.

WP Core code that defines preload paths (5.7): https://github.com/WordPress/wordpress-develop/blob/c8a4205394819839ee33fad040d24a4fd355cb23/src/wp-admin/edit-form-blocks.php#L46

Gutenberg middleware js: https://github.com/WordPress/gutenberg/blob/3b31957897302c9274afe259e59d1737098d6f8d/packages/api-fetch/src/middlewares/preloading.js

You can see this in action by searching the page source of the editor: the wp.apiFetch.createPreloadingMiddleware function takes an object with all of the preloaded API responses for loading data into the editor.

Bug

Because wpcom API paths are transformed to use public-api.wordpress.com, using our own api middleware, Gutenberg is not able to take advantage of preloading API requests when loading.

For example the /wp/v2/types?context=edit path is preloaded. But the API request for Simple Sites is https://public-api.wordpress.com/wp/v2/sites/{site_id}/types?_envelope=1&context=edit..., so Gutenberg's preloading middleware is not able to retrieve the response from the JS object printed out in the page source and makes a separate XHR request as the editor loads.

The impact of this is likely a slower time to load the editor (I haven't specifically measured, but strongly suspect making multiple async requests while loading takes longer than preloading the data).

Possible solutions

A couple routes that could solve this (may need both)

1. Add our own wpcom specific preloading middleware that looks for the public-api paths (similar to the api fetch middleware we already have)
2. Filter block_editor_preload_paths (note, changed to block_editor_rest_api_preload_paths in WP 5.8) to add public-api specific paths.