この記事の結論
- このブログのスマホ点数（PageSpeed Insights）が低かった一番の原因は、テーマのCSS 約778KBのうち約595KBが「ソースマップ」という開発用メモだったことでした。
- メモは表示に使われません。消すだけで、CSSの転送量が206KB → 42KBになりました（見た目は同じ）。
- 消したのに古いファイルが配られ続けるキャッシュの落とし穴と、点数を下げてしまった失敗例も正直に書きます。
こんにちは、SEOブログ管理人です。
2026年10月に復活させたこのブログ「se0.info」。中身を整えたあと、スマホの表示速度をPageSpeed Insights（以下PSI）で測ると58点でした。画像を圧縮しても、スライダーを止めても、60点前後から上がりません。
原因を一つずつ調べていくと、意外なものが見つかりました。この記事は、その実際の記録です。同じWordPressテーマ「Diver」を使っている方や、「何をしても点数が上がらない」という方の参考になればうれしいです。
作業前の状態：スマホ58点、表示まで5.5秒
作業前のスマホの測定結果（トップページ）はこうでした。
| 項目 | 結果 |
|---|---|
| パフォーマンスの点数 | 58 |
| First Contentful Paint（最初に何か表示されるまで） | 5.5秒 |
| Largest Contentful Paint（一番大きな部分が表示されるまで） | 9.0秒 |
| Cumulative Layout Shift（画面のずれ） | 0 |
画面のずれは0なので問題なし。とにかく「表示が始まるまで」が遅い、という状態です。
原因の探し方：「レンダリングをブロックしているリクエスト」を見る
表示が始まるのが遅いときは、PSIの診断にある「レンダリングをブロックしているリクエスト」を開きます。ここには、読み終わるまで画面の表示を止めてしまうファイルが並びます。
このブログでは、次のようになっていました（抜粋）。
| ファイル | サイズ（転送量） | 止めている時間 |
|---|---|---|
| テーマなどのCSSをまとめたファイル（Autoptimizeが作成） | 159.6KiB | 2,850ミリ秒 |
| jQuery | − | 1,500ミリ秒 |
| Font Awesome（アイコン用CSS） | 7.7KiB | 1,050ミリ秒 |
| lity（ポップアップ用CSS） | 1.7KiB | 750ミリ秒 |
一番の原因は、CSSのまとめファイルでした。しかもPSIは、同じファイルについて「CSSの最小化で約123KiB減らせる」とも言っています。最適化プラグインでまとめて圧縮しているはずなのに、です。
発見：CSSの4分の3が「ソースマップ」という開発用メモだった
そこで、CSSファイルの中身を直接調べました。ファイルの大きさは約778KB。中身の大半は、次のような1行でした。
/*# sourceMappingURL=data:application/json;charset=utf8;base64,eyJ2ZXJzaW9uIjoz… */これはソースマップと呼ばれるものです。テーマの開発者が「圧縮前のどの行が、圧縮後のどこに当たるか」を調べるための開発用メモで、見た目には一切使われません。/* */ で囲まれた「コメント」なので、ブラウザは読み飛ばします。それでも、ダウンロードはされます。
出どころは、テーマ「Diver」（このブログでは 6.0.90）の css/style.min.css でした。このファイル自体が約775KBあり、その大部分がこのメモです。
最適化プラグインがあっても残っていた理由
このブログでは、CSSやJavaScriptをまとめるプラグイン「Autoptimize」を使っています。Autoptimizeは、名前に .min が付いたファイルを「もう圧縮済み」とみなして、中身に手を加えずにまとめます。そのため、メモもそのまま残っていました。
「最適化プラグインを入れているから大丈夫」とは限らない、という例です。
直し方：まとめたCSSからコメントを消す
テーマのファイルを直接書き換えると、テーマを更新したときに元に戻ってしまいます。そこで、Autoptimizeが作ったCSSから、最後にコメントだけ消す小さな設定ファイルを作りました。
wp-content/mu-plugins/ フォルダに、次のようなPHPファイルを置くだけです（mu-pluginsに置いたファイルは、有効化しなくても自動で動きます）。
<?php
// Autoptimize がまとめたCSSから、コメント（ソースマップ等）を消す
add_filter( 'autoptimize_css_after_minify', function ( $css ) {
$stripped = preg_replace( '#/\*[\s\S]*?\*/#', '', $css );
return ( null === $stripped || '' === trim( $stripped ) ) ? $css : $stripped;
} );置いたあとは、Autoptimizeのキャッシュを削除して、CSSを作り直させます。
結果、まとめたCSSは約778KB → 約183KBに。実際にスマホへ送られる量（圧縮後）は、トップページで206KB → 42KB、記事ページで240KB → 76KBになりました。見た目はまったく変わりません。
※ 自分で書いた「/*! 著作権表示 */」のような残す必要があるコメントがある場合は、消す対象を sourceMappingURL だけに絞ってください。
落とし穴：サーバーのキャッシュが古いCSSを配り続けた
ここで一つ、つまずきました。サーバー上のファイルは小さくなったのに、ブラウザから取り出すと、古い大きなファイルが返ってくるのです。
原因は、サーバー側のキャッシュでした。Autoptimizeは、中身が変わってもファイル名が同じになることがあります。そしてこのファイルには「1年間変わらないので、保存して使い回してよい」という印（Cache-Control: max-age=…, immutable）が付いていました。そのため、古いファイルが配られ続けていました。
対策として、CSSのURLの後ろに日付の目印（?v=20261007）を付けました。URLが変わるので、ブラウザもサーバーも新しいファイルを取りに行きます。
CSSを直したのに結果が変わらないときは、URLをそのまま開いてファイルの大きさを確かめるのがおすすめです。
結果：点数はどう変わったか
メモを消したうえで、次の3つも行いました。
- 使っていなかった YouTubeの部品（iframe_api）の読み込みを外す
- 広告ウィジェットの中で重複していた広告スクリプトを1つにまとめる
- アイコン用CSSの配信元を、ほかの部品と同じところ（cdnjs）にそろえる
この段階で、スマホは58点 → 63点でした。さらにjQueryを後読み（defer）にしたところ、90点（最初の表示2.1秒）が出ました。ただし、続けて測ると57点のこともあり、点数はかなりぶれます。
正直に言うと、点数そのものより確実なのは「送る量が5分の1になった」ことです。点数は、測るたびに数十点ぶれることがあります。何回か測って、真ん中の値で判断するのがよいと思います。
jQueryを後読みにする前に確かめたこと
jQueryを後読みにすると、jQueryを使うスクリプトが先に動いてエラーになることがあります。今回は次のことを確かめてから行いました。
- ページの中に直接書かれたスクリプトに、jQueryを使うものがないこと
- 記事の本文（このブログでは <script> を含む記事が36本）、ウィジェット、テーマの設定に、jQueryを使うものがないこと
- jQueryを使う部品（スライダー・ポップアップ・コメント欄など）が、すでにすべて後読みになっていること
後読みのスクリプトは、書かれた順番どおりに動きます。jQueryが一番前にあれば、先に用意されます。入れたあとは、ブラウザのコンソールでエラーが出ないことも確かめました。
失敗談：CSSを「後読み」にしたら43点に下がった
実は最初、別の方法を試して失敗しています。
「最初に見える部分の見た目だけ先に読み、残りのCSSは後から読む」という、よく紹介される方法です。以前に保存してあった「最初に見える部分の見た目（約20KB）」を使い、スマホだけこの方式にしました。
結果は43点。点数が下がりました。画面のずれ（CLS）が 0 から 0.523 に悪化したためです。保存してあった指定が古く、記事一覧の並べ方などが足りていませんでした。そのため、残りのCSSが届いた瞬間に、記事一覧の並びが大きく動いていました。
この方法を使うなら、今の見た目に合わせて「最初に見える部分の指定」を作り直す必要があります。古いものを使い回すのは危険、というのが教訓です。
よくある質問
Q. ソースマップを消すと、サイトの見た目は変わりますか？
A. 変わりません。ソースマップはコメントなので、ブラウザは表示に使っていません。開発者がブラウザの開発ツールで元のファイルを調べるときだけ使うものです。
Q. 自分のサイトにもソースマップが入っているか、どう調べればいいですか？
A. PSIで「CSSの最小化」の削減量が大きいファイルを開き、中で sourceMappingURL=data: を検索してみてください。ファイルの大きさに対して見た目の指定が少なすぎる場合も、疑ってみる価値があります。
Q. Autoptimize以外のプラグインでも同じことが起きますか？
A. 分かりません。この記事で確かめたのはAutoptimizeだけです。ほかのプラグインを使っている場合は、出力されたCSSファイルを実際に開いて確かめるのが確実です。
Q. 対策したのに点数が変わりません。
A. まず、サーバーやブラウザのキャッシュで古いファイルが配られていないか確かめましょう。CSSのURLを直接開いて、ファイルの大きさが小さくなっているか見るのが早いです。また、PSIの点数は測るたびにぶれるので、何回か測ってください。
まとめ
- PSIの「レンダリングをブロックしているリクエスト」で、表示を止めているファイルを探す
- 大きいCSSは中身を開いて確かめる。このブログでは約778KBのうち約595KBがソースマップだった
- 最適化プラグインがあっても、
.minの付いたファイルは手付かずのことがある - 直したらキャッシュに注意。URLに目印を付けると確実
- 点数はぶれる。送る量が減ったかを合わせて見る
復活したse0.infoでは、こうした実際に試したことを、うまくいかなかったことも含めて記録していきます。前回までの記事、サーチコンソールの登録方法とGoogleアナリティクス（GA4）の登録方法もあわせてどうぞ。
測定：PageSpeed Insights（スマホ）、se0.info トップページ、2026年10月7日。環境：WordPress 7.1.2、Diver 6.0.90、Autoptimize 3.1.16、Xserver。
