一般に、WebGL グラフィックス API はハードウェアアクセラレーションレンダリングに GPU を使用するため、GPU 上のネイティブのアプリケーションに近いパフォーマンスを得る必要があります。WebGL API の呼び出しとシェーダーを OS グラフィックス API（通常、Windows の場合は DirectX、Mac または Linux の場合は OpenGL) に変換するためのオーバーヘッドがわずかにあります。
CPU では、Emscripten がコードを WebAssembly に変換します。そのため、パフォーマンスはウェブブラウザーに依存します。詳細については、Unity のブログ WebAssembly Load Times and Performance を参照してください。
他にもいくつか注意点があります。JavaScript は、マルチスレッドや SIMD をサポートしていません。これらの機能を利用するコードは、他のコードよりも遅くなる可能性があります。スクリプトに WebGL のスレッドや SIMD のコードを記述することはできませんが、エンジンの一部は通常、マルチスレッドや SIMD 最適化が行われているため、WebGL ではパフォーマンスが低下します。例えば、スキニングのコードはマルチスレッドで SIMD に最適化されています。
Unity の新しいタイムライン Profiler を使って、WebGL 非対応のプラットフォームで Unity がどのように異なるスレッドに作業を分配しているかを確認できます。
最高のパフォーマンスを得るには、Build Player ダイアログで最適化レベルを Fastest に設定し、WebGL の Player 設定で Exception support を None に設定します。
WebGL は、Unity のプロファイラーをサポートしています。設定方法について詳しくは、プロファイラー のドキュメントを参照してください。
Run in background が WebGL プラットフォームのプレイヤー設定 で有効になっている場合、または Application.runInBackground を有効にする場合、キャンバスやブラウザーウィンドウがフォーカスを失っても、コンテンツは引き続き実行されます。
ただし、ブラウザーはバックグラウンドタブで実行されているコンテンツを減速する場合があります。コンテンツのタブが表示されない場合、コンテンツはほとんどのブラウザーで 1 秒に 1 回しか更新されません。これにより、デフォルト設定の Time.time の処理速度が通常よりも遅くなることに注意してください。なぜなら、Time.maximumDeltaTime のデフォルト値が 1 秒より短いためです。
ある状況では、CPU の使用を減らすために低いフレームレートで WebGL コンテンツを実行したい場合があります。他のプラットフォームと同様に、 Application.targetFrameRate API を使ってそれを行うことができます。
パフォーマンスを減速したくない場合、この API に高い値を置くよりもむしろ、デフォルト値 –1 を設定します。こうすることにより、ブラウザーのレンダリングループでもっとも滑らかなアニメーションにフレームレートが調整され、Unity がそのメインループでターゲットフレームレートを調整するよりもよい結果が得られる場合があります。