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 Web 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, and see Distribution size and code stripping for other options.
The WebGL graphics API doesn’t support threading. As Http downloads become available only after they’re downloaded, Unity Web platform 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 Web. 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.
the Web platform does not support file-system based AssetBundle caching with UnityWebRequestAssetBundle.GetAssetBundle. Instead the WebRequest responses are cached by the browser, see Cache behavior in Web for details. This means that the entire AssetBundle file is held in memory when an AssetBundle is loaded, and care must be taken to promptly unload unused AssetBundles, especially when they are large.