Large navigation menus load slowly and exhaust server resources

[dretzlaff]

Description

Our website has a menu with several submenus linking 30-40 pages in all. Loading the full site editor triggers API requests for ALL the pages. This is quite slow and results in multiple HTTP 508 Resource Limit Is Reached. Requests are CPU-limited on the server and our shared hosting environment limits pending requests to 20. This is ample server resources for everything we need except loading the site editor.

The cause seems to be this feature which decorates items if they point at invalid pages. Each page in the menu gets loaded.
https://github.com/WordPress/gutenberg/pull/31716/files

The HTTP 508 responses typically come from page requests with this stack trace:
useSelect @ data.js
useIsInvalidLink @ block-library.js
NavigationLinkEdit @ block-library.js

I would suggest that loading each page in a menu doesn't scale well. I don't know enough to suggest a path forward, but batching requests or at least limiting their concurrency would solve this.

Step-by-step reproduction instructions

1. Create a template containing a menu with multiple page links
2. Open the template in the full site editor.
3. Note network requests to each referenced page, e.g. wp-json/wp/v2/pages/##?context=edit&_locale=user

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 6.0.1
Chrome 103.0.5060.134
Windows 10.0.19043 Build 19043
Theme twentytwentytwo Version 1.2
Server Linux 3.10.0-962.3.2.lve1.5.38.el7.x86_64 x86_64
Web server Apache
PHP 7.4.30

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[talldan]

Just noticed this issue. I couldn't get the feature introduced by #31716 working anyway. It only seems to partially work. It probably needs a bit of a revamp.

This is an interesting engineering problem though. The link blocks are independent of one another and each making requests, so it would be difficult to orchestrate the requests.

It seems like if your concurrent requests are limited to 20 then there might be a few parts of the block editor that can cause issues. 😬

I wonder if you could introduce some of your own middleware to API Fetch (the request library used by gutenberg) to limit concurrent requests and smooth things out on your server. This is where the code is if you're interested in exporing that:
https://github.com/WordPress/gutenberg/tree/trunk/packages/api-fetch

[dretzlaff]

I like the idea of a middleware that limits concurrent requests using a queue of promises. I've implemented that in backend systems to good effect. Learning the frontend/npm world would be an investment for me, but I might look at it in a month or two. My workaround for now is to use mod_rewrite on the server to identify these page requests and return a static JSON response. Thanks, talldan. (-shortdan? :)

[jordesign]

@dretzlaff - Just looping back to this older report to see if you still see performance issues when testing larger menus?

[dretzlaff]

Hi! The site editor still makes a request for each page in the menu. On our shared Nixihost server, each request takes about 10 seconds and they're coming back in batches of 10, e.g. first 10 responses after 10s, 10 more requests finish after 20s, the last 10 requests finish after 30s. It feels slow.

The requests have URLs like this, one for each page:
https://SERVER/REST_URL_PREFIX/wp/v2/pages/88?context=edit&_locale=user

That said, Nixihost recently changed from Apache to Litespeed and probably along with that, no longer returns HTTP 508 after 20 requests are pending. So even though it's slow, at least it's not generating errors. As such, and given the learning curve for me to contribute correctly to WordPress, I won't be developing an improvement myself.