WebP โดยค่าเริ่มต้นถูกพักไว้สำหรับ 6.1 หลังจากการคัดค้านใหม่จาก WordPress Lead Developers

เมื่อสัปดาห์ที่แล้ว ผู้ร่วมทีมด้านประสิทธิภาพกำลังทำงานเพื่อปรับแต่งแพตช์ติดตามผลสำหรับฟีเจอร์ multi-mime/WebP หลังจากที่งานหลักของมันถูกรวมเข้ากับคอร์สำหรับ 6.1 เมื่อสิ้นเดือนกรกฎาคม ซึ่งรวมถึงรายการที่เกี่ยวข้องที่มีขนาดเล็กกว่า เช่น แผ่นชิมสำหรับเบราว์เซอร์ที่ไม่รองรับ และเพิ่มการรองรับ PDF ซึ่งได้รับการจัดการในตั๋วแยกต่างหาก

ข้อเสนอในการสร้างภาพ WebP ตามค่าเริ่มต้นสำหรับการอัปโหลดภาพ JPEG ใหม่นั้นเป็นที่ถกเถียงกันตั้งแต่ต้น ในขณะที่ผู้ร่วมให้ข้อมูลที่สนับสนุนโดย Google ที่ขับเคลื่อนโครงการได้ทำการแก้ไขบางอย่างหลังจากรอบแรกของข้อเสนอแนะที่สำคัญที่สำคัญ ผู้ร่วมให้ข้อมูลรายอื่นๆ ยังคงแสดงความกังวลว่าพวกเขากล่าวว่าไม่ได้รับการพิจารณา ผู้ร่วมให้ข้อมูลหลายคนรายงานปัญหาเกี่ยวกับคุณลักษณะนี้และแนะนำว่าควรเริ่มต้นด้วยการเลือกเข้าร่วม ซึ่งเป็นแนวคิดที่ถูกยกเลิกโดยสรุปก่อนที่จะเริ่มงานหลัก

เมื่อสัปดาห์ที่แล้ว Andrew Ozz หัวหน้านักพัฒนา WordPress ได้ชั่งน้ำหนักเรื่องตั๋วด้วยการคัดค้านใหม่:

เช่นเดียวกับ @MatthiasReinholz, @eatingrules และอื่น ๆ ฉันคิดว่าแนวทางนี้อาจขาดไป เหตุใดจึงมีไฟล์รูปภาพมากเป็นสองเท่าที่ใช้พื้นที่พิเศษในเมื่อครึ่งหนึ่งจะไม่เคยถูกใช้ที่ไหนเลย

IMHO แนวทางที่ดีกว่าคือสร้าง WEBP ขนาดย่อยของรูปภาพทั้งหมด หากจำเป็นต้องใช้ JPEG จริง สามารถสร้างไฟล์เหล่านี้ได้ทันทีตามต้องการ ไม่มีจุดที่จะอุดตันที่เก็บข้อมูลของเว็บเซิร์ฟเวอร์ด้วยไฟล์ที่ไม่มีประโยชน์ทั้งหมดเหล่านี้

ในทางกลับกัน หากขนาดไฟล์ WEBP ใหญ่กว่า JPEG จริง ๆ นั่นก็อาจหมายความว่าจำเป็นต้องมีเครื่องมือที่ดีกว่า และโปรแกรมแก้ไขนี้ก่อนกำหนด

เมื่อหกสัปดาห์ก่อน ในการตอบสนองต่อข้อร้องเรียนเรื่องหนึ่งว่า “ทรัพยากรสำหรับการแปลงจะมีมหาศาล” อดัม ซิลเวอร์สเตน ผู้ให้การสนับสนุนหลักที่ได้รับการสนับสนุนจาก Google ยืนยันว่าทรัพยากรสำหรับการสร้างภาพในการอัปโหลดจะ “เพิ่มขึ้นอย่างมาก”

“อย่างไรก็ตาม ทรัพยากรสำหรับให้บริการภาพจะลดลง” ซิลเวอร์สตีนกล่าว “เนื่องจากการอัปโหลดรูปภาพนั้นหายากมากเมื่อเทียบกับการให้บริการรูปภาพ การบีบอัดและจัดเก็บรูปภาพจึงควรค่าแก่ความพยายามเป็นพิเศษ”

