Abysmal response time when fetching pages to be listed in page attributes

[bobbingwide]

Issue Overview

In my development machine the elapsed server time for invoking the classic-editor is around 2.5 seconds.

When using Gutenberg the elapsed server time to return the results for the Page Attributes
select list is 7.5 seconds.

And that's just one of the REST requests.

It needs to be a lot quicker.

Steps to Reproduce (for bugs)

1. Edit a hierarchical custom post type which has a custom taxonomy
2. Measure the elapsed server performance for each request
3. Tabulate the results and compare with the time to load the classic-editor

Expected Behavior

From the Core philosophies Clean lean and mean section

The core of WordPress will always provide a solid array of basic features.
It’s designed to be lean and fast, and will always stay that way.

Gutenberg should be as quick as or better than the classic-editor.

Current Behavior

It's not. It's far too sluggish.

Time to invoke classic editor. 2.5 secs
For Gutenberg, in a particular development environment I'm getting

Time (secs)	Request
3.2	Edit
2.0	Custom taxonomy query
2.0	Custom taxonomy list
2.4	Users
7.5	Page attributes
17.1	TOTAL

Possible Solution

Screenshots / Video

Related Issues and/or PRs

Todos

• Tests
• Documentation

[bordoni]

Just to make sure, are all of these Requests sequential? On my local environment they seem to fire at the same time when I load the page, and they are pretty fast (about 1.2seconds for Page Attributes).

Do you have any particular plugins active?

[bobbingwide]

In that particular environment I have quite a few plugins, none of which do anything which is REST related except perhaps some the_content filtering. The requests aren’t run in parallel if you keep the sidebar boxes closed initially. I admit my environment is slow.
I’m just using these figures to make a point.
The server load of the editor is much greater.
And this is before we take mega data (more than 100 items) into account.

[bobbingwide]

When using the classic-editor the total elapsed time for page_attributes_meta_box() is just over 0.14 seconds, the SQL query taking just 0.005 seconds.

The REST API is slow since:

1. The whole of WordPress has to be loaded.
2. the_content is being run for every published post that's not the post being edited or a child of it.
3. the_excerpt is also being run.

The fact that these filters are performed is complete nonsense, given that the request is only asking for the following fields: id, parent, title.

It would appear to me that a pre-requisite to delivering an editor that uses the REST API is to significantly improve the performance of the REST API so that it only populates the required fields.

[danielbachhuber]

It looks like a _fields= parameter landed in WordPress 4.9. However, WordPress still generates every field and then filters it out. Ideally, the fields wouldn't be generated in the first place.

@bobbingwide I suspect your particular problem is exacerbated by having so many shortcodes in your post content.

[bobbingwide]

@danielbachhuber Yes. Any shortcode expansion, other than for the title, is unnecessary. So is wpautop and, of course, dynamic block processing. Perhaps you like to try the same experiment with 40 or so pages each containing the Recent posts block.

When I convert my shortcodes to blocks I’ll still have the problem.

[lougreenwood]

Just wanted to say +1 for any REST API performance improvements - @bobbingwide, you mentioned that part of the reason for the problem is that the "whole of WP has to be loaded" - seems that issue is also being felt in the wild for some time: https://stackoverflow.com/questions/45421976/wordpress-rest-api-slow-response-time/45425091#45425091

Personally, we're about to launch a product which extensively uses WP as a REST-only application server and the UI is provided by an SPA, so I'm very encouraged to see WP REST API "dogfooding" happening :)

[danielbachhuber]

However, WordPress still generates every field and then filters it out. Ideally, the fields wouldn't be generated in the first place.

I've created a Trac ticket for this: https://core.trac.wordpress.org/ticket/43874

[danielbachhuber]

With https://core.trac.wordpress.org/changeset/43087, the performance of GET wp/v2/pages?_fields=id,title will significantly improve. You may see this as soon as WordPress 4.9.7. There are no additional changes we need to make in Gutenberg, however.

[bobbingwide]

I need to reopen this issue. I can't see the _fields parameter being used for the Page Attributes requests.