[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:  reopened
 Priority:  high                    |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  major                   |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------

Comment (by adamsilverstein):

 Hey @sergiomdgomes thanks for the question, I appreciate you taking the
 time to share your concerns. I think Pascal and Weston mostly answered;
 I'll add a few things.

 * As Pascal mentioned VIPS does more than image conversion - it acts as a
 full replacement for the Imagick or GD libraries WordPress historically to
 process uploaded images. VIPS is an even more capable processing library
 that will let us not only improve on these older libraries, it enables
 more modern capabilities they don't provide (such as UltraHDR support).
 Plus: an [https://github.com/kleisauke/wasm-vips actively maintained wasm-
 vips implementation] reduces what we need to solve to implement this in
 WordPress. And we can keep it up to date, unlike the server dependencies.

 * The bundle size comparison isn't quite fair: JavaScript bytecode vs
 inlined WASM bytecodecode we are shipping: compiled from the original
 C/C++. Yes, the size is significant, but its also doing something far
 beyond a typical JavaScript library. Finally, as mentioned: only loaded on
 capable devices on sufficient networks which we define
 [https://github.com/WordPress/gutenberg/blob/421782ebb24606bd1c0671271171fa3035b9e890/packages
 /upload-media/src/feature-detection.ts#L31-L41 here]. We can fine tune
 these limits.

 * Regarding performance: this is a performance boosting feature - for the
 front end. JPEG encoding will improve 10-15% for most sites (MozJPEG like
 encoding), and 100% of WordPress sites will be able to generate AVIF's (vs
 ~30% now). In the future things like video poster generation, gif to movie
 conversion etc. are enabled by this infrastructure. Things we can't do at
 all today with our existing media libraries.

 * Regarding editor performance which is is probably what you meant: As you
 noticed we are somewhat careful about that: the library is lazy loaded
 when you use the image uploader. We only enable the feature if your CPU
 has 4 cores and your system at least >=2GB of memory. The library runs in
 a worker thread, effective preventing its operations from impacting the
 editor UI. We only enable the feature when the user's network is 4g or
 better (and not in reduced data mode) to account for the additional
 bandwidth to load the library and to upload each compressed image.

 * Regarding dynamically loading only the parts of VIPS we need, I
 generally support that idea in principle and will continue to investigate.
 For now the approach is to only load VIPS when the system has sufficient
 resources.

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