As someone who uses the Unity WebGL export in production, it's a long way away from the point where you can simply build a game in Unity, deploy with WebGL, and

As someone who uses the Unity WebGL export in production, it's a long way away from the point where you can simply build a game in Unity, deploy with WebGL, and expect it to work reliably. It took us several months of optimizations, rebuilding assets, etc. to get it to a marginally viable state, and even then I wouldn't call it reliable. As it is it will usually work on maybe 50% of computers. More if the game is minimal (this is the case with most, if not all, of the online demos). A lot of this is due to patchy WebGL support and the fact that ASM.js's viability is mainly due to politics, not due to it being a good solution in practice. The computers it does work on, frequently you'll get an out of memory error, since you can't resize the memory arena in ASM.js (well, you sort of can but it makes the code much slower, and the resize operation frequently will crash the browser tab). You can mitigate this by requesting a larger memory arena, but in our testing, any size above 128MB fails to work on about 20% of machines. The parsing time for the ASM.js code is also so long that frequently browsers will ask if you want to kill the tab, because the page has been unresponsive... And when the browser is actually parsing the code, it will usually allocate over a gigabyte of memory. (Even firefox, which supposedly has a more optimized parser for ASM.js code). This is ignoring browsers like Safari, IE11, and Edge (not to mention mobile), which all have their own sets of problems. I don't really know where I'm going with this, other than to say that from the people I've talked to, this is pretty much the experience of everybody who has tried to ship anything nontrivial with Unity WebGL. I've heard that Unreal's HTML5 export is similar, but I've never used it so I can't confirm.