PageSpeed Insights のモバイルスコアを確認したところ、私のサイトは 53 点でした。
正直なところ、最初に見たときは少し落ち込みました。普段から高速化には気をつけていたので、「さすがにもう少し良い数字が出るだろう」と思っていたからです。普段から Cocoon の高速化設定は触っていますし、画像もできるだけ圧縮しています。キャッシュについても、当時は WP Fastest Cache を使って、ページキャッシュやブラウザキャッシュを一通り設定していました。
それでも、PageSpeed Insights のモバイル結果は 53 点です。
「画像が重いのか」「Cocoon の設定が足りないのか」「キャッシュの設定が甘いのか」と思い、よくある高速化対策をひとつずつ確認しました。Cocoon 側の JavaScript 遅延読み込み、画像の遅延読み込み、不要な CSS や JavaScript の見直し、WP Fastest Cache のミニファイ設定などです。
もちろん、触れば少しは変わります。ただ、どれも決定打にはなりませんでした。数字が少し動いても、モバイル表示の重さがはっきり軽くなる感じはありません。「まだどこかに、見落としている原因が残っている」と感じました。
そこで PageSpeed Insights のレポートをもう一度、上から順番に見直しました。そこで目に留まったのが、「使用していない JavaScript の削減」という項目です。
そこに、見覚えのない外部スクリプトが表示されていました。
accounts.google.com/gsi/client ── 89.8 KiB。
測定日: 2026年2月(改善前) / 2026年2月(改善後)
測定対象 URL: https://raplsworks.com/(トップページ)
測定ツール: Google PageSpeed Insights(モバイル)
測定回数: 同条件で複数回測定し、ばらつきを考慮した上で代表値を採用
キャッシュ状態: WP Fastest Cache 有効、ブラウザキャッシュクリア後の状態
最初は、Google が配信しているスクリプトなので、何か必要なものだろうと思っていました。ところが詳細を見ると、89.8 KiB のうち 69.5 KiB が使用されていないと表示されています。
要するに、読み込んでいるのに、ページ上ではほとんど使われていない状態です。
ここから原因を調べ始めました。結果として分かったのは、Google Site Kit の「Sign in with Google」機能が、ログインページ以外のフロントエンドページにも gsi/client を読み込んでいたことです。
この記事では、その原因をどう確認したのか、どのようにフロントエンドだけから除去したのか、実際にどのくらい改善したのかを、私の環境での検証結果としてまとめます。
この記事で分かったこと
私の環境では、Google Site Kit の「Sign in with Google」機能が、本来は wp-login.php で使われるはずの gsi/client（89.8 KiB）を、フロントエンドページにも読み込んでいました。子テーマの functions.php でフロントエンド側だけ除去したところ、ログインページの Google ログイン機能は残したまま、PageSpeed Insights 上の未使用 JavaScript とクリティカルパスを減らせました。私のサイトでは、他の高速化設定の見直しも含めて、PSI モバイルスコアが 53 点から 72 点に改善しました(2026年2月、トップページを PageSpeed Insights v5 で計測)。
検証環境：WordPress 6.9 / Cocoon 2.9.0 / Site Kit 1.174.0 / Xserver スタンダードプラン / PHP 8.3.21(2026 年 2 月時点)
計測条件：PageSpeed Insights v5 モバイル計測 / 計測対象 URL は https://raplsworks.com/(トップページ) / キャッシュクリア後に同一日内で複数回計測した代表値 / 回線・端末は PageSpeed Insights のデフォルト(Slow 4G、Moto G Power 相当)
確認日: 2026年2月(数値計測)、2026年5月6日(公式情報の最終確認)
確認できたこと: 自分のサイト(raplsworks.com)のトップページで gsi/client が読み込まれていた事実、子テーマでの除去後の DevTools / PageSpeed Insights による計測結果、Site Kit 公式ドキュメントと WordPress.org プラグインページの記述
確認できていないこと: 他のテーマ(SWELL、JIN 等)での再現性、他のレンタルサーバー(ConoHa WING、ロリポップ! 等)での挙動、Site Kit 1.174.0 以降のバージョンでの仕様変更、wp-login.php 以外のページ(管理画面の特殊ページ等)での挙動
備考: 本記事の数値は私の環境での実測値であり、サイト構成・サーバー・キャッシュ設定によって結果は変わります。同じ対策を適用する場合は、必ず適用前後の DevTools と PageSpeed Insights のスクリーンショットを残し、自分の環境での効果を確認してください。
※本記事の数値は、私のサイトで 2026 年 2 月に確認した結果です。Site Kit や WordPress の仕様は今後変わる可能性があります。実際に試す場合は、必ずバックアップを取り、適用前後を DevTools と PageSpeed Insights で確認してください。
※本文中の「Site Kit は Google 公式の WordPress プラグイン」「Sign in with Google は WordPress のログインページにボタンを追加できる機能」という説明は、Site Kit 公式ドキュメントと WordPress.org のプラグインページを確認した内容です（2026 年 5 月 6 日確認）。一方で、「通常の記事ページでも gsi/client が読み込まれていた」「除去後に PSI が 53 点から 72 点になった」という部分は、私の環境での実測結果です。
gsi/client は何のためのスクリプトなのか
gsi/client は、Google アカウントでのログインボタンや One Tap ログインを表示するために使われる JavaScript です。
ログインボタンを表示するページであれば、必要になるのは分かります。問題は、私のサイトではトップページや通常の記事ページに Google ログインボタンを置いていなかったことです。
それなのに、PageSpeed Insights では accounts.google.com/gsi/client が読み込まれていました。
「どこから出ているのか」と調べていくと、Google Site Kit の設定画面にたどり着きました。
Site Kit は、Search Console、Analytics、AdSense、PageSpeed Insights などを WordPress 管理画面から確認できる Google 公式の WordPress プラグインです。私も普段から使っています。
その中に「Sign in with Google」という機能があります。この機能を有効にすると、WordPress のログイン画面に Google アカウントでログインするためのボタンを追加できます。公式ドキュメント上でも、標準の WordPress ログインページにボタンを表示できる機能として説明されています。
ところが私の環境では、この機能を有効にした状態で、ログインページではない通常のフロントエンドページにも gsi/client が読み込まれていました。ここは公式仕様として断定するのではなく、少なくとも私の環境で確認できた挙動として書いておきます。
読者がログインする必要のないブログ記事ページで、Google ログイン用の JavaScript が毎回読み込まれていたわけです。
問題はファイルサイズだけではなく、読み込み順にもあった
最初は「89.8 KiB くらいなら、そこまで大きな問題ではないのでは」とも思いました。
しかし、PageSpeed Insights の「ネットワークの依存関係ツリー」を見ると、単なるファイルサイズの問題ではないことが分かりました。
|
1 2 3 4 5 |
クリティカル パスの最大待ち時間: 790 ms https://raplsworks.com — 227 ms, 153.88 KiB /gsi/client(accounts.google.com) — 471 ms, 90.94 KiB /gsi/style(accounts.google.com) — 790 ms, 1.38 KiB |
gsi/client を読み込んだ後に、さらに gsi/style が連鎖して読み込まれます。外部スクリプトを 1 つ呼ぶだけでは終わらず、後続のリクエストが直列に並ぶ構造になっていました。
このとき問題になるのは、主に次の 3 点です。
| 原因 | 影響 | 補足 |
|---|---|---|
| 外部ドメインへの接続 | 初回接続に時間がかかる | accounts.google.com への DNS / TCP / TLS 接続が必要になる |
| リクエストの連鎖 | 描画までの待ち時間が伸びる | gsi/client の後に gsi/style が続いて読み込まれる |
| JavaScript の解析・実行 | TBT に影響する | 使っていない JS でも、ブラウザは読み込み・解析・実行の処理を行う |
特にモバイル計測では、この差が大きく出やすいです。PageSpeed Insights は低速なモバイル環境を想定して計測するため、外部スクリプトの読み込みやメインスレッドの処理がスコアに響きます。
今回のケースでは、ログインボタンを表示していないフロントエンドページで、その負担だけが発生していました。
自分のサイトで同じ症状が出ているか確認する方法
同じ問題が起きているかどうかは、Chrome DevTools で確認できます。
まず、サイトのトップページか通常の記事ページを開きます。次に DevTools を起動し、Network タブを開きます。フィルタ欄に gsi と入力して、ページを再読み込みします。
ここで accounts.google.com/gsi/client や accounts.google.com/gsi/style が表示される場合、フロントエンドでも gsi 系のスクリプトが読み込まれています。
もう少し詳しく見るなら、DevTools の Coverage タブも使えます。
Mac なら Cmd + Shift + P、Windows なら Ctrl + Shift + P を押し、「Show Coverage」と入力して Coverage タブを開きます。その状態でページを再読み込みすると、JavaScript や CSS のうち、実際に使われた部分と使われなかった部分を確認できます。
gsi/client の未使用部分が大きい場合、PageSpeed Insights で表示されている「使用していない JavaScript」の警告と合わせて、かなり納得しやすくなります。
ページソースでも確認できます。ページを開いた状態でソースを表示し、gsi で検索します。accounts.google.com/gsi/client を含む <script> が見つかれば、HTML 側にも出力されています。
対策方針：ログインページは残し、フロントエンドだけ外す
今回やりたいことは、Site Kit の機能を全部止めることではありません。
私が目指したのは、次の状態です。
- 通常の記事ページやトップページでは
gsi/clientを読み込ませない wp-login.phpでは Google ログインボタンを残す- 管理画面やログイン機能には影響を出さない
逆に Google ログインをまったく使っていないなら、Site Kit の設定から「Sign in with Google」自体を切断する方が簡単です。ただし、その場合はログイン画面の Google ログインボタンも消えます。
私の場合は、ログインページ側の動作は残したかったので、子テーマの functions.php でフロントエンドだけ除去する方法にしました。
functions.php に追加したコード
以下は、私が使ったコードを、記事用に整理したものです。作業前に必ずバックアップを取り、できれば子テーマの functions.php か Code Snippets プラグインで試してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
/** * Site Kit の gsi/client をフロントエンドだけで無効化する * * 目的： * - 通常の記事ページやトップページでは gsi/client を読み込ませない * - wp-login.php の Google ログイン機能は残す * * 検証環境： * WordPress 6.9 / Site Kit 1.174.0（2026年2月時点） */ /** * 方法A：WordPress に登録されたスクリプトから除去する */ function rw_remove_sitekit_gsi_registered_scripts() { if (is_admin()) { return; } global $wp_scripts; if (empty($wp_scripts) || empty($wp_scripts->registered)) { return; } foreach ($wp_scripts->registered as $handle => $script) { if (!empty($script->src) && strpos($script->src, 'accounts.google.com/gsi') !== false) { wp_dequeue_script($handle); wp_deregister_script($handle); } } } add_action('wp_enqueue_scripts', 'rw_remove_sitekit_gsi_registered_scripts', 999); add_action('wp_print_scripts', 'rw_remove_sitekit_gsi_registered_scripts', 999); /** * 方法B：HTML に直接出力されている場合の保険 */ function rw_remove_sitekit_gsi_from_html() { if (is_admin()) { return; } ob_start(function($html) { // gsi/client の script タグを除去 $html = preg_replace( '/<script[^>]*accounts\.google\.com\/gsi\/client[^>]*><\/script>/i', '', $html ); // gsi/style の link タグを除去 $html = preg_replace( '/<link[^>]*accounts\.google\.com\/gsi\/style[^>]*>/i', '', $html ); return $html; }); } add_action('template_redirect', 'rw_remove_sitekit_gsi_from_html', 0); |
方法 A は、WordPress に登録されたスクリプトを探して、accounts.google.com/gsi を含むものを解除する処理です。
方法 B は、HTML に直接出力されてしまう場合の保険です。Site Kit 側の出力方法やバージョンによっては、登録済みスクリプトの解除だけでは消えない可能性があるため、HTML 出力から該当タグを取り除く形にしています。
ただし、方法 B は HTML を正規表現で書き換える方法なので、万能ではありません。Site Kit 側の出力形式が変わると効かなくなる可能性があります。公開サイトでいきなり方法 A と方法 B を両方入れるのではなく、まずは方法 A だけで試してください。それでも gsi/client が残る場合に限り、方法 B を追加する方が安全です。
コードを入れた後に必ず確認すること
コードを追加したら、すぐにこの確認をします。
- キャッシュプラグインのキャッシュを削除する
- ブラウザキャッシュを削除する、またはシークレットウィンドウで確認する
- DevTools の Network タブで
gsiを検索する - トップページや記事ページで
gsi/clientが出ないことを確認する wp-login.phpにアクセスし、Google ログインボタンが残っているか確認する
フロントエンドでは消えていて、ログインページではボタンが残っていれば、狙い通りです。逆に、ログインページの Google ボタンまで消えてしまった場合は、いったんコードを戻して、方法 A だけにするか、Site Kit 側の設定を確認してください。
コードを触りたくない場合は、Site Kit 側で切断する
コードを触りたくない場合は、Site Kit の管理画面から「Sign in with Google」自体を切断する方法もあります。
WordPress 管理画面から Site Kit の設定を開き、「接続済みサービス」の中にある「Sign in with Google」を切断します。
この方法なら、gsi/client は読み込まれなくなります。ただし、ログイン画面の Google ログインボタンも使えなくなります。
そのため、次のように考えると分かりやすいです。
| 方法 | 向いている人 | 注意点 |
|---|---|---|
| Site Kit で切断する | Google ログインを使っていない人 | ログイン画面の Google ログインボタンも消える |
| functions.php でフロントエンドだけ除去する | ログインページでは Google ログインを残したい人 | テーマ更新やプラグイン仕様変更後に再確認が必要 |
公式フィルターフックで制御できる場合もある
Site Kit のバージョンによっては、フィルターフックで制御できる場合があります。
|
1 2 3 4 5 6 7 8 9 10 |
/** * Site Kit の Sign in with Google をログインページ以外で無効化する */ add_filter('googlesitekit_sign_in_with_google_enabled', function($enabled) { if (($GLOBALS['pagenow'] ?? '') !== 'wp-login.php') { return false; } return $enabled; }); |
この方法で制御できるなら、HTML を後から書き換えるよりきれいです。
ただし、このフィルターが使えるかどうかは Site Kit のバージョンに依存します。実際に使う場合は、コードを入れた後に必ず DevTools で gsi/client が消えているか確認してください。効かない場合は、無理にこの方法へこだわらず、前述の方法 A から順番に確認するのが安全です。
対策後の PageSpeed Insights の結果
対策後、PageSpeed Insights のモバイルスコアは 72 点になりました(2026 年 2 月、トップページ https://raplsworks.com/ をキャッシュクリア後に PageSpeed Insights v5 で計測した代表値。同一日内に複数回計測しています)。
ここは誤解が出やすいので、はっきり書いておきます。
この改善は、gsi/client を消しただけの単独効果ではありません。Cocoon の高速化設定、画像の遅延読み込み、キャッシュ設定の見直しなども同じ調査の中で触っています。したがって、この記事の数値は「gsi/client 除去を含む一連の改善後の結果」として見てください。
ただし、PageSpeed Insights で大きく出ていた「使用していない JavaScript」は、412 KiB から 54 KiB まで減りました。そのうち gsi/client は 90 KiB 弱を占めていたため、未使用 JavaScript 削減の中では目立っていた要因のひとつでした。
下記は、トップページ https://raplsworks.com/ を、キャッシュクリア後に PageSpeed Insights v5(モバイル計測)で複数回測定した代表値です(2026 年 2 月、同一日内)。回線・端末の条件は PageSpeed Insights のデフォルト(Slow 4G、Moto G Power 相当)を使用しました。
| 指標 | 対策前 | 対策後 | 改善幅 |
|---|---|---|---|
| パフォーマンススコア | 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 |
特に体感で大きかったのは、LCP の改善です。対策前は 13.0 秒でしたが、対策後は 5.0 秒まで下がりました。まだ完璧な数値ではありませんが、モバイルで開いたときの重さはかなり減りました。
同じ症状が出ているか確認した方がいいサイト
今回の問題は、ぱっと見では気づきにくいです。
理由は、gsi/client が Google のドメインから配信されているためです。PageSpeed Insights に表示されても、「Google のスクリプトなら必要なものだろう」と思って見逃しやすいです。私も最初はそうでした。
特に、次の条件に当てはまるサイトは一度確認しておくと安心です。
- Google Site Kit を使っている
- Site Kit の「Sign in with Google」を有効化している
- PageSpeed Insights で
gsi/clientが表示される - DevTools の Network タブで
accounts.google.com/gsiが出てくる - ログインボタンを置いていない記事ページでも gsi 系のリクエストが出る
このうち複数に当てはまる場合は、Site Kit の設定を見直す価値があります。逆に、gsi/client が出ていないサイトでは、この対策を入れる必要はありません。まずは確認してから判断してください。
今回の作業で分かったこと
今回の件で一番強く感じたのは、WordPress の高速化は「テーマ・画像・キャッシュ」だけを見ても足りないことがある、ということです。
Cocoon の設定を見直す。画像を圧縮する。キャッシュを入れる。ここまでは定番ですし、もちろん大事です。
ただ、それでも PageSpeed Insights のスコアが伸びないときは、プラグインがフロントエンドで何を読み込んでいるかを確認した方がいいです。今回のように、普段は管理画面用だと思っていたプラグインが、実はフロントエンドにも外部スクリプトを出していることがあります。
もうひとつ大事なのは、PageSpeed Insights のスコアだけを見ないことです。
点数だけを見ると、「53 点で低い」「72 点で少し良くなった」で終わってしまいます。今回の原因が見つかったのは、「使用していない JavaScript」と「ネットワークの依存関係ツリー」のセクションを丁寧に読んだからでした。改善すべき場所は、結局のところスコアの下にある詳細項目の中に出ていたわけです。
参考にした公式情報
本記事を書くにあたり、次の公式情報を確認しました（2026 年 5 月 6 日確認）。
- WordPress.org：Site Kit by Google プラグインページ
- Site Kit 公式ドキュメント：Sign in with Google
- Google Developers：Site Kit : Sign in with Google Configuration
ただし、通常の記事ページで gsi/client が読み込まれていたことや、除去後の PageSpeed Insights の数値は、上記公式情報から引用したものではなく、私のサイトで実際に確認した結果です。
まとめ
私の環境で PageSpeed Insights の足を引っ張っていた目立つ原因のひとつが、Google Site Kit 経由でフロントエンドに読み込まれていた gsi/client でした。子テーマの functions.php で制御すれば、ログインページの Google ログイン機能は残したまま、通常の記事ページやトップページからは除去できます。
Site Kit を使っていて、PageSpeed Insights に gsi/client が表示されている場合は、まず DevTools の Network タブで gsi を検索してみてください。通常の記事ページにも読み込まれているなら、本記事の対策で改善できる可能性があります。ただし、環境によって挙動は変わるため、必ず適用前後のスクリーンショットと数値を残して確認することをおすすめします。
PageSpeed Insights の数値が思うように伸びないとき、本当に効くのはスコアの下にある詳細項目を丁寧に読むことだと、今回の調査で改めて感じました。
関連記事
- Cocoonでサムネイルがぼやけた｜以前あったRetina設定が見つからなかった話と、子テーマで直した記録 ── 同じく Cocoon テーマでハマった画像周りの話。
- 1記事だけ「検出 – インデックス未登録」が1ヶ月以上続いた話｜URL変更と301リダイレクトで動いた ── 同じく Search Console まわりのトラブルと対処の記録。
コメント