#64734 closed defect (bug) (fixed)
WordPress ZIP size grew 20MB in 7.0 due to adding the vips library
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 7.0 | Priority: | high |
| Severity: | major | Version: | trunk |
| Component: | General | Keywords: | dev-feedback has-patch |
| Focuses: | Cc: |
Description
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
Change History (10)
#1
@
7 days ago
- Component changed from AI to General
- Keywords dev-feedback added
- Milestone changed from Awaiting Review to 7.0
- Priority changed from normal to high
#2
@
6 days ago
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
`
#3
@
6 days ago
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.
#4
@
6 days ago
I started work on this in https://github.com/WordPress/gutenberg/pull/75993
This ticket was mentioned in PR #11109 on WordPress/wordpress-develop by @adamsilverstein.
2 days ago
#5
- Keywords has-patch added
## Summary
- Skip
.mapsource map files incopyDirectory()— sourceMappingURL references are already stripped from JS files by the existingremoveSourceMapstransform, so the.mapfiles 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.jsand verify no.mapfiles 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)
#6
@
2 days ago
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?
#7
@
2 days ago
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.
@adamsilverstein commented on PR #11109:
41 hours ago
#8
This worked well in my testing, committing.
#9
@
30 hours ago
- Owner set to adamsilverstein
- Resolution set to fixed
- Status changed from new to closed
In 61794:
@westonruter commented on PR #11109:
24 hours ago
#10
Committed in r61794 (8db186734aeb5a72f1268b85f82ea772cde81bb2).
(Not sure why this PR wasn't closed automatically with the commit.)
Move into
generalcomponent.