Make the bundle smaller than 20M #2
Comments
|
The file extensions seen inside of the bundle are: |
adamziel
changed the title
|
Here's an idea I saw today in Golang's documentation about reducing the size of WASM files. https://github.com/golang/go/wiki/WebAssembly#reducing-the-size-of-wasm-files They recommend EDIT: Oops, never mind - this issue is about the file |
adamziel
changed the title
adamziel
changed the title
|
@eliot-akira I just played with brotli compression and the results are impressive:
https://caniuse.com/brotli says it's supported on most major browsers – it shouldn't be that hard to serve brotli-compressed version of this files by default and offer a gzip fallback for unsupported browsers. |
|
Cool! Glad the information about brotli turned out to be useful. Just saw PR #43, amazing. |
adamziel
changed the title
|
Brotli compress/decompress of php.wasm + wp.data php.wasm - 1.58 MB It loads fast enough now for you to even remove the Progress Bar. |
|
We're down to 3MB - 4MB for both php.wasm and wp.data! The actual bundles are about 15MB at the moment, but the webservers apply Brotli compression which dramatically reduces the amount of data transferred over the wire. Furthermore, #66 explores Brotli at JavaScript level to support non-webserver environments and more aggressive compression levels. I'm going to close this issue for now, feel free to reopen at any point if needed. |
Using `''` instead of `null` to prevent the following error:
```json
{
“type”:“deprecated”,
“message”:“http_build_query(): Passing null to parameter WordPress#2 ($numeric_prefix) of type string is deprecated”,“file”:“wp-content/mu-plugins/playground-includes/wp_http_fetch.php”,“line”:113,“stack”:[“http_build_query()“,”Wp_Http_Fetch_Base::format_get()“,”Wp_Http_Fetch_Base->request()“,”WpOrg\Requests\Requests::request()“,”WP_Http->request()“,”WP_Http->get()“,”wp_remote_get()“,”WP_Community_Events->get_events()“,”wp_ajax_get_community_events()“,”do_action(‘wp_ajax_get-community-events’)“],“component”:“MU Plugin: playground-includes”
}
```
Using `''` instead of `null` in Wp_Http_Fetch to prevent the following error:
```json
{
“type”:“deprecated”,
“message”:“http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated”,“file”:“wp-content/mu-plugins/playground-includes/wp_http_fetch.php”,“line”:113,“stack”:[“http_build_query()“,”Wp_Http_Fetch_Base::format_get()“,”Wp_Http_Fetch_Base->request()“,”WpOrg\Requests\Requests::request()“,”WP_Http->request()“,”WP_Http->get()“,”wp_remote_get()“,”WP_Community_Events->get_events()“,”wp_ajax_get_community_events()“,”do_action(‘wp_ajax_get-community-events’)“],“component”:“MU Plugin: playground-includes”
}
```
## What is this PR doing? Similar to #1357, but taking a deeper cut at it, as import expects to be run within an admin interface. ## What problem is it solving? The following fatal will be triggered: ``` PHP Fatal error: Uncaught Error: Call to undefined function wp_read_audio_metadata() in /wordpress/wp-admin/includes/image.php:2 Stack trace: #0 /wordpress/wp-content/plugins/WordPress-Importer-master/class-wxr-importer.php(1067): wp_generate_attachment_metadata(821, '/wordpress/wp-c...') #1 /wordpress/wp-content/plugins/WordPress-Importer-master/class-wxr-importer.php(861): WXR_Importer->process_attachment(Array, Array, 'https://raw.git...') #2 /wordpress/wp-content/plugins/WordPress-Importer-master/class-wxr-importer.php(383): WXR_Importer->process_post(Array, Array, Array, Array) #3 /internal/eval.php(20): WXR_Importer->import('/tmp/import.wxr') #4 {main} thrown in /wordpress/wp-admin/includes/image.php on line 2 ``` Fixes #1444 (Since found this issue) ## How is the problem addressed? Including includes/admin.php which pulls in all admin-related functionality, rather than just the cropping functionality. Alternatively, this could've been done by selectively importing `includes/media.php` as well as `includes/image.php`, but I anticipate that core is likely to include other related admin functions. ## Testing Instructions Note: This is an untested change. Try running https://playground.wordpress.net/builder/builder.html#{%22preferredVersions%22:{%22php%22:%228.0%22,%22wp%22:%22latest%22},%22phpExtensionBundles%22:[%22kitchen-sink%22],%22features%22:{%22networking%22:true},%22steps%22:[{%22step%22:%22login%22,%22username%22:%22admin%22,%22password%22:%22password%22},{%22step%22:%22importWxr%22,%22file%22:{%22resource%22:%22url%22,%22url%22:%22https://raw.githubusercontent.com/WordPress/theme-test-data/try/cors-accessible-images/themeunittestdata.wordpress.xml%22}}]}
The largest files to load for the initial paint are:
wp.data– 13M – the WordPress installation and all its php filesphp-web.wasm– 6.2M – the WebAssembly PHP buildwp.js– 182k – the emscripten-generated JS loader forwp.dataphp-web.js– 153k – the emscripten-generated JS loader forphp-web.wasmphp-webworker.js– 153k – same as above, but for the webworker backendLet's shrink them as much as possible.
Here's a few ideas:
.dataand.wasmfiles using brotli compression – props to @eliot-akira. Edit: Web servers take care of it and most browsers support the brotli compression!wp.datafrom 43M to 13M!.eot,.gif,.htaccess,.md,.mp4,.png,.scss,.stylelintignore,.svg,.ttf,.txt,.woff, and.woff2filesThe text was updated successfully, but these errors were encountered: