これは多くの要素が絡み合い、答えるのが少し難しいです。
一般的に、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 設定で Exception support を None に設定します。
Unity プロファイラーは WebGL でサポートされています。設定の仕方に関しては こちら を参照してください。
Run in background が WebGL プラットフォームのプレイヤー設定 で有効になっている場合、または Application.runInBackground を有効にする場合、キャンバスやブラウザーウィンドウがフォーカスを失っても、コンテンツは引き続き実行されます。
ただし、ブラウザーはバックグラウンドタブで実行されているコンテンツを減速する場合があります。コンテンツのタブが表示されない場合、コンテンツはほとんどのブラウザで 1 秒に 1 回更新されます。これにより、デフォルト設定の Time.time の処理速度が通常よりも遅くなることに注意してください。なぜなら、Time.maximumDeltaTime のデフォルト値が 1 秒より短いためです。
ある状況では、CPU の使用を減らすために低いフレームレートで WebGL コンテンツを実行したい場合があります。他のプラットフォームと同様に、 Application.targetFrameRate API を使ってそれを行うことができます。
パフォーマンスを減速したくない場合、この API に高い値を置くよりもむしろ、デフォルト値 –1 を設定します。こうすることにより、ブラウザーのレンダリングループでもっとも滑らかなアニメーションにフレームレートが調整され、Unity がそのメインループでターゲットフレームレートを調整するよりもよい結果が得られる場合があります。