【実測】WordPressが遅い原因はテーマより「Googleのスクリプト」だった。6サイトのCSS・JavaScriptを測った結果

「サイトが遅いから、テーマを軽いものに変えよう」と考える人は多いですが、実際に測ってみると、重いのはテーマではありませんでした。運用している6つのWordPressサイトの、CSSとJavaScriptのサイズを測った結果をまとめます。あわせて、「転送14KB」のような表示が何を意味するのかも説明します。

この記事で分かること

• 6サイトのCSSとJavaScriptの、実際のサイズ
• 「展開後」と「転送」のサイズが違う理由（圧縮）
• 重い原因が、テーマではなく、Googleのスクリプトだった理由
• アクセス解析のタグが、2重に読み込まれていた実例と、見つけ方

測った条件

• 測った日: 2026年10月29日
• 対象: 運用中のWordPress 6サイト（サイトA〜F。名前は伏せています）。トップページ
• 方法: スマホ（iPhone）を想定したUser-Agentで、トップページのHTMLを取得し、読み込まれるCSSとJavaScriptのファイルを、curlで1回ずつ取得してサイズを記録
• 「展開後」は圧縮を戻したあとのサイズ、「転送」は、実際にネットワークを流れるサイズ

限界: 1回ずつの測定で、ブラウザの表示時間や、JavaScriptの実行時間は測っていません。サイトごとに、構成（プラグインや広告）が違います。数字は目安として読んでください。

結果：6サイトのCSSとJavaScript

「転送14KB」とは？展開後と転送のサイズ

サイトEのCSSは、展開後で約82KBですが、ネットワークを流れた量（転送）は、約14.7KBでした。同じファイルで、サイズの数字が2つあるのは、サーバーが、ファイルを圧縮して送っているからです。

• 転送サイズ: 圧縮された状態で、ネットワークを流れる量です。通信の速さに関わります。
• 展開後のサイズ: ブラウザが、圧縮を戻したあとの、実際の中身の量です。ブラウザが読み込んで、処理（解析、実行）するのは、この大きさです。

圧縮の方式は、gzipやBrotliです。CSS、JavaScript、HTMLのような文字のファイルは、大きく縮みます。今回の測定でも、次のようになりました。

気をつける点があります。転送が小さくても、ブラウザが処理するのは、展開後のサイズです。JavaScriptは、サイズが大きいほど、読み込んだあとの解析と実行に、CPUの時間がかかります。この時間は、操作ができない時間（TBT）に、影響します。詳しくは、Total Blocking Timeの記事を参照してください。

なお、すでに圧縮されている画像（WebPやJPEGなど）は、圧縮をかけても、ほとんど縮みません。圧縮が効くのは、主に文字のファイルです。

分かったこと：重いのはテーマではなく、Googleのスクリプト

• 6サイトとも、テーマはGeneratePress（もともと軽いテーマ）でした。CSSは、17〜98KBと、小さい範囲です。使っていないCSSを削る仕組み（UCSS）で、すでに絞られているサイトもあります。
• 大きいのは、JavaScriptです。合計で約560KB〜1.2MB（展開後）。
• その中で一番大きいのは、Googleのアクセス解析のタグ（gtag.js）で、1つで約460〜590KB（展開後）です。広告（AdSense）のスクリプトも、約162KB（転送は約56KB）あります。

つまり、CSSを減らすためにテーマを変えても、効果は小さく、先に見るべきは、アクセス解析や広告のスクリプトでした。ここを減らすほうが、サイズの削減が大きくなります。LCPを改善する方法は、LCPの改善方法の記事も参考になります。

実例：アクセス解析のタグが2重に読み込まれていた

サイトFでは、Googleのタグが2つ、読み込まれていました（展開後は、どちらも約462KB。転送は、それぞれ約157〜160KB）。原因は、2つのプラグインが、それぞれタグを出力していたことです。

• アクセス解析のプラグイン（MonsterInsights）が、GA4のタグを出力
• Googleの公式プラグイン（Site Kit）も、Googleタグを出力

調べると、Site Kit側のタグは、もう一方と同じGA4の計測先を含んでいました。同じページの閲覧を、同じ計測先に、2回送っていた可能性があります（イベント数が、実際より多く記録されることがあります）。

見つけ方

ページのHTMLを取得して、googletagmanager.com/gtag/js?id= が何回出てくるかを数えます。2つ以上あれば、タグが重複しています。

curl -s https://example.com/ | grep -oE "googletagmanager.com/gtag/js\?id=[A-Za-z0-9-]+"

直し方

使っているのは、片方で十分です。今回は、アフィリエイトのリンク追跡を使っていなかったので、MonsterInsightsを無効にして、Site Kitを残しました。無効にしたあと、HTMLで、gtag.js の読み込みが、1つになったことを確認しています。

サイズを自分で測るコマンド

圧縮後（転送）と、展開後のサイズは、次のコマンドで測れます。URLは、調べたいファイルに置き換えます。

# 転送サイズ（圧縮後）
curl -s -o /dev/null -H "Accept-Encoding: gzip, deflate, br" -w "転送 %{size_download} bytes\n" https://example.com/style.css

# 展開後のサイズ
curl -s --compressed -H "Accept-Encoding: gzip, deflate, br" https://example.com/style.css | wc -c

TTFBなど、サーバーの応答の速さの測り方は、TTFBとは？で説明しています。CDNを使ったTTFBの実測は、QUIC.cloudの実測の記事にまとめています。

テーマを変える前に見るもの

1. アクセス解析・広告のスクリプト: 重複がないか、使っていないものがないか。
2. 画像: 大きすぎる画像を、縮小して、軽くする。
3. キャッシュとCDN: 配信の速さを確認する。
4. テーマ: 軽量なテーマ同士の乗り換えは、効果が小さい。今回は、GeneratePress以外のテーマは、測っていません。

注意：CSSを削る方法のデメリット

不要なCSSを削る方法（QUIC.cloudのUCSSなど）は、効果が出やすい一方で、次の点に注意が必要です。ここは、測定した結果ではなく、考え方の整理（推測を含む）です。

• 費用がかかる可能性がある: UCSS（使われているCSSだけを作る機能）は、作るときに、サービス側のクレジットを使います。無料枠を超えると、有料になることがあります。ページ数が多いサイトや、キャッシュを何度も消すサイトでは、使う量が増えます。
• 不具合の原因が増える: 削ったCSSは、サービス側で作られるため、表示が崩れたときに、テーマの問題か、生成されたCSSの問題かを、切り分ける手間が増えます。
• ハッキングからの復旧は、Astraのほうが楽かもしれない: 軽いテーマ（Astraなど）は、最初から余分なCSSが少なく、外部のサービスに頼る部分が少なくてすみます。そのぶん、改ざんされたときに、元の状態へ戻して確かめる作業が、単純になる可能性があります。ただし、これも、実際に比べて測ったものではありません。

まとめ

• 「転送14KB」は、圧縮されたあとの通信量で、展開後（約82KB）より、小さい。ブラウザが処理するのは、展開後のサイズ。
• 6サイトの測定では、CSSは小さく、重いのはJavaScript（特にGoogleのタグ）だった。
• アクセス解析のタグが、2つのプラグインで、重複していた例があった。HTMLで、gtag.js の回数を数えると、見つかる。
• テーマを変える前に、スクリプトの重複と、画像を確認する。

※ 測定は、1回ずつの結果で、2026年10月29日の時点のものです。サイトの構成によって、結果は変わります。