これは多くの要素が絡み合い、答えるのが少し難しいです。
一般的に、GPU 側では、ハードウェア・アクセラレーションを利用したレンダリングに GPU を使用しているので WebGL のグラフィックス API はネイティブアプリに近いパフォーマンスを得ることができます。
CPU 側では、すべてのコードは JavaScript の asm.js に変換されます。よって使用しているブラウザの Javascript エンジンに多くのものが依存しているため、パフォーマンスは使用するブラウザによって違いが出ます。現在（2015年11月）では、多数のプログラミングベンチマークによるとネイティブコードと比べてスピードの遅さを2倍未満に抑え、JavaScript コードの AOT コンパイルに asm.js を使用しているのは、現在だと Microsoft Edge と Mozilla Firefox のみです。Unity のコードも 2つのブラウザで一番のパフォーマンスを発揮します。また Unity で作成したベンチマークでも Microsoft Edge と Mozilla Firefox 上で計測した所、同様の結果となりました。
その他に考慮することはあります。ですが現在、JavaScript はマルチスレッドも SIMD もサポートしていません。ですのでこれらの機能が役立っているコードはすべて他のコードに比べ、大幅に減速するように見えます。WebGL のスクリプトでスレッドや SIMD のコードを書くことはできませんが、いくつかのエンジン部分はマルチスレッドや SIMD 用に最適化されているので、WebGL 上でパフォーマンスが悪いように見えます。例としては、スキニングコードで、これにはマルチスレッドと SIMD の最適化両方が使われています。Unity の新しいタイムライン プロファイラー を使うと、WebGL 以外のプラットフォームに関しては、Unity が 異なるスレッドにどのように作業の配分をしているかを見ることができます。将来、この機能が WebGL でも同様に使えるようになることを期待しています。
最高のパフォーマンスは Build Player ウィンドウで最適化レベルを「Fastest」にすることと、WebGL の Player Settings で「Exception support」を「None」にすることです。
Unity プロファイラーは WebGL でサポートされています。設定の仕方に関しては こちら を参照してください。
WebGL Player Settings の Run in background が有効になっているか、Application.runInBackground が有効になっている場合、キャンバスやブラウザウィンドウがフォーカスされなくともコンテンツの再生は止まらなくなります。
しかし、ブラウザがバックグラウンドタブでのコンテンツ実行を制限する可能性があることに気を付けなくてはいけません。コンテンツを再生しているタブが見えなくなった場合、ほとんどのブラウザでは更新が1秒置きにのみ実行されるようになります。この仕様により Time.time の経過が通常より遅くなることに注意してください。この原因は Time.maximumDeltaTime の初期値が1秒よりも少ないためです。
ある状況では、CPU の使用を減らすために低いフレームレートで WebGL コンテンツを実行したい場合があります。他のプラットフォームと同様に、 Application.targetFrameRate API を使ってそれを行うことができます。
パフォーマンスを減速したくない場合、この API に高い値を置くよりもむしろ、デフォルト値 –1 を設定します。こうすることにより、ブラウザーのレンダリングループでもっとも滑らかなアニメーションにフレームレートが調整され、Unity がそのメインループでターゲットフレームレートを調整するよりもよい結果が得られる場合があります。