久しぶりにGoogle Search Consoleを見てみたのですが、エクスペリエンスの欄を見てみると、モバイルの「ウェブに関する主な指標」が不良になっていました。
実際は改善の必要が最初はチェックが入っていたので、改善して検証を開始したのですが、「合格」となったはずなのに今度は全て不良判定されるという謎な状態になっていました。
何か間違ったかなと思い色々確認したのですが、問題はなさそうでした。実際PC側は同じ状態で問題なくなったので、タイミングが悪かったとかあるのかもしれません。
改善の必要があったのはCLSの項目で、今回のタイトルである画像圧縮とは関係がなかったのですが、こちらも久しぶりにPage Speed Insightを見てみると「次世代画像フォーマットでの配信」がオレンジ色(赤色のマーク程でないが、改善はした方がよい)状態でした。今まではMozillaJPEG(mozJPEG)で問題なかったのですが、どこかで変更が入ったようで、警告が表示されるようになっていました。
そこで、いろいろ改善するなら全部やってしまえということで、いろいろ調べて「次世代画像フォーマットでの配信」にチャレンジしてみました。このブログは基本的にアクセス数が少ないので、運営を考えると有償のWordpressのプラグインを使わないことを目標にしました。その結果、タイトルにある「CompressX」にたどりついたわけです。
目次
最初に気になっていること
始める前から気なっている点として、5年ほど運営してきたこのブログですが、今まで使ってきた画像データを何とかできるのかということです。
新しいフォーマットで画像を配信するということは、今までに対する記事をどうするかの視点を持つ必要がありますよね。選択肢としては二つ。
- 新規記事のみに適応する
- 今までのすべての記事の画像を次世代フォーマット化
それぞれの手間について考えてみると、新規記事のみ対応するのが一番簡単で、画像をアップロードする際に事前に変換しておけば問題ないです。
従来の記事の全ての画像を次世代フォーマットにする場合、従来の記事の差し替えをどうするか、画像の変換をどうするかという点を気にしないといけません。
差し替え作業は手作業でやるのは骨が折れる作業なので自動でしたいところ。ただ、単純に画像を記事を書くときにメディアライブラリで違う画像に差し替えるのでは不安が残ります。これは新規記事のみに適応する場合も同じことが言えます。
複数の画像フォーマットの準備をどうするか
例えばwebp形式で画像を配信したとします。しかし、webpに対応しないブラウザだったら画像を表示できませんよね。最新のAVIFでも同じです。実際はほとんどの方が使うchrome、FireFoxみたいな有名どころのブラウザは全てが対応しています。アクセスの99%が問題なく表示できる環境だといえます。とはいえ、AVIFがMicrosoft Edgeで1年前に対応したレベルなので、見れない環境の人もいないことはないはず。そうなると、一番圧縮効率が良い順番で表示できるようにしたいのですが、単純に画像を差し替えるだけではそれは実現できません。
具体的にはAVIF>WebP>JPEGの順番にブラウザが対応していれば圧縮率の高い画像を表示するという風にしたいわけですが、メディアライブラリにAVIFの画像をアップロードしてしまうと、他のフォーマットに対応できないわけです。これを考えると「大掛かりに変更しないといけないな…」と作業に及び腰でした。
これを考えるだけでも面倒なのに、画像の変換するだけでなく他の画像フォーマットをどうするのかを考えるともっと面倒です。これを自動でやれないかと調べていると色々なツールが出てきます。有償プラグインではアップロードしたときに圧縮してくれたりするみたいです。無償のプラグインだと何かと制約があることが多く、実用的ではないものが多いように感じました。
「CompressX」が良さそう
自分で1から組むかーと思っていた矢先に見つけたのがこちらの記事でした。この方が書いているように「これだよこれ」というプラグイン「CompressX」を見つけることができました。私的に気になったのはインストール数の少なさでした(入れたタイミングで6000程度)。私は圧倒的安定志向なので、あまりほかの方が使わないプラグインは使わない主義者なのですが、画像変換にはいい感じのプラグインがなかったので、使ってみることにしましたが、大正解でした。これが無償なら間違いなく今後の定番プラグインとして伸びていく気がします。
まずこのCompressXでできることを紹介します。
- 画像を一括でAVIF,WebPに変換できる
- どちらか片方だけ生成を選ぶことも簡単
- メディアライブラリに新規アップロードしたファイルを自動で変換(手動に変更も可)
- 画像変換の品質も簡単に選べる
- 任意のフォルダを指定・除外可能
- 画像の表示も自動で設定してくれる
- Apacheは自動設定(htaccess自動生成機能)
- Nginxは手動設定が必要だが比較的簡単
- 変換後の容量が大きくなる場合は変換しない設定もできる
- プラグインを消すだけで簡単に元に戻せる
元記事の方が書いている通りですが、かゆいところに手が届く素晴らしい仕様です。求めていた全てがこのプラグインに入っています。
「CompressX」良し悪し
良いところもこの方が書かれている通りではありますが、私的に良いと思ったのは以下の部分。
- 手軽さ
- わかりやさ
- 元に戻しやすさ
- 細かいところへの配慮
手軽さはプラグインを入れてボタン一つで有効化できます。もう一つ良いのが、そのボタンを一つ有効化すると今まで画像を勝手に変換するみたいな仕様にもなっていないことです。一括変換のボタンを押して初めて変換がスタートして途中でキャンセルもできます。
わかりやすさは表記こそ英語表記しかありませんが、書かれていることもいじるところも少なく簡単なので問題なしです。私がインストールしてやったのはボタンを二つポチポチしただけです。
元に戻しやすさはプラグインを消すだけで元通りにできる点です。Apacheならwp-content以下に自動生成された.htaccessファイルを消して生成した画像データも消してとなりますが、それも全てやってくれます。Nginxの場合はサーバーの設定を変えないといけませんがレベル的には簡単です。
細かいところへの配慮はフォルダの指定ができたり、容量が大きくなる場合は変換しない、PNGは圧縮しないなどです。とにかくシンプルだけど見やすかったり、使いやすかったりと細かいところに配慮がされていると感じました。
一括変換以外にもメディアライブラリからの手動変換や容量を見ることもできて非常にシンプルでよくできていると感じます。
気になったというか、私が悪い部分でもあるのですが、Imagimagickがメモリを食いすぎるので、リソースが少ないマシンだとしっかり最適化しないとフリーズしたりOut of Memory(OOM)でシステムがダウンしたりします。1Core, 1GB RAMだとかなり微妙なスペックで画像の処理は遅いし、結構無理している感じはあります。サーバが画像を変換するときに重いだけなので普段のブログを配信する程度で速度が著しく低下するとかはありません。
私の場合は一括変換をした際にOOMが出て何が問題かわからずひとまずswap領域を大きくとってひとまず変換してから後で最適化をしました。とはいえやはり低スぺVPSではswapを活用した方が安全そうだったので、ひとまず従来はswapなしだったのをswapを2GB確保してお茶を濁す感じにしました。内部でどういう処理をしているかを見せていないからこそ何が悪いのかつかみにくかったという感じです。最終的にphpのスレッド数を制限したりしたので、ここらへんがうまく処理できるようになったら嬉しいですね。
ここら辺のメモリ設定の周りは自分でしろということだとは思いますが、もう少し親切にこの設定を変更したらよいとか指示があったら嬉しいと思いました。
Nginxでの導入について
先ほど軽く触れていますが、Apacheの場合は.htaccessが生成されて自動で設定も終わりますが、Nginxの場合は自分で設定ファイルを変更する必要があります。
ここは親切に公式がドキュメントを用意してくれています(リンク)。英語で書かれていること以外はシンプルだと思いますが、私が導入した際の作業を紹介しておきます。
設定ファイルはNginxでWordPressを触る人には説明は不要だと思いますが、/etc/nginx以下のどこかにあるものです。/etc/nginx/sites-available/example.comと公式ドキュメントには書かれていますが、各サイトごとに設定をわけていなけれれば/etc/nginx/sites-available/defaultというファイルがあるのでそれに追記をしていきます。そのファイル内にはserverというディレクティブがあると思うので、その部分の下の方に以下の文言を追加します。
# BEGIN CompressX
set $ext_avif ".avif";
if ($http_accept !~* "image/avif") {
set $ext_avif "";
}
set $ext_webp ".webp";
if ($http_accept !~* "image/webp") {
set $ext_webp "";
}
location ~ /wp-content/(?<path>.+)\.(?<ext>jpe?g|png|gif|webp)$ {
add_header Vary Accept;
add_header Cache-Control "private";
expires 365d;
try_files
/wp-content/compressx-nextgen/$path.$ext$ext_avif
/wp-content/compressx-nextgen/$path.$ext$ext_webp
$uri = 404;
}
# END CompressX公式サイトのをコピペするだけで問題ありません。
次に画像ファイル(jpg,png,gif,webp)に対するほかのルールがある場合は削除します。自分の場合は以前にキャッシュの時間を設定するようにしていたため以下ような設定を書いていました。
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 365d;
add_header Cache-Control "public, no-transform";
}これを以下のように変更しておきます。コメントをつけてもとに戻したいときに変更しやすいようしておきます。
location ~* \.(js|css|svg|ico)$ {
#js|css|png|jpg|jpeg|gif|svg|ico is original but change by CompressX
expires 365d;
add_header Cache-Control "public, no-transform";
}これを変更したら最後に「/etc/nginx/mime.types」を編集します。以下の二つの文言が存在するように変更します。
image/webp webp;
image/avif avif;私の場合はwebpはもとからあったのでavifの方を追加するだけでOKでした。プラグインを入れてボタンを二つポチポチするだけです。
ちなみに、この設定をしないNginx環境でCompressXを入れるとご丁寧にプラグインのページの上の方に設定ができていないことを教えてくれる親切設計なので、導入忘れみたいな可能性は低めに作られています。
まとめ
次世代画像フォーマットでの配信に簡単に対応することができました。サーバースペックがあれば簡単のですが、私のような貧弱なVPSでやるとPHPの設定などを細かく触らないといけないのが玉に瑕かなという感じです。
ただ、AVIFの画像処理はサーバー的にはかなり重い処理になるので、どうしてもスペックが必要なのは仕方のない部分ではあります。そもそも低スぺVPSに自動変換機能を入れるなという話だとは思いますが…
ひとまず当初の目的も達成できました。Page Speed Insightでもほぼ満点が出せて文句はなさそうです。SEOだけ低いのは面倒で設定していないMetadiscriptionのせいです。適当なことを書くぐらいならそんなに差はないので諦めています。
というわけで配信速度にも大きな影響もでず、通信容量を削減できたということで、簡単に十分な成果が出せました。CompressXは今後人気ツールになる気配がします。
以上です。お読みいただきありがとうございました。