🚀

Webページ速度改善 事始め①概要💨

1 min read

最近、サービスのパフォーマンスや品質向上に関して学んでいます。
特に課題だと感じたことが、「フロントエンド側からのWebページ速度計測や改善」について。
「計測して、解決案を提案する」機会があり、見様見真似で検証ツールみたりまとめたりしましたが、無事に打ちのめされ、、、

ダメだったこと

  • 自分の中に体系的な知識がなく、速度の基準などが確立されていなかった
  • 検証ツールを使いこなせていなかった

これらを少しでもマシにするために、ブログ記事などではなく、体系的にまとまった書籍を一冊読むことが必要でした。

そこで今回、参考した書籍「超速!WEbページ速度改善ガイド」を今後のためにも自分なりにチェックポイントをまとめたいと思います。多分4章ぐらいに分けます。

Webを高速化する際のポイント

フロントエンド側から関与できるものとしては、3つあります。

ネットワーク処理

HTMLドキュメントやサブリソース(CSS, JS, 画像)をダウンロードする処理。
リソースが巨大だったり、画像が大きかったり複雑だったりすると時間がかかるよね、という話。

レンダリング処理

実際にユーザーの目に見えるように表示されるときに行われる処理。
ダウンロードが終わってもCSSやJSで複雑なアニメーションを組んでいたら、読み込む→表示に時間かかるよね、という話。

スクリプト処理

Javascriptによる処理。
Javascriptは、基本的にレンダリング前に評価される(クリティカルレンダリングパスに含まれる)ため、ここが長いとユーザーに届くのも遅くなるよね、という話。
特に、React, Vueに代表されるSPAはJavascriptによる制御がメインのため、ここがボトルネックの可能性も高い。

※クリティカルレンダリングパスとは簡単にいうと...?

Webページは、

  1. HTMLドキュメントを取得・評価
  2. DOMを構築
  3. DOMを元にCSS, JSなどのサブリソースを取得
  4. CSSOMツリーの構築やDOMツリーへの反映
  5. レンダーツリーの構築
  6. レンダリング
    という手順を踏みます。

この時、レンダリングは前の5ステップが終了するまで行われないため、この一連の動作をクリティカルレンダリングパス(個人的な意訳をすると、レンダリングするために絶対必要な一連の流れ)と呼びます。
開発者は、レンダリング以後は基本的に関与できないです(あとはデバイスの能力次第なとこあるので)。
よってレンダーツリーの構築までをいかに早めるかが最重要項目ということです。

目標となる指標

理想的な速度として、取り上げられている指標は以下です。(書籍内参考記事)

https://www.nngroup.com/articles/response-times-3-important-limits/
  • ユーザーがUIを操作して、遅延を感じない時間の限界 0.1秒(100ミリ秒)
  • 遅延が起こってもユーザーがとりあえず見るか..と考えられる時間の限界 1.0秒(1000ミリ秒)
  • ユーザーが関心を向けていられる時間 10秒

このことを、googleのエバンジェリスト達が、より明確に紹介しています。
この目指すべき指標を、RAILモデルと言います。

R response(UI操作で応答があるまでの時間) 100ミリ秒(0.1秒
A animation(アニメーション1フレームにかける時間) 10ミリ秒(0.01秒)
I idle(何も行われていない時に、操作した時の処理単体の時間) 50ミリ秒(0.05秒)
L load(ページロードの時間)1000ミリ秒(1.0秒)

つまり速度改善として目指す指標は、

  • ユーザーの操作に起因するものは100ミリ秒以内を目指せ
  • ページの表示は、1000ミリ秒以内を目指せ
    です。

ということを踏まえて、次回はネットワーク処理の計測と改善について、書きます。

Discussion

ログインするとコメントできます