นี่เป็นอีกปัญหาหนึ่งที่ออซอ้างในการคัดค้านแนวทางนี้

“จริง ๆ แล้วการใช้ทรัพยากรที่เพิ่มขึ้นอย่างมากเมื่ออัปโหลดรูปภาพเป็นผลข้างเคียงที่แย่มากที่นี่” Ozz กล่าว “หมายความว่าการอัปโหลดจำนวนมากจะล้มเหลว และปล่อยให้ผู้ใช้ติดอยู่ นอกจากนี้ยังจะเพิ่มการร้องขอการสนับสนุนสำหรับทั้ง WordPress และบริษัทโฮสติ้งอย่างมาก อย่าคิดว่ามันเป็นที่ยอมรับ ด้วยเหตุนี้ แม้ว่า WordPress จะต้องรองรับ image multi-mime แต่แนวทางปัจจุบันดูเหมือนจะไม่ใช่ทางออกที่ดี”

ประมาณ 24 ชั่วโมงต่อมา Felix Arntz ผู้ให้การสนับสนุน Google ได้แสดงความคิดเห็นเพื่อแนะนำว่ากลไกทางเลือก WebP สำหรับ JPEG สำหรับเบราว์เซอร์รุ่นเก่านั้นพร้อมสำหรับการคอมมิตและเขาวางแผนที่จะดำเนินการภายในสองสามวัน

Ozz กล่าวว่า "โปรดอย่าคอมมิตโค้ดใดๆ เพิ่มเติมที่นี่ เว้นแต่จะเป็นการจัดการกับทรัพยากรที่เพิ่มขึ้นอย่างมากที่จำเป็นในการสร้างขนาดย่อยของรูปภาพหลังจากอัปโหลด" “อย่างที่ฉันได้กล่าวไว้ข้างต้น การเพิ่มขึ้นดังกล่าวเป็นสิ่งที่ยอมรับไม่ได้

“มีข้อมูลใดบ้างเกี่ยวกับจำนวนทรัพยากร (หน่วยความจำ เวลาในการประมวลผล ฯลฯ) ที่จำเป็นในการอัปโหลดภาพขนาดต่างๆ หรือไม่? ค่าประมาณใดเกี่ยวกับจำนวนไซต์ที่อาจได้รับผลกระทบจากสิ่งนั้น ข้อเสนอแนะใด ๆ เกี่ยวกับวิธีการจัดการกับมัน? คุณรู้หรือไม่ว่าจะเกิดอะไรขึ้นเมื่อการประมวลผลภาพที่อัปโหลดล้มเหลวหลังการประมวลผล?

“ตรงไปตรงมาในตอนนี้ ดูเหมือนว่าแพตช์นี้จะต้องถูกเปลี่ยนกลับและปรับโครงสร้างใหม่เพื่อที่จะแก้ไขปัญหานี้”

Adam Silverstein ตอบข้อกังวลของเขาด้วยการชี้แจงว่าเหตุใดพวกเขาจึงเลือกแนวทางปัจจุบัน โดยคาดว่าจะมีกรณีขอบบางกรณี และในที่สุดก็เพิ่มการสนับสนุนสำหรับรูปแบบเช่น AVIF เมื่อได้รับการสนับสนุนอย่างกว้างขวางมากขึ้น:

ฉันมักจะเห็นด้วยกับการประเมินของคุณว่าควรสร้างขนาดย่อยทั้งหมดเป็น WebP เท่านั้น นั่นคือรูปร่างของข้อเสนอดั้งเดิม สำหรับกรณีการใช้งาน/ผู้ใช้ส่วนใหญ่ วิธีนี้จะได้ผลดีที่สุด ฉันจะเปิดให้พิจารณาสิ่งนี้เป็นค่าเริ่มต้น (พร้อมการบรรเทาผลกระทบบางอย่างดูด้านล่าง)

