Asynchronously load TinyMCE (when possible) #29681
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This component allows us to wrap existing components and delay them until required 3rd party scripts and styles are asynchronously loaded. It also provides a hook for post-load setup that resolves before the children are rendered, guaranteeing that the children aren't active until the world around them is set up correctly.
Later on we'll be able to expand this pattern generically, but for now we'll keep it focused on TinyMCE.
Meta boxes _may_ depend on TinyMCE already being initialized. Because of this, we cannot utilize asynchronous TinyMCE when any "non backwards compat only" meta boxes are detected for the current post type.
We cannot delay loading TinyMCE in this case because when the editor first boots up it renders each block's `edit` component. Because this is expected to be synchronous, the classic block never gets a chance to finish rendering its content and you end up with just the placeholder block.
6 tasks
sarayourfriend
added
[Package] Block library
|
Size Change: +273 B (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 freeform 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.
The solution I'm exploring in this PR 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:
Otherwise, when the freeform 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
editis run. Indeed, in this case, if someone never uses the freeform 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 freeform 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:
WP_Scripts).Because we can get the URL for TinyMCE without using a REST API (partially it's already available in the
tinyMCEPreInitobject 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:
LazyLoadTinyMCEcomponent to wrap theFreeformEditcomponent.LazyLoadTinyMCEcomponent is basically a TinyMCE specific version of the the solution described in this PR.TinyMCE URLs
There is one caveat about using
tinyMCEPreInit.baseURLis 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']->depsand then follow a strategy similar toget_urlin the REST API PR to retrieve the URI for thewp-tinymcescripts and then add those to an array the frontend can use. Adding functionality likeget_urltoWP_Scriptsdirectly 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.phpenqueues 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_boxestakes care of processing meta boxes for a post. I think we can move this logic before the call towp_enqueue_editorinedit-form-blocks.phpwithout consequence and then look into theglobal $wp_meta_boxesin the action we'll add in Gutenberg to override TinyMCE script printing.When the freeform block is already used on a post
When a post is first loaded into the block editor, the
editfor each block gets run. This means that when a freeform 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_contentand decide whether we think the freeform block is being used. There already exists a functionhas_blocks, however it relies on the block's boundaries being renderedinto thepost_contentand unfortunately, the freeform 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 throughparse_blocksand then walk the block tree and see if acore/freeformblock exists.Summary of changes
To summarize, we need to make changes to WordPress core and Gutenberg.
LazyLoadTinyMCEonce the dependency is loaded.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 more general solution documented in #2768.
What this PR actually does
This PR adds a
LazyLoadTinyMCEcomponent that wraps the freeform block. This component delays the rendering of the freeform block's edit component until TinyMCE has been loaded.The PR depends on changes proposed in WordPress/wordpress-develop#232.
On a clean WordPress and Gutenberg install, this offsets approximately 272.274KB in transfer and 1,007.209KB parsed (that's over a MB in parse!) after TinyMCE itself and all the various plugins.
How has this been tested?
Using a WP installation running the changes in WordPress/wordpress-develop#232:
window.tinymceexists__back_compat_meta_boxin its args (using ACF for example) for a specific post type. Edit and create a new post of that post type and verify that TinyMCE is loaded on page load and not re-loaded when a classic block is added or edited.Types of changes
This is a new feature. The only user-facing change in behavior will be a delay between when a freeform block is "edited" and when it is actually "editable".
Checklist: