WordPress ZIP size grew 20MB in 7.0 due to adding the vips library

[berislav.grgicak]

The WordPress zip size increased to 54.7MB in 7.0 beta from 24.8MB in 6.9.

Most of the size increase comes from the vips library wp-includes/js/dist/script-modules/vips/.
The worker.min.js file contains an inlined wasm that is 10mb and the script-modules/vips directory also includes a worker.min.js.map which is also 10mb.
Similarly, there is both a worker.js and a worker.min.js.

We should minimize the ZIP size increase to reduce the installation time on hosts and in Playground.

Slack discussion: ​https://wordpress.slack.com/archives/C02RQBWTW/p1772083012240729

[mukesh27]

Move into general component.

[knutsp]

I don't know if related, but I am not able to manually update to latest, stuck on unpacking. I have tried with no active plugins, with and without debug mode, no errors logged. Background updates for nightlies do work. Manually reverting to 6.9.1 works fine.

This is a cPanel shared hosting with "unlimited" disk space and 4GB virtual memory available.

I always test beta releases, and have never seen this. So I wonder if this has to do with the new size. Still investigating the issue, though.

Redacted Site Health info:
`
### wp-core ###

version: 7.0-beta1-61729
site_language: nb_NO
user_language: nb_NO
timezone: Europe/Oslo
multisite: false
blog_public: 0
dotorg_communication: true

### wp-active-theme ###

name: Twenty Twenty-Five (twentytwentyfive)
version: 1.4

### wp-server ###

server_architecture: Linux 5.14.0-611.16.1.el9_7.x86_64 x86_64
httpd_software: LiteSpeed
php_version: 8.5.2 64bit
php_sapi: litespeed
max_input_variables: 10000
time_limit: 180
memory_limit: 2G
max_input_time: 600
upload_max_filesize: 64M
php_post_max_size: 64M
curl_version: 8.14.1 OpenSSL/3.5.1
suhosin: false
imagick_availability: true
opcode_cache: true
opcode_cache_memory_usage: 237910072 of 268435456
opcode_cache_interned_strings_usage: 100% of 8388608 (0 free)
opcode_cache_hit_rate: 94.66
opcode_cache_full: false

### wp-constants ###

WP_MEMORY_LIMIT: 512M
WP_MAX_MEMORY_LIMIT: 768M
WP_DEBUG: true
WP_DEBUG_DISPLAY: false

### wp-filesystem ###

wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable
fonts: writable
mu-plugins: writable
`

[adamsilverstein]

The increase should be closer to 4mb. Looks like we are including map files and un minified files we really do t need for these wasm binaries.

[adamsilverstein]

I started work on this in ​https://github.com/WordPress/gutenberg/pull/75993

## Summary

• Skip .map source map files in copyDirectory() — sourceMappingURL references are already stripped from JS files by the existing removeSourceMaps transform, so the .map files serve no purpose in Core
• Skip non-minified VIPS JS files — they are ~10MB of inlined WASM binary data with no debugging value over the minified versions
• Saves ~30MB total from the build output

## Test plan

• [ ] Run node tools/gutenberg/copy-gutenberg-build.js and verify no .map files are copied
• [ ] Verify VIPS directory only contains minified files (worker.min.js, loader.min.js, asset PHP files)
• [ ] Verify other script module packages still have their expected files
• [ ] Confirm overall build size reduction (~30MB savings)

[adamsilverstein]

this one on the Gutenberg side is still in discussion: ​https://github.com/WordPress/gutenberg/pull/75993

@berislavgrgicak I worked on a wp core solution (just on the WordPress side). Can you confirm this fixes the issue on your end? ​https://github.com/WordPress/wordpress-develop/pull/11109. It excludes the extra files as it brings over Gutenberg during the build.

I couldn't figure out how to build a test zip so i'm looking at the build folder. is there a grunt command i am missing?

[berislav.grgicak]

I'm not sure how we build the final relese ZIP, so I tested it by running npm run build and zip -9 -r wordpress.zip build/. The trunk build is 76MB, and the build for this PR is 63MB.

This worked well in my testing, committing.

[adamsilverstein]

In 61794:

General: VIPS library omit un-minimized and .map files.

Omit these files which offer little value since the VIPS library is primarily inlined WASM. Saves ~30MB total from the build output.

Props swissspidy, westonruter, adamsilverstein, berislav.grgicak, knutsp.
Fixes: #64734.

Committed in r61794 (8db186734aeb5a72f1268b85f82ea772cde81bb2).

(Not sure why this PR wasn't closed automatically with the commit.)

[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.

​Squoosh is an online image converter / optimiser / resizer that was developed by Google a few years ago, and as far as I can tell, ​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.

[westonruter]

Replying to sergiomdgomes:

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.

Just to note that there are checks to avoid client-side media processing on such devices ​in detectClientSideMediaSupport().

[ellatrix]

Reopening so we don't loose track of this discussion, and to make sure all alternatives are considered.

[swissspidy]

FWIW, yes, we did look at other solutions like Squoosh, but they're not nearly as comprehensive as Vips. And Squoosh specifically is unmaintained. This feature needs to support a ton of image formats and operations, not just simple PNG to WebP conversions.

Vips itself actually supports a modular approach with dynamic imports, but with the WordPress distribution limitations they end up in the same bundle anyway.

[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 ​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 ​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. We are trying to err on the side on caution here.

• 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.

[siliconforks]

The size issue seems to be getting worse again - after improving in beta3, it got worse in beta4 and again in beta5, so now it is almost as big as it was in beta2:

$ ls -al wordpress-6.9.4.tar.gz wordpress-7.0-beta*.tar.gz
... 27064862 ... wordpress-6.9.4.tar.gz
... 47011545 ... wordpress-7.0-beta1.tar.gz
... 47050444 ... wordpress-7.0-beta2.tar.gz
... 34171138 ... wordpress-7.0-beta3.tar.gz
... 37986708 ... wordpress-7.0-beta4.tar.gz
... 41814080 ... wordpress-7.0-beta5.tar.gz

[adamsilverstein]

Replying to siliconforks:

The size issue seems to be getting worse again - after improving in beta3, it got worse in beta4 and again in beta5, so now it is almost as big as it was in beta2:

Thanks for reporting. I'm not sure this is coming from vips.

Where are you getting these builds from so I know what to check?

[siliconforks]

These are just the ordinary downloads from wordpress.org.

​https://wordpress.org/download/releases/#betas (look for the section "Beta & RC releases")

The size increase is definitely coming from vips.

[siliconforks]

Looking at it in more detail:

$ du -sh wordpress-7.0-beta?/wordpress/wp-includes/js/dist/script-modules/vips/worker*js*
11M     wordpress-7.0-beta2/wordpress/wp-includes/js/dist/script-modules/vips/worker.js
11M     wordpress-7.0-beta2/wordpress/wp-includes/js/dist/script-modules/vips/worker.js.map
11M     wordpress-7.0-beta2/wordpress/wp-includes/js/dist/script-modules/vips/worker.min.js
11M     wordpress-7.0-beta2/wordpress/wp-includes/js/dist/script-modules/vips/worker.min.js.map
11M     wordpress-7.0-beta3/wordpress/wp-includes/js/dist/script-modules/vips/worker.min.js
11M     wordpress-7.0-beta4/wordpress/wp-includes/js/dist/script-modules/vips/worker.js
11M     wordpress-7.0-beta4/wordpress/wp-includes/js/dist/script-modules/vips/worker.min.js
17M     wordpress-7.0-beta5/wordpress/wp-includes/js/dist/script-modules/vips/worker.js
17M     wordpress-7.0-beta5/wordpress/wp-includes/js/dist/script-modules/vips/worker.min.js

In beta3, worker.js and the .map files were removed.

In beta4, worker.js came back.

In beta5, worker.js is still there, and also both it and worker.min.js grew from 11 megabytes to 17 megabytes for some reason.

It is also curious that worker.js seems to be the same size as worker.min.js. Shouldn't the .min.js version be much smaller?

[zieladam]

The latest stats:

Variant	Compressed (zip)	Uncompressed
6.9	27.6 MB	72.6 MB
7.0 beta 5	42.4 MB	118.8 MB

WordPress 7.0 Beta 5 is about 15MB larger than 6.9.

The vips library

~10MB can be explained by the vips library. Without the wp-includes/js/dist/script-modules/vips/ directory, the zip is 32M. However, if I remove just the worker.min.js file and zip again, the archive is 37MB. We've just saved 5MB!

I suggest deleting worker.min.js and always using worker.js. They're approximately the same size and the benefit of keeping both seems negligible versus making every Playground user download an additional 5MB.

I also wonder – what kind of size reduction could we get with a custom build procedure for the WASM module? One that would remove all the code paths WordPress doesn't rely on?

The rest of it

The remaining ~5MB out of that 15MB increase seems to come from a long tail of other changes:

File	6.9	7.0	Change
js/dist/components.js	2.4 MB	3.8 MB	+1.4 MB
js/dist/editor.js + .min.js	1.5 MB	3.5 MB	+2.0 MB
js/dist/block-editor.js + .min.js	3.1 MB	3.8 MB	+0.6 MB
js/dist/block-library.js + .min.js	3.2 MB	3.7 MB	+0.5 MB
js/dist/media-utils.js + .min.js	33 KB	874 KB	+841 KB
css/dist/block-library/ (per-block CSS split)	880 KB	4.0 MB	+3.1 MB
css/dist/editor/	256 KB	640 KB	+384 KB
build/routes/ (new admin routing)	—	5.5 MB	+5.5 MB
icons/library/ (332 icon files)	—	1.3 MB	+1.3 MB
php-ai-client/	—	956 KB	+956 KB
New JS packages (sync, theme, upload-media, etc.)	—	~820 KB	+820 KB
66 new .min.asset.php dependency manifests	—	264 KB	+264 KB
codemirror/espree.min.js	—	247 KB	+247 KB
build/pages/	—	140 KB	+140 KB
ai-client/, collaboration/	—	80 KB	+80 KB

I don't see an easy solution to that ¯\_(ツ)_/¯

[adamsilverstein]

Thanks for the feedback @zieladam and @siliconforks - let me take another pass at this. We certainly don't need both the regular and minified worker. I'll look at introducing a custom build to exclude parts we aren't using. Also, not clear why we regressed in beta 4.

[adamsilverstein]

Regarding size, I started these PRs:

​https://github.com/WordPress/wordpress-develop/pull/11281
and
​https://github.com/WordPress/gutenberg/pull/76615/

I'm also working separately on removing unused parts to further reduce the size.

[ellatrix]

@youknowriad There seems to be duplicated CSS in /wp-includes/css/dist/block-library/ for each block separately, this seems like an issue with the new build script?

I believe another large part comes from the new Global Styles UI packages, which is bundled in a lot of other packages instead of exported to a wp global: ​https://github.com/WordPress/gutenberg/pull/72599. @youknowriad any reason we can't make those private APIs?

And I'm guessing build/routes/ has a similar situation with no scripts reused.

Cc @mcsf regarding the icons, I guess there's nothing to be done but wanted to double check if the 332 public icons is correct.

Here's what Claude found for me:

Item	Size increase	Notes
build/routes/ (new)	+5,500 KB	New admin pages — 6 list routes ~800KB each (unmin+min)
css/dist/block-library/<name>/ (new)	+3,000 KB	Unused duplicate of per-block CSS already in blocks/
editor.js + .min.js	+2,010 KB	global-styles-ui/engine bundled in (no wpScript) + collaborators, style-book, revisions
script-modules (new, 6 packages)	+1,776 KB	latex-to-mathml, abilities, route, workflow, boot, lazy-editor (unmin+min)
components.js + .min.js	+1,473 KB	Unminified grew +1,475KB due to webpack→esbuild switch; .min.js unchanged (-2KB)
icons/library/ (new)	+1,300 KB	332 SVG icon files, new directory
php-ai-client/ (new)	+956 KB	AI client PHP library
media-utils.js + .min.js	+840 KB	New media upload modal + media-fields bundled in
block-editor.js + .min.js	+642 KB	global-styles-engine + dataviews bundled in (no wpScript)
block-library.js + .min.js	+546 KB	New/changed blocks
sync.js + .min.js (new)	+468 KB	Real-time collaboration
css/dist/editor/	+384 KB	Styles for global styles sidebar, collaborators, etc.
66 .min.asset.php (new)	+264 KB	Dependency manifests — didn't exist in 6.9
codemirror/espree.min.js (new)	+248 KB	JS parser for CodeMirror
theme.js + .min.js (new)	+188 KB	Design tokens package

[adamsilverstein]

For client side media size, I added this PR to remove JXL code since we don't support the format yet anyway: ​https://github.com/WordPress/gutenberg/pull/76639 saving another ~18%

I'm separately working on a PR to try a custom build to further slim the package.

[desrosj]

There have been a few changes in the last 24 hours that would have affected the package size:

• [62069] removed a bunch of stray directories and files that were no longer supposed to be included (see ticket:64393#comment:177)
• The most recent pinned hash bump pulled in upstream improvements from the gutenberg repository.

I've gone and performed a new comparison of the built files. Below is a chart comparing file sizes between the ​latest commit on the build server as of writing this comment with the result of running build in the 6.9 branch of wordpress-develop today. The threshold to appear in the list is a difference of at least 100KB.

File	Latest Build Server Commit	Fresh build from the 6.9 branch	Difference (+ added, - removed)
build/wp-includes/js/dist/script-modules/vips/worker.min.js	13.1M	0B	+13.1M
build/wp-includes/js/dist/components.js	3.8M	2.3M	+1.4M
build/wp-includes/js/dist/editor.js	2.4M	1.0M	+1.3M
build/wp-includes/build/routes/template-list/content.js	664.7K	0B	+664.7K
build/wp-includes/js/dist/media-utils.js	637.1K	23.3K	+613.7K
build/wp-includes/js/dist/editor.min.js	1016.6K	409.7K	+606.8K
build/wp-includes/build/routes/template-part-list/content.js	596.4K	0B	+596.4K
build/wp-includes/build/routes/pattern-list/content.js	589.2K	0B	+589.2K
build/wp-includes/build/routes/post-list/content.js	583.1K	0B	+583.1K
build/wp-includes/build/routes/navigation-list/content.js	570.9K	0B	+570.9K
build/wp-includes/build/routes/font-list/content.js	561.6K	0B	+561.6K
build/wp-includes/js/dist/block-editor.js	2.6M	2.2M	+483.1K
build/wp-includes/js/dist/block-library.js	2.5M	2.1M	+382.1K
build/wp-includes/js/dist/script-modules/latex-to-mathml/index.js	365.0K	0B	+365.0K
build/wp-includes/js/dist/sync.js	356.4K	0B	+356.4K
build/wp-includes/js/dist/script-modules/abilities/index.js	281.6K	0B	+281.6K
build/wp-includes/build/routes/template-list/content.min.js	272.9K	0B	+272.9K
build/wp-includes/build/routes/font-list/content.min.js	267.2K	0B	+267.2K
build/wp-includes/js/codemirror/espree.min.js	248.1K	0B	+248.1K
build/wp-includes/build/routes/template-part-list/content.min.js	240.5K	0B	+240.5K
build/wp-includes/build/routes/post-list/content.min.js	235.0K	0B	+235.0K
build/wp-includes/build/routes/pattern-list/content.min.js	232.1K	0B	+232.1K
build/wp-includes/js/dist/media-utils.min.js	237.6K	9.7K	+227.8K
build/wp-includes/build/routes/navigation-list/content.min.js	223.7K	0B	+223.7K
build/wp-includes/js/dist/script-modules/latex-to-mathml/index.min.js	197.9K	0B	+197.9K
build/wp-includes/js/dist/script-modules/route/index.js	177.3K	0B	+177.3K
build/wp-includes/js/dist/block-editor.min.js	1.0M	871.3K	+159.0K
build/wp-includes/js/dist/block-library.min.js	1.0M	959.9K	+155.6K
build/wp-includes/js/dist/script-modules/abilities/index.min.js	137.4K	0B	+137.4K
build/wp-includes/js/dist/script-modules/workflow/index.js	136.6K	0B	+136.6K
build/wp-includes/js/dist/theme.js	127.6K	0B	+127.6K
build/wp-includes/js/dist/sync.min.js	117.0K	0B	+117.0K
build/wp-includes/js/dist/script-modules/boot/index.js	111.4K	0B	+111.4K
build/wp-includes/css/dist/editor/style.css	173.3K	64.1K	+109.2K
build/wp-includes/css/dist/editor/style-rtl.css	173.2K	64.1K	+109.1K
build/wp-includes/build/routes/connectors-home/content.js	103.6K	0B	+103.6K
build/wp-content/themes/twentytwentyone/assets/css/ie.css	45B	133.3K	-133.2K
build/wp-includes/js/dist/latex-to-mathml.min.js	0B	192.0K	-192.0K
build/wp-includes/js/dist/latex-to-mathml.js	0B	444.7K	-444.7K
build/wp-includes/js/dist/date.js	176.3K	790.8K	-614.5K
build/wp-includes/js/dist/date.min.js	141.1K	765.3K	-624.1K

In total, this accounts for a net +23.9MB increase in package size.

The nightly was rebuilt after [62069] and is clocking in at 60MB.

60MB (latest nightly) - 24.8 (6.9.4 size) = 35.2MB increase. The table above is only accounting for ~24MB, so roughly 11MB is still unaccounted for.

[adamsilverstein]

I investigated removing client side media from core in a PR, here is the removing feature savings analysis: ​https://github.com/WordPress/wordpress-develop/pull/11309#issuecomment-4093581793

VIPS accounts for around 13MB of the new weight, or 4MB compressed.

Our entire zip with VIPS/client-side media included is 61 MB uncompressed.

I checked the latest Drupal and it is 156.3MB uncompressed (35.9MB compressed).

I realize we don't want to ship duplicate code, or code that doesn't add enough value, but - I'm not convinced we should be so concerned about our package size when adding incredible new capabilities like client-side media! We are shipping an entire media processing library compressed into a WASM binary directly to WordPress users! This is a major new component and I feel some weight should be expected her.

I'm not clear what the concern is about over the package size (besides the "worth the value" equation).

[adamsilverstein]

Here is Claude's analysis of the size changes: ​https://github.com/WordPress/wordpress-develop/pull/11309#issuecomment-4095229993

[Presskopp]

related #60674

[desrosj]

I just wanted to provide an update on what I've found over the last ~24 hours. I've been digging into what files were added, moved, or deleted during the 7.0 cycle, and there were several files being included that were either unnecessary or left in place simply due to an undiscovered technical nuance.

• In [62051]/#64716, the grunt clean task was updated to ensure all new/moved files after the build script changes were accounted for. This did not directly affect the package size, but it ensures that contributors have a way to ensure a pristine working environment locally.
• In [62069], a change was made to the sequence of tasks for the build scripts to guarantee that grunt clean -- --dev would always run before building. This addresses an issue described in ticket:64393#comment:177 where files previously subject to version control were still present on the build server and were included in the built packages because their parent directory was added to the svn:ignore property before the files were explicitly removed. ​Result: 28 files removed and a net change of just under -69KB.
• After [62072]/#64909, two files were identified that were intended to be minified but actually were not. Since the files would have had no differences, the unminified version was chosen to remain because it is human-readable. ​Result: a net change of -58KB.
• In [62073], the *.min.asset.php files that were being copied to the wp-includes/js/dist directory were identified as being unnecessary and were removed. ​Result: 67 files deleted and a net change of 14KB
• In [62079], the build script was configured to stop including files associated with inactive and experimental routes. ​Result: 66 files removed and a net change of -4.46MB.

I am still working through the list of files changed since 6.9.4 to confirm which ones belong and which ones do not. After the above changes and the removal of client-side media, ​here is the list with all of the icon library SVG assets and php-ai-client related files removed (linking out to a Gist because Trac is truncating the full list).

Note: this list of files added does not account for files that were moved, intentionally or not.

[mukesh27]

The Nightly build (​https://wordpress.org/download/beta-nightly/) includes all bundled themes, whereas the release version (​https://wordpress.org/latest.zip) only includes the three latest default themes.

We should take this into account when comparing the zip size between the Nightly and release versions.

[desrosj]

Circling back to report on the size of the 7.0-beta6 package. With all the related changes, it's clocking in at 31.6MB.

I'm going to leave this ticket open for now to continue monitoring the package size leading up to the final release.

[desrosj]

I have another update here. After [62103], an ​additional 661 files have been removed from the package that were being included twice resulting in a net -944KB difference.

The size of the RC1 package is 29.8MB.

[desrosj]

Given that an entire new external library was introduced during the 7.0 release cycle (PHP AI SDK) along with the usual additions that come with new features, I am going to suggest we close this out.

This is a roughly 20% increase in package size, but I don't know that we'll get this to be any smaller given what has been added to the release. Does anyone feel strongly against closing this?

[desrosj]

Closing since there were no objections.