Coding Methodology

サイトパフォーマンス最適化のためのWebサイト解析ツール3選

2022 / 06 / 30

新規制作、既存改修どちらのプロジェクトでもサイトパフォーマンスを気にされるお客様が増えてきています。
スケジュール内でデザインと仕様に沿ったWeb制作をすすめるだけでは初期表示速度(LCP)やレイアウトシフト(CLS)、操作可能までの時間(TTI)など近年要求されるサイトパフォーマンスを高水準に達成するのはなかなか難しいものです。
そこで今回は、現状のサイトのパフォーマンスを解析するのに役立つツールと使用方法をご紹介します。

サイトパフォーマンス最適化のためのWebサイト解析ツール3選

以下、LTSバージョンのnode.js、Google chromeがインストールされたmac or WSL環境のwindowsを想定し進めていきます。

サイト解析にはLighthouseが便利だけど

chromeに標準で搭載されているLighthouseは、結果ページの視認性もよく、チェックされる項目も充実しているため、私は計測ツールとしてもっとも多いタイミングで使用しています。

大定番のLighthouseは便利ではあるのですが、1ページ、1ページ結果を確認するのは大変です。また項目によっては具体的な改善点まで提示されないものもあり、改めての調査も発生します。

さすがは我らがCFサイト計測時点では満点となっていました!

1.lighthouse-paradeでサイトクローリングしながらWebページをスコアリングする

すでに公開されているサイトであればnpmライブラリlighthause-pardeを使い、サイト全体をクロールしながらパフォーマンスを調査できます。

npm:https://www.npmjs.com/package/lighthouse-parade
GitHub:https://github.com/cloudfour/lighthouse-parade

不必要にライブラリをインストールする必要は無いのでnpxコマンドで実行していきます。

# ディレクトリを作成し移動します
mkdir my-site-performance && cd my-site-performance

使い方
次のコードの<url>に本サイトのURLを入力し実行してみます。ぜひご自身のWebサイトURLで使用してみてください。

# npx lighthouse-parade <url> mySiteData
npx lighthouse-parade https://coding-factory.com/ CFSiteData

ネットワーク環境、サイト規模にもよりますが、しばらくすると指定したアウトプットディレクトリにパフォーマンスデータが格納されます。

ページごとの詳細をcsvファイルで取得

出力されるaggregatedMobileReport.csvをスプレッドシート等で開けばページごとのパフォーマンスを見ながらサイト全体の傾向を把握できます。
また、同時に出力されるurls.csvでクローリングされたurlの一覧を取得できますので以降のさらなる詳細把握に役立てることができます。

2.lighthouse-batchでページごとの詳細な解析データを取得する

ページごとのスコアはわかりましたので、問題となっているアセット等の情報も調べていきます。

先程lighthouse-paradeで取得したurls.csv(制作時にサイトマップをまとめていればそちらでも良いと思います。)にあるページURLをつかいlighthouse-batchというライブラリでページパフォーマンスの詳細データを取得していきます。

npm:https://www.npmjs.com/package/lighthouse-batch
GitHub:https://github.com/mikestead/lighthouse-batch

urls.csvの1列目がurlとなっていますので、たとえば

cut -d ',' -f 1 CFSiteData/urls.csv | sed -e "1d" | sed -e 's/"//g' > url_list.txt

みたいな感じで、次のようなurlだけのファイルを作成します。

# ex url_list.txt
https://coding-factory.com/
https://coding-factory.com/en
https://coding-factory.com/file
https://coding-factory.com/contact
https://coding-factory.com/th
https://coding-factory.com/about
https://coding-factory.com/feature
https://coding-factory.com/service
https://coding-factory.com/works
...

またまたライブラリをnpxから実行します。

npx lighthouse-batch -h -f url_list.txt

  • -hオプションは解析内容をjsonとともにhtmlファイルでも出力します。ビジュアルで情報を共有したい際に役立つと思います。
  • -f オプションはurlを行区切りで記述したファイルを読み込むオプションです。url一つだけを実行したい場合は-s <url>となります。

その他のオプションについてはlighthouse-batchのgithubページを確認してみてください。

こちらはかなり時間がかかります。PCスペックに余裕があるようであれば他の作業をしながら気長に待ちましょう。ネットワークに繋がってないとデータが取得できませんのでスリープの設定等ご注意ください。ご参考までに、cfサイト126ページの取得には1時間26分かかりました。

そのため、サイトが大規模であるなら全データの取得はなかなか厳しいため、詳細取得の前に改善したいサイトのパフォーマンス基準を決めてしまうことをおすすめします。基準を定めた上で、スコアが良い数ページと基準を下回ったページのリストを作成してからライブラリのスクリプトを実行して行きましょう。

