Skip to content
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

Ability to trim track changes integration plugins #17637

Open
bendemboski opened this issue Dec 12, 2024 · 4 comments
Open

Ability to trim track changes integration plugins #17637

bendemboski opened this issue Dec 12, 2024 · 4 comments
Labels
package:track-changes type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@bendemboski
Copy link
Contributor

📝 Provide a description of the improvement

The track changes plugin requires a bunch of integration plugins to integrate with various editor features. They contribute about ~366kb total to my bundle size. A number of them are for features/plugins that I don't use, so it would be really nice to be able to trim those out of my bundle.


If you'd like to see this improvement implemented, add a 👍 reaction to this post.

@bendemboski bendemboski added the type:improvement This issue reports a possible enhancement of an existing feature. label Dec 12, 2024
@Witoso
Copy link
Member

Witoso commented Dec 13, 2024

Hey, thanks for the issue. Could you provide further details about what you mean:

requires a bunch of integration plugins to integrate with various editor features (...) features/plugins that I don't use.

@scofalik
Copy link
Contributor

scofalik commented Dec 13, 2024

I think that @bendemboski refers to the fact that TrackChanges plugin requires and imports all the integration plugins, even for these plugins that are not used by the editor. Unfortunately, given how the files are imported, you can't do anything about that without changes in CKE5 codebase.

I wonder what did you use to measure that the extra size is 366kb. As far as I see, the directory itself, not minified, takes 250kb. Maybe some of these integrations plugins also load something extra that is not needed? Or maybe this 366kb size you measured includes other things, that are necessary.

Regarding how the plugins are required/loaded. That was a decision we made when we introduced track changes feature, and it based on some architectural limitations we have regarding importing and loading plugins.

We needed to decide on two things:

  • whether the integration code should end up in track changes package or features packages,
  • whether we should force integrators to add each integration plugin to the config on their own.

We decided to go with "convenient" options, so we put integrations in track changes package and we decided to load them all by default, but unfortunately the drawback is that we load some extra code.

Other than the bundle size, there are some other smaller factors which make me believe that the integration code should be in features packages. However, I am afraid that the ROI here is minor, compared to other initiatives that we plan to take on. Unless, maybe there's one thing we could consider: put all integration plugins into one plugin TrackChangesIntegrations. Then the integrator could decide to conveniently use TrackChangesIntegrations or choose integrations by themselves to optimize bundle size (but also take this small maintaining effort).

We discussed this issue with @filipsobol and he will check whether there are no glaring errors in the integrations plugins that would cause them to import unnecessary code. Maybe he will find something.

@filipsobol
Copy link
Member

filipsobol commented Dec 13, 2024

The following numbers are uncompressed sizes generated by Vite. Other bundlers may produce different results

The following imports result in a bundle of about 700 KiB:

import { ClassicEditor, AutoLink, Autosave, Bold, CloudServices, Essentials, Italic, Link, Paragraph } from 'ckeditor5';

Adding the following imports increases the bundle size to 1.06 MiB:

import { TrackChanges, TrackChangesData } from 'ckeditor5-premium-features';

Out of these extra ~300 KiB:

  • ~200 KiB is from track changes
  • ~45 KiB is from socket.io
  • ~42 KiB is from date-fns
  • ~30 KiB is from protobufjs

If you are using the real-time features of CKEditor, these dependencies cannot be removed. However, if you are not using any real-time features, you can follow our Optimizing build size document.

Using the following imports, I was able to remove socket.io, date-fns, and protobufjs from the bundle and reduce the size to <900 KiB:

import { ClassicEditor } from '@ckeditor/ckeditor5-editor-classic/dist/index.js';
import { Link, AutoLink } from '@ckeditor/ckeditor5-link/dist/index.js';
import { Autosave } from '@ckeditor/ckeditor5-autosave/dist/index.js';
import { Bold, Italic } from '@ckeditor/ckeditor5-basic-styles/dist/index.js';
import { Essentials } from '@ckeditor/ckeditor5-essentials/dist/index.js';
import { Paragraph } from '@ckeditor/ckeditor5-paragraph/dist/index.js';
import { CloudServices } from '@ckeditor/ckeditor5-cloud-services/dist/index.js';
import { TrackChanges, TrackChangesData } from '@ckeditor/ckeditor5-track-changes/dist/index.js';

@bendemboski
Copy link
Contributor Author

I wonder what did you use to measure that the extra size is 366kb

I'm webpack-bundling and this is what bundle-stats reports. I guess webpack is inflating the sizes a bit, because it tells me that src/integrations/tableclipboard.js is 29.48kb while the published file is 25.1kb, and src/integrations/undo.js is reported as 2.92kb vs 2.74kb in the published file.

As far as I see, the directory itself, not minified, takes 250kb

This is probably before you run it through your code obfuscator? I guess the obfuscator is increasing the size significantly because looking at the published package, the .js files in @ckeditor/ckeditor5-track-changes/src/integrations have a total size of 327,426 bytes. But regardless of whether it's 366kb or 327kb or even 250kb, it's a significant contribution to bundle size!

put all integration plugins into one plugin TrackChangesIntegrations

I think this is a fantastic idea. The TrackChanges glue plugin could require it, so there's no additional configuration for the probably-most-common case where people just use that, and then folks like me could just include TrackChangesEditing and TrackChangesUI (ideally without the menubar integration!) and the specific integration plugins for the features that I use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:track-changes type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

No branches or pull requests

4 participants