Site Kitの「Sign in with Google」が全ページにgsi/clientを読み込みPageSpeedスコアを19点下げていた|原因と対策

Site KitのGoogle Sign-Inが全ページで読み込まれてPageSpeedスコアを下げていた話 WordPress
この記事は約14分で読めます。
PageSpeed Insightsでモバイルスコアの改善に取り組んでいたとき、ある意外な犯人を見つけました。Google Site Kitが挿入する「Sign in with Google」のスクリプト(gsi/client)です。 ログインページでしか使わないはずのこのスクリプトが、トップページや記事ページなどすべてのフロントエンドページで読み込まれていたのです。しかも89.8KiBという決して小さくないサイズで。 本記事では、この問題を発見した経緯から、なぜパフォーマンスに悪影響を与えるのか、具体的な対策方法、そして実際にどの程度の改善効果があったのかを詳しく解説します。 この記事で分かること:
  • Site Kitのどの機能がgsi/clientを全ページに挿入しているのか
  • 89.8KiBのスクリプトがFCP・LCP・TBTにどう影響するか
  • functions.phpでフロントエンドからスクリプトを除去するコード
  • 対策後にPageSpeedスコアが53→72に改善した実測データ

問題の発見:PageSpeed Insightsの警告

PageSpeed Insightsのモバイルスコアが53点で、「使用していないJavaScriptの削減」にgsi/client(89.8KiB・うち69.5KiBが未使用)が表示されていました。さらにクリティカルパスに約790msを追加していたことが判明しました。 対策前のPageSpeed Insightsモバイルスコア サイトの表示速度改善のためにPageSpeed Insightsでモバイル版の計測を行ったところ、スコアは53点。お世辞にも良いとは言えない結果でした。 診断セクションを一つずつ確認していくと、「使用していないJavaScriptの削減」という項目に見慣れないURLが表示されていました。

89.8KiBの未使用JavaScript

gsi/clientが89.8KiBを読み込み、そのうち69.5KiBが未使用と報告されている accounts.google.com/gsi/clientというスクリプトが、89.8KiBを転送し、そのうち69.5KiBが未使用と報告されています。つまり、このスクリプトの約77%がページ上で使われていないということです。

クリティカルパスへの影響

さらに深刻だったのは、「ネットワークの依存関係ツリー」を確認したときです。 gsi/clientがクリティカルパスに含まれ、後続のgsi/styleまで約790msの遅延を発生させている gsi/clientがクリティカルレンダリングパスに含まれており、さらにgsi/styleという後続リソースも呼び出しています。この連鎖だけで約790msをクリティカルパスに追加していたのです。

原因の特定:なぜフロントエンドに読み込まれるのか

原因はGoogle Site Kitプラグインの「Sign in with Google」機能です。wp-login.phpでのみ使用されるスクリプトが、Site Kitの実装により全フロントエンドページにも挿入されていました。

どこから読み込まれているのか

gsi/clientの正体は、Googleの「Sign in with Google」機能を提供するJavaScriptライブラリです。Googleアカウントでのログインボタンやワンタップログインを実装するために使われます。 Site Kitの設定画面。Sign in with Googleが接続済みサービスとして表示されている ではなぜこれがブログの記事ページで読み込まれているのでしょうか。 原因はGoogle Site Kitプラグインでした。Site KitはGoogleの公式WordPressプラグインで、Google Analytics、Search Console、AdSenseなどのサービスをWordPressのダッシュボードから一元管理できる便利なツールです。 Site Kitには「Sign in with Google」という機能があり、WordPressのログインページにGoogleアカウントでのログインボタンを追加できます。この機能自体はwp-login.phpでのみ使用されるものです。 しかし、Site Kitはこのgsi/clientスクリプトをフロントエンドのすべてのページにも読み込んでいたのです。 なお、Site Kitでは「Sign in with Google」以外にも、Consent Mode(同意モード)関連で予期しない挙動が発生することがあります。Consent APIの警告が出て困っている場合は、以下の記事も参考にしてください。

確認方法:Chrome DevToolsで実際に見てみる

Chrome DevToolsのNetworkタブ。トップページでgsi/clientが読み込まれていることが確認できる 実際にChrome DevToolsで確認してみましょう。
  1. サイトのトップページを開く
  2. F12キーでDevToolsを開く
  3. 「Network」タブを選択
  4. フィルターに「gsi」と入力
  5. ページをリロード
accounts.google.com/gsi/clientへのリクエストが表示されれば、同じ問題が発生しています。 また、ページのソースコード(Ctrl+U)を表示して「gsi」で検索すると、Site Kitが挿入した<script>タグを直接確認できます。

