コンテンツへスキップ

WordPress SEO ブログで使用している画像の「次世代フォーマット化」や、サイトの最適化について考える。

画像の次世代フォーマット化と、サイトの最適化について考える。

概要

WP サイトの読み込みが遅いということで、使用している画像ファイルのフォーマットや、キャッシュについてコンサイダーするように、Google Sitekit (プラグイン)から提案を受け対応した時の内容です。

サイトの読み込みが遅い気がしている方や、同じようなことをGoogle に言われてプラグインを検討中の方に。

読み込みが速くなるから、次世代フォーマットや、キャッシを使用する事を考えましょうと。
キャッシュポリシーとか、最適化とかプラグインをとか試せよと。

図1: Google Site Kit のサイト改善提案。レンダリングを妨げるリソースの除外、次世代フォーマットでの画像配信など7項目のリストが表示されている
図1: Google Site Kit のサイト改善提案。レンダリングを妨げるリソースの除外、次世代フォーマットでの画像配信など7項目のリストが表示されている

考え中

次世代フォーマット

なるほど、考えてもいませんでした。画像フォーマットに既に次世代が出てきているんですねー。

Google 検索したら、良きサイトがサクサクと出てきました。ですので細かい説明は別途「画像、次世代フォーマット」などで検索していただければ良いソースが沢山見つかると思いますので割愛します。

簡単に言うと、その名の通り次の時代のフォーマットでした。
「JPEG」が進化したフォーマットが2つと、Google が開発しているフォーマット「WebP」が注目株のようです。(他にもあるのかもですが、これらが軒並み紹介されています。)

いずれも従来の形式に比べ高圧縮との事ですが、それぞれに対応するブラウザの種類に難がある様ですね。どのブラウザでも読める形式のものは無く、覇権争い中の様です。

まあ、情報源が半年くらい前の記事なので現在の状況も調べる必要がありそうではありますが、Google の検索エンジン向けの最適化なので、Google に寄せておけばいいでしょう。

という事で「WebP」 形式に対応する方向で決まりました。

現時点では全てのブラウザがWebP に対応していないので、それ向けに代替の画像を用意しておく必要がありそうです。

余談ですが、WebP のさらに向こうからAVIF というフォーマットもやって来ているらしいです。

キャッシュについて。

キャッシュ用のポリシーを実装すると、ブラウザキャッシュとのやり取り効率化される、というものらしいです。

やって損は無さそうなので、とりあえず何かしらプラグインを入れて、デフォルトで運用(丸投げ)しようかと思います。

コード最適化

これも、プラグインに丸投げの方向で。

プラグインは何が良い?

今回の最大の目玉はWebP 変換のプラグインだなという事で、画像ファイルの一発変換とWebP 非対応ブラウザだった場合の処理も追加してくれる事が前提だと意気込んで検索したところ、大体そんな仕様でした。

そうなるとさらに何を選んで良いか分からんじゃないか。

であれば、
「トップにヒットするプラグインで、いろいろ網羅した都合がいいプラグインがいいんじゃないか。」
ということで適当に翻訳を見ながら埋めてみました。

欲しいなーと思う機能が「ある」、「なし」のみ確認しています。
英語をGoogle 翻訳しつつ、パラパラ読みなので、見落としや間違いもあるかもです。

プラグイン名キャッシュWebP フォーマット画像圧縮サイト最適化
W3 Total Cache
Smush – Lazy Load Images, Optimize & Compress ImagesPro のみ
Imagify – Optimize your Images & Convert WebP20M/月 の制限あり。
WP-Optimize – Clean, Compress, Cache.DB 最適化
EWWW Image Optimizer

意外とWebP 対応が少ない。

W3 Total Cache は確定で入れようと思います。何よりオープンソースです。

EWWW Image Optimizer がWebP も対応なので、画像対策はこれにしようと思います。

と言う訳で方針が決まりました。

じゃあ、最適化してみよう。

最適化の効果を検討するために、現状を確認。
テストの度にスコアが変わるのでホント参考程度に。

