UnityWebGL-LoadingTest: measuring what a Unity web build actually costs

A measurement rig with seven hundred live builds

UnityWebGL-LoadingTest is described as Unity WebGL platform and version comparisons with a lot of nice extras, and its stated purpose is testing Unity's WebGL size and loading time for different versions, from 2018.4 to 6000.6, and different settings.

The scale of the archive is the point. The feature list says it tracks different Unity versions starting from 2018.4, with over 700 live demo builds for you to evaluate, and the README links an overview page of all builds at deml.io/experiments/unity-webgl. Those builds are hosted, so the comparison is not a table of numbers in a document, it is a set of pages you can open and load with your own browser on your own connection.

That is a real methodological difference. Build size is easy to state and easy to misread, since it depends on compression, on stripping, on which render pipeline and on how much of the engine the project touches. Loading time is harder still, because it depends on the network and the device. A hosted build per version and per configuration lets you measure the thing you actually care about on the hardware you actually have.

The audience is a Unity developer choosing a target platform or a version, and secondarily a studio trying to argue about a budget. The companion links point at an implementation in Godot, so the same experiment has been run in another engine, and there is a Unity forum thread about WebGL builds for mobile.

The licence is MIT, the last push was on 2026-09-08, and the release history shows 1.5.0 in January 2026, 1.4.0 in January 2025 and 1.3.0 in July 2024.

The size tables, and what they actually compare

The README is largely tables, and the tables are organised by render pipeline and target rather than by version alone. That organisation is the useful part, because the size difference between the pipelines dwarfs the difference between versions.

For the built-in render pipeline on WebGL2, the newest build, Unity 6000.6.0f1, is listed at 3.76 MB, and the numbers step down through 6000.5.11f1 at 3.66 MB, 6000.3.19f1 at 3.51 MB, 6000.2.15f1 at 3.40 MB, 6000.1.17f1 at 3.34 MB, 6000.0.74f1 at 3.38 MB, 2023.2.20f1 at 3.28 MB, 2023.1.20f1 at 3.20 MB, 2022.3.62f3 at 3.19 MB, 2022.2.18f1 at 3.11 MB, 2022.1.24f1 at 2.88 MB, down to 2021.3.45f2 at 2.84 MB. The spread across that entire range of Unity versions is under a megabyte.

The URP table is a different story. The same 6000.6.0f1 build is listed at 7.52 MB for URP on WebGL2, roughly double the built-in pipeline number, and the URP rows run from 5.58 MB to 8.79 MB depending on the version. The 6000.4.12f1 build is the outlier at 8.79 MB, while 6000.5.11f1 sits at 5.58 MB, which is a sharp drop from the 6000.4 build and then a rise again at 6000.6.

The WebGPU tables for the built-in pipeline run from 3.39 MB to 3.83 MB, and the URP WebGPU table from 5.54 MB to 8.60 MB. A separate minimum size table exists for both pipelines, with the built-in minimum sizes running from 2.64 MB to 3.29 MB and the URP minimum sizes from 4.48 MB to 6.76 MB.

Two observations follow. Pipeline choice moves the payload far more than version choice does, and the minimum size builds are dramatically smaller than the standard ones, which is a large enough gap to suggest that stripping and configuration matter more than the engine version. The tables also do not cover every version for every pipeline, so the missing rows are the versions the project was not tracking in that configuration.

A custom loading template, not a stock Unity page

The repository layout shows a normal Unity project, with Assets/, Packages/, ProjectSettings/, a Configuration/ directory, a Documentation/ directory and a webgl_sharing directory, which is where a custom WebGL template lives in a Unity project.

The template is the interesting engineering here, because the loading page is what a player sees while the engine boots. The feature list describes a responsive template layout for maximum mobile compatibility and smooth transition to the game after loading finished, and there is a toggle-able in-DOM debug console with Unity rich text styling support for the browser console and the debug console.

That in-DOM console is a small thing with real value. Unity's WebGL output is a large download, and once you have it running in a browser tab, the browser devtools console is a long way from the game's own state, and Unity's own logging in WebGL is not a rich console. A debug console rendered in the page, with Unity rich text styling, means you can read log output, call into Unity functions, and inspect times and memory consumption from the same place.

The README lists easy access to unity functions through the browser console, with a linked video, and handy debug functions for times and memory consumption. So the template is instrumented to report on its own loading, which is how it can function as a measurement rig and not just as a nicer loading screen.

The feature list also names Brotli compression and build targets for webgl1, webgl2 and webgpu with both BiRP and URP, and the project has a Godot counterpart, so the technique is not Unity-specific in principle.

CI that upgrades Unity versions and opens the pull request

The automation is described in two lines of the feature list, and it is the part that keeps the archive honest. Github Actions builds the project automatically and deploys it to the server via Game CI, and there is an action to upgrade a branch automatically to a new Unity version with automated builds and a pull request.

That second workflow is the one worth understanding. When a new Unity release lands, the action moves a branch to that version, rebuilds every configuration, and opens a pull request with the results. A reviewer then reads the size tables, sees what changed, and merges. The archive stays current because refreshing it is a single automated step rather than a manual afternoon.

It also explains the structure of the data. The tables are version rows and configuration columns, and the rows appear when a build for that combination has been produced. The versions with gaps, like 6000.4.12f1 appearing in the URP tables but not in the built-in ones, are gaps in what was built and tracked, not gaps in Unity's release history.

The documentation directory holds the images referenced in the README, including the debug console screenshot, the rich text support screenshot and the two build size charts, one for the built-in pipeline and one for URP. The charts are what most people will actually look at.

The last push was on 2026-09-08 and the release versions are 1.5.0 from 2026-01-07, 1.4.0 from 2025-01-27 and 1.3.0 from 2024-07-14, so the numbered releases are not where the per-version data lives. The data is in the hosted builds.

Using the rig, and where it stops

There is no installation step, and that is not a gap in the documentation. This is a Unity project that you open in the Unity editor, and the artifacts that people consume are the hosted builds, which you open in a browser. The repository's own overview page is the entry point, and the README is explicit that it is a testing project for size and loading time rather than a product.

What you can take from it is a method and a set of data points. The method is to fix a scene, fix the settings, vary one thing at a time across engine versions and render pipelines, and publish the result as a live page per combination so that anyone can reproduce the measurement on their own hardware. The built-in versus URP comparison, the WebGL2 versus WebGPU comparison and the standard versus minimum size comparison are three separate axes, and the tables let you pick a column rather than guess.

The limits are equally clear. The numbers describe one test scene, not your project, and a scene with a lot of art, audio or video will scale differently. The tables also stop at Unity 6000.6, so a version released after that is not in the archive. And where the URP tables skip a version that the built-in tables include, the missing row is missing data rather than a zero.

If you are not using Unity, the Godot implementation linked from the README is the equivalent experiment, and the approach transfers even though the numbers do not.

Editorial conclusion

Adopt UnityWebGL-LoadingTest if you are deciding which Unity version and which web target to ship, and you would rather compare live builds yourself than infer it from release notes. Do not adopt it as a production template without reading the loading page code, since it is built for measurement rather than for shipping, and do not expect it to cover non-Unity engines. Verify first that the version you are considering appears in the build tables for the render pipeline and target you care about, since the URP tables list fewer versions than the built-in pipeline ones, and check whether the project is still being rebuilt against your Unity version before you rely on the numbers.

Frequently asked questions

Official sources

1. JohannesDeml/UnityWebGL-LoadingTest on GitHub
2. License: MIT
3. Project website
4. README
5. Releases