In general, the WebGL performance is close to native apps on the GPU, because the WebGL graphics API uses your GPU for hardware-accelerated rendering. The only exception is the slight overhead for translating WebGL API calls and shaders to your OS graphics API (typically DirectX on Windows, OpenGL on Mac, and Linux).
On the CPU, Emscripten translates your code into WebAssembly, the performance of which depends on the web browser you’re using. For more information, see the Unity blog post WebAssembly Load Times and Performance.
Following are the additional considerations that you must be aware of:
Tip: To see how Unity distributes work to different threads on non-WebGL platforms, see the new timeline Profiler in Unity.
To improve performance, set Exception support to None in the Player settings for WebGL by expanding Other Settings > Stack Trace.
WebGL supports the Unity profiler. See the Profiler documentation to learn how to set it up.
However, some browsers can throttle content running in background tabs. If the tab with your content isn’t visible, your content only updates once per second in most browsers. Note that this causes Time.time to progress slower than usual with the default settings, as the default value of Time.maximumDeltaTime is lower than one second.
You might want to run your WebGL content at a lower frame rate in some situations to reduce CPU usage. For example, on other platforms, you can use the Application.targetFrameRate API to do so.
When you don’t want to throttle performance, set this API to the default value of –1, rather than to a high value. This allows the browser to adjust the frame rate for the smoothest animation in the browser’s render loop, and might produce better results than Unity trying to do its own main loop timing to match a target frame rate.