많은 요인에 따라 달라지기 때문에 답하기가 약간 어려운 질문입니다.
일반적으로 WebGL 그래픽스 API는 GPU를 하드웨어 가속 렌더링에 사용하므로 GPU 측의 네이티브 앱과 유사한 성능을 얻을 것이라고 보통 간주합니다. WebGL API 호출과 셰이더를 운영체제 그래픽스 API(Windows의 경우 DirectX, Mac이나 Linux의 경우 OpenGL)로 전환하는 약간의 부하만을 추가로 요구하기 때문입니다.
CPU 쪽에서는 모든 코드가 asm.js JavaScript로 변환됩니다. 따라서 기대할 수 있는 성능은 사용하는 웹 브라우저의 JavaScript 엔진에 크게 좌우되며, 현재 이 차이는 매우 큰 편입니다. 이 글을 작성한 시점(2015년 11월)을 기준으로, Microsoft Edge와 Mozilla Firefox가 Unity 코드에서 최고 성능을 제공합니다. 이들 브라우저만이 asm.js 스펙을 활용하여 해당 경우에 대한 JavaScript 코드의 최적화된 AOT 컴파일 경로를 사용하기 때문입니다. 이 경우 성능은 많은 프로그래밍 벤치마크에서 사용하는 네이티브 코드에 비해 2배 정도 향상되며, WebGL에 배포하고 Firefox나 Edge에서 실행한 여러 Unity 콘텐츠의 경우에서 실증된 바 있습니다.
하지만 고려해야 할 사항이 몇 가지 더 있습니다. 현재 JavaScript 언어는 멀티 스레딩이나 SIMD를 지원하지 않습니다. 따라서 이런 기능으로 이득을 얻는 코드는 다른 코드보다 속도가 더 느려집니다. 스크립트에서 WebGL에 스레딩 또는 SIMD 코드를 작성할 수 없지만, 일부 엔진 파트는 일반적으로 멀티 스레드되거나 SIMD 최적화되므로 WebGL에서 더 낮은 성능으로 실행됩니다. 예로는 멀티스레드 및 SIMD 최적화가 모두 가능한 스키닝 코드를 들 수 있습니다. Unity에서 새 타임라인 프로파일러를 사용해 Unity가 비WebGL 플랫폼에서 작업을 여러 스레드에 어떻게 배포하는지 확인할 수 있습니다. 장기적으로는 이런 기능을 WebGL에서도 사용할 수 있게 될 것으로 기대됩니다.
성능을 극대화하려면 빌드 플레이어 다이얼로그에서 최적화 레벨을 “가장 빠른”으로 설정하고 WebGL 플레이어 설정에서 “지원 제외”를 “없음”으로 설정합니다.
Unity 프로파일러는 WebGL에서 지원됩니다. 설정 방법은 여기를 참조하십시오.
WebGL 플레이어 설정에서 배경에서 실행 을 활성화하거나 Application.runInBackground 을 활성화하면 포커스가 캔버스 또는 브라우저 창에서 벗어나도 콘텐츠가 계속 실행됩니다.
하지만 브라우저는 배경 탭에서 실행 중인 콘텐츠의 속도를 줄일 수 있습니다. 콘텐츠가 있는 탭이 보이지 않으면 대부분의 브라우저에서는 콘텐츠가 1초에 한 번씩만 업데이트됩니다. 이로 인해 Time.maximumDeltaTime 의 기본값이 1초보다 작으므로 기본 설정을 사용하면 Time.time 이 일반적인 경우보다 더 느리게 진행됩니다.
경우에 따라 CPU 사용량을 줄이기 위해 WebGL 콘텐츠를 더 낮은 프레임 속도로 실행할 수 있습니다. 다른 플랫폼과 마찬가지로, Application.targetFrameRate API를 사용하여 이렇게 할 수 있습니다.
성능을 낮게 조절하고 싶지 않으면 API를 높은 값 대신 기본값인 –1로 설정해야 합니다. 그러면 프레임 속도가 브라우저 렌더 루프에서 가장 부드러운 애니메이션을 재생할 수 있도록 조정됩니다. 이렇게 하면 Unity가 목표 프레임 속도를 달성하기 위해 스스로 루프 타이밍을 찾는 것보다 더 나은 결과를 얻을 수도 있습니다.