スマホは、アクセスが少なくて、フィールドデータがとれない。

図2: PageSpeed Insights のラボデータ(スマホ)。Total Blocking Time 3,680ミリ秒、Largest Contentful Paint 4.9秒、Cumulative Layout Shift 0.22 でいずれも「悪い」評価
図2: PageSpeed Insights のラボデータ(スマホ)。Total Blocking Time 3,680ミリ秒、Largest Contentful Paint 4.9秒、Cumulative Layout Shift 0.22 でいずれも「悪い」評価

PCはこんな感じ

図3: PageSpeed Insights のラボデータ(PC)。Total Blocking Time 280ミリ秒、Largest Contentful Paint 1.0秒、Cumulative Layout Shift 0 でいずれも良好
図3: PageSpeed Insights のラボデータ(PC)。Total Blocking Time 280ミリ秒、Largest Contentful Paint 1.0秒、Cumulative Layout Shift 0 でいずれも良好
図4: PageSpeed Insights のフィールドデータ(PC)。First Input Delay 2ms、Largest Contentful Paint 3.7秒、Cumulative Layout Shift 0.15
図4: PageSpeed Insights のフィールドデータ(PC)。First Input Delay 2ms、Largest Contentful Paint 3.7秒、Cumulative Layout Shift 0.15

EWWW Image Optimizer

インストール、設定。

インストールはポチるだけ。
恐ろしい時代。

図5: EWWW Image Optimizer プラグインのインストール中画面
図5: EWWW Image Optimizer プラグインのインストール中画面

ダッシュボード >「設定」に該当のプラグインの項目が増えていたので、早速クリックしてみます。

図6: WordPress管理画面の「設定」メニュー。一番下に新しく追加された「EWWW Image Optimizer」の項目が表示されている
図6: WordPress管理画面の「設定」メニュー。一番下に新しく追加された「EWWW Image Optimizer」の項目が表示されている

下記の画面が出てきました。

図7: EWWW Image Optimizer の初期設定ウィザード。「Speed up your site」「Save storage space」にチェックが入り、「Stick with free mode for now」を選択
図7: EWWW Image Optimizer の初期設定ウィザード。「Speed up your site」「Save storage space」にチェックが入り、「Stick with free mode for now」を選択

「speed up your site 」
迷わずにチェック。そのために入れました。

「Save storage space」
バックアップを取る的なボタンでしょうか。やばそうな感じではないのでOK しておきます。

「Get 5x more optimization priority support 」
直訳(Google)すると「5倍以上の最適化優先度サポートを取得」
最適化の処理とか優先してもらえる感じの有料オプションでしょうか。
とりあえず、「free」の方で。

NEXT をクリックして、次の設定に進みます。

図8: EWWW Image Optimizer のおすすめ設定確認画面。WebP変換は未チェックの状態で、有効化するとストレージが増える旨の警告が表示されている
図8: EWWW Image Optimizer のおすすめ設定確認画面。WebP変換は未チェックの状態で、有効化するとストレージが増える旨の警告が表示されている

「WebP 変換」を有効にすると、容量が増える。。。。的なメッセージが。
仕方無いと思います。ということで「Continue」をクリックします。

図9: EWWW Image Optimizer のおすすめ設定確認画面。WebP変換にチェックを入れて「Save Settings」を押す直前の状態
図9: EWWW Image Optimizer のおすすめ設定確認画面。WebP変換にチェックを入れて「Save Settings」を押す直前の状態

「Save Settings」して設定は終わりです。

次にこんな画面が開いてきます。
この設定は「新しいアップロードから有効で、既存の画像については、バルク・オプティマイザを使う」との事。

図10: EWWW Image Optimizer のセットアップ完了画面。新規アップロードは自動最適化、既存画像はBulk Optimizerを使うよう案内されている
図10: EWWW Image Optimizer のセットアップ完了画面。新規アップロードは自動最適化、既存画像はBulk Optimizerを使うよう案内されている

最適化の実行

画面の指示に従って、スキャン、最適化を実施。

