Editor: Preload initial Site Editor canvas data

[chubes4]

Summary

• Preloads Site Editor canvas data that can be predicted from the initial route/template.
• Derives referenced template parts from the resolved template block tree, only adds Query Loop post preloads when core/query is present, and covers deterministic static-front-page requests.
• Syncs the related Gutenberg preload change from Site Editor: preload initial canvas data gutenberg#78075.

Trac ticket

https://core.trac.wordpress.org/ticket/65206

Gutenberg PR

WordPress/gutenberg#78075

Testing

• php -l src/wp-admin/site-editor.php
• git diff --check
• Gutenberg CI passes on the source PR.
• Supporting Studio benchmark scenarios: Add Site Editor preload evidence scenarios chubes4/homeboy-rigs#108

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (openai/gpt-5.5)
• Used for: Drafting and validating the route-aware preload patch plus PR description; Chris reviewed the backport workflow and filed the Trac ticket.

[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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props extrachill, westonruter.

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

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[westonruter]

Related:

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

[westonruter]

I can see that this is successfully eliminating 4 client-side REST API requests:

Before	After

Is there an opportunity to preload more?

[chubes4]

I think there is a strong chance the answer is yes. I will run some more tests and see what I can do. Appreciate your feedback.

[chubes4]

Thanks for asking whether there was room to preload more. I did a focused sweep of the remaining visible REST requests using the Homeboy Site Editor benchmark rig and REST waterfall diff tooling.

What changed in the latest push:

• Added GET /wp/v2/types/post?context=edit when the resolved initial template contains a Query Loop.
• Added the edit-context page tree request: GET /wp/v2/pages?context=edit&per_page=100&_fields=id,link,menu_order,parent,title,type&orderby=menu_order&order=asc.

Validated scenarios, with the extra route set matching the actual patch behavior (types/post only for Query Loop templates):

Scenario	Baseline measured REST	Candidate measured REST	Baseline ready	Candidate ready	Delta
Default TT5	5	0	1439ms	883ms	-555ms / -38.6%
Static home page	6	0	2889ms	1008ms	-1881ms / -65.1%
Front-page template without Query Loop	5	0	1474ms	966ms	-508ms / -34.5%
Front-page template with Query Loop	5	0	1703ms	1156ms	-547ms / -32.1%

The earlier 3-iteration default run with both added routes also reduced the full REST waterfall from 34 requests / 19 unique to 20 requests / 12 unique while keeping the measured canvas phase at 0 REST resources. That run averaged 1209ms -> 894ms, a -316ms / -26.0% delta.

I tested other visible routes too, but did not add them:

• GET /wp-block-editor/v1/navigation-fallback?_embed=true removed its target request, but reintroduced measured resources and slowed readiness.
• GET /wp/v2/users/me?context=edit, GET /wp/v2/pages?context=view..., GET /wp/v2/menus?..., and GET /wp/v2/wp_pattern_category?... did not remove their target requests in this scenario.

Tooling used:

• Homeboy Site Editor preload comparison rig: Report Site Editor REST preload waterfalls chubes4/homeboy-rigs#113
• REST waterfall comparison/reporting helpers: wordpress: report REST network diffs Extra-Chill/homeboy-extensions#575

Validation run locally:

• php -l src/wp-admin/site-editor.php
• ./vendor/bin/phpcs -s --standard=phpcs.xml.dist src/wp-admin/site-editor.php
• ./vendor/bin/phpcs -s --standard=phpcompat.xml.dist src/wp-admin/site-editor.php
• homeboy lint --path /Users/chubes/Developer/wordpress-develop@fix-site-editor-preload-canvas-data --extension nodejs
• homeboy test ... got through build and QUnit (456 tests, 0 failures), then stopped at local PHPUnit setup because wp-tests-config.php is not configured.