-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use WebAssembly.instantiateStreaming when available #1036
Use WebAssembly.instantiateStreaming when available #1036
Conversation
Here are timings from running the tests:
This is with the cache disabled, 30mbps down, 15mbps up, and 20ms latency: (my home internet is 100mbps down)
I'm a little suspicious of whether or not the If you'd like, I can commit the code that adds these timings (its wrapped in a boolean so it can be easily turned off). Without emulateNetworkConditions and without setting the cache to disabled:
|
I do think this change should be done (I even have a draft of this change somewhere), and I appreciate the thoughtfulness that went into this. However, I've been thinking that this should be done by instead just trying My thinking is that not serving WebAssembly with the right MIME type is really a bug on the server, albeit one with a graceful fallback, and is somewhat of an exceptional situation that shouldn't be catered to for performance. The default behavior should assume that everything is set up correctly for maximum speed. So the way I'd like to see this implemented is a) there is no configuration option to change behavior and b) |
This makes
esbuild.initialize
automatically useWebAssembly.instantiateStreaming
in supported browsers by default.For browsers that support
WebAssembly.instantiateStreaming
and if thewasmURL
is same-origin, it adds an additional (defaulttrue
) option,verifyWasmURL
which sends aHEAD
request to thewasmUrl
to check that theContent-Type
header isapplication/wasm
and that the response is ok. If not, it fallsback toWebAssembly.instantiate
and logs toconsole.info
. This makes it a backwards-compatible change, incase a developer's webserver is not configured to correctly send theapplication/wasm
header such as nginx or if thewasmUrl
is under a different origin (like a CDN).To do this, it inlines
wasmUrl
intoglobal.ESBUILD_WASM_URL
. Ifglobal.ESBUILD_WASM_URL
is truthy andWebAssembly.instantiateStreaming
is defined, it uses that instead.I have not manually tested this, but the browser test failed until I made it check forHEAD
requests to/esbuild.wasm
, which is a good sign. I had some build environment issues I think due to having a later version of Go installedI added tests that cover:
WebAssembly.instantiateStreaming
supportWebAssembly.instantiateStreaming
support,verifyWasmURL
falseWebAssembly.instantiateStreaming
support,verifyWasmURL
trueWebAssembly.instantiateStreaming
support,verifyWasmURL
true, return wrong content type. It should fallback toWebAssembly.instantiate