เหตุผลที่เราตัดสินใจสร้างทั้งสองรูปแบบคือเพื่อพิจารณาความเข้ากันได้แบบย้อนหลังสำหรับกรณี edge สองสามกรณีที่เราระบุตำแหน่งที่รูปภาพ WebP อาจไม่ทำงาน ได้แก่ รูปภาพที่ส่งทางอีเมล (ไคลเอนต์ outlook/windows รุ่นเก่าบางรุ่น) แท็ก Open Graph (บริการบางอย่างไม่รองรับ WebP) และเบราว์เซอร์ Safari รุ่นเก่ากว่า ความเป็นไปได้อย่างหนึ่งที่เราพิจารณาคือเก็บเฉพาะ JPEG ขนาดเต็มเท่านั้น ดังนั้นจึงมีให้สำหรับเคสขอบเหล่านั้นเสมอ

การสนับสนุน "multi-mime" ที่นี่สร้างขึ้นเพื่อสร้างหลายรูปแบบ ดังนั้นไซต์ของคุณสามารถจัดเตรียมรูปแบบหลักและรูปแบบทางเลือกด้วยบางอย่างเช่นองค์ประกอบ picture สิ่งนี้มีความสำคัญน้อยกว่าสำหรับ WebP เนื่องจากได้รับการสนับสนุนอย่างกว้างขวาง แต่จะเป็นประโยชน์สำหรับการปรับใช้รูปแบบที่ใหม่กว่าเช่น AVIF ด้วยปลั๊กอินหรือแกน

Silverstein ยังกล่าวอีกว่าตัวเลือกในการสร้างภาพในทันทีเป็นสิ่งที่พวกเขาจำเป็นต้องคิดออก แต่ "รู้สึกว่าอยู่นอกขอบเขตสำหรับความพยายามนี้"

ในการตอบสนองต่อการร้องเรียนเกี่ยวกับทรัพยากรที่เพิ่มขึ้นอย่างมากสำหรับการอัปโหลดรูปภาพ Silverstein กล่าวว่าพวกเขากำลังใช้กลไก "ลองใหม่" เพื่อลดปัญหานี้

“การเปลี่ยนแปลงนี้ยังเพิ่มจำนวนครั้งที่ WordPress พยายามสร้างภาพใหม่อีกครั้งเป็นสองเท่า ดังนั้นในขณะที่เวลาในการประมวลผลจะเพิ่มขึ้น ผมไม่คิดว่าเราจะเห็นความล้มเหลวที่เพิ่มขึ้นอย่างจำเป็น” เขากล่าว “ฉันรู้ว่าเรามีปัญหาในการเพิ่มขนาดใหม่ในอดีต แต่นั่นคือก่อนที่เราจะเพิ่มกลไกการลองใหม่”

ทีมงานที่อยู่เบื้องหลังโปรเจ็กต์เริ่มต้นของ WebP ให้ความสำคัญกับการให้บริการรูปภาพที่มีขนาดเล็กกว่าในส่วนหน้า และพิจารณาการใช้ทรัพยากรเพิ่มเติมในการอัปโหลดเป็นการเสียสละที่จำเป็นสำหรับผู้ใช้ WordPress

“ทรัพยากรเพิ่มเติม ณ เวลาอัพโหลดจะต้องชั่งน้ำหนักเทียบกับทรัพยากรที่ลดลงของการให้บริการภาพ WebP ที่มีขนาดเล็กลง โดยเฉพาะอย่างยิ่งเนื่องจากการให้บริการมักจะเกิดขึ้นหลายลำดับความสำคัญมากกว่าการอัปโหลด” Silverstein กล่าว

“หากการอัปโหลดล้มเหลวหลังจากลองใหม่ทั้งหมด ผู้ใช้จะมีประสบการณ์เช่นเดียวกับในปัจจุบัน: พวกเขาจะเหลือภาพที่เสียหายและใช้งานไม่ได้ นั่นอาจแก้ไขได้ แม้ว่าฉันจะไม่คิดว่าการเปลี่ยนแปลงนี้จะช่วยเพิ่มอัตราความล้มเหลวได้”

หัวหน้านักพัฒนา WordPress Dion Hulse ยังแสดงความคิดเห็นเกี่ยวกับตั๋วเพื่อรายงานปัญหาเกี่ยวกับการแปลง WebP ใน WordPress Photo Directory:

