Unity beschrieb am 20. September 2016 in einem technischen Überblick zur Speicherverwaltung in Unity WebGL, weshalb Browserprojekte anders kalkuliert werden müssen als Spiele für Konsolen. Auf einer Konsole ist die verfügbare Speichermenge bekannt. Im Web hängen die Grenzen dagegen vom Browser, vom Betriebssystem und von parallel geöffneten Seiten ab.
Der Unity Heap ist nur ein Teil des Speicherbedarfs
Unity zählt im Heap unter anderem Spielobjekte, Komponenten, Texturen und Shader. Zusätzlich belegen das Document Object Model, Asset-Daten und der kompilierte Code Speicher im Browserprozess. Asset Bundles, WebAudio und das virtuelle Memory File System kommen abhängig vom Ablauf hinzu. Beim Laden können weitere temporäre Bereiche für das Parsen und Kompilieren von asm.js entstehen, was vor allem auf 32-Bit-Browsern zu Problemen führt.
Die Heap-Größe wird vor dem Start festgelegt
Die Größe des Unity Heaps muss vorab reserviert werden und kann während der Laufzeit weder schrumpfen noch wachsen. Unity setzte den Standardwert in der damaligen Version auf 256 MB, während ein leeres Projekt laut dem Beitrag mit rund 16 MB auskommt. Für ein reales Projekt können 256 MB oder mehr nötig sein. Jede zusätzliche Anforderung schränkt jedoch die Zahl der Geräten ein, auf denen der Inhalt gestartet werden kann.
Asset Bundles begrenzen Lastspitzen
Die heruntergeladenen Unity-Daten liegen im Web ebenfalls im Speicher, weil kein normaler Dateizugriff auf einen lokalen Datenträger möglich ist. Asset Bundles helfen bei der Strukturierung, beseitigen Lastspitzen aber nicht automatisch. Ein sehr großes Bundle kann beim Download zusätzliche Puffer anlegen. Auch das Caching bleibt im virtuellen Dateisystem im Speicher erhalten. Unity empfahl deshalb, Datenmengen, Code und Heap gemeinsam zu messen und nicht nur die Downloadgröße zu betrachten.
Für die Optimierung nennt Unity unter anderem das Entfernen nicht benötigter Engine-Module, eine passende Kompression und den Einsatz des Memory Profilers. Der damalige Beitrag zu Unity 5.3 und WebGL beschreibt die parallel eingeführten Editorfunktionen. Für WebGL-Projekte bleibt die entscheidende Frage, wie viel Speicher der konkrete Inhalt beim Laden und während des Betriebs tatsächlich benötigt.