図11: EWWW Image Optimizer の一括最適化画面。メディアライブラリ内5,909個のアップロードファイルが検出され、スキャン開始ボタンが表示されている
図11: EWWW Image Optimizer の一括最適化画面。メディアライブラリ内5,909個のアップロードファイルが検出され、スキャン開始ボタンが表示されている
図12: 一括最適化のスキャン処理中画面(ステージ2、少々お待ちくださいの表示)
図12: 一括最適化のスキャン処理中画面(ステージ2、少々お待ちくださいの表示)
図13: 一括最適化できる画像が46,954点見つかった画面。「46,954点の画像を最適化」ボタンが表示されている
図13: 一括最適化できる画像が46,954点見つかった画面。「46,954点の画像を最適化」ボタンが表示されている

最適化中。

図14: 一括最適化の実行中画面。46,954件中26件処理済みで、直近に処理したファイルの削減率が一覧表示されている
図14: 一括最適化の実行中画面。46,954件中26件処理済みで、直近に処理したファイルの削減率が一覧表示されている

しばらく放置です。

折をみて、、、設定 >「EWWW Image Optimizer 」を開くと、スコアが出ていました。

結構、最適化された?

図15: EWWW Image Optimizer の設定画面。最適化スコア50%、Local Compression Savings 1.01MBと表示されている
図15: EWWW Image Optimizer の設定画面。最適化スコア50%、Local Compression Savings 1.01MBと表示されている

ダッシュボード >ツール >「EWWW Image Optimizer」を開くと、最適化した画像についての後処理ができる感じでした。

図16: ダッシュボード>ツールの「EWWW Image Optimizer」ページ。最適化済み画像数や再最適化などの後処理メニューが並んでいる
図16: ダッシュボード>ツールの「EWWW Image Optimizer」ページ。最適化済み画像数や再最適化などの後処理メニューが並んでいる

Ludicrous Mode
普段は使わなくても良さそう。

図17: EWWW Image Optimizer の詳細設定画面(Ludicrous Mode 有効化後)。Local、上級者向け、リサイズ、変換などのタブが追加表示されている
図17: EWWW Image Optimizer の詳細設定画面(Ludicrous Mode 有効化後)。Local、上級者向け、リサイズ、変換などのタブが追加表示されている

効果を確認。

スマートフォン

使用前

図18: PageSpeed Insights のラボデータ(スマホ)。Total Blocking Time 3,680ミリ秒、Largest Contentful Paint 4.9秒、Cumulative Layout Shift 0.22 でいずれも「悪い」評価
図18: PageSpeed Insights のラボデータ(スマホ)。Total Blocking Time 3,680ミリ秒、Largest Contentful Paint 4.9秒、Cumulative Layout Shift 0.22 でいずれも「悪い」評価

使用後

図19: PageSpeed Insights のラボデータ(スマホ、最適化後)。Total Blocking Time 2,680ミリ秒、Largest Contentful Paint 10.5秒、Cumulative Layout Shift 0.141
図19: PageSpeed Insights のラボデータ(スマホ、最適化後)。Total Blocking Time 2,680ミリ秒、Largest Contentful Paint 10.5秒、Cumulative Layout Shift 0.141

ページ読み込みにかかる時間「Largest Contentful Paint」が5倍くらいに増えているのは、遅延読込を有効化した結果でしょう。
その代わりに 「Total Blocking Time」が減りました。
まあ、テストする度に結果が変わるので、評価方法を間違えた感じです。
このあと、自分のページに実際にアクセスして見ましたが、体感で圧倒的に速くなっていました。

PC

使用前

図20: PageSpeed Insights のラボデータ(PC)。Total Blocking Time 280ミリ秒、Largest Contentful Paint 1.0秒、Cumulative Layout Shift 0 でいずれも良好
図20: PageSpeed Insights のラボデータ(PC)。Total Blocking Time 280ミリ秒、Largest Contentful Paint 1.0秒、Cumulative Layout Shift 0 でいずれも良好
図21: PageSpeed Insights のフィールドデータ(PC)。First Input Delay 2ms、Largest Contentful Paint 3.7秒、Cumulative Layout Shift 0.15
図21: PageSpeed Insights のフィールドデータ(PC)。First Input Delay 2ms、Largest Contentful Paint 3.7秒、Cumulative Layout Shift 0.15

