サイトが遅いと言われたら｜PageSpeed改善の実測値と100点にしない判断

自社サイトの表示速度を改善を試みました。

パソコン版の結果は94点で作業時間は1.5時間ほどです。

モバイル版はの結果は61点で作業時間は1時間ほどです。

数字だけ見れば、割に合わない仕事に見えると思います。

実際、点数の伸びは3点しかありません。

それでも、この作業には意味がありました。

そして途中で「これ以上は上げない」と決めた場面があります。

この記事では、実際に測った数字をすべて出したうえで、なぜ100点を目指さなかったのかを書きます。

Web制作会社から「サイトの表示速度が遅いので改善しましょう」と提案されたことがある方に、判断材料として読んでいただければと思います。

PageSpeed Insights とは何か？

Googleが提供している、Webページの表示速度を測るツールです。URLを入れると0から100の点数が出ます。

点数の色分けはこうなっています。

赤が出ると不安になります。緑にしたくなります。その気持ちは自然なものです。

ただし、この点数が何を測っているのかを知らないまま追いかけると、判断を誤ります。

改善前の状態

自社サイトのトップページを測ったところ、こうでした。すべてモバイルでの計測です。

あわせて、こう指摘されていました。

レンダリングをブロックしているリクエスト、推定される削減時間 5,400ミリ秒。

5.4秒です。画面に何も表示されないまま、5秒以上待たされている計算になります。

まず疑ったこと

最初に考えたのは「サーバーが遅いのではないか」でした。共用サーバーを使っているので、可能性はあります。

そこで実測しました。

サーバーは問題ありませんでした。 十分に速い。原因は別のところにあります。

原因は「外部から読み込んでいるファイル」だった

ページのHTMLの先頭部分（head）で、次の3つを外部のサーバーから読み込んでいました。

ここで重要なのは、ファイルの大きさだけが問題ではないということです。

別のドメインからファイルを取りに行くとき、ブラウザは毎回こういう手順を踏みます。

ドメイン名からIPアドレスを調べる。そのサーバーと接続を確立する。暗号化の取り決めをする。ようやくファイルを受け取る。

この一連の準備に、モバイル回線では数百ミリ秒かかります。ファイルが小さくても、この時間は変わりません。

実際、Lenis のCSSはわずか513バイトでした。文字数にして数百文字です。そのために外部サーバーとの接続を一つ丸ごと確立していました。

やったこと1：アイコンを自社サーバーに置いた

Font Awesome は便利なアイコン集です。<i class="fas fa-envelope"> と書くだけで封筒のアイコンが出ます。

ただし読み込んでいたのは全アイコンのセットでした。CSSだけで102KB、フォントファイルは4種類あります。

調べたところ、当サイトで実際に使っているアイコンは19種類だけでした。封筒、上向き矢印、SNSのアイコン、開閉のプラス記号などです。

そこで、必要な定義だけを抜き出したCSSを作り、フォントファイルとあわせて自社サーバーに置きました。

この作業で見つかった不具合

調査の途中で、サービスページと制作実績ページに書体の読み込み自体が無いことが分かりました。

この2ページに直接訪問した人には、指定した明朝体が配信されていなかったことになります。パソコンに入っている代替の書体で表示されていました。

他のページとフォントが違う状態が、しばらく続いていたわけです。速度改善を目的とした調査でしたが、結果的に表示品質の不具合が見つかりました。

こういうことは実際に起きます。全ページを機械的に走査しなければ気づきませんでした。

ところが、点数はほとんど動かなかった

期待して測り直したところ、こうでした。

FCPは1.1秒縮まりました。しかしブロック時間は変わっていません。

つまり、アイコンは主犯ではなかったということです。仮説が外れました。

やったこと2：スムーズスクロールのCSSを本体に統合

Lenis というライブラリのCSSは513バイトでした。これを既存の style.css の末尾に貼り付け、読み込み行を削除しました。

JavaScriptのほうも自社サーバーに置きました。

これで外部ドメインがもう一つ消えました。 ファイルサイズの削減はごくわずかですが、接続の確立という手間が一つ減ります。

やったこと3：書体のウェイトを絞った

ここが本丸でした。

Google Fonts から3種類の書体を読み込んでいます。それぞれ複数の太さ（ウェイト）を指定していました。

このとき配信されるCSSファイルの大きさを測ったところ、575KBありました。

なぜCSSがそんなに大きいのか

日本語フォントは文字数が膨大です。そのためGoogle Fonts は、フォントを100個以上に分割して配信しています。表示に必要な範囲だけを取りに行く仕組みです。

この仕組み自体は優れています。しかし「どの範囲がどのファイルにあるか」の目録が巨大になります。それが575KBの正体でした。

目録を読み終えるまで、ブラウザは次に進めません。これがブロック時間の主因です。

失敗した試み

Google Fonts には言語を絞り込むパラメータがあります。日本語とラテン文字だけに限定すれば、目録が小さくなるはずです。