なぜこれが問題なのか:技術的な考察

外部ドメインへの接続コスト、後続リソースのリクエストチェーン、メインスレッドの占有が重なり、FCP・LCP・TBTのすべてのCore Web Vitals指標に悪影響を与えます。しかもフロントエンドではまったく使われていないスクリプトです。 「たかが89.8KiB」と思われるかもしれません。しかし、このスクリプトがパフォーマンスに与える影響は、単純なファイルサイズ以上のものがあります。

1. 外部ドメインへの接続コスト

gsi/clientはaccounts.google.comという外部ドメインから読み込まれます。ブラウザがこのスクリプトを取得するためには、DNS解決、TCP接続、TLSハンドシェイク、リクエスト送信とレスポンス受信というステップを踏む必要があります。 自サーバーのリソースであれば接続が再利用されますが、外部ドメインの場合はこれらのステップを最初から行わなければなりません。特にモバイル回線(PageSpeed Insightsでは低速4Gでシミュレーション)では、この接続確立だけで数百ミリ秒かかります。

2. 後続リソースの連鎖

gsi/clientは単独では完結しません。読み込まれた後にgsi/styleという追加のリソースを要求します。つまり以下の連鎖が発生します。 この「リクエストチェーン」がクリティカルパスに含まれると、ページの最初のレンダリングが完了するまでの時間が直接的に増加します。

3. メインスレッドの占有

JavaScriptはブラウザのメインスレッドで解析・コンパイル・実行されます。89.8KiBのスクリプトは、展開後のコード量はさらに大きく、その処理にメインスレッドの時間を消費します。 メインスレッドが占有されている間、ページのレンダリングやユーザー操作への応答は待たされます。これがTBT(Total Blocking Time)の増加につながります。

4. Core Web Vitalsへの影響

これらの要因が組み合わさることで、以下のCore Web Vitals指標に悪影響を与えます。
指標 影響 理由
FCP(First Contentful Paint) 悪化 クリティカルパスにスクリプトが追加され、最初のコンテンツ描画が遅れる
LCP(Largest Contentful Paint) 悪化 メインスレッドの占有によりレンダリングが遅延する
TBT(Total Blocking Time) 悪化 スクリプトの解析・実行がメインスレッドをブロックする
Core Web VitalsはGoogleの検索ランキング要因の一つです。つまり、ログインページでしか使わないスクリプトが、すべてのページのSEOに悪影響を与えている可能性があるのです。

5. そもそも使われていない

最も根本的な問題は、このスクリプトがフロントエンドでまったく使われていないことです。 「Sign in with Google」のボタンが表示されるのはwp-login.phpだけです。トップページや記事ページにGoogleログインボタンは存在しません。にもかかわらず89.8KiBのスクリプトを読み込み、外部への接続を発生させ、メインスレッドの時間を消費しています。 これは完全な無駄であり、除去しても機能には一切影響しません。

対策方法

推奨は子テーマのfunctions.phpでgsi/clientスクリプトをフロントエンドから除去する方法です。wp-login.phpでのGoogleログイン機能は維持したまま、不要なスクリプト読み込みだけを停止できます。 gsi/clientをフロントエンドから除去する方法はいくつかあります。

方法1:functions.phpでスクリプトを除去する(推奨)

以下のコードを子テーマのfunctions.phpまたはCode Snippetsプラグインに追加してください。 方法Aと方法Bの両方を記述していますが、これは保険のためです。Site Kitのバージョンによって、wp_enqueue_scriptで登録されている場合と、直接HTMLに出力されている場合があります。両方を記述することで、どちらのケースでも確実に除去できます。

方法2:Site Kitの「Sign in with Google」を無効化する

Site Kitの管理画面から機能自体を無効化する方法です。
  1. WordPress管理画面 → Site Kit設定
  2. 「接続済みサービス」タブを開く
  3. Sign in with Google」の項目を探す
  4. 「切断」または「無効化」をクリック
この方法はコードの追加が不要ですが、ログインページでのGoogleログイン機能も使えなくなります。Googleアカウントでのログインを使用していない場合はこちらが最も簡単です。

方法3:条件付きで読み込む(上級者向け)

Site KitのフィルターフックでSign in with Googleの出力を制御する方法です。 このフィルターが利用可能かはSite Kitのバージョンに依存します。利用できない場合は方法1を使用してください。

対策後の確認

対策を適用した後、以下の手順で確認します。
  1. サイトのキャッシュをクリア(キャッシュプラグインのキャッシュ削除)
  2. ブラウザのキャッシュもクリア(Ctrl+Shift+Delete
  3. Chrome DevToolsのNetworkタブで「gsi」をフィルタリング
  4. トップページをリロードして、gsi/clientのリクエストが消えていることを確認
  5. wp-login.phpに直接アクセスして、Googleログインボタンが正常に表示されることを確認(方法1の場合)
キャッシュクリア後も変化がない場合は、ブラウザ・サーバー・プラグインの各キャッシュ層を順番に確認してください。キャッシュの切り分け方法は以下の記事で詳しく解説しています。

対策後の効果

パフォーマンススコアが53点→72点(+19点)に改善し、LCPは13.0秒→5.0秒と8秒短縮されました。TBTも260ms→30msまで大幅に減少しています。 対策後のPageSpeed Insightsモバイルスコア 実際に対策を適用した結果を示します。gsi/clientの除去に加えて、同時に行った他の最適化も含まれていますが、gsi/clientの除去が最も大きな効果をもたらしました。
指標 対策前 対策後 改善幅
パフォーマンススコア 53点 72点 +19点
First Contentful Paint 7.5秒 3.2秒 -4.3秒
Largest Contentful Paint 13.0秒 5.0秒 -8.0秒
Total Blocking Time 260ms 30ms -230ms
Speed Index 7.5秒 5.0秒 -2.5秒
未使用JavaScript 412 KiB 54 KiB -358 KiB
対策後はgsi/clientのリクエストが完全に消えている 特に注目すべきはLCPの改善です。13.0秒から5.0秒へと8秒もの短縮を実現しました。 未使用JavaScriptも412KiBから54KiBまで削減されています。gsi/client(89.8KiB)の除去に加え、関連する改善も行った結果です。

あなたのサイトでも確認すべき理由

Site Kitは400万以上のアクティブインストールを持つ人気プラグインですが、gsi/clientの全ページ挿入に気づいているサイト運営者はごく少数です。PSIでは「Other Google APIs/SDKs」に分類されるため見落としやすい問題です。 この問題が厄介なのは、気づきにくい点にあります。 Site Kitは非常に人気のあるプラグインで、WordPressの公式ディレクトリで400万以上のアクティブインストールを誇ります。Sign in with Google機能を有効にしている(あるいはデフォルトで有効になっている)サイトは多いでしょう。 しかし、この機能が全ページにスクリプトを挿入していることに気づいているサイト運営者はどれだけいるでしょうか。 PageSpeed Insightsのレポートでは「Other Google APIs/SDKs」というカテゴリに分類されるため、一見するとGoogleの標準的なスクリプトに見えます。「Googleのスクリプトなら仕方ない」とスルーしてしまいがちです。

チェックリスト

以下に該当する場合は、同じ問題が発生している可能性があります。
  • Google Site Kit プラグインを使用している
  • PageSpeed Insightsでgsi/clientが「使用していないJavaScript」に表示されている
  • Chrome DevToolsのNetworkタブでaccounts.google.com/gsiへのリクエストがある
  • ページのソースにaccounts.google.com/gsi/clientのscriptタグがある
一つでも該当すれば、本記事の対策を適用することでパフォーマンスの改善が期待できます。

まとめ

Site Kitの「Sign in with Google」がログインページ専用のgsi/client(89.8KiB)を全ページに挿入し、PageSpeedスコアを19点下げていた問題は、functions.phpでの除去コードで解決できます。 ポイントをまとめると以下のとおりです。
  • Site Kitの「Sign in with Google」は全フロントエンドページにgsi/clientスクリプトを挿入する
  • 89.8KiBのうち69.5KiB(約77%)が未使用で、完全な無駄になっている
  • 外部ドメインへの接続、リクエストチェーン、メインスレッドのブロックによりFCP・LCP・TBTすべてに悪影響を与える
  • functions.phpでフロントエンドからスクリプトを除去することで、ログイン機能を維持したまま対処できる
  • 実測でパフォーマンススコアが19点改善(53→72)し、LCPは8秒短縮された
WordPressのパフォーマンス最適化では、画像の圧縮やキャッシュの設定といった定番の施策に目が行きがちです。しかし、プラグインが密かに挿入している不要なスクリプトが最大のボトルネックになっているケースもあります。 PageSpeed Insightsの「使用していないJavaScript」セクションを注意深く確認し、本当に必要なスクリプトだけがフロントエンドで読み込まれているか、一度チェックしてみることをおすすめします。

コメント

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