WordPress 리드 개발자의 새로운 반대 이후 WebP는 기본적으로 6.1에 대해 보류 중입니다.

지난 주 성능 팀 기여자들은 7월 말에 6.1의 핵심 작업으로 병합된 후 multi-mime/WebP 기능에 대한 후속 패치를 개선하기 위해 노력했습니다. 여기에는 지원되지 않는 브라우저에 대한 shim 및 PDF 지원 추가와 같은 더 작은 관련 항목이 포함되며, 이는 별도의 티켓에서 처리됩니다.

새로운 JPEG 이미지 업로드를 위해 기본적으로 WebP 이미지를 생성한다는 제안은 처음부터 논란이 되어 왔습니다. 프로젝트를 주도하는 Google 후원 기여자들이 중요한 초기 피드백을 받은 후 일부 수정을 가한 반면, 다른 기여자들은 계속해서 고려되지 않고 있다는 우려를 표명했습니다. 몇몇 기고자들은 이 기능에 대한 문제를 보고했으며 주요 작업이 완료되기 전에 간단히 기각된 아이디어인 옵트인(opt-in)으로 시작해야 한다고 제안했습니다.

지난 주 WordPress의 수석 개발자인 Andrew Ozz는 다음과 같은 새로운 반대 의견을 제시했습니다.

@MatthiasReinholz, @eatingrules, 그리고 다른 사람들처럼 나는 이 접근 방식이 아마도 부족하다고 생각합니다. 이미지 파일의 절반이 어디에서도 사용되지 않을 때 많은 추가 공간을 차지하는 이미지 파일이 왜 두 배나 많을까요?

IMHO 더 나은 접근 방식은 모든 이미지 하위 크기를 WEBP로 만드는 것입니다. JPEG가 실제로 필요한 경우 필요에 따라 즉석에서 생성할 수 있습니다. 이 쓸모없는 파일로 웹 서버 저장소를 막는 것은 의미가 없습니다.

반면에 WEBP 파일 크기가 실제로 JPEG보다 크다면 더 나은 도구가 필요하며 이 패치는 시기상조입니다.

6주 전, "변환 리소스가 엄청날 것"이라는 한 불만에 대해 Google이 후원하는 핵심 커미터인 Adam Silverstein은 업로드 시 이미지를 생성하기 위한 리소스가 "극적으로 증가할 것"이라고 확인했습니다.

"그러나 이미지를 제공하기 위한 리소스는 줄어들 것입니다."라고 Silverstein은 말했습니다. "이미지 업로드는 이미지 제공에 비해 매우 드물기 때문에 이미지를 압축하고 저장하는 추가 노력은 그만한 가치가 있습니다."

이것은 Ozz가 이 접근 방식에 대한 반대에서 인용한 또 다른 문제입니다.

Ozz는 "사실 이미지를 업로드할 때 리소스 사용량이 급격히 증가하는 것은 매우 나쁜 부작용입니다."라고 말했습니다. "많은 업로드가 실패하고 사용자가 좌초될 것임을 의미합니다. 또한 WordPress와 호스팅 회사 모두에 대한 지원 요청이 크게 증가합니다. 이것이 용납될 수 있다고 생각하지 마십시오. 이 때문에 워드프레스에서 이미지 멀티마임 지원이 필요하더라도 현재 접근 방식은 좋은 해결책이 아닌 것 같다”고 말했다.

약 24시간 후, Google 후원 기고자 Felix Arntz는 이전 브라우저용 JPEG로의 WebP 폴백 메커니즘이 커밋할 준비가 되었으며 며칠 내로 커밋할 계획이라고 조언했습니다.

Ozz는 "업로드 후 이미지 하위 크기를 생성하는 데 필요한 리소스의 극적인 증가를 해결하기 위한 경우가 아니면 여기에 더 이상 코드를 커밋하지 마십시오."라고 말했습니다. “위에서 말했듯이 이러한 증가는 용납할 수 없습니다.

“다른 크기의 이미지를 업로드할 때 얼마나 더 많은 리소스(메모리, 처리 시간 등)가 필요한지에 대한 데이터가 있습니까? 그로 인해 영향을 받을 수 있는 사이트가 몇 개나 될까요? 처리 방법에 대한 제안 사항이 있습니까? 업로드된 이미지의 후처리가 실패하면 어떻게 되는지 알고 계십니까?

"솔직히 현재로서는 이 패치를 되돌리고 이 문제를 해결하기 위해 리팩토링해야 할 것 같습니다."

