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.
El Unity profiler es soportado en WebGL, mirar aquí para ver cómo configurarlo.
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.
Usted podría querer ejecutar su contenido de WebGL en un frame rate menor en algunas situaciones para reducir el uso del CPU. Como en otras plataformas, usted puede utilizar la API Application.targetFrameRate para hacer esto.
Cuando no quiere acelerar el rendimiento, configure esta API al valor predeterminado de –1, en vez de un valor alto. Esto le permite al explorador ajustar el frame rate para la animación más suave en el render loop del explorador, y puede producir unos mejores resultados que Unity tratando de hacer su propio tiempo de bucle principal para que coincida con un frame rate objetivo.