เพียงแค่สังเกตว่าการแปลง webp เพิ่มเติมเหล่านี้ดูเหมือนจะเป็นสาเหตุหลักของความล้มเหลวในการอัปโหลดบน WordPress Photo Directory ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ดู #meta6142 และตั๋วถูกปิดเหมือนซ้ำกัน

ข้อผิดพลาดโดยทั่วไปเป็นไปตามบรรทัดของ Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (เห็นได้ชัดว่ามีค่าไบต์) ในขณะที่พยายามทำการแปลง jpeg -> webp ดั้งเดิมขนาดเต็มเริ่มต้น

ไม่ส่งผลต่อ ทุกการอัปโหลด เฉพาะบางภาพเท่านั้น อาจเกี่ยวข้องกับค่า $quality ที่ส่งผ่านสำหรับคำขอ webp (IIRC ค่าเริ่มต้น 82 ได้รับการปรับให้เหมาะสมสำหรับ jpeg หรือไม่)

Hulse ปิดใช้งานการแปลง JPEG เป็น WebP อันเป็นผลมาจากข้อผิดพลาดเหล่านี้ เนื่องจากไดเรกทอรีรูปภาพไม่ได้ใช้ WebP ในขณะนี้ แต่ตั้งข้อสังเกตว่า "อาจเป็นสัญญาณว่าควรพิจารณาสร้าง webp สำหรับรูปภาพที่ปรับขนาดเท่านั้น แทนที่จะเป็นสำหรับ ไฟล์ต้นฉบับด้วย”

Silverstein กล่าวว่าพวกเขากำลังตรวจสอบปัญหาที่ Hulse รายงาน เนื่องจากอาจมีข้อบกพร่อง

Ozz วนกลับมาเพื่อแนะนำว่าการปรับขนาดย่อยตามต้องการเป็นวิธีที่ดีกว่า โดยจะมีการประมวลผลภาพที่อัปโหลดเร็วขึ้นและลดความต้องการพื้นที่ลง เนื่องจากภาพ JPEG เพิ่มเติมจะไม่ถูกสร้างขึ้นเว้นแต่จำเป็น เขายังตั้งข้อสังเกตว่า “ลองใหม่” สำหรับการประมวลผลภาพหลัง “ใช้งานไม่ได้อย่างที่คาดไว้”

“ข่าวร้ายก็คือ หากการโพสต์ล้มเหลว มีโอกาสที่ไฟล์ที่อัปโหลดในตอนแรกจะยังคงอยู่” Ozz กล่าว “จากนั้นจะใช้ทุกที่ เนื่องจากรหัสส่วนใหญ่ใน WP จะกลับไปเป็นขนาดที่มีอยู่ และขนาดเดียวจะเป็นขนาดดั้งเดิม นั่นหมายความว่าเราจะให้บริการรูปภาพขนาดใหญ่ (เฉลี่ย 4MB - 8MB) ข้อเสียเปรียบอย่างร้ายแรง”

Silverstein ตอบสนองต่อคำแนะนำของ Ozz โดยเห็นด้วยกับหลาย ๆ คนและเสนอแนวทางที่เป็นไปได้สองทางสำหรับโครงการ:

1. รักษาโครงสร้างพื้นฐาน multi-mime ปัจจุบัน แต่เปลี่ยนค่าเริ่มต้นเพื่อให้สร้างเฉพาะไฟล์ WebP เท่านั้น อาจถึงขนาดเกณฑ์ที่เกินกว่าที่จะสร้างเฉพาะ JPEG เท่านั้น งานที่มีอยู่ส่วนใหญ่จะดำเนินต่อไป การกรองเนื้อหาอาจถูกลบออก
2. เปลี่ยนโครงสร้างพื้นฐาน multi-mime และเปลี่ยนกลับไปใช้วิธี mime เดียว โดยใช้ WebP สำหรับรูปภาพที่มีขนาดไม่เกินขีดจำกัด และปรับเลเยอร์ความเข้ากันได้เพื่อใช้ JPEG ที่เราเก็บไว้

ทีมประสิทธิภาพกำลังทำการวิจัยเพิ่มเติมและได้หยุดทำอย่างอื่นชั่วคราวจนกว่าพวกเขาจะได้รับคำติชมเกี่ยวกับทิศทางถัดไปสำหรับโครงการ