Esto es un poco complicado de responder ya que depende de muchos factores.
En general, usted puede asumir que usted obtendrá un rendimiento cerca a apps nativas en el lado del GPU, ya que el API de gráficos de WebGL utiliza su GPU para un renderizado acelerado de hardware - simplemente hay una sobre-carga para traducir los llamados de la API de WebGL y shaders al API gráfica de su OS (típicamente DirectX en Windows o OpenGL en Mac o Linux).
Para el lado del CPU, todo su código es traducido a asm.js JavaScript. Entonces el tipo de rendimiento que usted espera depende de mucho en el motor JavaScript del navegador utilizado, y hay muchas diferencia significativas ahí actualmente. En el punto de esta escritura (Noviembre de 2015), Microsoft Edge y Mozilla Firefox entregan el mejor rendimiento en código de Unity, ya que son los únicos navegadores que hacen uso del spec asm.js para utilizar una ruta de compilación AOT optimizada de código JavaScript para este caso, que entrega rendimiento dentro de un factor de menos de una disminución 2x comparada al código nativo para muchos benchmarks de programación - y ese factor también coincide con los resultados que hemos visto en diferentes contenidos de Unity desplegado a WebGL y corridos en Firefox y Edge.
Hay otras consideraciones sin embargo. Actualmente el lenguaje JavaScript no soporta multi-hilos, ni SIMBD. Entonces, cualquier código que se beneficie de estas características verá mayores retrasos que en otro código. Usted no puede escribir hilos o código SIMBD en WebGL en sus scripts, pero algunas partes del motor son normalmente ejecutadas en multi-hilos y optimizado-SIMBD. Usted puede utilizar la nueva linea de tiempo del profile en Unity y ver cómo Unity distribuye trabajo a diferentes hilos en plataformas no-WebGL. En un futuro no muy lejano, esperamos que estas características se vuelvan disponibles en WebGL también.
Para un mejor rendimiento, configure el nivel de optimización a “Fastest” en el dialogo de Build Player, y configure “Exception Support” a “None” en los player settings para WebGL.
Usted puede utilizar el Unity Profiler en WebGL, como cualquier otra plataforma. Una importante distinción es que usted no puede adjuntar a los reproductores corriendo en WebGL, aunque, Web GL utilice WebSockets para comunicación, lo cual no va a permitir conexiones entrantes por el lado del navegador. Más bien, usted necesita utilizar la casilla de verificación del “Autoconnect profiler” en los build settings. Tenga en cuenta que las draw calls no pueden ser profiled (perfiladas) actualmente para WebGL.
Si el Run in background está habilitada en los WebGL Player Settings, o si usted habilita Application.runInBackground, entonces su contenido va a continuar ejecutándose cuando el canvas o la ventana del navegador pierdan foco.
Sin embargo hay que señalar que los navegadores pueden estrangular contenido ejecutado en pestañas de fondo. Si la pestaña con su contenido no es visible, su contenido será actualizado una vez por segundo en la mayoría de los navegadores. Tenga en cuenta que esto va a causar Time.time que progrese más lento que lo usual con los ajustes predeterminados, ya que el valor predeterminado de Time.maximumDeltaTime es menor que un segundo.