[wp-trac] [WordPress Trac] #64734: WordPress ZIP size grew 20MB in 7.0 due to adding the vips library

[WordPress Trac]

#64734: WordPress ZIP size grew 20MB in 7.0 due to adding the vips library
------------------------------------+------------------------------
 Reporter:  berislav.grgicak        |       Owner:  adamsilverstein
     Type:  defect (bug)            |      Status:  closed
 Priority:  high                    |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  major                   |  Resolution:  fixed
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------

Comment (by sergiomdgomes):

 Hey folks! 👋

 I came across `@wordpress/vips` recently when looking at bundles, and I'm
 pretty concerned with the size of this dependency, coming from a
 performance background.

 Now, I want to start off by saying that as far as I can tell, this is only
 ever loaded dynamically, and only ever gets loaded into a worker, both of
 which are good things! It means that it shouldn't affect the critical
 path, and it shouldn't affect the main thread while it loads and runs 👍

 That said, this is still an **incredibly large** amount of code to load
 and run. I'm looking at a project that uses the block editor, and
 `@wordpress/vips` accounts for 3.6MB of JavaScript, gzipped. That's over
 twice as much as all other `@wordpress` dependencies put together (1.6MB
 gzipped), and that latter number is including some large external
 transitive dependencies as well, like `moment-timezone`. It's simply far,
 far too much.

 Loading and running this much JS is likely going to be a problem on lower-
 end (and even mid-range) devices, which not only include things like
 mobile phones and tablets, but also some Chromebooks and other budget
 devices.

 Now, as far as I know, the feature set we're looking for here is mostly to
 convert between image types (e.g. PNG to WebP), to resize images, and to
 crop them. Would it be possible to use a more modular approach, instead of
 using a monolithic dependency like vips? Perhaps we could package up each
 encoder and decoder into its own module, and only load the ones we need?
 If the input is PNG and the output is WebP, then we only need the PNG
 decoder and the WebP encoder, not the encoders and decoders for every
 other format like TIFF, BMP and JPEG.

 [https://squoosh.app/ Squoosh] is an online image converter / optimiser /
 resizer that was developed by Google a few years ago, and as far as I can
 tell, [https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs it
 follows that approach]. As I use the app, I see that it only loads what's
 needed when it's needed, with encoders being pulled in as I choose
 different output formats. Given the similarities in the use-case, we
 should be able to do something similar, and the Squoosh codebase looks
 like a great starting point.

 The other possibility is to try to mitigate the monolithic approach
 somewhat, by using a custom build of vips that only includes the
 functionality we need. However, it's not clear to me how easy that would
 be, how much of a reduction that would lead to, and whether it would be
 enough.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64734#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform