Search Issue Tracker


Fixed in 2022.2.3f1, 2023.1.0a19



Found in



Issue ID




WebGL build times have regressed



Many informal observations of the WebGL build time, in particular the final linker step now take longer than when we first moved to Emscripten 2 in Unity 2021.2

This is especially detrimental in our user's iteration time with development (debug) builds.

The change which likely caused this was the upgrade to Emscripten 3.1.8 in Unity 2022.2

Brendan found this issue, [], that concluded compiling with "-sERROR_ON_WASM_CHANGES_AFTER_LINK -sWASM_BIGINT -O1" took linking time from 180 seconds to a couple seconds.

We set the linker options in Platforms/WebGL/WebGLPlayerBuildProgram/WebGLPlayerBuildProgram.cs
in the function SetupPlayerExecutable()
in particular the -O optimization flag is set on line 170
.WithOptLevel(!PlayerBuildConfig.Development && WebGlConfig.optimizeForSize ? "s" : "3")
We need to evaluate the linker flags used, particularly in our development builds to achieve the fastest link time possible, even at the expense of WASM size.

We should make sure that the release (non-development) builds remain with the optimal flags.


-- For anyone finding this Issue June 2023 or later --

Some clarifying information:
* The primary speed up referred to in this ticket is related to Development builds. As an example an empty scene targeting WebGL development build in 2022.2.2f1 -> 437 seconds compared to same project built in 2022.2.8f1 -> 156 seconds 
* If you are iterating locally and want to test a build quickly, use development builds when you can.
* In newer builds of the Editor an option _Shorter Build Time_ was added and could be used for quick iteration with QA
* Runtime Speed or Disk Size release builds are still going to take significantly longer to build, the optimizations are for deployment or run time purposes. 
* Some slowness in recent versions is related to LLVM's LTO setting which provides additional optimization, however it comes at a time cost when building. For most situations using "Shorter Build Time" a viable release build.

If you see a significant increase in time taken while doing a _Development_ build or _Short Build Time_ optimization please let us know

When commenting on this ticket, please include additional data including versions being used, build options, and amount of time taken. Or please reach out on the forums.

  1. Resolution Note (fix version 2022.2.3f1):

    Verified the fix has landed to 2022.2.4f1 with Ubuntu 20.04

Comments (12)

  1. tantx

    Jul 05, 2023 05:28

    still problem in 2022.3.1.f1
    fake fixed...

  2. Evgeniy_Vysockiy

    Jun 29, 2023 09:22

    Reproduced in 2022.3.3f1 LTS

  3. Epiroc_RS

    Jun 12, 2023 06:47

    No resolved. Builds are completely broken in 2022.3.1f1.

  4. PinguinoSod

    Jun 11, 2023 10:56

    This problem is happening in version 2022.3.1f1 LTS

  5. BeorGames

    Jun 08, 2023 16:47

    I'm experiencing the same problem on version 2022.3.1f1 LTS. The build never passes Linking build.js, I left it more than 2 hours...

  6. richardNXRT

    Apr 05, 2023 07:47

    Not fixed. I am using 2022.2.6f1 the problem remains

  7. cnscoo

    Mar 30, 2023 06:09

    I upgrade my project from 2021.3.21f1c1 to 2022.2.12f1c1, the problem remains.
    10 minutes later, the wasm-Id.exe is occupied 3G memory space.
    Still waiting "Linking build.js".

  8. Arlorean

    Mar 15, 2023 13:27

    An empty 3D URP project for me took 393s (6m33s) on 2022.2.6f1 on Windows 11.
    Code Optimization set to "Shorter Build Time" and Development Build not checked.
    Is this to be expected with the fix or is there still a problem?

  9. Andrew-Park

    Mar 02, 2023 02:01

    We are suffering. :(

  10. UDN_98b912b3-c4ea-4f68-ad59-676fdd76a47e

    Feb 26, 2023 23:37

    I don't think this is fixed, or it has regressed in 2022.2.7f

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.