บทเรียนราคาแพงจากภารกิจย้ายไฟล์เว็บ: ปัญหาเว็บอืดไม่ได้แก้ได้ด้วย WebP เสมอไป

เมื่อผู้ดูแลเว็บไซต์ตัดสินใจใช้เวลาช่วงสั้นๆ ในการแปลงรูปภาพบนเว็บไซต์ WooCommerce ผสม LearnDash ที่ใช้ธีม Divi ซึ่งมีอายุยาวนานกว่า 8 ปีและมีรูปภาพนับพันไฟล์ เป้าหมายแรกคือการเปลี่ยนไฟล์ทั้งหมดให้อยู่ในรูปแบบ WebP เพื่อลดภาระขนาดหน้าเว็บ โดยเกือบจะเลือกติดตั้งปลั๊กอิน ShortPixel แล้วจบงานในทันที

อย่างไรก็ตาม แทนที่จะทำตามแผนเดิม ท่ามกลางการตรวจสอบระบบด้วยคำสั่งผ่านเทอร์มินัลเป็นเวลา 20 นาที กลับพบว่ารูปแบบไฟล์ WebP เป็นเพียงปัญหาลำดับที่ 4 เท่านั้นที่เว็บไซต์นี้กำลังเผชิญอยู่ และการติดตั้งปลั๊กอินปรับแต่งภาพอัตโนมัติอาจทำให้สถานการณ์เลวร้ายลงไปอีก เนื่องจากเซิร์ฟเวอร์ VPS ขนาด 4GB เคยประสบปัญหาหน่วยความจำหมดจนทำให้ MySQL ล่มมาแล้วถึงสองครั้งในไตรมาสเดียวกัน การประมวลผลไฟล์ภาพจำนวนมากจึงมีความเสี่ยงสูง

ผลลัพธ์จากการรันคำสั่งเช็คไฟล์ในไดเรกทอรีอัปโหลดทำให้ต้องชะงัก เมื่อพบไฟล์ WebP จำนวนมากถึง 12,301 ไฟล์ บนเว็บไซต์ที่ผู้ดูแลระบบคิดว่าไม่เคยเปิดใช้งาน WebP มาก่อน โดยชื่อไฟล์ลงท้ายด้วย .jpg.webp ซึ่งเป็นรูปแบบไฟล์พ่วง (sidecar) ของปลั๊กอิน EWWW Image Optimizer ที่เคยถูกติดตั้งและถูกถอนการออกไปนานแล้ว

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ไฟล์ขยะขนาด 241 เมกะไต์เหล่านี้กลายเป็นภาระที่ระบบสแกนไวรัสต้องตรวจสอบทุกรอบ และถูกนับรวมในทุกการสำรองข้อมูล โดยไม่มีการเรียกใช้งานในฐานข้อมูลเลยแม้แต่น้อย หลังจากตรวจสอบความปลอดภัยผ่านคำสั่ง SQL แล้ว ไฟล์ทั้งหมดจึงถูกลบออกเพื่อดึงพื้นที่เก็บข้อมูลกลับมา บทเรียนสำคัญคือ ปลั๊กอินปรับแต่งภาพมักจะทิ้งผลลัพธ์ค้างไว้เสมอเมื่อถูกถอนการติดตั้ง

นอกจากเรื่องไฟล์ขยะแล้ว ปัญหาใหญ่ถัดมาคือการตั้งค่าขนาดรูปภาพย่อย (thumbnail sizes) ที่ถูกปรับแต่งไว้ล่วงหน้าโดยปลั๊กอิน disable-thumbnails-and-threshold ซึ่งปิดการใช้งานขนาดภาพย่อยไปถึง 18 ขนาด ส่งผลให้ระบบ WooCommerce พยายามเรนเดอร์ภาพขนาด 300x300 พิกเซล แบบ on-the-fly ผ่าน Imagick สำหรับคำขอรูปภาพสินค้าถึง 94% บนเซิร์ฟเวอร์ที่มีปัญหาเรื่องซีพียูอยู่แล้ว

ท้ายที่สุด การแก้ไขปัญหาจึงมุ่งเน้นไปที่การจัดการโครงสร้างขนาดภาพที่ขาดหาย และการตั้งค่าเงื่อนไขการเรนเดอร์ที่ถูกต้อง แทนที่จะเป็นการบังคับเปลี่ยนนามสกุลไฟล์เพียงอย่างเดียว

ที่มา: Dev.to