今回は弊社の公式サイトを題材に、PageSpeed Insights（以下、PSI）で「ウェブに関する主な指標」の合格判定をもらうまでにやったことをまとめます。

弊社の公式サイトはこちらです。
https://eustylelab.co.jp/

実際にご覧いただくと分かると思いますが、

• キービジュアルの動画
• 各下層ページへのメニュー
• お知らせのスライダー（スマートフォンのみ）

といった、いたって一般的な構成です。
「リッチコンテンツが大量にある」というほどでもありません。

ところが、PSIで計測してみると、「ウェブに関する主な指標の評価」が不合格。

これはエンジニアとして、ちょっと悔しい。
ということで、合格判定をもらうべく、いろいろと改善してみました。

まずは「おすすめの方法」から

最初に取り掛かったのは、PSIの「おすすめの方法」に表示されていた項目です。

とくに、

• JavaScriptプラグインによるエラー
• CSS内で読み込んでいる画像の404
• その他、ブラウザのコンソールに出ているエラー

などを一つずつ潰していきました。

コンソールエラーは、それ自体が指摘事項になるだけではありません。
エラーが発生していることで、ページの表示やJavaScriptの動作などに影響し、結果的に「パフォーマンス」にも悪影響を与える可能性があります。

そのため、PSIの改善に取り掛かる際は、まずコンソールエラーを確認してみることをおすすめします。

何より、エラーが出ているのは、エンジニアとしてちょっと不名誉（笑）

ということで、まずはここからです。

次に「ユーザー補助」と「SEO」

コンソールエラーをある程度解消したところで、次はPSIの「ユーザー補助」と「SEO」の改善に取り掛かりました。

今回対応したのは、例えば以下のような項目です。

• 画像の alt 属性を整備
• 画像の width / height 属性を整備
• リンクを識別しやすくする
• href のない <a> タグなどを見直す

このあたりは、ある意味で「単純な取りこぼし」です。
「ここを直してください」とPSIが教えてくれるので、それを一つずつ潰していけばいい。

そのため、「ユーザー補助」や「SEO」は、比較的100点を狙いやすい項目だと思います。

もちろん、サイトのデザインや構造によっては対応が難しいものもありますが、少なくとも今回のサイトでは、「言われたことを一つずつ直していく」

というアプローチでかなり改善できました。

最後に「パフォーマンス」

そして、いよいよ本丸です。
PSIで最も目立つ「パフォーマンス」の改善に取り掛かりました。

今回対応したのは、主に以下です。

• Google Fontsによるレンダリングブロックの改善
• 外部CSSファイルのインライン化
• PNG画像をWebPへ変更
• 画像をSVGへ置き換え
• 画像サイズの最適化
• 必要以上に大きな画像の縮小
• キービジュアル動画をMP4からWebMへ変更

Google Fontsのレンダリングブロックを改善

例えばGoogle Fontsについては、読み込み時のレンダリングブロックを避けるため、以下のような実装に変更しました。

<link rel="preload" href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap"></noscript>

ポイントは、

media="print" onload="this.media='all'"

の部分です（または非同期読み込み属性の適用）。
最初は通常のCSSとして読み込ませず、読み込みが完了したタイミングで適用することで、初期表示時のレンダリングブロックを避けます。

CSS・画像もできる範囲で最適化

外部CSSについても、可能なものはインライン化しました。

また、

• PNG → WebP
• PNG → SVG
• 画像の圧縮
• 大きすぎる画像のリサイズ

なども実施。

さらに、サイトのキービジュアルで使用していた動画についても、MP4からWebMへ変更しました。
動画は画像以上に容量が大きくなりやすいため、ここは体感としても効果が分かりやすい部分でした。

ただし、「パフォーマンス100点」はかなり難しい

ここで一つ注意したいのが、PSIの「パフォーマンス」です。

特に携帯電話（スマートフォン）の計測は、かなり厳しい条件で測定されます。
実際のユーザー環境を想定した低速なネットワーク環境なども考慮されるため、実際のサイト利用環境では十分高速でも、PSI上ではなかなか高得点にならないことがあります。

そのため、「PSIでパフォーマンス100点を取る！」

という目標は、かなりハードルが高いと思います。

少なくとも今回のサイトでは、いろいろと改善したものの、パフォーマンスについては、

• モバイル：40点台
• デスクトップ：60点台

程度でした。

「結構頑張ったのに、こんなもんか……」
という感じです。

そして、最終結果

最終的な結果はこのようになりました。

「おすすめの方法」については、一部アナリティクス関連のタグが原因となるエラーが残りました。
「ユーザー補助」についても、デザイン上の理由から、使用色のコントラスト比に関する指摘が一部残っています。

画面上のパフォーマンス数値も決して高得点とは言えません。

それにもかかわらず……

携帯電話（スマートフォン）を含め、無事に「合格判定」をもらうことができました。

結論：PSIは「パフォーマンス」だけを見てはいけない

今回実際にPSIと格闘してみて、個人的に一番感じたことがあります。

それは、PSIで合格判定をもらうことだけを目的とするなら、「パフォーマンス」だけに注力する必要はないのでは？

ということです。

もちろん、パフォーマンスを改善するに越したことはありません。
画像をWebPにしたり、動画をWebMにしたり、不要なCSS・JavaScriptを削減したりすることは、実際のユーザー体験にもつながります。

ただ、PSIの画面を開くと、まず大きく表示されるのが「パフォーマンス」のスコアです。
そのため、「パフォーマンスの点数を上げなければ！」

と、ついそこに意識が集中してしまいます。

しかし、今回の結果を見ると、パフォーマンスが40～60点台でも、「ウェブに関する主な指標」は合格判定になりました。

一方で、

• 「ユーザー補助」
• 「おすすめの方法」
• 「SEO」

については、比較的対応しやすく、サイトによっては100点を狙える項目です。

例えば、

• alt が設定されていない
• width / height が設定されていない
• href がない
• リンクの役割が分かりづらい
• コンソールにエラーが出ている

など。
こういった「ちょっとした取りこぼし」を一つずつ潰していくことが、PSI改善ではかなり重要だと感じました。

PSIの点数に振り回されない

今回の経験を通して、PSIは**「点数を上げるゲーム」ではなく、サイトの問題点を見つけるためのチェックリストとして使う**のが良いのではないかと思っています。

特に、「パフォーマンスの数字が低い！」

と焦る前に、

1. コンソールエラーを確認する
2. 「おすすめの方法」の指摘を潰す
3. 「ユーザー補助」の取りこぼしを潰す
4. 「SEO」の取りこぼしを潰す
5. その上で「パフォーマンス」を改善する

という順番で進めてみるのがおすすめです。

パフォーマンス改善は奥が深く、やればやるほどキリがありません。
一方で、その他の項目には、「指摘されていることを直せば改善する」という分かりやすいものも多くあります。

PSIの画面では「パフォーマンス」が一番派手に見えますが、そこだけにとらわれない。
地味だけど基本的なところを一つずつ潰していく。

今回、実際に合格判定をもらうところまでやってみて、これがPSI改善の一つのポイントなのではないかと感じました。