Site Editor: preload initial canvas data

[chubes4]

What?

Preloads initial Site Editor canvas data that can be predicted server-side for the initial route/template:

• referenced template part records from the resolved initial template
• post collection requests only when the resolved template contains a Query Loop
• static front page record/template/type requests when show_on_front=page
• public taxonomies used by the Site Editor

Why?

The Site Editor currently preloads broad template collections, but the first canvas render can still issue several individual REST requests after boot.

In environments where each WordPress REST request has meaningful transport/bootstrap overhead, those missed preloads add visible latency before the editor canvas is ready.

This keeps the preload set route-aware instead of preloading every template-dependent resource unconditionally.

Fixes #78074.

How?

The preload logic derives likely template slugs from the standard WordPress template hierarchy:

• specific page route: page-{post_name}, page
• root Site Editor: front-page, static-front-page page templates, home, index

It then resolves pattern blocks and walks the selected template blocks to preload only template parts actually referenced by core/template-part. Query Loop post collection preloads are added only when the resolved block tree contains core/query.

For static front pages, the page record, page template lookup, and page type requests are also deterministic server-side, so those are preloaded for the root Site Editor route when show_on_front=page.

Testing Instructions

• Open the Site Editor.
• In browser devtools, inspect REST requests during the initial canvas load.
• Confirm route/template-derived requests are satisfied by preloaded data rather than new network requests.

Evidence

Supporting Homeboy-rigs benchmark scenarios: chubes4/homeboy-rigs#108

Scenario	Baseline	Candidate	Delta	REST waterfall
Default TT5 home	1223ms	988ms	-235ms / -19.2%	5 -> 0
Static front page	1876ms	874ms	-1002ms / -53.4%	4 -> 0
Custom front page without Query Loop	1219ms	904ms	-314ms / -25.8%	3 -> 0
Custom front page with Query Loop	1277ms	897ms	-380ms / -29.8%	4 -> 0

Additional local checks:

php -l lib/compat/wordpress-7.0/preload.php
git diff --check

Gutenberg CI passes, including PHP coding standards, PHP unit tests, Playwright, and performance tests.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (openai/gpt-5.5)
• Used for: Investigating missed preload routes, drafting the route-aware patch, running local validation/benchmarks, and preparing the PR description. Chris remains responsible for review and testing.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: chubes4 <extrachill@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[westonruter]

Related:

• Connectors: preload REST API responses on the Connectors screen #77353

[chubes4]

Updated this to make the preload set route/template-aware rather than broad/unconditional.

The implementation now derives likely template slugs from the standard template hierarchy, resolves pattern blocks, and only preloads template parts/query data when present in the resolved initial template. I also added static-front-page coverage for the page record, template lookup, and page type requests, since those are deterministic for show_on_front=page.

Supporting benchmark scenarios are in chubes4/homeboy-rigs#108.

[chubes4]

Pushed the same follow-up preload additions to the Gutenberg backport.

Backport commit: dd5ed07223

The detailed scenario matrix and route-by-route evidence are in the Core PR comment: WordPress/wordpress-develop#11766 (comment)

Local validation for the changed backport file, lib/compat/wordpress-7.0/preload.php:

• php -l lib/compat/wordpress-7.0/preload.php
• ./vendor/bin/phpcs -s --standard=phpcs.xml.dist lib/compat/wordpress-7.0/preload.php
• homeboy lint --path <gutenberg checkout> --extension nodejs --file lib/compat/wordpress-7.0/preload.php

[chubes4]

Follow-up from the remaining visible REST rows in DevTools: I dug into the preloading middleware keys and caller stacks to separate missing server declarations from client-side duplicate consumers.

The current preload patch should stay focused on deterministic initial canvas data. The remaining OPTIONS rows are not additional PHP preload paths missing from this PR:

• OPTIONS /wp/v2/settings?_locale=user is tracked in core-data: root site OPTIONS response is not reused for canUser permissions #78259. The root site entity schema loader fetches OPTIONS /wp/v2/settings, then a later canUser( ..., { kind: 'root', name: 'site' } ) permission check fetches the same endpoint again instead of reusing the first response's Allow header.
• OPTIONS /wp/v2/navigation?_locale=user is tracked in core-data: id-less entity resources can duplicate canUser OPTIONS requests #78260. useResourcePermissions() / canUser() can resolve the same id-less navigation collection permission with slightly different arg shapes, so the first request consumes the preload entry and the duplicate falls through to the network.

One important diagnostics detail: the visible DevTools URL can include _locale=user after apiFetch default middleware runs, but createPreloadingMiddleware() checks the pre-locale key first. For example, GET /wp/v2/taxonomies?context=view is the correct declaration even though DevTools may show /wp/v2/taxonomies?_locale=user&context=view.

So I think the right split is:

• Keep this PR on route/template-aware server preload declarations for predictable initial canvas data.
• Treat the two duplicate OPTIONS rows as core-data resolver/cache reuse bugs in core-data: root site OPTIONS response is not reused for canUser permissions #78259 and core-data: id-less entity resources can duplicate canUser OPTIONS requests #78260.
• Avoid broadening this PR to chase a zero-request waterfall when the remaining rows are duplicate client consumers rather than missing preload declarations.

The caller-attribution/probe evidence that led to those two issues is captured in this Homeboy run:

Run ID: 63df7a69-2f6f-4a39-9ee6-1fcf07bd449f
Artifact: /Users/chubes/Developer/_bench-evidence/homeboy-artifacts/63df7a69-2f6f-4a39-9ee6-1fcf07bd449f/8c48727c-0eac-4844-bc4b-c6fe2316c366-result-studio-site-editor-preload-comparison-17100-1778709161659-9azz7zw3074.json

[talldan]

It's odd that this function name was already wrong. 😄

Anyway, WordPress 7.0 is already in the late stages of release and its too late to add an enhancement like this. All of this new preloading code should be in the lib/compat/wordpress-7.1 folder instead (to indicate it's intended to be shipped in the 7.1 release).

There is a README here that explains a bit more - https://github.com/WordPress/gutenberg/blob/trunk/lib/README.md

[chubes4]

Moved to lib/compat/wordpress-7.1/preload.php, and moved the backport changelog entry to backport-changelog/7.1 as well. Thanks for the pointer!