PageSpeed が 53 点だった原因は Google Site Kit の gsi/client だった|フロントだけ除去して 72 点にした記録

WordPress
この記事は約8分で読めます。

2026年2月、PageSpeed Insights のモバイルが 53 点でした。最終的に 72 点まで上げたのですが、いちばん意外だったのは、効いた原因が画像でもキャッシュでもなかったことです。Google Site Kit が、フロントにも accounts.google.com/gsi/client という外部スクリプトを読み込んでいました。本来は wp-login.php の Google ログインで使うものが、ログインボタンを置いていない通常の記事ページにも、毎回読み込まれていたのです。

対策前後のPageSpeed Insightsモバイルスコアの並列比較。53点から72点へ

gsi/clientが89.8KiBを読み込み、そのうち69.5KiBが未使用と報告されている

先に外し方を置きます。やりたいのは Site Kit を全部止めることではなく、記事ページでは gsi/client を読み込ませず、wp-login.php の Google ログインボタンは残す、という状態です。子テーマの functions.php に次を足すと、フロント側だけ除去できます。作業前にバックアップを取り、できれば Code Snippets プラグインか子テーマで試してください。

これは、WordPress に登録されたスクリプトから accounts.google.com/gsi を含むものを解除する処理です。Site Kit のバージョンによっては、次のフィルターフックで、もっときれいに制御できることもあります。効くかはバージョン依存なので、入れたあとに必ず DevTools で gsi/client が消えているか確認してください。

コードを触りたくない場合、もうひとつの道があります。Site Kit の管理画面から Sign in with Google を切断すれば、gsi/client は読み込まれなくなります。ただしログイン画面の Google ボタンも消えます。Google ログインを使っていないなら Site Kit で切断、ログインページのボタンを残したいなら functions.php でフロントだけ除去。この2択で考えると分かりやすいです。

検証環境:WordPress 6.9 / Cocoon 2.9.0 / Site Kit 1.174.0 / Xserver スタンダードプラン / PHP 8.3.21(2026年2月)。数値は自分のサイトでの実測で、サーバーやキャッシュ設定によって結果は変わります。適用するときは、必ず適用前後を DevTools と PageSpeed Insights で確認してください。

なぜ、置いていないページで重くなるのか

gsi/client は、Google アカウントのログインボタンや One Tap を表示するための JavaScript です。ログインボタンを出すページなら要ります。問題は、トップや記事ページにはボタンを置いていないのに読み込まれていたことでした。89.8 KiB のうち 69.5 KiB が使用されていない、と PageSpeed Insights は報告していました。読み込んでいるのに、ほとんど使われていない。

サイズだけの話でもありませんでした。ネットワークの依存関係ツリーを見ると、リクエストが直列に連鎖していました。

gsi/client の後に gsi/style が続きます。外部ドメインへの接続には DNS と TCP と TLS の時間がかかり、その後続が直列に並ぶことで、描画までの待ち時間が伸びます。使っていない JavaScript でも、ブラウザは読み込み・解析・実行をするので、Total Blocking Time にも響きます。PageSpeed Insights は低速なモバイルを想定して計測するため、この差が大きく出ます。ログインボタンを表示していないフロントで、その負担だけが発生していました。

gsi/clientがクリティカルパスに含まれ、後続のgsi/styleまで約790msの遅延を発生させている

自分のサイトで起きているか確かめる

同じことが起きているかは、Chrome DevTools で確認できます。

  • Network タブを開き、フィルタに gsi と入れて再読み込み。トップや記事ページで accounts.google.com/gsi/client が出れば、フロントでも読み込まれています。
  • Coverage タブ(Cmd / Ctrl + Shift + P から Show Coverage)で再読み込みすると、gsi/client の未使用部分の大きさが視覚的に分かります。
  • ページのソースを gsi で検索して、該当の script タグが出力されていないかを見ます。

Chrome DevToolsのNetworkタブで、トップページにもかかわらずgsi/clientが読み込まれている

次の条件に複数当てはまるなら、見直す価値があります。Google Site Kit を使っている。Sign in with Google を有効化している。PageSpeed Insights や DevTools で accounts.google.com/gsi が出る。ログインボタンを置いていない記事ページでも gsi 系のリクエストが出る。逆に gsi/client が出ていないサイトでは、この対策は要りません。まず確認してから判断してください。

どれだけ変わったか

対策後、PageSpeed Insights のモバイルは 72 点になりました。ここは誤解が出やすいので書いておくと、これは gsi/client を消しただけの単独効果ではありません。同じ調査の中で、Cocoon の高速化設定、画像の遅延読み込み、キャッシュ設定の見直しも触っています。一連の改善後の結果として見てください。それでも、大きく出ていた未使用 JavaScript は 412 KiB から 54 KiB まで減り、そのうち gsi/client は 90 KiB 弱を占めていました。

指標 対策前 対策後 改善幅
パフォーマンススコア 53 点 72 点 +19 点
First Contentful Paint 7.5 秒 3.2 秒 -4.3 秒
Largest Contentful Paint 13.0 秒 5.0 秒 -8.0 秒
Total Blocking Time 260 ms 30 ms -230 ms
Speed Index 7.5 秒 5.0 秒 -2.5 秒
未使用 JavaScript 412 KiB 54 KiB -358 KiB

トップページ https://raplsworks.com/ を、キャッシュクリア後に PageSpeed Insights v5(モバイル)で同一日内に複数回計測した代表値です(2026年2月)。回線・端末は PSI のデフォルト(Slow 4G、Moto G Power 相当)。

体感で大きかったのは LCP でした。13.0 秒から 5.0 秒まで下がり、モバイルで開いたときの重さがはっきり減りました。

対策後はDevToolsでgsi/clientのリクエストが完全に消えている

点数ではなく、その下の詳細を読む

今回の原因が見つかったのは、スコアの数字ではなく、使用していない JavaScript と、ネットワークの依存関係ツリーを一行ずつ読んだからでした。Google が配信しているスクリプトだと、必要なものだろうと思って見逃しやすい。私も最初はそうでした。Google が配信していることと、自分のページで要ることは、別の話です。フロント側で何が起きているかを疑うという意味では、コード記事の更新で 501 Not Implemented が出た話も、原因がテーマや記事本体ではなくサーバー側にあった同じ種類の見落としでした。WordPress の高速化は、テーマ・画像・キャッシュだけでは足りないことがあります。同じように管理画面のサイトヘルスから入り口が見えた例として、永続オブジェクトキャッシュの警告にエックスサーバーで向き合った記録も別に書いています。スコアが伸びないときは、プラグインがフロントで何を読み込んでいるかを、一度のぞいてみてください。

参考にした公式情報

次の公式情報を確認しました(2026年5月6日確認)。記事ページで gsi/client が読み込まれていたことや、除去後の数値は、これらからの引用ではなく、自分のサイトで確認した結果です。

WordPress
この記事を書いた人
rapls

WordPressのプラグインを作っているフリーランスエンジニアです。Web開発はもう6年以上。WordPress.orgで Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator、Prime Cache の4本を公開し、保守を続けながら、日本語ロケールの翻訳エディター(PTE)も務めています。このブログに書くのは、現場で自分が実際にハマって、調べて、直した話です。

raplsをフォローする
raplsをフォローする

コメント

タイトルとURLをコピーしました