Site Editor: preload template parts, query posts, and taxonomies used during initial canvas load

[chubes4]

What problem does this address?

The Site Editor still issues several REST requests during the initial editor canvas load that appear to be known up front and can be preloaded server-side. In a Studio/Playground-style local environment where each WordPress REST request is relatively expensive, these missed preloads add a stable ~500ms to the measured Site Editor load path.

This is not specific to Studio UI code. Studio amplifies the cost, but the missed requests are WordPress/Gutenberg Site Editor requests after site-editor.php has already rendered the preload payload.

Observed missed requests

On the measured Site Editor path, these requests were made after page boot and before the canvas reached the ready gate:

/wp-json/wp/v2/template-parts/twentytwentyfive//header?context=edit&_locale=user
/wp-json/wp/v2/template-parts/twentytwentyfive//footer?context=edit&_locale=user
/wp-json/wp/v2/posts?context=edit&offset=0&order=desc&orderby=date&per_page=10&ignore_sticky=false&_locale=user
/wp-json/wp/v2/posts?context=edit&offset=0&order=desc&orderby=date&per_page=3&ignore_sticky=false&_locale=user
/wp-json/wp/v2/taxonomies?context=view&_locale=user

The current preload list already includes template/template-part collection routes, settings, navigation, etc., but the collection preload does not satisfy the individual getEntityRecord lookups for template parts.

Evidence

A local A/B harness compared current Site Editor loading against a dynamic preload candidate that:

• preloads every get_block_templates( array(), 'wp_template_part' ) template-part ID individually
• preloads the observed query-loop post collection routes for per_page=10 and per_page=3
• preloads /wp/v2/taxonomies?context=view

Two-run local probe summary:

baseline avg: 1445ms
dynamic preload candidate avg: 941ms
delta: -504ms / -34.9%
baseline measured REST resources: 5
candidate measured REST resources: 0

Durable Homeboy-rigs workload smoke result after extracting this into a reusable benchmark:

baseline_site_editor_measure_ms: 1443
candidate_site_editor_measure_ms: 943
site_editor_preload_delta_ms: -500
site_editor_preload_delta_pct: -34.6
baseline_measure_resource_count: 5
candidate_measure_resource_count: 0

Harness PR: chubes4/homeboy-rigs#106

Related prior work

This looks like a follow-up to earlier Site Editor preload work, not a duplicate:

• Site Editor: preload settings requests #66488 preloaded Site Editor settings requests.
• Site editor: preload post if needed #66631 preloaded the directly edited post/page when needed.
• Site Editor: preload always required settings #61088 explored always-required Site Editor settings and was closed in favor of Site Editor: preload settings requests #66488 and Core Data: Add the 'getEntitiesConfig' resolver #65871.
• Core Data: Add the 'getEntitiesConfig' resolver #65871 addressed duplicate core-data entity config request behavior.

Notes

The preload cache should use the normalized REST path without _locale=user; apiFetch's locale middleware appends _locale=user after the preload middleware checks the original path.

The template part routes should be derived dynamically rather than hardcoding twentytwentyfive//header or twentytwentyfive//footer.

[Mamaduka]

The /wp-json/wp/v2/taxonomies?context=view&_locale=user seems reasonable.

The remaining request depends on a template, so if someone has a static "about me" page as their homepage, those preloaded resources will be wasted.

If/when the editor switches to new client-side routing, it might be easier to predict what data is needed and preload on the client.

cc @jsnajdr, @tyxla

[tyxla]

Preloading the taxonomies feels like it makes the most sense and safe to land regardless of what comes next.

On the template parts: my hunch is the hit rate is still pretty high there, since even a static "about me" homepage usually resolves through a template that pulls in the theme's header/footer. But that's worth poking at before we commit to it.

The query-loop posts are definitely the trickier bit. I wonder if there's a middle ground here: parsing the resolved template server-side and only preloading query routes when there's actually a core/query block in the tree. That way, the common "homepage shows posts" case still benefits, without wasting anything on templates that don't need it. Maybe it's worth exploring, but also possible that it's more trouble than it's worth.

[chubes4]

Updated #78075 to take this feedback into account. It now derives preloads from the initial route/template rather than broadly preloading template-dependent resources.

The speed gains seem worth pursuing. This makes the Site Editor feel much snappier in local Studio environments.