The problem

TinyMCE is a huge dependency that is used rarely in the context of the block editor. Primarily it is used to support the classic block and some meta boxes. In total (TinyMCE core and plugins) it costs 272.274KB in compressed trasferred JS and 1,007.209KB parsed (that's over a MB in parse!). This is a big cost to pay for something that many users will never interact with.

A solution

The solution I'd like to explore is to offset loading TinyMCE as often as possible until it is needed. Given certain edge cases and exclusions, this would offset the cost of loading TinyMCE except in the following case, which are the minority of use cases:

1. We cannot do this when non-backwards compat meta boxes are installed as they may depend on TinyMCE (as in the case of Advanced Custom Fields, for example).
2. We cannot do this when a classic block is already being used on a post (for reasons described in this issue Automatically and transparently load block assets asynchronously #23098 in the "Problems with blocks already used on a post" section).

Otherwise, when the classic block has not already been added to a post or when custom meta boxes aren't installed, we can offset the TinyMCE dependency until the block's edit is run. Indeed, in this case, if someone never uses the classic block, they will not pay the penalty for having it.

There was an existing draft PR for asynchronously loading TinyMCE that built upon an existing PR in Gutenberg that introduced a REST API for retrieving a list of dependencies. This REST API isn't technically necessary for asynchronously loading TinyMCE for the classic block, it was included in the draft PR as a way of looking forward to enabling similar async behavior in other blocks.

However, the REST API itself presents some complexities and concerns:

1. REST calls to WP are expensive as all of WP needs to spin up, and in the current implementation it could require more than one call if someone ran with the experimental version.
2. While the REST API does return inline scripts, TinyMCE’s inline scripts are complex and varied (there are three, not all are "registered" in WP_Scripts).

Because we can get the URL for TinyMCE without using a REST API (partially it's already available in the tinyMCEPreInit object but this won't be sufficient as I describe below) I think we can shortcut getting a win against TinyMCE around the REST API.

To accomplish this async TinyMCE project, I propose the following:

1. Creat a LazyLoadTinyMCE component to wrap the ClassicEdit component.
   • This LazyLoadTinyMCE component is basically a TinyMCE specific version of the the solution described in this PR.
2. Cutting TinyMCE from the initial pageload of the block editor whenever possible.

TinyMCE URLs

There is one caveat about using tinyMCEPreInit.baseURL is that we need to decide which TinyMCE script to use as different scripts are used for different environments and compression settings. I’m not totally sure how to get this information to the frontend. One potential solution is to use $wp_scripts->registered['wp-tinymce']->deps and then follow a strategy similar to get_url in the REST API PR to retrieve the URI for the wp-tinymce scripts and then add those to an array the frontend can use. Adding functionality like get_url to WP_Scripts directly would be good for making the functionality available generally. It could alternatively be added as a utility function in Gutenberg's plugin, but in any case, it would need to be available outside the REST API.

Stopping WordPress from equeueing TinyMCE

Along with that, we also need to be enable Gutenberg to prevent core from enqueuing the TinyMCE scripts. To do that we ought to move the printing of the editor scripts into an action that can be overwritten by the plugin. This trac ticket proposes that change: https://core.trac.wordpress.org/ticket/49964

Edge cases/exclusions

Meta boxes

As stated above, there are some exceptions to when we can do this. Meta boxes present a backwards compatability issue as some of them depend directly on TinyMCE. Meta box development hasn’t stopped and widely used plugins like Advanced Custom Fields depend on them. Preserving the ability for meta boxes that depend on TinyMCE to continue to work is part of the work for v1. We’ll do this by disabling async TinyMCE when we detect that custom meta boxes are being used.

From what I understand at the moment edit-form-blocks.php enqueues the editor scripts before processing metabox data. Ideally we would like to have already run through processing meta boxes before we render scripts for the editor so that we have some basis for deciding whether meta boxes are really being used. register_and_do_post_meta_boxes takes care of processing meta boxes for a post. I think we can move this logic before the call to wp_enqueue_editor in edit-form-blocks.php without consequence and then look into the global $wp_meta_boxes in the action we'll add in Gutenberg to override TinyMCE script printing.

When the classic block is already used on a post

When a post is first loaded into the block editor, the edit for each block gets run. This means that when a classic block exists on a post, TinyMCE will be needed immediately on page load. Asynchronously loading TinyMCE here isn't possible because we need to render the block's contents into the editor. I think we should solve this by cutting this from the scope of the async TinyMCE project and instead solve it as part of the wider project to async all block dependencies whenever possible (if indeed it is a solvable problem).

We'll need to introspect into a posts post_content and decide whether we think the classic block is being used. There already exists a function has_blocks, however it relies on the block's boundaries being renderedinto the post_content and unfortunately, the classic block doesn't render block markup comments. So the only way I can think of right now to do it is to run the post through parse_blocks and then walk the block tree and see if a core/freeform block exists.

Summary of changes

To summarize, we need to make changes to WordPress core and Gutenberg.

• Core
  1. Devise a way to detect whether meta boxes that use TinyMCE are present that would be usable the Gutenberg plugin so that it can decide when to follow the default path of eagerly loading TinyMCE.
  2. Start injecting the TinyMCE dependency URIs into the frontend.
  3. Move printing editor scripts into an action overridable by the Gutenberg plugin so that we can prevent TinyMCE scripts from being injected when meta boxes are not present and when the classic block is not already being used for the post being edited.
• Gutenberg
  1. Create a version of the LazyLoad component that is able to load dependencies from URIs and that does not use the REST API.
  2. Prevent TinyMCE from being loaded by overriding the action we created in core. Also print translation initialization into a JS function to be executed by LazyLoadTinyMCE once the dependency is loaded.
  3. Wrap the classic block’s edit component with LazyLoadTinyMCE.

Completing the above will deliver a significant decrease in JavaScript download and parse times for most Gutenberg users.

Alternatives

We could move TinyMCE into the block directory, however then every post would pay the cost of the dependency, regardless of whether it was going to be used, so I don't think this is an adequate solution.

Alternatively, we could move it into the block directory and then have the block directory offset loading a block's dependencies until it is edited... but that's just the other project documented in #23098.