-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delay loading TinyMCE until a classic block is edited #21738
Comments
I'm reluctant to add complexity to an already-difficult problem which has lost momentum many times in the past, but I have two observations where I think we may orient the effort to set us on the right foot without making incremental progress more difficult:
I guess it depends how much we consider this to be low-hanging fruit. TinyMCE is large and there's a lot of savings to be had by loading it asynchronously. On the other hand, I typically view low-hanging fruit as being "easy". To me, the work around loading TinyMCE is far from easy 😅 In general, I like the direction that #21684 is going so far as having a component which can simply receive a script handle and resolve/load it and all of its dependencies. I think the difference for me would be to optimize toward this being used by the framework, to pass a block type's registered |
Yes, it would be ideal to have a solution like this. It's already complex enough because it needs to account for the fact that such Have you considered extracting Classic block to its own npm package/WordPress module and make it exposed server-side? It would make it possible to remove the script or even unregister the block at all on pages that don't use Classic block. It might be a viable solution for many sites that don't need the legacy handling provided by the Classic block and it's quite fast to implement. |
Thanks for bringing that up. We could add getting the list of already loaded scripts and styles to the client along with the preloaded list of known dependency URIs (as part of the v0.2 I proposed in the PR: #21684 (comment)).
I had not considered that. I figure that it would indeed work as long as we coupled the work to prevent TinyMCE from being put into the page... but it would be a big workflow change for people who frequently use the classic block, no? |
I don’t think it’s something that WordPress core would enforce on users. It’s rather an option for site owners to opt out from the Classic block with one line of code or admin setting. Eventually Classic block could install on demand by becoming it’s own plugin that is featured in Block Directory that is planned for later this year. |
Okay y'all, I think I've come up with a new version of this plan. I've updated the issue description to reflect it (feel free to check out the earlier revisions for context and changes). I'm also linking this to a master thread about asyncing block dependencies generally: #2768 |
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:
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:
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:
LazyLoadTinyMCE
component to wrap theClassicEdit
component.LazyLoadTinyMCE
component is basically a TinyMCE specific version of the the solution described in this PR.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 toget_url
in the REST API PR to retrieve the URI for thewp-tinymce
scripts and then add those to an array the frontend can use. Adding functionality likeget_url
toWP_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 towp_enqueue_editor
inedit-form-blocks.php
without consequence and then look into theglobal $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 functionhas_blocks
, however it relies on the block's boundaries being renderedinto thepost_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 throughparse_blocks
and then walk the block tree and see if acore/freeform
block exists.Summary of changes
To summarize, we need to make changes to WordPress core and Gutenberg.
LazyLoadTinyMCE
once 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 project documented in #23098.
The text was updated successfully, but these errors were encountered: