As all your Asset data must be pre-downloaded before your content starts, you should consider moving Assets out of your main data files and into AssetBundles. This lets you create a small loader Scene for your content which loads quickly and dynamically loads Assets on-demand as the user proceeds through your content. AssetBundles also help with Asset data memory management: You can unload Asset data from memory for Assets that you don’t need any more by calling AssetBundle.Unload.
The following considerations apply when using AssetBundles on the WebGL platform:
When you use class types in your AssetBundle which aren’t used in your main build, Unity may strip the code for those classes from the build. This can cause a fail when trying to load Assets from the AssetBundle. Use BuildPlayerOptions.assetBundleManifestPath to fix that, or see the section on [Distribution size and code stripping](webgl-distribution size-codestripping.md), below, for other options.
WebGL doesn’t support threading. As Http downloads become available only after they’re downloaded, Unity WebGL builds need to decompress AssetBundle data on the main thread after the download is complete, blocking the main thread. To avoid this interruption, LZMA AssetBundle compression isn’t available for AssetBundles on WebGL. AssetBundles are compressed using LZ4 instead, which is de-compressed efficiently on-demand. If you need smaller compression sizes than LZ4 delivers, you can configure your web server to use gzip or Brotli compression (on top of LZ4 compression) on your AssetBundles. See documentation on Deploying compressed builds for more information on how to do this.
WebGL supports AssetBundle caching with UnityWebRequestAssetBundle.GetAssetBundle. This method uses the IndexedDB API from your browser to store a cache on the user’s device. Some browsers might have limited support for IndexedDB and any browsers might request the user’s authorization to store data on the disk. For more information, see WebGL browser compatibility.