PageSpeed Insightsで「レンダリングを妨げるリクエスト」と指摘されたら、Google Fontsのスタイルシートを非同期で読み込む──高速化の解説でよく見かける定番の対策です。ところが、この「教科書どおりの対策」を実行したらかえってスコアが下がった、という開発者の体験記が2026年11月10日にHackerNoonに掲載されました。WordPressサイトではありませんが(Node.js製の個人プロジェクト)、原因と直し方はWordPressサイトにもそのまま当てはまる内容なので、要点を整理します。
📉 何が起きたのか
筆者のサイトは、モバイルのPageSpeedスコアが86点でした。レポートでは「レンダリングを妨げるリクエスト」が指摘され、見込まれる短縮は840ミリ秒。いちばん大きな原因はGoogle Fontsのスタイルシートでした。
そこで、media="print"とonloadを組み合わせてスタイルシートを非同期で読み込む、よく知られた方法を適用したところ、スコアは86点から77点に下がりました。FCP(First Contentful Paint=最初に何かが表示されるまでの時間)は改善せず、CLS(Cumulative Layout Shift=表示中にレイアウトがどれだけずれたかを表す指標)が0.001から0.131に悪化したためです。
理由は単純で、フォントが最初の描画より後に届くようになったからです。文字はまず代替フォントで表示され、本来のフォントが届いた瞬間に幅や行の高さが変わって、ページ全体がガタッと動きます。筆者の言葉を借りれば、コストが「待ち時間」から「ずれ」に移っただけでした。
🔍 本当の原因は3つあった
筆者は小手先の対策をやめて、診断項目を1つずつcurlコマンドで確かめていきました。見つかったのは次の3つです。
- テキスト圧縮が効いていなかった:リバースプロキシの設定にはgzip・zstdの圧縮が書いてあったのに、実際の応答には
Content-Encodingヘッダーがありませんでした。本番環境では、そのプロキシがサーバーの前に入っていなかったのです。HTMLも、76KBのスタイルシートも、圧縮されないまま配信されていました。サーバー側に圧縮の設定を1行足して解決しています。 - 隠れた
@importがあった:数か月前に作った寄付ボタンの部品の中に、Google Fontsを読み込む@importが残っていました。ビルド時にこれがメインのCSSに取り込まれ、すべてのCSSが外部サーバーの応答待ちになっていました。このフォントはシステムフォントに置き換えています。 - いちばん大きな見出しがアニメーション待ちだった:ファーストビューの見出しが、透明(
opacity: 0)から0.8秒かけてフェードインし、さらに最大0.85秒の遅延がついていました。筆者によると、見えていない要素は最大の描画として数えられないため、LCP(Largest Contentful Paint=いちばん大きな要素が表示されるまでの時間)がアニメーションの分だけ遅れていました。アニメーションを0.35秒に縮め、遅延をなくし、最初からほぼ見える状態にして解決しています。
フォントについては、非同期読み込みをやめて自分のサーバーに置く方法(セルフホスト)に切り替えました。woff2ファイルをダウンロードし、@font-faceの定義をHTMLに直接書き、ファーストビューで使う2書体のラテン文字だけをプリロード(先読み)しています。
📊 結果
| 指標(モバイル) | 対策前 | 対策後 |
|---|---|---|
| パフォーマンススコア | 86 | 99 |
| FCP | 3.0秒 | 1.4秒 |
| LCP | 3.2秒 | 2.0秒 |
| CLS | 0.001 | 0.023 |
なお、これは1つのサイトでの体験記で、記事に出てくるのはPageSpeedのレポート上の数値です。実際の訪問者のデータ(フィールドデータ)や、INP・TTFBについては触れられていません。CLSは対策前よりわずかに増えていますが、「良好」の目安とされる0.1以下には収まっています。
🛠 WordPressサイト運営者が確認したいこと
- フォントの非同期読み込みを有効にしているなら、CLSを見比べる:キャッシュ系・高速化系のプラグインには、Google Fontsを非同期で読み込む設定を持つものがあります。オンにする前と後でPageSpeed Insightsを測り、CLSが増えていたら、オフに戻すか、フォントのセルフホストを検討します。
- 圧縮が本当に効いているか、応答ヘッダーで確かめる:プラグインやサーバーの設定画面で「有効」になっていても、実際の応答に反映されているとは限りません。ターミナルで
curl -sI -H "Accept-Encoding: gzip" https://自分のサイト/を実行し、content-encodingの行(gzip、br、zstdなど)が返ってくるかを見ます。HTMLだけでなく、CSSやJavaScriptのURLでも確かめておくと安心です。 - テーマやプラグインのCSSに
@importが残っていないか探す:子テーマのstyle.cssや追加CSSに、昔書いたGoogle Fontsの@importが残っていることがあります。ブラウザーの開発者ツールのネットワークタブで、自分で入れた覚えのないフォントのリクエストがないかを見るのが早道です。 - ファーストビューの見出しや画像にフェードインをかけない:ページビルダーやテーマの「スクロールアニメーション」「表示時のアニメーション」を、ページ最上部のいちばん大きな要素にかけていると、LCPがその分だけ遅れる可能性があります。最上部の要素だけはアニメーションを外すのが無難です。
- 変更は1つずつ、毎回測る:筆者がいちばん強調しているのがこの点です。「フォントを非同期にする」という助言は、あるサイトでは正しく、別のサイトでは逆効果になります。複数の設定を同時に変えると、どれが効いてどれが悪さをしたのか分からなくなります。
まとめ
今回の体験記でいちばん効いた対策は、凝ったテクニックではなく「圧縮がそもそも効いていなかった」という基本の見落としでした。PageSpeed Insightsの指摘は出発点としては役に立ちますが、スコアはあくまで目安です。定番の対策をそのまま当てはめる前に、まず基本の設定が実際に働いているかを確かめ、変更のたびに測り直す──この順番を守るだけで、遠回りをかなり減らせます。
出典: HackerNoon「I Followed the Textbook Fix for PageSpeed and My Site Got Slower」
