일반적으로 WebGL 그래픽스 API는 GPU를 하드웨어 가속 렌더링에 사용하므로 GPU 측의 네이티브 앱과 유사한 성능을 얻습니다. WebGL API 호출과 셰이더를 운영체제 그래픽스 API(Windows의 DirectX, Mac이나 Linux의 경우 OpenGL)로 전환하는 약간의 부하만을 추가로 요구하기 때문입니다.
CPU에서 Emscripten은 코드를 WebAssembly로 변환하므로 해당 성능은 사용 중인 웹 브라우저에 기반합니다. 자세한 내용은 WebAssembly 로드 시간 및 성능에 대한 Unity 블로그 포스트를 참조하십시오.
다음은 알아두어야 할 다른 고려 사항입니다. * JavaScript 언어는 멀티 스레딩이나 SIMD를 지원하지 않습니다. * 이러한 기능을 활용하는 모든 코드는 다른 코드보다 속도가 느려집니다. * 스크립트의 WebGL에 스레딩 또는 SIMD 코드를 작성할 수 없지만, 일부 엔진 파트는 대개 멀티 스레드 또는 SIMD가 최적화되므로 WebGL의 성능 소모를 낮춥니다. 멀티 스레드와 SIMD 최적화가 모두 적용되는 WebGL 스키닝을 예로 들 수 있습니다.
팁: Unity가 WebGL 플랫폼이 아닌 플랫폼의 다른 스레드에 작업을 배포하는 방법에 대해 알아보려면 Unity의 새로운 타임라인 프로파일러를 참조하십시오.
성능을 극대화하려면 Build Player 창 최적화 레벨을 Faster로 설정하고 Other Settings > Stack Trace를 확장하여 WebGL에 대한 플레이어 설정에서 Exception support를 None으로 설정합니다.
WebGL은 Unity 프로파일러를 지원합니다. 설정 방법은 프로파일러 문서를 참조하십시오.
WebGL 플랫폼용 플레이어 설정에서 Run in background를 활성화하거나 Application.runInBackground을 활성화하면 포커스가 캔버스 또는 브라우저 창에서 벗어나도 콘텐츠가 계속 실행됩니다.
하지만 일부 브라우저는 배경 탭에서 실행 중인 콘텐츠의 속도를 늦출 수 있습니다. 콘텐츠가 있는 탭이 보이지 않으면 대부분의 브라우저에서는 콘텐츠가 1초에 한 번씩만 업데이트됩니다. 이로 인해 Time.maximumDeltaTime의 기본값이 1초보다 작으므로 기본 설정을 사용하면 Time.time이 일반적인 경우보다 더 느리게 진행됩니다.
경우에 따라 CPU 사용량을 줄이기 위해 WebGL 콘텐츠를 더 낮은 프레임 속도로 실행할 수 있습니다. 예를 들어, 다른 플랫폼에서 Application.targetFrameRate API를 사용하여 이렇게 할 수 있습니다.
성능을 낮게 조절하고 싶지 않으면 API를 높은 값 대신 기본값인 –1로 설정해야 합니다. 그러면 프레임 속도가 브라우저 렌더 루프에서 가장 부드러운 애니메이션을 재생할 수 있도록 조정됩니다. 이렇게 하면 Unity가 목표 프레임 속도를 달성하기 위해 스스로 루프 타이밍을 찾는 것보다 더 나은 결과를 얻을 수도 있습니다.