Adam Silverstein은 특정 극단적인 경우를 예상하고 결국 AVIF와 같은 형식이 더 광범위하게 지원되면 지원을 추가하기 위해 현재 접근 방식을 선택한 이유에 대한 설명으로 그의 우려에 응답했습니다.

나는 모든 하위 크기가 원래 제안의 형태인 WebP로만 생성되어야 한다는 귀하의 평가에 동의하는 경향이 있습니다. 대다수의 사용 사례/사용자의 경우 이것이 가장 잘 작동합니다. 나는 이것을 기본값으로 고려할 수 있습니다(일부 완화와 함께, 아래 참조).

두 형식을 모두 생성하기로 결정한 이유는 WebP 이미지가 작동하지 않을 수 있는 몇 가지 극단적인 경우에 대한 이전 버전과의 호환성 고려 사항이었습니다. WebP) 및 이전 Safari 브라우저. 우리가 고려한 한 가지 가능성은 전체 크기의 JPEG만 유지하여 이러한 경우에 항상 사용할 수 있도록 하는 것입니다.

여기에서 "멀티 마임" 지원은 여러 형식을 생성하도록 구축되어 사이트에서 picture 요소와 같은 기본 및 대체 형식을 제공할 수 있습니다. 이것은 광범위하게 지원되기 때문에 WebP에서는 덜 중요하지만 플러그인이나 코어로 AVIF와 같은 새로운 형식을 채택하는 데 도움이 될 것입니다.

Silverstein은 또한 즉석에서 이미지를 생성하는 옵션이 파악해야 하지만 "이 노력의 범위를 벗어났다"고 말했습니다.

이미지 업로드를 위한 리소스의 급격한 증가에 대한 불만에 대해 Silverstein은 이 문제를 완화하기 위해 "재시도" 메커니즘에 의존하고 있다고 말했습니다.

"이 변경은 WordPress가 이미지 재생성을 재시도하는 횟수를 두 배로 늘리므로 처리 시간은 늘어나지만 반드시 실패가 급증하지는 않을 것이라고 생각합니다."라고 그는 말했습니다. "과거에 새 크기를 추가하는 데 문제가 있었다는 것을 알고 있지만 재시도 메커니즘을 추가하기 전이었습니다."

기본적으로 WebP 프로젝트 뒤에 있는 팀은 프론트엔드에서 더 작은 이미지 크기를 제공하는 데 더 중점을 두고 있으며 WordPress 사용자에게 필요한 희생을 업로드할 때 추가 리소스 사용량을 고려합니다.

Silverstein은 "특히 일반적으로 서비스가 업로드보다 수십 배 더 자주 발생하기 때문에 업로드 시 추가 리소스는 더 작은 WebP 이미지를 제공하는 감소된 리소스와 비교해야 합니다."라고 말했습니다.

"모든 재시도 후에 업로드가 실패하면 사용자는 현재와 동일한 경험을 하게 됩니다. 깨진 이미지가 남게 됩니다. 이 변화가 실패율을 증가시킬 것이라고는 생각하지 않지만, 그것은 아마도 고칠 수 있을 것입니다.”

WordPress 리드 개발자 Dion Hulse는 또한 WordPress Photo Directory의 WebP 변환 문제를 보고하는 티켓에 대해 다음과 같이 언급했습니다.

여기에서 이러한 추가 webp 변환이 최근 몇 주 동안 WordPress 사진 디렉토리에서 업로드 실패의 주요 원인이었던 것으로 보입니다. #meta6142 및 티켓이 중복으로 종료된 것을 참조하세요.

오류는 일반적으로 초기 전체 크기 원본 jpeg -> webp 변환을 수행하는 동안 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의 제안에 응답하여 많은 사람들에게 동의했으며 프로젝트를 위한 두 가지 잠재적인 경로를 제안했습니다.

1. 현재의 multi-mime 인프라를 유지하되, WebP 파일만 생성되도록 기본값을 변경합니다. 최대 임계값 크기를 초과하면 JPEG만 생성될 수 있습니다. 대부분의 기존 작업은 계속됩니다. 콘텐츠 필터링이 제거될 수 있습니다.
2. 다중 MIME 인프라를 되돌리고 임계값 크기까지 이미지에 WebP를 사용하고 유지하는 JPEG를 사용하도록 호환성 계층을 조정하여 단일 MIME 접근 방식으로 다시 전환합니다.

성능 팀은 더 많은 연구를 하고 있으며 프로젝트의 다음 방향에 대한 피드백을 받을 때까지 다른 작업을 일시적으로 중단했습니다.