Cocoon時代のPSI改善ログ|事前読み込みを整理してJavaScript遅延を試した記録

  • URLをコピーしました!

この記事は、ミコトホドがCocoonを使っていた頃に、PageSpeed Insightsの数値を改善するために試した内容をまとめたLogです。

現在はSWELLへ移行しています。
そのため、この記事は現在のミコトホドの設定紹介ではありません。

それでも、当時の検証で分かった「事前読み込みは多ければ良いわけではない」「JavaScriptの遅延は便利だが、遅らせてはいけないものもある」という考え方は、テーマが変わっても参考になる部分があります。

ここでは、Cocoonの事前読み込み設定を見直したこと、Flying ScriptsでJavaScriptの遅延を試したこと、そしてPageSpeed Insightsの数値がどう変わったのかを記録として残します。

この記事はCocoon時代の検証Logです。現在のミコトホドはSWELLで運用しています。設定内容をそのまま真似するための記事ではなく、PSI改善時に「何を読み込ませているのか」「遅延しても問題ないJavaScriptなのか」を確認した記録として読んでください。

目次

まずは何もしていない状態のPSIスコアを見る

Cocoon時代にPageSpeed Insightsで測定した初期状態のスコア

最初に、記事ページをPageSpeed Insightsで測定しました。
PC表示のスコアは比較的高く出やすかったため、ここではスマホ表示のパフォーマンスを中心に見ています。

この時点で、モバイルのパフォーマンスは62でした。

まずはプラグインに頼る前に、Cocoon側とサーバー側で使える高速化設定を確認し、どこまで改善できるか試すことにしました。

Cocoon側とサーバー側の高速化設定を確認する

当時のCocoon設定では、CSS縮小化とJavaScript縮小化を有効にし、Googleフォントの非同期読み込みもオンにしました。

Lazy Loadについては、この時点では使わずに様子を見ることにしました。

サーバー側ではConoHa WINGを使っていたため、ブラウザキャッシュとWEXAL Page Speed Technologyを有効にしました。

テーマ・サーバー側の高速化後に再計測する

Cocoonとサーバー側の高速化設定後にPageSpeed Insightsで測定したスコア

この段階で、モバイルのパフォーマンスは76まで上がりました。
測定タイミングによって数値は変わり、最高では82まで出ることもありました。

ただ、安定して80台を維持できる状態ではありませんでした。

この時点で入れていたプラグインの数は10です。
ページキャッシュ系のプラグインは使っていませんでした。キャッシュ機能を持つプラグイン自体は入っていましたが、その機能は無効にしていました。

それでもページのもっさり感が気になったため、次にオブジェクトキャッシュを試しました。そこで導入したのが、APCu Managerです。

APCu Managerについては、別の記事で実際に使ってみた記録をまとめています。
APCu Managerを使ってみた記録|WordPressのオブジェクトキャッシュ運用メモ

APCu Manager導入後にPageSpeed Insightsで再び計測してみると、数値は大きくは変わりませんでした。少し上がり、80台前半に届くことはありましたが、決定的な改善とは言いにくい状態です。

体感としてページのもっさり感は軽くなった一方で、PageSpeed Insightsは別の場所を指してきます。
つまり、「JavaScriptの読み込みをどうにかしなさい」という話です。

事前読み込み設定を仕分ける

Cocoon設定の高速化項目には、事前読み込み設定があります。

当時の環境では、外部サービス、広告、分析、フォント、アフィリエイト関連など、複数の接続先があらかじめ設定されていました。

事前読み込みは、必要な接続先を早めに準備できる便利な仕組みです。
ただし、自分のサイトで使っていないサービスまで先に読み込ませると、PageSpeed Insights上では余計な負担として見えることがあります。

そこで今回は、「全部消す」ではなく、当時のサイトで使っているものと使っていないものを分けるつもりで、事前読み込みの内容を見直しました。

当時の事前読み込み設定を分類する

当時の事前読み込み設定を、役割ごとに大きく分けて確認しました。

細かい用途はサイト構成や使用サービスによって変わりますが、当時のミコトホドでは、主に次のような接続先が含まれていました。

1. Googleの分析・広告関連

  • www.googletagmanager.com
  • www.google-analytics.com
  • pagead2.googlesyndication.com
  • googleads.g.doubleclick.net
  • tpc.googlesyndication.com
  • ad.doubleclick.net

2. フォント・ライブラリ・見た目に関係する接続先

  • ajax.googleapis.com
  • www.gstatic.com
  • fonts.googleapis.com
  • fonts.gstatic.com
  • cdnjs.cloudflare.com
  • cdn.jsdelivr.net

