Chrome DevTools becomes extremely slow or crashes when .wasm is bundled with asset/inline in webpack #20613
-
|
My team compiles Rust to .wasm and bundles it with webpack. For years, Chrome DevTools were extremely slow and frequently crashed whenever our app was loaded with DevTools open. Debugging was basically impossible—stepping through code, inspecting state, even heavy console logging could freeze or crash the tab. The app itself ran fine as long as DevTools were closed. We knew it was wasm-related because the issue only happened when loading .wasm. The problem persisted for years; no one on the team managed identify the cause, and even reports to the Chromium team didn’t lead anywhere. Last week I happened to remove this line from our webpack config while working on something else: As soon as I did that, DevTools started working normally. No slowdowns, no crashes. It appears that inlining the wasm was somehow causing DevTools to become completely unusable. The size of the .wasm asset is ~55MB. Is this known behavior? I couldn’t find anything about it in the docs. Also, would this be considered a webpack issue, or something the Chromium team should investigate? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
|
Your should report it for |
Beta Was this translation helpful? Give feedback.
-
|
You’re likely running into a DevTools limitation rather than a webpack-specific issue. When When Chrome DevTools opens, it tries to parse and analyze the entire bundle for debugging, source mapping, and inspection. A very large inlined asset can make DevTools extremely slow or unstable because it has to process that huge encoded string. A better approach is usually to load WebAssembly as a separate asset instead of inlining it. For example: {
test: /\.wasm$/,
type: "asset/resource"
}or rely on webpack’s built-in WebAssembly support. This keeps the Given the size (~55MB), the behavior you're seeing is probably more related to DevTools performance limits, so reporting it to the Chromium team (as suggested above) would still be useful. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed answer. Perhaps adding a warning to the webpack docs, or emitting a warning if a big inline is detected, might still be useful to do from the webpack side, just to make it easier for the people to notice that this might be causing them trouble. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @enver-dedalus, Dependency resolution and plugin configuration in Webpack can get messy quickly. Checking if a recent loader version update (or Babel mismatch) caused a breaking change might be the fastest way to isolate the issue. Let us know if you find the root configuration bug! Let me know if you make any progress or if you need another fresh set of eyes on it! |
Beta Was this translation helpful? Give feedback.
You’re likely running into a DevTools limitation rather than a webpack-specific issue.
When
type: "asset/inline"is used, webpack embeds the.wasmfile directly into the JavaScript bundle as a base64 data URI. For a ~55MB WebAssembly file this can significantly increase the size of the generated script.When Chrome DevTools opens, it tries to parse and analyze the entire bundle for debugging, source mapping, and inspection. A very large inlined asset can make DevTools extremely slow or unstable because it has to process that huge encoded string.
A better approach is usually to load WebAssembly as a separate asset instead of inlining it. For example: