既存のメディアライブラリに対してバッチ処理を実行する

この実行がすること — そして事前にオンになっていなければならないもの

Kakapo Performance の 2 つの画像モジュールは、WordPress が画像サイズを生成するその瞬間に働きます：圧縮モジュールは品質を設定し、生成されたサイズから EXIF、IPTC、XMP のマーカーを取り除きます。フォーマットモジュールは WebP と AVIF の派生ファイルを作ります。どちらも次のアップロードから効きます。すでにメディアライブラリにある画像には何も起こりません — この穴を埋めるのが一括実行です。

この実行が作業を勝手に作り出すことはありません。上で新しいアップロード向けに有効にした設定、つまり WebP および／または AVIF と「メタデータを削除」を、既存のファイルにそのまま適用するだけです。どれも有効になっていなければ開始ボタンはロックされ、その理由が表示されます — 例えばサーバーが WebP を書き出せない、あるいは単に有効な設定が一つもない、といった具合です。「既存のメディアライブラリを再処理」のカードは「画像」の領域、画像設定の下にあります。画面上の並び順は操作の順序と同じです。まず設定し、それから既存のファイルに対して実行します。

手が加えられるのは、ゴミ箱に入っていない JPEG と PNG の添付ファイルだけです。「保有する JPEG / PNG 画像」の行に、開始する前にその件数が表示されます。

開始し、見守り、停止する

「一括実行を開始」をクリックすると実行が作成され、ただちに始まります。処理は 8 秒の時間予算をもつ回に分けて進みます。1 回が終わるたびに結果が返り、表示が更新され、200 ミリ秒後に次の回が始まります。ある回の終わりで残り時間が 3.5 秒を下回っている場合、新しい添付ファイルには着手しません — 画像形式モジュールは内部で 1 枚あたり最低 3 秒を見込んでいるためです。max_execution_time が設定されているサーバーでは、時間予算はさらにその上限の 80 パーセントで頭打ちになります。回がリクエストの途中で打ち切られないようにするためです。

バーは本当の進捗を示します：処理の済んだ添付ファイルの数を全体数で割ったものです。その下には現在の数値が並びます — 生成された派生ファイルとスキップされた派生ファイル、WebP と AVIF それぞれ 1 行ずつ、さらに軽量化されたファイルと解放されたバイト数です。いちばん下には直近 14 行のログが流れ、それぞれファイル名と、そのファイルで何が起きたかが表示されます。

「停止」で実行が止まります。ボタンはその後「再開」に変わり、次のスタートは止まったところの添付ファイルからそのまま続きます。タブをそのまま閉じたときも同じです：実行は止まり、失われるものはありません。ページを開き直すと、状態を問い合わせ、まだ終わっていない実行を自分で先へ進めます。

実行が中断を乗り越える仕組み

進み具合は、一つひとつの添付ファイルの処理を終えた後ではなく、始める前に保存されます。途中で処理が死んだ場合 — Web サーバーの実行制限、メモリー、GD がつまずくファイル — 次の処理はどこで引っかかったかを知っています。同じ添付ファイルが 3 回続けてまったく進まない場合、その添付ファイルはログに平文の 1 行を残して飛ばされます。1 つのファイルで実行が永久に止まったままになるのを避けるためです。

管理画面を 2 つ同時に開いても、互いに邪魔をすることはありません：ロックによって、常に 1 回分の処理しか通しません。ある処理が Web サーバーに打ち切られ、ロックが残ってしまった場合、そのロックは 180 秒後に取り残されたものとみなされ、引き継がれます。

再開のときは、全体数が固定されるのではなく求め直されます — 停止と再開の間にアップロードや削除が行われている可能性があるからです。実行の途中で画像の設定をすべてオフにすると、実行は誰も求めていない作業を続けるのではなく、自分から止まります。「リセット」は進捗とレポートを破棄します。すでに生成されたファイルはそのまま残ります。

レポートを正しく読む

最後に、計測されたファイルサイズを載せた最終行が表示されます — 推定値ではありません。生成された派生ファイルごとに、元のファイルのサイズと結果のサイズを比べます。どちらも生成したその瞬間の実測値です。数えられるのはこの実行で新しくできたものだけです。アップロード時にすでに変換されたものは、二度は現れません。

3 つの点は、見栄えよりも正確さのために、意図してそう書かれています：WebP と AVIF は別々の行になります。同じ元のファイルから派生ファイルが 2 つできるためで、合計を 1 つにまとめると元のファイルを二重に数えてしまうからです。そのためパーセント値は行ごとの値であり、足し合わせてはいけません。ブラウザーが取得するのは、常にどちらか一方の形式だけです。そして新しいファイルはディスク上の場所をさらに使います：節約されるのは訪問者への転送量です。ディスク容量を本当に空けるのはメタデータの削除だけで、そのバイト数は専用の行に表示されます。

何も生成されなかった場合、レポートはそのことも伝えます：保有分についてすでにすべて済んでいたか、あるいはどの結果も元のファイルより小さくならなかったかです。小さくならなかった結果は破棄され、「スキップ」として数えられます — 決して節約分としては数えません。

何かがスキップされるとき

生成されなかった派生ファイルにはそれぞれ理由が平文で付き、理由は最終行にまとめて表示されます：

•「元ファイルより小さくならなかった」— 通常の結果です。元ファイルがそのまま残ります。•「使用できるメモリに対して大きすぎる」— 画像形式モジュールはデコードの前に画像の寸法を調べ、PHP をメモリ上限まで走らせる代わりに処理を断ります。•「保存先にすでにファイルがあった」— 上書きはしません。これは添付ファイル側の記録が失われ、ファイルだけが残っている場合によく起こります。•「読み取れない」— 壊れているか、CMYK の JPEG か、特殊な種類のファイルです。•「書き込めない」— アップロードフォルダーの権限を確認してください。•「この形式はこのサーバーでは利用できない」— AVIF は libavif を組み込んだ PHP 8.1 以降を、WebP は libwebp を組み込んだ GD ライブラリを必要とします。

よく不具合と思われますが、そうではないものが 2 つあります：2 回目の実行はほとんど動きを見せません。済んだ作業は繰り返さないからです — 添付ファイルに付く目印が、いくつのファイルでメタデータの削除が済んでいるかを記録しています。そして品質の段階を変えても、すでに生成されたファイルが作り直されるわけではありません。そのためには、まず派生ファイルを取り除く必要があります。