Webパフォーマンスボトルネックのチェックリスト

概要

Webシステムのパフォーマンスが悪くなった際、どの観点で見るべきなのか漏れてしまう可能性があるため、チェックリストとして観点をまとめました。

※この記事は都度更新して観点を追加します！

Webパフォーマンスとは

MDNの「ウェブパフォーマンスとは」では以下のように解説されています。

ウェブパフォーマンスとは、遅い処理を速く見せることも含めて、ウェブサイトを速くすることです。サイトがすぐに読み込まれるか、ユーザーがすぐに操作を始めることができるか、何かの読み込みに時間がかかっている場合には安心感のあるフィードバック (ローディングスピナーなど) を提供しているか。スクロールやアニメーションはスムーズか。

今回は下記の2つの点に着目してチェックリストを考えていきます。

1. サイトの読み込み時間を削減する
2. ユーザーが操作可能な状態を早く実現する

1. サイトの読み込み時間を削減する

ウェブサイトの表示に必要なファイルが、ユーザーの環境にダウンロードされるまでの時間を削減する方法を考えます。

下記の観点で対応方法を検討します。

• 💽 データを削減する
• 📡 通信回数を削減する

フロントエンド

• 💽 読み込みリソースを疑う
  • ファイルのサイズが大きくないか
  • ファイルの数が多くないか
• 💽 リソースの読み込みタイミングが適切かを疑う
  • 必要なリソースが先読み(preload)されていない可能性を疑う
    • 遅延読み込み(Lazy loading)で必要なタイミングだけ読み込む戦略を取れていることもチェックします

バックエンド

• 💽 発行されるSQLを疑う
  • データ取得時にスロークエリ、N+1問題が発生していないか
    • データ取得時に遅いクエリ・不必要なクエリ発行は、レスポンス速度の遅延に直結します
      • ※ORMを利用する場合は、データ取得時に不要な問い合わせが発生していないかをチェックしましょう
      • ActiveRecordのincludesは使わずにpreloadとeager_loadを使い分ける理由
• 💽 レスポンスに含まれるリソースのサイズを疑う
  • サムネイルに保存画像がそのまま利用されていないか
    • 高画質な画像をサムネイルにそのまま利用すると、レスポンスサイズを不必要に増加させます
    • 適切なサイズに画像を加工し、データサイズが削減されていることをチェックしましょう
    • Active StorageのVariantの指定方法いろいろ
• 💽 レスポンスのレコード量を疑う
  • 一覧などのレスポンスで、取得したデータをそのまま戻していないか
    • 一覧ページは全データを表示することが多く、全てをレスポンスに含めているとデータ量の増加が直接ボトルネックになるため、ページネーションが実装されていることをチェックしましょう
    • 【Rails】Kaminariを用いたページネーション機能まとめ！導入手順、デザインの変更、日本語化についてまとめて解説
• 📡 適切なレスポンスが戻せていないことを疑う
  • フロント側で画面に必要な情報を作成するため、複数回のAPIを投げさせていないか
    • フロント:バック = 1:1 の場合のみに限りますが、画面ごとに最適なレスポンスを戻すことで通信回数が削減されます

2. ユーザーが操作可能な状態を早く実現する

ユーザーがすぐに使い始めることができる状態、何を操作すれば良いかを伝えるための方法を考えます。
（ここは情報が薄いので、必要）

下記の観点で対応方法を検討します。

• ℹ️ ユーザーに情報を連携する

フロントエンド

• ℹ️ ユーザーの優先度の高い情報を表示できているか疑う
  • 優先度の高い情報を先に読み込めているか
    • ユーザーのアクティビティを考慮した、読み込みフローになっているかをチェックします
      • このフローはUXに直結する部分となるため、チェックリストレベルで考えるものではないと判断しております...
• ℹ️ ユーザーに待ち時間を与えない仕組みになっているかを疑う
  • リソースの読み込みがバックグラウンドで実施されているか
    • リソース読み込みが非同期処理で行われているかをチェックします

バックエンド

• ℹ️ ユーザーに連携すべき情報を戻せているか疑う
  • バリデーションやエラー時に適切なメッセージが戻せているか
    • ユーザーに表示したいエラーがある場合、実装されているかをチェックします