WordPressのリード開発者からの新しい異議の後、デフォルトで6.1の保留中のWebP

公開: 2022-08-25

先週、パフォーマンスチームのコントリビューターは、7 月末に 6.1 のコアにマージされた後、マルチマイム/WebP 機能のフォローアップパッチの改良に取り組んでいました。これには、サポートされていないブラウザー用の shim や PDF サポートの追加などの小さな関連項目が含まれ、これらは別のチケットで処理されます。

新しい JPEG 画像のアップロード用にデフォルトで WebP 画像を生成するという提案は、当初から物議を醸していました。プロジェクトを推進している Google が後援するコントリビューターは、重要な重要なフィードバックの最初のラウンドの後、いくつかの修正を行いましたが、他のコントリビューターは、考慮されていないと述べた懸念を表明し続けています. 何人かの寄稿者がこの機能に関する問題を報告し、オプトインすることから始めるべきだと提案しましたが、主要な作業がコミットされる前に即座に却下されたアイデアです。

先週、WordPress の主任開発者である Andrew Ozz 氏は、新たな異議を唱えてこのチケットに加担しました。

@MatthiasReinholz、@eatingrules などのように、このアプローチにはおそらく欠けていると思います。画像ファイルの半分がどこにも使用されないのに、なぜ 2 倍の画像ファイルが多くの余分なスペースを占有するのでしょうか?
私見より良いアプローチは、すべての画像サブサイズをWEBPにすることです。 JPEG が実際に必要な場合は、必要に応じてオンザフライで生成できます。これらすべての不要なファイルで Web サーバーのストレージを詰まらせても意味がありません。

一方、WEBP ファイルサイズが実際に JPEG よりも大きい場合は、より優れたツールが必要であることを意味し、このパッチは時期尚早です。

6 週間前、「変換のためのリソースが膨大になる」という 1 件の苦情に対して、Google が後援するコアコミッターの Adam Silverstein は、アップロード時に画像を生成するためのリソースが「劇的に増加する」ことを確認しました。

「しかし、画像を提供するためのリソースは減ります」と Silverstein 氏は述べています。「画像のアップロードは、画像の提供に比べて非常にまれであるため、画像を圧縮して保存するための余分な労力は、それだけの価値があるはずです。」

これは、Ozz がこのアプローチに対する異議の中で言及したもう 1 つの問題です。

「実際、画像をアップロードする際のリソース使用量の劇的な増加は、ここでは非常に悪い副作用です」と Ozz 氏は述べています。「これは、多くのアップロードが失敗し、ユーザーが立ち往生することを意味します。また、WordPress とホスティング会社の両方に対するサポートリクエストが劇的に増加します。これは受け入れられるとは思わないでください。このため、WordPress でイメージマルチマイムのサポートが必要な場合でも、現在のアプローチは適切なソリューションとは思えません。」

約 24 時間後、Google がスポンサーとなっている寄稿者の Felix Arntz は、古いブラウザ用の JPEG への WebP フォールバックメカニズムをコミットする準備ができており、数日以内にコミットする予定であるとコメントしました。

「アップロード後に画像のサブサイズを作成するために必要なリソースの劇的な増加に対処する場合を除き、ここでこれ以上コードをコミットしないでください」と Ozz 氏は述べています。「上で述べたように、このような増加は容認できません。

「さまざまなサイズの画像をアップロードするときに、どれだけ多くのリソース (メモリ、処理時間など) が必要かについてのデータはありますか? その影響を受ける可能性のあるサイトの数についての見積もりはありますか? それに対処する方法について何か提案はありますか？アップロードされた画像の後処理が失敗するとどうなるか知っていますか?

「率直に言って、これに対処するには、このパッチを元に戻してリファクタリングする必要があるようです。」

Adam Silverstein は、現在のアプローチを選択した理由を明確にして、彼の懸念に応えました。これは、特定のエッジケースを見越して、より広くサポートされるようになったら、最終的には AVIF などのフォーマットのサポートを追加するためです。

私は、すべてのサブサイズは WebP のみとして生成されるべきであるというあなたの評価に同意する傾向があり、それが当初の提案の形でした。ユースケース/ユーザーの大部分では、これが最適です。私はこれをデフォルトとして検討することにオープンです (いくつかの軽減策があります。以下を参照してください)。
両方の形式を生成することにした理由は、WebP 画像が機能しない可能性があると特定したいくつかのエッジケースの後方互換性を考慮したためです。つまり、電子メールで送信された画像 (一部の古い Outlook/Windows クライアント)、Open Graph タグ (一部のサービスはサポートしていません)。 WebP) および古い Safari ブラウザー。私たちが検討した 1 つの可能性は、フルサイズの JPEG のみを保持して、これらのエッジケースで常に使用できるようにすることです。

