[wp-trac] [WordPress Trac] #56815: [Performance][Multisite][Block Editor] Massive (potential) performance issues within get_default_block_editor_settings

[WordPress Trac]

#56815: [Performance][Multisite][Block Editor] Massive (potential) performance
issues within get_default_block_editor_settings
------------------------------------+-------------------------------------
 Reporter:  janthiel                |      Owner:  (none)
     Type:  defect (bug)            |     Status:  new
 Priority:  normal                  |  Milestone:  Awaiting Review
Component:  Editor                  |    Version:  trunk
 Severity:  major                   |   Keywords:  needs-patch 2nd-opinion
  Focuses:  multisite, performance  |
------------------------------------+-------------------------------------
 Hi there,

 we currently investigate some performance issues within the frontend of
 some larger sites.
 We figured out that there is a potentially bad design decision within the
 Block editor causing unnecessary slowdowns within the frontend.

 **The issue is as the following:**
 Take a single site within a multisite, quota enabled, with many media
 files and a large amount. We revisit the already optimized dirsize
 calculation here which currently is in the best possible shape WP core can
 deliver - imho.
 Now add a Theme with the block editor (theme.json present) and hit a state
 where the dirsize cache was cleared. After a media upload for example. Or
 delete the 'dirsize_cache' transient.
 Opening the Frontend(!) as a **non-loggedin** user now becomes super slow
 as the frontend request triggers the recursive dirsize calculation.

 Tracing the issue on trunk leads to the following call chain:

 {{{
 script-loader.php::_wp_theme_json_webfonts_handler
 WP_Theme_JSON_Resolver::get_merged_data()
 WP_Theme_JSON_Resolver::get_theme_data()
 block-editor.php::get_default_block_editor_settings
 media.php::wp_max_upload_size()
 #filter(upload_size_limit)#
 ms-functions.php::upload_size_limit_filter()
 ms-functions.php::get_upload_space_available()
 ms-function.php::get_space_used()
 }}}


 The latter then triggers the dirsize calculation and does real-time
 calculation in case the cache isn't there for whatever reasons. Which can
 take any arbitrary time blocking the frontent.

 This callstacks happens on each and every pageload. I do not see why the
 information about the max_upload_size is required within this context. An
 **unauthenticated** request does not need this information.
 Before this code was introduced all calls to dirsize / quota relevant
 features were limited to authenticated wp-admin requests or API requests
 leading to media upload or deletion. And I believe it should be this way.

 My suggestion would be to remove this piece of information from the
 default editor settings in {{{get_default_block_editor_settings()}}} as a
 quick fix and only add it to a context where the information is really
 required.

 But I would ask for some more pair of eyes on this who know the reasoning
 behind this code in the block editor in the first place.

 Thanks and best regards,

 Jan

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56815>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform