swellでreCAPTCHAを必要なページだけ稼働させたい。(Blog高速化 最終章)
SWELLの高速化の敵。reCAPTCHAは非常に重い。
PageSpeed Insights で計測していると大体 くっそ重たい原因が reCAPTCHA。
reCAPTCHAを取り去るだけでスコアが20−30あがるもんね。
しかも Invisible reCaptcha のプラグイン使っていても結局全てのページにreCAPTCHAのスクリプトは読み込まれてるので全く高速化には役に立たないことが判明。
正直 問い合わせのページ以外はいらないんだよねこのスクリプト。
でも外しちゃうとすぐにスパム飛んできてうざい。
Invisible reCaptchaはPHPのver8使うとエラーでてとんでもないことになるらしいしどうも開発元も2年以上放置しているらしい。
僕のサーバーではいまんとこ普通に動いていたので使えないことはないがやはり不安要素は取り除くべき。
swellの問い合わせページ以外reCAPTCHAスクリプト削ればいいんじゃね?
Invisible reCaptcha は削除 することにした。
reCAPTCHAのKEYとシークレットキーを控えておいてContact Form 7に再登録する。
reCAPTCHAのKEYとかは contactフォーム7のインテグレーションのメニューから普通に登録しておく。
この状態では全ページにreCAPTCHAスクリプトがガッツリ読み込まれて重くなる。
functions.phpに次の関数を追加するとお問い合わせのページ以外スクリプトを読み込まないようになるので関係ないページが軽くなる。
以下はお問い合わせのページURLが
https://mlabo.org/contact/
の形の場合なので contact 以外のスラッグならそれに合わせて変更してください。
function loadRCPv3(){ if (!is_page('contact')){ wp_deregister_script('google-recaptcha'); } } add_action('wp_enqueue_scripts','loadRCPv3',50);
上記をON/OFFできたり利用者を限定したり安全に便利なので直接スクリプト書くよりこのプラグインで実装する方が安全かなー?
swell高速化の最終型
基本はSWELLの機能だけで全て高速化処理は完結。
大好きなEWWWも画像処理だけで遅延読み込みの担当は外してSWELLにやらせる。
javascriptの遅延もSWELLで。
高速化のプラグインは全部外した。
javascriptの遅延について
スクリプトの遅延設定で Googleアナリティクスなどのスクリプトを遅延させないとこれもスコアダウンの元凶になるので PageSpeed Insightsで表示されたURL部分を別ウインドウで開いてブラウザのURL欄からしっかりとスクリプト部分を抜き出す。
僕の例だと念の為ここまでしつこく抽出してあるw
pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-3217770281096014,
pagead2.googlesyndication.com/pagead/managed/js/adsense/m202203070101/show_ads_impl_with_ama_fy2019.js?client=ca-pub-3217770281096014,
これで確実に遅延処理できたようだ。
テストのリザルトに出現しなくなった。
実は大切な遅延時間の最適設定
遅延処理してもPageSpeed Insightで遅延できていないと指摘される場合は遅延させる時間を色々と試してください。だいたい3秒から6秒くらいで収まることが多いと思いますがサーバーの環境によって確実に遅延できる秒数が必ず存在しますのでそこはカットアンドトライで最適秒数を探してくださいね。
これはSWELLの遅延機能以外の場合例えば他テーマでプラグインでjs遅延させている場合でも全く同じです。
ウェブフォントの読み込み中のテキスト表示について
これも減点対象になっているのか?とりあえず自分で突っ込んだFONT類は全てSWAPを宣言したので減点対象からは外れた。
対策したものを カスタマイズの追加CSSに記載した。
@font-face { font-family:Quicksand; font-display: swap; src:url('/fa/Quicksand/Quicksand-Regular.ttf') format("truetype"); }
しかしまだなんか残っているな・・・・。
調べてみるとSWELLが内部で使用可能にしているアイコンぽい。
icomoon.ttf め なんとかしてやらねば。
これもカスタマイズの追加CSSに追加記載
@font-face { font-family: 'icomoon'; src:url('/wp-content/themes/swell/assets/fonts/icomoon.ttf?7ojy2d') format('embedded-truetype'), url('/wp-content/themes/swell/assets/fonts/icomoon.ttf') format('truetype'), url('/wp-content/themes/swell/assets/fonts/icomoon.woff') format('woff'), url('/wp-content/themes/swell/assets/fonts/icomoon.svg') format('svg'); font-weight: normal; font-style: normal; font-display: swap; }
これでフォントの減点は無しになった。
これだけやった状態で計測すると。ロリポップのキャッシュはOFFで計測。
モバイル
デスクトップ
結論
以前のキャッシュやら遅延やらのプラグインたちも決して悪くない。
悪いのはアナリクスやAdSenseなんかのスクリプトやreCAPTCHAのスクリプト&フォントの読み込み時のテキスト表示。
これらは高速化プラグインだけ突っ込んでも根本的な解決にならん。
上記の対策を行うと比較的安定にモバイルもデスクトップも90以上を出すことが多い。
SWELL本体のキャッシュしか使わないし余分なプラグインも無い。
これが最終形態だなw あー楽しかったw
ちなみにお問い合わせのページを速度計測するとreCAPTCHAの邪悪さがよくわかるぜww
単体ページのみでreCAPTCHAを稼働させた場合の効果についての疑問
reCAPTCHAのページごとのスクリプトを制限しちゃうとreCAPTCHAのアルゴリズム上正確にBOTを排除できない可能性もあるって話もあります。
自分のサイト内のページの徘徊具合とかそのあたりがBOT判別のキーになってるとかなってないとか。
実際に お問い合わせだけ単体にスクリプトが発動している状態でどれだけスパムくるか
しばらく検証してみたいと思います。
↓検証結果はこの記事にあります!↓