これは多くの要素が絡み合い、答えるのが少し難しいです。
一般的に、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 の最適化の両方を行うスキニングコードです。現在、WebGL では対応していませんが WebGL 以外のプラットフォームでスレッドごとの処理を確認するための新しいタイムプロファイラが使用できます。長期的な見解ですが、将来的に WebGL でもこのプロファイラが利用可能になることを期待しています。
最高のパフォーマンスは Build Player ウィンドウで最適化レベルを「Fastest」にすることと、WebGL の Player Settings で「Exception support」を「None」にすることです。
他のプラットフォームと同じように、WebGL上で Unity のプロファイラーを使用することができます。1つ重要な違いとして、WebGL として実行しているプレイヤーへアタッチすることはできません。これはブラウザ側が接続を許可しないため WebSocket を使用しているためです。代わりに、Build Settings の「Autoconnect profiler」にチェックを入れて使用する必要があります。WebGL では現在のドローコールをプロファイリングすることはできません。
WebGL Player Settings の Run in background が有効になっているか、Application.runInBackground が有効になっている場合、キャンバスやブラウザウィンドウがフォーカスされなくともコンテンツの再生は止まらなくなります。
しかし、ブラウザがバックグラウンドタブでのコンテンツ実行を制限する可能性があることに気を付けなくてはいけません。コンテンツを再生しているタブが見えなくなった場合、ほとんどのブラウザでは更新が1秒置きにのみ実行されるようになります。この仕様により Time.time の経過が通常より遅くなることに注意してください。この原因は Time.maximumDeltaTime の初期値が1秒よりも少ないためです。