使用後

図22: PageSpeed Insights のラボデータ(PC、最適化後)。Total Blocking Time 270ミリ秒、Largest Contentful Paint 1.5秒、Cumulative Layout Shift 0
図22: PageSpeed Insights のラボデータ(PC、最適化後)。Total Blocking Time 270ミリ秒、Largest Contentful Paint 1.5秒、Cumulative Layout Shift 0
図23: PageSpeed Insights のフィールドデータ(PC、最適化後)。First Input Delay 2ms、Largest Contentful Paint 3.3秒、Cumulative Layout Shift 0.20
図23: PageSpeed Insights のフィールドデータ(PC、最適化後)。First Input Delay 2ms、Largest Contentful Paint 3.3秒、Cumulative Layout Shift 0.20

数値的には、あまり変わっていないような気がしますが、スマホ、PC ともに読み込みが体感レベルでは「速くなった」と感じます。

上記のスコアはテストする度にかわるので、あまりこれで一喜一憂しないようにします。
冒頭でGoogle Site Kit に指摘されていた、サイト改善提案内容が減っているところを見ると改善された判定なんでしょう。

これもテストの度に変わるので何ともですが。

図24: Google Site Kit のサイト改善提案(最適化後)。項目が「使用していないJavaScriptの削除」「レンダリングを妨げるリソースの除外」「使用していないCSSを削除してください」の3つに減っている
図24: Google Site Kit のサイト改善提案(最適化後)。項目が「使用していないJavaScriptの削除」「レンダリングを妨げるリソースの除外」「使用していないCSSを削除してください」の3つに減っている

増えたファイルの量を確認。

ファイルが増えるって話だったので、FTP でサイトのファイルを一括ダウンロードして、バックアップしておいた実施の前のデータサイズと比べてみたいと思います。

データベースのエクスポートファイルサイズ。

10M くらい増えましたね。

図25: バックアップしたデータベースのSQLファイルのプロパティ比較。左が最適化前で39.8MB、右が最適化後で49.4MBとサイズが増えている
図25: バックアップしたデータベースのSQLファイルのプロパティ比較。左が最適化前で39.8MB、右が最適化後で49.4MBとサイズが増えている

画像ファイル

画像ファイルについては、この「upload」フォルダに保存されているみたいですね。(「違うよ!」という場合、ご指摘いただけますと大変ありがたいです。)
比べてみると倍ぐらいになっていますね。
そりゃ、全部WebP に変換したんだから当然か。ファイルサイズが倍になっていないのは素晴らしいと思います。さすが次世代フォーマット。

図26: uploadsフォルダのプロパティ比較。ファイル数が47,055個から94,985個に倍増している一方、サイズは2.84GBから3.60GBの増加にとどまっている
図26: uploadsフォルダのプロパティ比較。ファイル数が47,055個から94,985個に倍増している一方、サイズは2.84GBから3.60GBの増加にとどまっている

W3 Total Cache

インストールと設定

これもインストールをポチって、有効化するだけです。

図27: W3 Total Cache プラグインのインストール画面。「有効化」ボタンが表示されている
図27: W3 Total Cache プラグインのインストール画面。「有効化」ボタンが表示されている

左サイドのツールバーと上部のツールバーにアイコンが一個追加になっていました。

図28: WordPress管理画面の上部ツールバーに追加された「パフォーマンス」メニューのドロップダウン。背景にW3 Total Cacheのインストールエラーが表示されている
図28: WordPress管理画面の上部ツールバーに追加された「パフォーマンス」メニューのドロップダウン。背景にW3 Total Cacheのインストールエラーが表示されている
図29: WordPress管理画面の左サイドバーに新しく追加された「パフォーマンス」アイコン(オレンジ枠で強調表示)
図29: WordPress管理画面の左サイドバーに新しく追加された「パフォーマンス」アイコン(オレンジ枠で強調表示)

さっそくダッシュボードにアクセスしてみました。

おおっと。
どうやらファイルに書き込みができなくてインストールが完了していない。

図30: FTP認証情報の書き込みエラーメッセージと、その下に表示されたW3 Total Cache セットアップガイドのウェルカム画面(データ収集への同意を求めるAccept/Declineボタン)
図30: FTP認証情報の書き込みエラーメッセージと、その下に表示されたW3 Total Cache セットアップガイドのウェルカム画面(データ収集への同意を求めるAccept/Declineボタン)

下記の内容を書き込んでくれと。

図31: W3 Total Cache のインストールエラー。「Files and directories could not be automatically created」と表示され、wp-config.phpに追記すべきコードが案内されている
図31: W3 Total Cache のインストールエラー。「Files and directories could not be automatically created」と表示され、wp-config.phpに追記すべきコードが案内されている

レンタルサーバーのホームページにログインして管理からFTP で指示されたファイルを開いてみると、確かに書き込み権限がないので、一旦書き込み権限をつけてから、上記の一文を追加。追加後に、権限をもとに戻しておきました。

ページを開きなおすと、メッセージが消えてました。
これで、インストールは正常終了という事で良さそうです。

図32: エラーが消えたW3 Total Cache セットアップガイドのウェルカム画面。データ収集への同意を求めるAccept/Declineボタンが表示されている
図32: エラーが消えたW3 Total Cache セットアップガイドのウェルカム画面。データ収集への同意を求めるAccept/Declineボタンが表示されている

画面の下に「Skip」と「NEXT」のボタンがありましたが、NEXT はAccept が必要なのか、グレーアウトしてましたので、とりあえずSkip をしてみることに。

図33: WordPressの「ご利用ありがとうございます」画面。下部にSKIP/NEXTのボタンがあり、SKIPが選択されている
図33: WordPressの「ご利用ありがとうございます」画面。下部にSKIP/NEXTのボタンがあり、SKIPが選択されている

画面がダッシュボードに変化したようです。
とりあえず、ここではこれ以上出来る事はなさそうです。

図34: W3 Total Cache のダッシュボード画面。キャッシュのクリアボタン群やCaching Statisticsのグラフが表示されている
図34: W3 Total Cache のダッシュボード画面。キャッシュのクリアボタン群やCaching Statisticsのグラフが表示されている

一般設定

図35: WordPress管理画面の「パフォーマンス」サブメニュー。「一般設定」が選択されている
図35: WordPress管理画面の「パフォーマンス」サブメニュー。「一般設定」が選択されている

設定項目がかなりあります。結構難しい話が多い。。。

図36: W3 Total Cache の一般設定画面上部のタブメニュー(一般/ページキャッシュ/Minify/Opcode Cache/データベースキャッシュなど)
図36: W3 Total Cache の一般設定画面上部のタブメニュー(一般/ページキャッシュ/Minify/Opcode Cache/データベースキャッシュなど)

良さそうなサイトを発見。乗っからせていただきます。
下記のサイトでは、「General Setting」として解説されてました。

W3 Total Cache のおすすめの設定方法

https://bazubu.com/w3-total-cache-23854.html

(一般設定の)一般

図37: W3 Total Cache の一般設定「一般」セクション。Preview modeの有効化ボタンと設定保存ボタンが表示されている
図37: W3 Total Cache の一般設定「一般」セクション。Preview modeの有効化ボタンと設定保存ボタンが表示されている

ここは、やることないです。

ページキャッシュ

図38: W3 Total Cache のページキャッシュ設定。「有効化」にチェックが入り、ページキャッシュ方法は「ディスク:拡張」に設定されている
図38: W3 Total Cache のページキャッシュ設定。「有効化」にチェックが入り、ページキャッシュ方法は「ディスク:拡張」に設定されている

