- PageSpeed Insights
- Googleが無料で公開している、ホームページの表示の速さを採点する道具です。URLを入れるだけで、どなたでも同じ点数を確かめられます。
- LCP
- そのページでいちばん大きい部分が表示されるまでの秒数です。開いてから何秒待たされたか、とお考えいただければ十分です。
- SEO対策
- 同じように調べたとき、地図の枠の下に並ぶ「サイトの一覧」に出てくるようにすることです。
- キャッシュ
- 一度読み込んだものを手元に取っておいて、次から速く出す仕組みです。直したのに古いまま見えるのは、たいていこれが原因です。
KB（キロバイト）は、荷物の重さのようなものです。重いほど、開くまで待たされます。電波の弱い場所では、待っているあいだに閉じられます。
このサイトで実際に起きたことです。日本語の文字の形（Webフォント）を読み込むのをやめたところ、取りに行くファイルが50本以上から8本に、読み込む量が975KBから46KBになりました。いずれも本番のサイトでの実測値です。
先に結果
説明の前に数字を出します。同じURL、同じモバイルの条件で測ったものです。
改善前
パフォーマンス
転送量 975KB／リクエスト50本超
改善後
パフォーマンス
転送量 46KB／リクエスト8本
FCP
8.3秒2.6秒
最初の文字や画像が出るまでの「真っ白な時間」
LCP
9.0秒4.1秒
主役のコンテンツが表示されるまで
転送量
975KB46KB
最初の表示に必要なデータ量
改善後のパフォーマンス以外の項目は、ユーザー補助96・おすすめの方法100・SEO100・エージェントによるブラウジング3/3でした。
パフォーマンス
ユーザー補助
おすすめの方法
SEO
エージェントによる
ブラウジング
先に断っておきます
81点は、Googleが「良好」とする90点には届いていません。LCPの4.1秒も、良好の目安である2.5秒を超えたままです。「改善しました」と「十分になりました」は別の話なので、分けて書きます。残っている課題は後半にまとめました。
8.3秒、画面は真っ白でした
FCPは「最初の文字や画像が出るまで」の時間です。ここが8.3秒だったということは、スマートフォンでこのサイトを開いた方は、8秒以上なにもない画面を見ていたということになります。
8秒がどれくらいかというと、信号待ちの半分くらいです。移動中に他の候補と並べて開いている人が、その間ずっと待ってくれるとは思えません。内容を1文字も読まれずに閉じられていた可能性が高いということです。
ホームページ制作を仕事にしている会社のサイトがこの状態だった、というのが実際のところです。
犯人はフォントでした。ページの96%です
PageSpeed Insightsは点数を出すだけでなく、何が何KBを占めているかまで見せてくれます。開いてみると、内訳はこうでした。
- 最初の表示に必要なデータ量：975KB
- うち、Google Fontsの日本語フォント：935KB（96%）
- その内訳は、フォントファイル45本・843KB＋フォント用のCSS 92KB
- 残りの本文・レイアウト・画像すべて合わせて：40KB
読んでいただきたい内容そのものは40KBしかなく、残りの96%は「文字の形」を届けるためのデータでした。低速4Gの環境では、935KBを引くだけで4.7秒ほどかかります。8.3秒の大半はここです。
なぜ日本語フォントはこれほど重いのか
文字数です。英語のアルファベットは大文字小文字と記号を合わせても100文字程度ですが、日本語は常用漢字だけで2,000字を超え、実用上は1万字近くが必要になります。1書体を丸ごと届けようとすると、それだけで数百KB〜1MB級になります。
Google Fontsはこれを賢く分割していて、1つの書体が120以上の小さなファイルに分かれ、ページに出てくる文字が含まれる分だけを読み込む仕組みになっています。理屈のうえでは軽くなるはずでした。
ところが、実際にサイト全体で使われている文字を集めると、結局45本のファイルを引くことになり、843KBに達していました。加えて、どのファイルを読むかを指示するCSS自体が92KBあります。「分割されているから軽い」は、日本語では成り立ちませんでした。
ここは実際に測るまで気づけなかった部分です。仕組みの説明としては正しく、それを信じたまま運用していました。
前言を撤回して、撤去しました
5日前の記事で、パフォーマンスが90点止まりだった理由について、こう書きました。
主な要因は日本語のウェブフォントで、日本語は文字数が多いため、フォントの読み込みがどうしても重くなります。読みやすさとのトレードオフなので、体裁を犠牲にしてまで100点を取りにいくつもりはありません。
この判断を変えました。
「トレードオフ」と書いたのは、失うものと得るものが釣り合っているという前提があったからです。しかし実際に測ってみると、釣り合ってなどいませんでした。ページのほぼ全部がフォントで、そのために8秒待たせていた。これは天秤ではなく、ただの一方的な損です。
書体がわずかに変わることと、8秒間なにも表示されないこと。並べてみれば選ぶ方は決まっていました。
実際にやった3つのこと
1. 日本語のWebフォントを読むのをやめた
代わりに、訪問者の端末にすでに入っている書体を使う指定に切り替えました。iPhoneやMacならヒラギノ、Windowsなら游ゴシック、Androidなら端末内蔵のNoto Sans JPが使われます。ダウンロードが発生しないので、待ち時間はゼロです。
なお、見出しの数字と英字に使っている欧文フォント（Manrope）は24KBしかないので、そのまま残しました。欧文は文字数が少ないぶん、この程度で済みます。
2. アクセス解析タグを後回しにした
Googleアナリティクスの計測タグは、圧縮後でも186KBあります。これをページの表示が終わったあとに読み込むように変えました。計測に必要な準備だけ先に済ませておけば、数値は落ちません。
解析タグは「訪問者に見せるもの」ではなく「こちらが知るためのもの」です。訪問者を待たせてまで先に読む理由がありません。実際に書いたコードと、この変更で計測を取りこぼす可能性というトレードオフは、アクセス解析タグの重さを実測した記事にまとめました。
3. 結果として、読み込むファイルが50本超から8本になった
フォント45本が丸ごと消えたので、通信の回数そのものが激減しました。975KB → 46KB、リクエスト50本超 → 8本。ファイルサイズだけでなく、通信の往復回数が減ることも速さに効いています。
残っている課題
ここが、この記事でいちばん書きたかった部分です。
1. 81点は、90点ではありません
Googleの区分では0〜49が不良、50〜89が中間、90〜100が良好です。57点から81点へは大きく動きましたが、まだ中間帯です。「良好になりました」とは書けません。
LCPも4.1秒で、良好の目安である2.5秒を超えています。残っている主な指摘は、使っていないJavaScriptが76KB分あること、レイアウトの再計算が発生していること、長く動き続ける処理が3件あることです。ここはこれから手をつけます。
2. 直せないと分かっている項目もあります
「効率的なキャッシュ保存期間を使用する（25KiBの削減余地）」という指摘が残っていますが、これは当社の力では直せません。このサイトが使っている配信の仕組みでは、キャッシュの保持時間が10分に固定されているためです。
直せないものを「これから改善します」と書くのは誠実ではないので、直せないと書いておきます。
3. Windowsでは、以前より文字が細く見えます
端末内蔵の書体を使う方式にした結果、Windowsでは游ゴシックで表示されます。以前より線が細く見える箇所があります。これは承知のうえでの選択で、見栄えを取り戻すために935KBを戻すつもりはありません。
4. これは「実験室の数値」です
PageSpeed Insightsの上部にある「実際のユーザーの環境で評価する」欄は、当社のサイトでは今も「データがありません」と表示されます。アクセス数が集計の基準に届いていないためです。今回の数字はGoogleのサーバー上で1回読み込んだ結果であり、実際の訪問者の回線での体感を保証するものではありません。
ご自身のサイトで確かめる手順
費用はかかりません。5分あれば犯人の見当がつきます。
- 検索で「PageSpeed Insights」と調べ、Googleの公式ページを開く
- 自社サイトのURLを入力して「分析」を押す
- 必ず「携帯電話」タブを見る 訪問者の多くはスマートフォンです
- まずFCPを見る。3秒を超えていたら、それだけ真っ白な画面を見せています
- 下にある「ツリーマップを見る」を開く。何が何KBを占めているかが面積で分かります
- そこでいちばん大きい四角が、あなたのサイトの犯人です
当社の場合はフォントでしたが、実際にいちばん多いのは、圧縮していない写真です。スマートフォンで撮った写真をそのまま載せると1枚で3〜5MBあり、それが数枚並んでいるだけで致命的になります。写真が犯人なら、作り直さなくても圧縮するだけで直ります。
なお、そもそも何で作るかの段階で速さの上限はほぼ決まります。公開後に直すより、作る前に決めておく方が安く済みます。
実際に聞かれた質問
日本語のWebフォントは使わない方がいいのですか？
一概には言えません。判断の材料は「そのフォントが何KBか」です。日本語は1書体で数百KB〜1MB級になることがあり、当社の場合は935KBでした。欧文だけなら数十KBで収まることが多く、見出しの数字や英字に限って使うのは十分に現実的です。まず実測してから決めてください。
うちのサイトも同じ原因でしょうか？
フォントが原因とは限りません。実際には、圧縮していない写真が最大の原因になっているケースの方が多いです。PageSpeed Insightsの「ツリーマップを見る」を開くと、何が何KBを占めているかが面積で分かります。犯人を特定してから手をつけてください。
81点は良い数字なのですか？
Googleの区分では50〜89が中間帯で、良好とされる90には届いていません。改善前が57点だったので大きく上がったのは事実ですが、良好圏に入ったとは言えない状態です。当社としては、この数字をそのまま公開して、残っている課題も併記する方針をとっています。
見た目は悪くなりませんでしたか？
端末によっては変わりました。端末に入っている書体を使う方式にしたため、Windowsでは游ゴシックで表示され、以前より細く見える箇所があります。これは承知のうえでの選択です。8秒間なにも表示されない状態と、書体がわずかに変わることを比べて、後者を選びました。
自分のサイトも測ってもらえますか？
はい。URLをお送りいただければ測定し、何が重さの原因になっているかと、直すとしたら何から手をつけるべきかをお伝えします。無料で、ご依頼いただかなくても費用はかかりません。「今のままで問題ない」なら、直す必要はありませんとお伝えします。
測ってから、直すまで
- 自社サイトのモバイルは57点、真っ白な時間が8.3秒だった
- 原因は日本語Webフォント。975KB中935KB（96%）を占めていた
- 撤去して81点、FCP 2.6秒、46KBになった
- ただし90点には届いておらず、LCPも4.1秒で良好圏ではない
- ご自身で確かめるなら、「携帯電話」タブ＋ツリーマップの2つだけ見れば犯人は分かる
速さの話をしていますが、本題は「思い込みで判断していた」ことの方です。フォントが重いのは知っていました。それでも「読みやすさとのトレードオフだ」と考えて、そのままにしていました。測って初めて、トレードオフですらなかったと分かりました。
5日前に書いた記事の内容を、5日後に自分で覆すことになりました。それでも、間違っていた記録を消すより、なぜ変えたかを書いて残す方がいいと考えます。ご依頼を検討される際は、こういう会社だと思って見ていただければと思います。