お問い合わせフォームにスパム対策としてreCAPTCHA v3を導入したのですが、初期状態だとサイトの全ページでバッジとスクリプトが読み込まれてしまうことに気づきました。フォームがあるのはお問い合わせページだけなのに、他のページにも同じ読み込みが発生していたので、対象ページを絞り込んだ方法をまとめます。
気づいたきっかけ
reCAPTCHAを設定した後、ブラウザの開発者ツールでトップページのネットワークタブを見ていたところ、フォームが存在しないページでもgoogle-recaptchaというスクリプトが読み込まれていることに気づきました。画面右下に例の「保護されています」というバッジも、フォームのないページに表示されていました。
なぜ全ページに読み込まれるのか
Contact Form 7のreCAPTCHAモジュールのコードを確認したところ、原因が分かりました。スクリプトの読み込み処理がwp_enqueue_scriptsフックに登録されているのですが、その処理の中で「今開いているページにCF7のフォームが実際に存在するか」を判定していませんでした。reCAPTCHAの機能自体が有効になっていれば、ページの中身に関係なく無条件でスクリプトを読み込む作りになっていたのです。
これはおそらく、ウィジェットやショートコードなど、テンプレートの外からフォームが差し込まれるケースにも対応するための仕様だと思われます。ただ、今回のサイトのようにフォームの設置場所が固定ページ1つだけと分かっている場合には、少し過剰な読み込みになってしまいます。
プラグイン本体を直接編集しなかった理由
原因のコードを見つけた時点で、プラグイン本体のファイルを直接書き換えればすぐに直せることは分かっていました。ただ、プラグインは今後アップデートされる可能性があり、直接編集した内容はアップデートのたびに消えてしまいます。子テーマのfunctions.phpからフックを使って外側から挙動を調整する方法であれば、プラグイン側が更新されても自分のカスタマイズは保持されます。テーマやプラグイン本体を直接書き換えるのではなく、フィルターフックやアクションフックを通じて外側から調整する、というのはWordPressカスタマイズの基本的な作法です。
解決策: 対象ページ以外でスクリプトを外す
プラグイン本体のコードは直接編集せず、子テーマのfunctions.phpで対応しました。CF7がスクリプトを登録し終わった後(優先度20)に、さらに遅い優先度でフックを追加し、お問い合わせページ以外では明示的にスクリプトを取り除く、という方法です。
add_action( 'wp_enqueue_scripts', function () {
if ( is_page( 'contact' ) ) {
return;
}
wp_dequeue_script( 'google-recaptcha' );
wp_deregister_script( 'google-recaptcha' );
wp_dequeue_script( 'wpcf7-recaptcha' );
wp_deregister_script( 'wpcf7-recaptcha' );
}, 30 );ポイントは優先度の数値です。CF7側の登録処理が優先度20で動いているので、それより後(数値が大きい)のタイミングで実行しないと、そもそもまだ登録されていないスクリプトを取り除こうとしてエラーになったり、処理が効かなかったりします。プラグインが「いつ」その処理を実行しているかを把握してから、それより後のタイミングに自分の処理を差し込む、という考え方はWordPressのフック全般で共通する基本です。
dequeueとderegisterの両方が必要な理由
wp_dequeue_scriptだけでも画面上の読み込みは止まりますが、念のためwp_deregister_scriptも一緒に呼んでいます。dequeueは「このページでの出力を取りやめる」処理、deregisterは「スクリプトの登録自体を取り消す」処理です。他のプラグインやテーマの処理が同じハンドル名を参照して再度エンキューしてしまうケースを考えると、両方セットで呼んでおいた方が安全です。
修正後の確認方法
修正後は、お問い合わせページとそれ以外のページの両方で、開発者ツールのネットワークタブとコンソールを見て、reCAPTCHA関連のスクリプトとバッジの有無を確認しました。あわせて、お問い合わせページでフォームが正常に送信できるかも再テストしています。特定条件でスクリプトを外す系の修正は、外した側だけでなく、本来表示されるべき側が壊れていないかも必ずセットで確認するようにしています。
他のページでも同じような無駄がないか見直した
この一件をきっかけに、他のプラグインが不要なページにもスクリプトやスタイルを読み込んでいないか、一通り見直しました。特にお問い合わせフォーム関連は、フォーム自体が1ページにしかないのに全ページ分の読み込みが発生しやすいプラグインが多い印象です。すべてを完璧にゼロにする必要はありませんが、開発者ツールのネットワークタブでページごとの読み込みファイルを見比べる習慣をつけておくと、こうした「気づいたら直せる無駄」が見つかりやすくなります。
ページ表示速度そのものへの影響は小さくても、こうした細かいチューニングを積み重ねる姿勢自体は、実務のコーディングでも役立つ感覚だと思っています。今回のように「動いているから良し」で終わらせず、なぜその挙動になっているのかまで追いかける癖は、今後もこのブログの記事ネタとして残していきたいです。
まとめ
プラグインが提供する機能は、必ずしも自分のサイトの構成に最適化された形で読み込まれるとは限りません。今回のように「本来1ページにしか要らないはずのスクリプトが全ページで読み込まれている」状態は、体感できるほどの速度低下ではなくても、地味に無駄な読み込みが積み重なる原因になります。プラグインのコードを読んで「いつ」「どの条件で」処理が走っているかを把握できると、こうした無駄を自分で削れるようになります。
