LiteSpeed Cache プラグインの最適化の現状
LOLIPOP! レンタルサーバーを契約して WordPress を使い始めたのは今年の1月28日、LiteSpeed Cache プラグインを使い始めたのは翌29日からでした。
それから約1カ月の間、少しずつ調整してきました。
トップページの PageSpeed Insights の結果を下表に示します。LiteSpeed Cache プラグインを有効 / 無効にした場合の結果を比較しました。
| 種類 | モバイル (LSCacheあり) | モバイル (LSCacheなし) | PC (LSCacheあり) | PC (LSCacheなし) |
| パフォーマンス | 100 | 31 | 100 | 70 |
| First Contentful Paint | 1.1 秒 | 2.4 秒 | 0.3 秒 | 0.7 秒 |
| Speed Index | 2.2 秒 | 11.2 秒 | 1.1 秒 | 2.2 秒 |
| Largest Contentful Paint | 1.1 秒 | 4.7 秒 | 0.5 秒 | 3.5 秒 |
| Time to Interactive | 1.2 秒 | 19.5 秒 | 0.4 秒 | 4.5 秒 |
| Total Blocking Time | 10 ミリ秒 | 4,650 ミリ秒 | 0 ミリ秒 | 320 ミリ秒 |
| Cumulative Layout Shift | 0 | 0 | 0 | 0.12 |
LiteSpeed Cache プラグイン無効の条件は、URL に /?LSCWP_CTRL=before_optm を付けて測定した結果です。測定の度に若干の数値のブレはありますが、概ね表の結果と大差のない数値が出ています。私の管理しているもう一つの日記、はてなブログの「hiro の長い冒険日記」の PageSpeed Insights の結果は、この日記の LiteSpeed Cache プラグイン無効の結果よりも悪い数値でした。LiteSpeed Cache プラグインを使用している効果が明確に見られると思います。
このサイトは凝った作りをしていませんし、CDN (Content Derivery Network) を使用できている影響もあると思いますので、今月末に CDN の回線の使用量を使い切った場合には、もう一度試してみます。
「画像の最適化」を調整する
前回の記事では、LiteSpeed Cache の「ページの最適化」の方法について記載しました。
CSS と JavaScript の最適化について記載しましたが、実際には「ページの最適化」より先に「画像の最適化」を行っておいた方が良いかと思います。順序が逆になってしまいましたが、私が設定している「画像の最適化」の項目について説明します。前回同様、LiteSpeed Cache プラグインのバージョンは 5.3.3 で検証しています。
前提条件と注意事項と免責については、上記のページを参照ください。
画像の最適化の設定箇所
LiteSpeed Cache プラグインの画像の最適化を設定する所は3箇所あります。
- 「画像の最適化」の [2] 画像最適化設定
- 「ページの最適化」の [4] メディア設定
- 「ページの最適化」の [5] VPI
それぞれについて設定内容を説明します。
項目1 : 「画像の最適化」 -> [2] 画像最適化設定
「画像の最適化」の中の [1] 画像最適化の概要の項目は最適化の進捗等の情報を確認する画面です。実際に設定するのは [2] の 「画像最適化設定」になります。
この項目は、QUIC.cloud に画像を送り、最適化した上で戻す処理を指定する部分です。画像の WebP フォーマットへの変換と、ウェブページへの反映についてもこちらで指定します。
設定している項目の一覧表を以下に記載します。
| 自動要求 Cron | オン (ON) |
| 自動戻し Cron | オン (ON) |
| オリジナル画像の 最適化 | オン (ON) |
| オリジナル バックアップを 削除する | オフ (OFF) |
| 可逆最適化 | オフ (OFF) |
| EXIF / XMPデータを 保存する | オフ (OFF) |
| WebP 画像への置換 | オン (ON) |
| WebP 属性を置換する | 初期状態 (自動で追加) |
| WebP の 特別な srcset | オン (ON) |
| WordPress 画像品質管理 | 82 |
- 自動要求 / 自動戻し Cron は ON にします。QUIC.cloud で画像を最適化するのに必要です。
- オリジナル画像の最適化は ON に、オリジナルバックアップを削除するは OFF にしています。WordPress に上げる画像は NAS にも保管していますが、仮に LiteSpeed Cache を使用しなくなった場合でもオリジナル画像が使用できるように残しています。
- 可逆圧縮化は OFF にしています。元画像を残していますので画質の改善より容量の少なさを選びました。
- EXIF / XMP データを保存するは OFF です。間違って EXIF 情報付きの写真をそのまま載せた場合でも削除してくれる事を期待しています。
- WebP 画像への置換は ON です。PageSpeed Insights で推奨されている画像フォーマットですので、置換するように設定しています。WebP 画像を生成し、対応しているブラウザには自動で WebP 画像を提供するようになり、対応していないブラウザには元の画像フォーマットで渡してくれます。
LiteSpeed will serve .webp images in place of .jpg or .png to browsers where it is supported. (If an unsupported browser requests a page with WebP images on it, LSCache will serve a version with the original image file format to that browser.)
LiteSpeed は、.jpg または .png の代わりに .webp 画像を、それがサポートされているブラウザーに提供します。 (サポートされていないブラウザーが WebP 画像を含むページを要求した場合、LSCache は元の画像ファイル形式のバージョンをそのブラウザーに提供します。)
https://docs.litespeedtech.com/lscache/lscwp/imageopt/#image-webp-replacement
- 「WebP 属性を置換する」は初期状態から変更していません。下記のページによれば画像の属性が自動で追加されて WebP フォーマットが使用されるようになるようです。
Add a new one to the list, if your site has an attribute we don't replace by default.
デフォルトでは置換されない属性がサイトにある場合は、新しい属性をリストに追加します。
https://docs.litespeedtech.com/lscache/lscwp/imageopt/#webp-attribute-to-replace
- WebP の 特別な srcset は ON です。可能な限り WebP フォーマットが提供されるようにしました。
- WordPress 画像品質管理はデフォルトの 82 のままです。
項目2 : 「ページの最適化」の [4] メディア設定
この項目で設定するのは、画像の遅延読み込み (Lazy Load) と低品質画像プレースホルダー (Low Quality Image Placeholder, LQIP) です。初期の読み込み時には同サイズの低品質画像を表示して、その後で通常品質の画像を表示させる事が出来ます。
設定している項目の内容は以下の通りです。
| 画像 遅延読み込み | オン (ON) |
| 基本的な画像 プレースホルダー | 初期値から変更なし (空白) |
| レスポンシブ プレースホルダー | オン (ON) |
| レスポンシブ プレースホルダー SVG | 初期値から変更なし |
| レスポンシブ プレースホルダーの色 | 初期値から変更なし (#cfd4db) |
| LQIP クラウド ジェネレーター | オン (ON) |
| LQIP 品質 | 4 初期値から変更なし |
| LQIP 最小寸法 | 150 x 150 ピクセル 初期値から変更なし |
| バックグラウンドでの LQIP の生成 | オン (ON) |
| 遅延読み込み iframe | オン (ON) |
| 不足しているサイズを 追加する | オン (ON) |
- 画像の遅延読み込みは ON です。これ以外の遅延読み込みに関係する項目は全て ON にしています。
- LQIP クラウドジェネレータは ON です。作成された LQIP の画像が好みに合わない場合には OFF にすれば良いかと思います。
- LQIP 品質は初期値の 4 で使用しています。1～20 の設定範囲の中で中間の 10 にしてみましたが、思ったよりも画像の品質が向上しない割に画像サイズが大きくなってしまいましたので 4 に戻しました。
ググると、他のプラグインで遅延読み込みを使用するので LiteSpeed Cache プラグインのこの項目を無効にしている事例が多いようですが、次の項目の VPI も絡みますので、個人的にはウェブページの最適化は LiteSpeed Cache プラグインで一括で設定した方が良いかと感じています。
項目3 : 「ページの最適化」の [5] VPI
VPI stands for "Viewport Images" and is a service that allows you to exclude above-the-fold images from lazy loading.
VPI は「Viewport Images」の略で、スクロールせずに見える画像を遅延読み込みから除外できるサービスです。
https://docs.litespeedtech.com/lscache/lscwp/pageopt/#vpi
全ての画像を遅延読み込みするのではなく、最初に表示される箇所の画像は除外する為の設定です。設定項目は2つです。
| ビューポートイメージ | オン (ON) |
| ビューポートイメージCron | オン (ON) |
- ビューポートイメージ (VPI) は ON です。こちらは PageSpeed Insights でも指摘される項目です。CSS の最適化が済んでいないページは指摘されてパフォーマンスが落ちています。
- ビューポートイメージ Cron は ON です。Cron で自動生成する設定にしていますが、CSS の最適化の方が優先されるらしく、VPI の最適化は後回しになる傾向があります。
まとめ
WordPress の LiteSpeed Cache プラグインの設定について、前回の CSS と JavaScript の最適化に続いて画像の最適化について調整しました。
WordPress の記事を編集する事なく画像を WebP 化でき、遅延読み込み (Lazy Load) やビューポートイメージの有効も合わせて、PageSpeed Insights の結果を向上させやすいと思います。
現在も一部のページで画像の WebP 画像への置換が済んでいないようで、各ページを読み込む際に少し時間を要する事がありますが、クロールと CSS の最適化が済めば解消できると考えています。
PageSpeed Insights の結果が全てではありませんが、自宅の PC やモバイルルーターの低速な回線に接続しているスマホで自分の日記を読み込ませると、画像がキャッシュに入ってしまえば非常に軽く表示されるのが分かります。
クロールが進み各条件での最適化が更に進めば、より快適な環境になる事を期待しています。
今回のアイキャッチ画像
ハスキー犬を Stable Diffusion WebUI で生成しました。大型犬は苦手ですが漫画の影響でハスキー犬はなんとなく好みです。
コメント