サポート

遅くしている原因は、Javascript

遅くしている原因は、Javascript

目的：パフォーマンスとユーザーエクスペリエンスを向上させるためには、まずネットワーク自体を見ることから始めます。

Mark Zeman　2018年6月25日

  • First byteとはなにか？
  • リクエスト数はいくつ？それにどれだけかかっているか？
  • ブラウザのレンダリングを妨げているものは何か？

ここ数年、ネットワークが原因ではないWebパフォーマンスの問題が増えています。というのは、ブラウザのメインスレッドが過度のCPU使用によって詰まってしまうという原因です。

優れたユーザーエクスペリエンスのために、速いネットワークと同様にCPU使用率を管理することが重要です。

モバイルでは、どのくらいの頻度でページ表示がされたにも関わらず、タップやスクロールしても何も起こらないとか、次の表示よりもずっと遅れているというケースがありますか？

  • 100％ CPUでは、ブラウザはどのくらいの時間ダメになっているか？
  • ユーザーは中断なくスムーズにやりとりができるか？
  • どのスクリプトがユーザーエキスペリエンスを損なう原因となるか？

新しいWebパフォーマンス指標とビジュアル化の開発により、私たちはJavaScriptのコストを把握し、ユーザーへの影響を監視しながらWebページの改善ができるようになりました。

これらのJavaScriptのパフォーマンス指標は、ユーザーがページとスムーズに対話できるまで、どれくらいの時間を要しているかを取得します。

First Interactiveは、ブラウザが どのタスクからもブロックされていない状態が0.5秒（50ms）以上続いた時点をマークするシンセティック(合成）な指標です。この値が小さいほどユーザー入力に素早く応答できるようになります。

First Input Delayは、LUXに追加したRUM（リアルユーザーモニタリング）のメトリックです。これは、ユーザーが最初にサイトとインタラクションしたとき（つまり、リンクをクリック、またはボタンをタップしたとき）から、ブラウザが反応した時間を計測します。

JavaScriptのウォーターフォール

JavaScriptのパフォーマンス監視課題の1つは、原因となるスクリプトの特定です。スクリプトのネットワーク状態と実行時間をフィルタリングし、遅延原因のスクリプトを分析できる「JavaScriptウォーターフォールチャート」についてご説明します。

Javascriptウォーターフォールでは、ユーザーエクスペリエンス（上のフィルムストリップ）とブラウザのメインスレッド（下のCPU使用率）を関連付けて、ブラウザメトリック（斜め線）を遅らせるスクリプトを特定できます。

以下のビューでは、JavaScriptの動きが0.5秒（50ms）以上かかるところを赤色でフィルタリングしています。多くのサードパーティ広告がどのようにしてFirst Interactiveを12.74秒にまで、伸ばしてしまうかを見ることができます。実際、ビューポートのヒーローコンテンツは3秒で表示されていますがが、サードパーティ広告のために、このページはその後10秒間は使用できないと考えられます。これはJavaScriptの隠されたコストであり、どれほど簡単にユーザーエキスペリエンスを悪化させてしまうかを物語っています。

また、ドメイン別にJavaScriptをグループ化して、問題の多いCPUの消費や、消費CPU時間の傾向を、Start renderなどのブラウザイベントを通じて浮き彫りにします。また、CPU scripting time to Page Loadなどの指標でパフォーマンス・バジェットを設定し、JavaScriptでページパフォーマンスが低下した場合に、Slackアラートの受け取りなどができます。

 

JavaScriptのコスト

最近のO’Reilly Fluent Conferenceでは、Addy Osmani氏がThe Cost of JavaScriptについての洞察を行いました。彼は、高速なデバイスや高速なネットワークで作業しテストする開発者として抱える疑問に挑戦しました。平均的なユーザーが何を経験しているかを調べるために、CPUを抑えてしまう古いデバイスに注目しました。JavaScriptは、CSSや画像よりも多くのCPUを消費し、ユーザーのページやりとりをブロックする可能性があることを覚えておきましょう。

 

JavaScriptは敵か味方か？  

ReactとVue.jsのようなJavaScriptフレームワークが提供する容易な開発と機能性が好まれていますが、そのコストについてはあまり言及されません。対価なしでは何も得られませんが、これらのフレームワークを選ぶ場合、ユーザーにかかるコスト問題についての議論はほとんどありません。

アプリケーションロジックとレンダリングをサーバーからクライアント側に押しつけると、パフォーマンスは実行するデバイスに依存します。多くの場合、これらのデバイスは期待するほど速くはありません。

Addy は、Netflixがウェブサイトのサインアップとビデオプレーヤーの一部の開発をJavaScriptからReactに移行したときに、このトレードオフの例を見ることができました。

最初のリリースでは、クライアント側のパフォーマンスとユーザーエクスペリエンスが低下していました。彼らはReactをいくつかのページから削除し、元のページと同じレベルに戻すためにプレーヤーのパフォーマンス課題に大きな労力を払いました。。

私を驚かせたのは、ユーザーエクスペリエンスが同じになったことです。それなら努力の価値はあったのでしょうか？彼らが余計な努力を払わなかった場合、デフォルトのReact版のユーザーエクスペリエンスは、実際はもっと悪かったことでしょう。

 

First Interactiveのような指標を監視して、ユーザーに負担がないことを確認していますか？

新しいJavaScriptでの開発の楽しみのために、ユーザーに与える痛みに盲目になってはいけません。

 

JavaScriptフレームワークに移行する際には、ユーザーエクスペリエンスを念頭に置き、ウェブサイトのスピードを向上させるのか、妨げるのかを尋ねることが重要です。SpeedCurve やA / Bテストようなツールを使ってプロトタイプをテストし、開発を進める前にJavaScriptフレームワークのコストを定量化させましょう。

私たちは、SpeedCurveの新しいゴールを「JavaScriptのパフォーマンスを監視するベストツールを目標にしています。 自分のJavaScriptのウォーターフォールを探索してみてください。自社のJavaScriptスタックのパフォーマンスを深く掘り下げて、そこで見たいものをお知らせください。

 

 

 

 

 

関連記事