1年前のWordPress 5.8の導入以来、ユーザーはWebP画像をアップロードしてコンテンツに使用できるようになり、自由度が高まりました。パフォーマンスチームは2022年3月、画像フォーマットのサポート拡大のため、WordPressのコア部分でWebPをデフォルトで有効化できるようにすることを提案しました。この提案では、新規JPEGアップロード時にWebP画像を生成したり、ウェブサイトのコンテンツにWebP画像を使用したりといった多くの機能が実現可能です。しかし、批判的なフィードバックを受け、この物議を醸す提案は4月に保留されました。
パフォーマンスチームの提案に従い、JavaScriptスニペットはWebPをサポートしていないブラウザを検出し、代わりにJPEGを読み込みます。さらに、以下のWebPリビジョンがデフォルトで含まれています。
WordPress 6.1では、他の画像サイズとは異なり、コア画像サイズのみがデフォルトでWebPバージョンとして自動生成されます。WebPバージョンを自動的に受け取るには、カスタム画像サイズを WebPがサポートしていない例外的なケースに限定されている場合はオプトアウトする
セカンダリ (WebP) サブサイズを保持するには、プライマリ MIME タイプよりも小さくする必要があります。.
ユーザーに表示されるフロントエンドコンテンツで使用することを想定した画像サイズのみで、WebP画像を生成する必要があります。使用しない画像をWebP形式で保存する必要はないため、ストレージ容量を節約できます。.
画像のサブサイズに基づくフィルターを追加することで、追加のMIMEタイプの生成を制御できます。これにより、開発者は、バックエンドでは使用されない画像など、フロントエンドコンテンツで使用される画像のサイズを特定に制限できます。.
WebP をデフォルト設定すると、コアに組み込まれた後に新しくアップロードされた画像にのみ影響し、既存の画像には影響しません。既存のアップロード画像は、更新されても自動的に WebP に変換されません。過去のアップロード画像をサムネイル画像に変換したい場合は、WP-CLI または Regenerate Thumbnails などのプラグインが最適です。.
これまでのところ、提案された改訂案に対する反応は様々です。しかしながら、新しいアプローチにはかなりの支持があるようで、他のチームメンバーは、この変更によって影響を受ける可能性のあるエンドユーザーへの実際的な影響について検討するようチームに促しています。.
複数のコメント投稿者によると、WordPress は、時代遅れのデザインに比べて優れた品質と圧縮率を備えた、より現代的な AVIF 形式の採用を検討すべきとのことです。.
この取り組みはプログレッシブエンハンスメントに分類されています。古い設計にフォールバックするのではなく、AVIFのような将来性のあるフォーマットをサポートした方がよいのではないでしょうか？JavaScript開発者のKevin Batdorf氏はこの質問に答えて次のように述べています。ブラウザは、これらの標準規格の開発に合わせてサポートを追加していく予定です。.
WebPサポートへの移行は、WordPressがREST APIを追加した時、皆が一斉にGraphQLに移行していた時と少し似ていました。RESTとWebPが使えるのは素晴らしいことですが、どちらも最新世代のテクノロジーなので、すぐに古臭く感じるでしょう。
