Abysmal response time when fetching pages to be listed in page attributes. 2nd try

[bobbingwide]

Describe the bug
The time to populate the Parent Page: pull down in the Page Attributes settings box is still abysmal.

I'm raising this since #5376 was closed without being fixed.
I re-discovered the problem while attempting to resolve a similar problem to that reported in #9441.

To Reproduce

1. Edit a hierarchical post type, such as Pages, in a site which has a lot of pages and where the pages contain multiple shortcodes which could take a long time to expand.
2. Measure the time taken to populate the Parent Page: pull down.
3. Tabulate the results and compare with the time to load the classic-editor.

Expected behavior
Page parent to be populated as quickly or faster than in the Classic Editor.

Observed behaviour
Multiple REST requests of the form
https://s.b/oikcom/wp-json/wp/v2/pages?per_page=100&exclude=7413&parent_exclude=7413&orderby=menu_order&order=asc&context=edit&_locale=user
with the second and subsequent requests including &page=n

• Each REST request took an absolute age to respond.
• Every single page was being expanded, and all the shortcodes were being expanded
• For both the_content and get_the_excerpt.
• When the elapsed execution time exceeded 120 seconds my local server terminated the request.
• Changing my code to not expand shortcodes reduced the elapsed time so that I did finally get to see the Parent Page: dropdown.

I notice that that requests do not include the _fields=id,title,parent parameter that was suggested would help with the performance.

When I add this parameter manually the performance is significantly better.

https://s.b/oikcom/wp-json/wp/v2/pages?per_page=100&exclude=7413&parent_exclude=7413&orderby=menu_order&order=asc&_locale=user&_fields=id,parent,title

Server execution reduced from 4.3 secs to 0.9
Note: Tested in browser with &context=edit removed.

Screenshots

If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows
• Browser: Chrome

Additional context

• WordPress 5.0.3 with / without Gutenberg 4.9

[youknowriad]

This is issue could be considered a duplicate of #7384 as we need a paginated select component to solve it. An quick win could be to increase the maximum number of items fetched per page to reduce the number of the requests being performed.

[bobbingwide]

An quick win could be to increase the maximum number of items fetched per page to reduce the number of the requests being performed.

That won't really reduce the amount of time wasted in the server. Each page will still be expanded to return the content and excerpt.

For my CPT called oik_file, with 511 posts, each request of 100 takes approximately 6 seconds.
Adding _fields=id,title,parent reduces the server time to 0.97

[youknowriad]

That's also a good thing to consider _fields but it's specific to this particular dropdown

[aduth]

I'm closing #15115 as a duplicate of this issue, which proposes the same in adding the _fields parameter. There's also #15114 which touches on related issues surrounding reuse of data amongst _fields-qualified requests.

[adamsilverstein]

Thanks for the _fields suggestion @bobbingwide - I added that to #16666 which should also resolve this issue, can you please give that a try?