ページキャッシュは、「有効化」にチェック。

ページキャッシュ方法は「ディスク:拡張」に設定します。

圧縮

図39: W3 Total Cache の圧縮設定。「有効化」のチェックは外れており(レイアウト崩れのため無効化)、圧縮モードは自動になっている
図39: W3 Total Cache の圧縮設定。「有効化」のチェックは外れており(レイアウト崩れのため無効化)、圧縮モードは自動になっている

圧縮 をいったん有効化したのですが、私の場合サイトのレイアウトが激しく崩れてしまったので、断念。
元に戻しました。

その他の値は、初期設定のままでOK のようです。

Opcode Cache

図40: W3 Total Cache のOpcode Cache設定。「Not Available」と表示され、Validate timestampsは未チェック
図40: W3 Total Cache のOpcode Cache設定。「Not Available」と表示され、Validate timestampsは未チェック

ここは解説がなかったので新機能かなと思います。
PHP をコンパイルしてキャッシュしておく仕組みのようです。

ちょっと怖いので、非活性のまま保留します。

データベースキャッシュ

図41: W3 Total Cache のデータベースキャッシュ設定。「有効化」にチェックが入り、方法は「ディスク」に設定されている
図41: W3 Total Cache のデータベースキャッシュ設定。「有効化」にチェックが入り、方法は「ディスク」に設定されている

キャッシュ有効にします。

Object Cache

図42: W3 Total Cache のObject Cache設定。「有効化」は未チェックのまま保留状態
図42: W3 Total Cache のObject Cache設定。「有効化」は未チェックのまま保留状態

オブジェクトをキャッシュしておく。

保留かな。

ブラウザーキャッシュ

図43: W3 Total Cache のブラウザーキャッシュ設定。「有効化」にチェックが入っている
図43: W3 Total Cache のブラウザーキャッシュ設定。「有効化」にチェックが入っている

ここはデフォルトのまま、有効。

CDN、リバースプロキシ

どちらも負荷分散を目的としてキャッシュ用にサーバーをたてる話になると思います。

別途サーバーが要るはずなので、ひとまずスルーしました。

USER Experience

図44: W3 Total Cache のUser Experience設定。「Lazy Load Images」のみチェックが入り、他のDisable系項目は未チェック
図44: W3 Total Cache のUser Experience設定。「Lazy Load Images」のみチェックが入り、他のDisable系項目は未チェック

Lazy Load Image のみチェックを入れました。
サイトの画面で表示されていない箇所の画像を後から読み込む設定(のはず。)

後は絵文字を無効化とか、WP 埋め込み無効化、jquery 無効化などと思われます。
とりあえず、保留です。

Statistics

サイトの統計を取って、予想通り効果が出ているか確認するための設定の様なので、スルー。

Fragment Cache

図45: W3 Total Cache のFragment Cache設定。フラグメントキャッシュの方法が「Please select a method」(未設定)に戻されている
図45: W3 Total Cache のFragment Cache設定。フラグメントキャッシュの方法が「Please select a method」(未設定)に戻されている

サイトページの各「部品」に個別に参照キーを割り当てて、キャッシュを行う仕組みのようです。

ディスクに設定してみました。

有償の機能だったようなので、元に戻しておきました。

以降は、ライセンスと、管理向けの設定だったので、以上にしました。

このプラグインはキャッシュの設定ですからね。
スピードアップではなくて効率化の話だと思うので、スコアは気にせずに様子見しようと思います。

変にサイトが重くなったとか、表示がおかしくなったとかなければ、今はいいと思います。

感想

体感ですが、以前に比べると「かなり速くなった」と感じています。
今まででもちょっと重いかなーで、「気にならない程度」レベルだと思っていましたが、
今回、最適化をして「結構遅い」のレベルだったと感じました。

プラグインを導入して良かったです。

スコアは測定ごとに変わるのであまり気にしないことにしています。

何より、「次世代フォーマット対応済」なサイトになったのがうれしいです。

以上です。

(Visited 317 times, 1 visits today)
タグ:

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です