ここでの「マルチマイム」サポートは、複数のフォーマットを生成するように構築されているため、サイトはpicture要素のようなものを使用してプライマリおよびフォールバックフォーマットを提供できます。 WebP は広くサポートされているため、これはそれほど重要ではありませんが、プラグインまたはコアによって AVIF などの新しい形式を採用する場合に役立ちます。

シルバースタイン氏はまた、オンザフライで画像を生成するオプションは、彼らが理解する必要があるものであるが、「この取り組みの範囲外だと感じた」と語った.

画像アップロード用のリソースが劇的に増加したという苦情に対して、Silverstein は、この問題を軽減するために「再試行」メカニズムに依存していると述べました。

「この変更により、WordPress が画像の再生成を再試行する回数も 2 倍になるため、処理時間は増加しますが、必ずしも失敗が急増するとは思いません」と彼は言いました。「過去に新しいサイズを追加するのに苦労したことは知っていますが、それは再試行メカニズムを追加する前のことです。」

WebP by default プロジェクトの背後にあるチームは、フロントエンドでより小さな画像サイズを提供することに重点を置いており、アップロード時に追加のリソースを使用することは、WordPress ユーザーにとって必要な犠牲であると考えています.

「アップロード時の追加リソースは、小さな WebP 画像を提供するために削減されるリソースと比較検討する必要があります。特に、サービス提供は通常、アップロードよりも数桁頻繁に発生するためです」と Silverstein 氏は述べています。

「すべての再試行の後にアップロードが失敗した場合、ユーザーは現在と同じ経験をします。壊れた使用できない画像が残ります。おそらく修正できるでしょうが、この変更によって失敗率が上がるとは思いません。」

WordPress の主任開発者である Dion Hulse は、WordPress Photo Directory での WebP 変換に関する問題を報告するためのチケットについてもコメントしています。

ここで注意しておきたいのは、これらの追加の webp 変換が、ここ数週間の WordPress フォトディレクトリでのアップロード失敗の主な原因となっているようです. #meta6142 を参照し、チケットは重複としてクローズされます。

エラーは一般的に、 Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (明らかにバイト値で) 割り当てようとしました) の行に沿っていました。
すべてのアップロードに影響するわけではなく、特定の画像のアップロードにのみ影響します。 webp リクエストに渡される$quality値に関連している可能性があります (IIRC のデフォルトの 82 は jpeg 用に最適化されましたか?)。

これらのエラーの結果、Hulse は JPEG から WebP への変換を無効にしました。これは、写真ディレクトリが現在 WebP を使用していないためです。元のファイルも。」

Silverstein は、Hulse が報告した問題を調査していると述べた。

Ozz 氏は、必要に応じて追加の JPEG 画像が生成されないため、アップロードされた画像の処理を高速化し、必要なスペースを削減するため、必要に応じてサブサイズを作成する方が良い方法であると推奨しました。彼はまた、画像の後処理の「再試行」が「期待どおりに機能しない」ことにも言及しました。

「悪いニュースは、後処理が失敗した場合、最初にアップロードされたファイルが残る可能性があることです」と Ozz 氏は述べています。「そうすれば、WP のほとんどのコードが利用可能なサイズにフォールバックし、唯一のサイズが元になるため、あらゆる場所で使用されます。つまり、巨大な (平均 4MB ～ 8MB) の画像を提供することになります。深刻な欠点。」

Silverstein は Ozz の提案に応え、多くの意見に同意し、プロジェクトの 2 つの可能性のある道筋を提案しました。

現在のマルチ MIME インフラストラクチャを維持しますが、WebP ファイルのみが生成されるようにデフォルトを変更します。おそらく、JPEG のみが生成されるしきい値のサイズまでです。既存の作業のほとんどは継続されます。コンテンツフィルタリングが削除される可能性があります。
マルチマイムインフラストラクチャを元に戻し、単一のマイムアプローチに切り替えます。しきい値サイズまでの画像には WebP を使用し、保持している JPEG を使用するように互換性レイヤーを調整します。

パフォーマンスチームはさらに調査を行っており、プロジェクトの次の方向性に関するフィードバックを受け取るまで、他のことをコミットすることを一時的に停止しています。