試しました。結果は575KBのまま、まったく変わりませんでした。

調べたところ、現行のAPIではこのパラメータは無視される仕様でした。古い情報を信じて時間を使ったことになります。

効いた方法

CSSを調べ直し、実際に使っている太さを洗い出しました。

使っていない太さを外しました。

4割の削減です。

最終結果

点数は3点しか上がりませんでした。

しかしFCPは2.2秒短縮されています。訪問者が「真っ白な画面を見ている時間」が3割減ったということです。

点数と体験は、必ずしも一致しません。

61点はダメなのか

ここが本題です。

結論から言えば、61点であること自体は問題ではありません。 ただし、それを判断するには点数以外を見る必要があります。

他の指標を見てください

CLS と TBT は、実際の使い心地に直結する指標です。 

ここが良好であることは、パフォーマンススコアの数字より重要かもしれません。

CLSは「読もうとした瞬間に広告が入って文字がずれる」あの現象を数値化したものです。0.007はほぼゼロです。

100点に近づける方法はあります

実は、あと何をすれば点数が上がるかは分かっています。

残っている最大の要素は、見出しに使っている明朝体です。この書体だけで244個の定義があり、CSSの大半を占めています。

これを外せば、点数は確実に上がります。

しかし、そうしませんでした。

なぜやらなかったのか

明朝体の見出しは、このサイトの見た目そのものだからです。

書体を変えれば、サイトの印象が変わります。落ち着いた雰囲気を作っているのは、あの細い明朝体です。

それを数点のスコアと引き換えに捨てる判断は、目的と手段が入れ替わっています。

速度を上げるのは、訪問者に快適に見てもらうためです。快適さのために見た目を損なうなら、本末転倒です。

100点を目指すときのリスク

高速化には、代償を伴う手法がいくつもあります。発注する側として知っておくべきものを挙げます。

書体を減らす・やめる

最も効果が大きく、最もリスクが大きい選択です。日本語のWebフォントは重いので、外せば確実に速くなります。

その代わり、訪問者のパソコンやスマホに入っている書体で表示されます。

 WindowsとMacで見た目が変わり、デザインの統一感は失われます。

画像を減らす・圧縮を強める

写真の画質を落とせば軽くなります。

ただし商品写真や施工事例では、画質がそのまま説得力になります。 

化粧品や飲食店なら致命的です。

JavaScriptを削る

アニメーション、スライドショー、アコーディオンなどを外せば軽くなります。

ただしそれらは訪問者の理解を助けるために入れたはずのものです。

アクセス解析を外す

Google Analytics や広告タグは、それ自体が読み込みの負荷になります。

外せば点数は上がります。

しかし解析を外せば、サイトがどう使われているか分からなくなります。 

改善の材料を失うことになり、長期的には損です。

共通するのは

どの手法も「速度」と「何か」を交換しています。

交換しているものが何かを理解せずに実行すると、点数は上がったのにサイトの成果は下がるという結果になりかねません。

発注者が判断すべきこと

「表示速度が遅いので改善しましょう」と提案されたとき、次の3つを確認してください。

1. 何を犠牲にするのか

速くなるのは間違いありません。問題は、その代わりに何を失うかです。

書体か、画質か、機能か。これを説明できない業者には任せないほうが安全です。

2. どの指標が問題なのか

「点数が低い」ではなく、「LCPが8秒かかっている」「CLSが0.3ある」のように具体的に言えるかどうか。

点数は結果であって、原因ではありません。

3. 何点を目指すのか、その根拠は

「100点にします」と言われたら、上に挙げたどれかを削ることになります。目標値の根拠を聞いてください。

Googleは点数で順位を決めているわけではない

最後に、誤解されやすい点に触れます。

Googleは表示速度を検索順位の要因の一つにしています。これは公式に表明されています。

ただし、要因の一つです。内容の適切さ、専門性、信頼性といった要素のほうが、はるかに大きな比重を占めます。

また、Googleが実際に見ているのは PageSpeed Insights の点数ではなく、実際の訪問者の環境で計測されたデータです。点数はあくまで参考値であり、測るたびに5点から10点は変動します。

1回の計測結果に一喜一憂する必要はありません。

まとめ

3時間かけて58点から61点。数字としては地味です。

しかし、その過程で次のことが分かりました。

外部サーバーからの読み込みは、ファイルの大きさ以上に接続の手間が響くこと。

日本語のWebフォントは、フォント本体より目録が重いこと。

そして2ページで書体が配信されていないという不具合が見つかったこと。

点数を追いかけた副産物として、実際の問題が見つかったわけです。

そして最後に、これ以上は上げないという判断をしました。

100点に近づける方法は分かっていますが、それは明朝体を捨てることを意味します。

速度は目的ではなく手段です。

手段のために目的を犠牲にする判断は、しないほうが無難と考えています。

自社サイトで実際に試したからこそ、この判断の根拠をお伝えできます。同じ問いに直面している方の参考になれば幸いです。