この記事は、ミコトホドがCocoonを使っていた頃に、PageSpeed Insightsの数値を改善するために試した内容をまとめたLogです。
現在はSWELLへ移行していますが、当時の検証で分かった「事前読み込みは多ければ良いわけではない」「JavaScriptの遅延は便利だが、遅らせてはいけないものもある」という考え方は、テーマが変わっても参考になる部分があります。
この記事では、Cocoonの事前読み込み設定を見直したこと、Flying ScriptsでJavaScriptの遅延を試したこと、そして実際にPSIの数値がどう変わったのかを記録として残します。
まずは何もしていない状態のPSIスコアを見る
これは記事ページをPageSpeed Insightsで測定したときの数値です。
PC表示のスコアは比較的高く出やすいため、ここではスマホ表示のパフォーマンスを中心に見ています。
この時点で、モバイルのパフォーマンスは62でした。
まずはテーマ側とサーバー側で使える高速化設定を確認し、プラグインに頼る前にどこまで改善できるか試すことにしました。
最初に見直したのは、Cocoon側とサーバー側で使える高速化設定です。
当時のCocoon設定では、CSS縮小化とJavaScript縮小化を有効にし、Googleフォントの非同期読み込みもオンにしました。Lazy Loadについては、この時点では使わずに様子を見ることにしました。
サーバー側ではConoHa WINGを使っていたため、ブラウザキャッシュとWEXALⓇ Page Speed Technologyを有効にしました。
テーマ・サーバー側の高速化後に再計測する
この段階で、モバイルのパフォーマンスは76まで上がりました。
時間帯によって数値は変わり、最高では82まで出ることもありましたが、安定して80台を維持できる状態ではありませんでした。
この時点で入れていたプラグインの数は10です。
ただし、ページキャッシュ系のプラグインは使っていませんでした。キャッシュ機能を持つプラグイン自体は入っていましたが、その機能は無効にしていました。
それでもページのもっさり感が気になったため、次にオブジェクトキャッシュを試すことにしました。そこで導入したのが、APCu Managerです。
APCu Managerについては、別の記事で実際に使ってみた記録をまとめています。
APCu Managerを使ってみた記録｜WordPressのオブジェクトキャッシュ運用メモ
導入後にPSIで再び計測してみると、数値は大きくは変わりませんでした。ほんの少し上がり、80台前半に届くことはありましたが、決定的な改善とは言いにくい状態です。
体感としてページのもっさり感は軽くなった一方で、PageSpeed Insightsは別の場所を指してきます。
つまり、「JavaScriptの読み込みをどうにかしなさい」という話です。
事前読み込み設定に触れる
事前読み込み設定を仕分ける
Cocoon設定の高速化項目には、事前読み込み設定があります。当時の環境では、外部サービスや広告、分析、フォント、アフィリエイト関連など、複数の接続先があらかじめ設定されていました。
事前読み込みは、必要な接続先を早めに準備できる便利な仕組みです。
ただし、自分のサイトで使っていないサービスまで先に読み込ませると、PageSpeed Insights上では余計な負担として見えることがあります。
そこで今回は、「全部消す」ではなく、当時のサイトで使っているものと使っていないものを分けるつもりで、事前読み込みの内容を見直しました。
事前読み込み設定がされているモノ
ひとつずつ細かく見ると長くなるため、ここでは当時の事前読み込み設定を、役割ごとに大きく分けて確認します。
大きく分けると、Googleの分析・広告関連、サイトの見た目や動きを支えるもの、外部連携パーツ、アフィリエイト関連の4つです。
1.Googleの分析・広告関連
- www.googletagmanager.com
タグマネージャー。今のGoogleアナリティクス（GA4）を動かすためのメインエンジンです。 - www.google-analytics.com
Googleアナリティクス。アクセス解析のデータをGoogleに送る場所です。 - pagead2.googlesyndication.com
Googleアドセンス。広告の「枠」や「設定」を読み込みます。 - googleads.g.doubleclick.net
アドセンス。ユーザーに合わせた広告を配信（追跡）するためのドメインです。 - tpc.googlesyndication.com
アドセンス。広告の「画像」などの重いデータを読み込む場所です。 - ad.doubleclick.net
Google広告関連。広告のクリック計測などに使われます。
2.サイトの「見た目」や「動き」を支える（Cocoonに必須）
- ajax.googleapis.com
Googleが提供するjQueryなどのプログラム置き場。サイトの動きに必要です。 - www.gstatic.com
Googleの共通ファイル置き場。アイコンや共通のプログラムを高速で読み込むために使われます。 - fonts.googleapis.com / fonts.gstatic.com
Googleフォント。おしゃれな文字（Webフォント）を使うための設定とデータです。 - cdnjs.cloudflare.com
世界中のプログラム（ライブラリ）の配信元。アイコンフォント等でよく使われます。 - cdn.jsdelivr.net
コードのハイライト（<pre>タグの装飾）や、Cocoonの一部機能で使われる配信元です。
3.外部連携パーツ
- cse.google.com：Googleカスタム検索用。
- secure.gravatar.com：コメント欄のアバター（顔写真）用。
- cdn.syndication.twimg.com：X（Twitter）のツイート埋め込み用。
- cdn.mathjax.org：数学の難しい公式を表示するため。
- assets.pinterest.com：Pinterestの「保存」ボタン用。
- cms.quantserve.com：海外のアクセス分析サービス（日本ではほぼ不要）。
4.アフィリエイト関連
- images-fe.ssl-images-amazon.com / completion.amazon.com / m.media-amazon.com
Amazonアソシエイトの商品画像や検索機能。 - i.moshimo.com
もしもアフィリエイトの商品画像。 - aml / dalc / dalb.valuecommerce.com
バリューコマースの広告表示や計測用。
こうして見ていくと、当時のミコトホドでは使っていない接続先も多く含まれていました。
Xの埋め込みは使っていない。Amazonの商品画像も使っていない。もしもアフィリエイトも登録はしているものの、長く使っていない。
そこで今回は、事前読み込みをすべて残すのではなく、当時のサイトで本当に必要なものだけを残すつもりで仕分けていきました。
JavaScriptの読み込みを遅延させるためにFlying Scriptsを試す
JavaScriptの読み込みを遅らせるために、当時はFlying Scriptsというプラグインを試しました。
指定した文字列に一致するJavaScriptを遅延できるため、読み込みタイミングを調整したいときに使いやすい印象でした。
ただし、やみくもに設定してはいけません。遅延させるものによっては、本来動くべき機能が遅れたり、表示が崩れたりすることがあります。
Flying Scriptsによって遅延させたJavaScriptと配信元
当時Flying Scriptsで遅延させたもの
当時のミコトホドでは、以下のようなJavaScriptや配信元をFlying Scriptsに指定して、読み込みタイミングを遅らせてみました。
googletagmanager.comgoogle-analytics.comgooglesyndication.comgoogleads.g.doubleclick.netadsbygoogle.jsjquery-migrate.min.js
遅延時間は3秒に設定しました。あくまで当時の環境で試した内容なので、この一覧をそのまま使うというより、自分のサイトで何が読み込まれているかを確認しながら判断する必要があります。
この状態で、PageSpeed Insightsを再度測定してみます。
当初は jQuery 本体も遅延させてみましたが、ソースコードの表示まわりが崩れたため、設定から外しました。JavaScriptの遅延は効果が出ることもありますが、サイトの機能や表示に必要なものまで遅らせると、別の不具合につながる場合があります。
事前読み込みの整理とJavaScript遅延後に再計測する
サーバーの混み具合や測定タイミングによって数値は変わりますが、この検証ではモバイルのパフォーマンスで90台を確認できました。
少なくとも当時の環境では、事前読み込みの整理とJavaScriptの遅延によって、PSI上の数値にははっきり変化が出たと言えます。
ただし、この数値は広告を貼る前の状態です。
実際に広告コードが入れば、読み込む外部リソースが増えるため、PageSpeed Insightsの数値や体感速度に影響が出る可能性があります。
この時点でも解決したい問題は残っていましたが、まずは「不要な事前読み込みを整理する」「遅延しても問題ないJavaScriptを見極める」という土台は見えてきました。
なお、ユーザー補助の数値については、SNSアイコンの色のコントラストが影響しているようでした。
今回の主題はパフォーマンス改善なので、ここでは深追いせず、別の課題として残しています。
Amazon、もしも、バリューコマース関連の事前読み込みについては、当時のミコトホドの使い方では優先度が高くないと判断しました。
ページ上部で商品画像や広告パーツをすぐに見せる運用でなければ、最初から接続を準備するより、必要になったタイミングで読み込ませる方が体感としても軽くなる場合があります。
※現在ミコトホドはSWELLへ移行しています。この記事はCocoonを使っていた当時の検証Logです。「何を読み込ませているのかを確認し、不要な読み込みを整理する」という考え方は、テーマが変わっても参考になる部分があるため、記録として残しています。
コメント