3. 外部連携パーツ

  • cse.google.com
  • secure.gravatar.com
  • cdn.syndication.twimg.com
  • cdn.mathjax.org
  • assets.pinterest.com
  • cms.quantserve.com

4. アフィリエイト関連

  • images-fe.ssl-images-amazon.com
  • completion.amazon.com
  • m.media-amazon.com
  • i.moshimo.com
  • aml.valuecommerce.com
  • dalc.valuecommerce.com
  • dalb.valuecommerce.com

こうして見ていくと、当時のミコトホドでは使っていない接続先も多く含まれていました。
Xの埋め込みは使っていない。Amazonの商品画像も使っていない。もしもアフィリエイトも登録はしているものの、長く使っていない。

そのため、事前読み込みをすべて残すのではなく、当時のサイトで本当に必要なものだけを残すつもりで仕分けていきました。

ここで大事なのは、一覧にある接続先を一律で消すことではありません。自分のサイトで使っている外部サービスかどうかを確認して、必要なものだけを残すことです。

Flying ScriptsでJavaScriptの遅延を試す

JavaScriptの読み込みを遅らせるために、当時はFlying Scriptsというプラグインを試しました。

指定した文字列に一致するJavaScriptを遅延できるため、読み込みタイミングを調整したいときに使いやすい印象でした。

ただし、やみくもに設定してはいけません。
遅延させるものによっては、本来動くべき機能が遅れたり、表示が崩れたりします。

当時Flying Scriptsで遅延させたもの

当時のミコトホドでは、以下のようなJavaScriptや配信元をFlying Scriptsに指定して、読み込みタイミングを遅らせてみました。

  • googletagmanager.com
  • google-analytics.com
  • googlesyndication.com
  • googleads.g.doubleclick.net
  • adsbygoogle.js
  • jquery-migrate.min.js

遅延時間は3秒に設定しました。

この一覧は、あくまで当時のミコトホドで試した内容です。
そのまま使うのではなく、自分のサイトで何が読み込まれているかを確認しながら判断する必要があります。

当初は jQuery 本体も遅延させてみましたが、ソースコードの表示まわりが崩れたため、設定から外しました。

JavaScriptの遅延は効果が出ることもあります。
ただし、サイトの機能や表示に必要なものまで遅らせると、別の不具合につながります。

事前読み込みの整理とJavaScript遅延後に再計測する

事前読み込み整理とJavaScript遅延後にPageSpeed Insightsで90台を確認した画面

サーバーの混み具合や測定タイミングによって数値は変わりますが、この検証ではモバイルのパフォーマンスで90台を確認できました。

少なくとも当時の環境では、事前読み込みの整理とJavaScriptの遅延によって、PageSpeed Insights上の数値にははっきり変化が出ました。

ただし、この数値は広告を貼る前の状態です。
実際に広告コードが入れば、読み込む外部リソースが増えるため、PageSpeed Insightsの数値や体感速度に影響が出ます。

この時点でも解決したい問題は残っていましたが、まずは「不要な事前読み込みを整理する」「遅延しても問題ないJavaScriptを見極める」という土台は見えてきました。

なお、ユーザー補助の数値については、SNSアイコンの色のコントラストが影響しているようでした。
今回の主題はパフォーマンス改善なので、ここでは深追いせず、別の課題として残しています。

Amazon、もしも、バリューコマース関連の事前読み込みについては、当時のミコトホドの使い方では優先度が高くないと判断しました。

ページ上部で商品画像や広告パーツをすぐに見せる運用でなければ、最初から接続を準備するより、必要になったタイミングで読み込ませる方が自然です。

まとめ|事前読み込みもJavaScript遅延も、まず中身を確認する

この検証で分かったのは、事前読み込みもJavaScript遅延も、ただ増やせばいい設定ではないということです。

事前読み込みは、必要な接続先を早めに準備するためのものです。
使っていないサービスまで先に読み込ませると、PageSpeed Insights上では余計な負担として見えることがあります。

JavaScript遅延も同じです。
遅延すれば数値が改善することはありますが、必要なスクリプトまで遅らせると、表示崩れや機能不全につながります。

当時のミコトホドでは、事前読み込みを整理し、Flying Scriptsで一部JavaScriptを遅延させることで、PageSpeed Insightsのモバイルスコアは90台まで上がりました。

ただし、これはCocoon時代の環境で行った検証結果です。
現在ミコトホドはSWELLへ移行しているため、同じ設定をそのまま使う記事ではありません。

この記事で残したいのは、設定値そのものではなく、「何を読み込ませているのかを確認し、不要な読み込みを整理する」という考え方です。テーマが変わっても、PSI改善ではまず読み込み内容を確認することが大切です。

  • URLをコピーしました!

コメント

コメントする

目次