取得したjsonファイルには膨大な情報が記載されています。基本的にはaudits配下の項目を見ていくことになります。以下にパフォーマンス観点で確認すべき項目をいくつかピックアップします。

項目内容
critical-request-chains
  • クリティカル要求チェーン。詳細はweb.dev(LighthouseのWebアプリ版)の下記ページをご覧ください。
    https://web.dev/i18n/ja/critical-request-chains/
  • アセットの読み込み戦略をたて、非同期読み込みが可能なものはないか検討する材料になります。
network-requests
  • ページロード中に発生したネットワークリクエストの一覧です。
resource-summary
  • ページ内リソースの種別ごとの容量がわかります。
largest-contentful-paint-element
  • 最大視覚コンテンツ要素
  • 最大=描画に時間がかかるというわけでもないと思いますが、もし目立たせる必要のない項目が該当しているならば見直すことでスコアの改善が見込めます。
unsized-images
  • img要素にサイズ属性を記載していない画像が記載されています。
unused-css-rules
  • 未使用のCSSスタイル
  • コーディングで解消できるポイント。網羅率があまりに低い場合は開発手法を改めたほうが良いでしょう。改善案として、モダンなフレームワークを使用しコンポーネントベース・ユーティリティベースの開発手法をとれば「common.css,layout.css」などの共通ファイルを設定する必要がなくなります。
unused-javascript
  • 上と同義です。リッチなトップページと下層ページで同一のスクリプトを読んでいると不要な記述とみなされるものが増えていきます。
modern-image-formats
  • AVIFやWebPなどの次世代画像フォーマット
  • モダンブラウザではWebPの補助としてのpng,jpgは不要になりました。
uses-optimized-images
  • 容量、サイズなどが最適化されていない画像
  • png,jpgを使用する場合は容量圧縮と合わせてサイズも最適化できると良いです。
legacy-javascript
  • レガシーなjavascriptコード
  • モダンブラウザであればトランスパイルはほぼ必要ない状況になってきています。また、基本的なWebインタラクションであれば、jQueryを使うよりも通常のJavaScriptで書いた方がトータル容量を削減できることが多い。
dom-size
  • ページ内のdomの数
  • domの量はパフォーマンスに大きく影響します。例えば、リッチなデザインのカードを大量に並べた場合、非力なスマートフォンでは顕著にレンダリングに影響が出ます。合理的なコンテンツ設計・デザイン・マークアップがパフォーマンスを改善させます。

例えば、取得したデータを整理し、圧縮できていない画像の一覧を作成できれば画像最適化の本丸が終わるので、その後の作業が効率よく進められます。

また、問題点の殆どがアナリティクスツール等第三者リソースの容量や読み込み時間のために発生しているようであれば、非同期読み込みや対象のページを整理するなど、自身を持って対応方法を選定することができると思います。

3.Yellow lab toolで改善点を洗い出す

例えばServer設定が悪い場合、いくらCSSや画像の最適化をしても改善は見込めません。

Yellow lab toolsを使用するとページのパフォーマンスがどこに影響を受けてのものなのかがわかりやすくなります。

https://yellowlab.tools/

上記URLにアクセス、対象のURLを入力しデバイスを選んだら「Launch test」をクリックします。

しばらくするとページのダッシュボードが表示されます。

各項目をクリックすると項目で拾い上げた内容がアセットごとに並びます。

下図は「Bad CSS」の「Uses of !important」(上図、赤枠部分)をクリックしたときに表示される内容です。

CSSファイルごとに!important ルールが記述されている箇所が抽出されている。

その他にも、CSSで同一セレクタで複数回記述していたり、ネストが深かったり、JSで何度もDOMにアクセスしているなど、要素や記述単位で該当箇所が確認できるため、異常値やコーディングの品質傾向を把握できます。パフォーマンス改善施策を策定する際に利用してみてください。


サイトパフォーマンス改善は一朝一夕に成し遂げられるものではありません。

また、制作当初は高速にレンダリングされていたページもリリース後に不要なスタイルやスクリプトが増えてしまい本来のページパフォーマンスを下回ってしまうこともあるかもしれません。

なんとなく重い気がするという感覚で改善を図ろうとしてもなかなか効果が出ず遠回りになってしまいます。
まずはサイトが重いのは本当か、何がボトルネックになっているかしっかりと調査し対処することが効果的です。

  • 解析し
  • 全体の傾向と指標を決め
  • 問題点をリストアップ

という手順を経てソースコードやサーバーの改善に着手していきます。今回ご紹介したツールが解析〜洗い出しまでのお役にたてると嬉しいです。

ではでは

一覧に戻る

CODING FACTORYのWebサイトにご訪問いただき、ありがとうございます!サイトの改善や情報発信に活かすために、個人情報保護方針に基づいたCookieの取得と利用のご同意をお願いいたします!
個人情報保護方針の詳細