การเพิ่มประสิทธิภาพรูปภาพใน WordPress

การปรับรูปภาพเป็นหนึ่งในวิธีที่ให้ผลตอบแทนสูงสุดในด้านประสิทธิภาพของ WordPress: ด้วยโครงสร้างหน้าและธีมเดียวกัน หากจัดการกับขนาดไฟล์ ขนาด รูปแบบ และวิธีการส่งรูปภาพได้อย่างเหมาะสม ประสบการณ์การโหลดมักจะดีขึ้นทันที

แต่การเพิ่มประสิทธิภาพรูปภาพก็เป็นสิ่งที่ทำให้ผู้คน “สับสนได้ง่ายที่สุด” เหตุผลไม่ใช่เพราะเทคโนโลยีซับซ้อนเกินไป แต่เป็นเพราะข้อมูลกระจัดกระจายเกินไป:
คุณอ่านบทความหลายบทความแล้ว รู้ว่าต้อง “บีบอัด” “WebP/AVIF” “โหลดแบบขี้เกียจ” แล้วมาอ่านคำอธิบายปลั๊กอินอีก กลับบอกว่า “ฟรี 100 หน่วยเครดิตต่อเดือน” “ฟรี 20MB” “รูปละ 1 หน่วยเครดิต” ผลคือยิ่งอ่านยิ่งงง — ฟรีพอหรือเปล่า? หักเงินยังไง? หรือว่าคุณเข้าใจ “สิ่งเดียวกัน” ผิด? และที่สำคัญที่สุด:หลังจากที่คุณทำเสร็จแล้ว มันมีผลจริงหรือไม่?

บทความนี้ทำเพียงสามสิ่ง:

1. นี่คือคำแนะนำที่เป็นประโยชน์สำหรับคุณแผนที่ทาง(ควรทำอะไรบ้างก่อน, ควรทำอะไรบ้างต่อไป)
2. กรุณาอธิบายตัวเลือกที่คุณกำลังพิจารณาอย่างละเอียด (ความแตกต่างระหว่างเวอร์ชันฟรีและเวอร์ชันเสียค่าใช้จ่ายคืออะไร และแต่ละเวอร์ชันเหมาะกับใคร)
3. นี่คือข้อผิดพลาดที่พบบ่อยที่สุดที่ควรระวัง (เพื่อที่คุณจะได้ไม่ต้องเสียเวลาค้นหาวิธีแก้ไขหลังจากทำเสร็จแล้ว)

1. พื้นฐาน: สิ่งที่ WordPress มีมาให้ และสิ่งที่ไม่มี

หากคุณไม่เข้าใจก่อนว่าแกนหลักของ WordPress ได้ทำอะไรไปแล้วบ้าง สองสถานการณ์ต่อไปนี้อาจเกิดขึ้นได้:

• แทนที่จะใช้ประโยชน์จาก “ความสามารถฟรี” ที่มีให้เรา เราได้ลงเอยด้วยการใช้เวลาและเงินในการประดิษฐ์ล้อขึ้นมาใหม่
• ฉันคิดว่า WordPress จะ “แปลงรูปภาพเก่าทั้งหมดเป็น WebP/AVIF โดยอัตโนมัติ” แต่ปรากฏว่ามันไม่ทำ

WordPress Core ได้รวมคุณสมบัติหลักเหล่านี้ไว้แล้ว:

• ภาพที่ตอบสนอง (srcset/sizes): ตั้งแต่ WordPress 4.4 เป็นต้นไป แกนหลักจะแสดงผลรูปภาพ srcset 与 sizes... และใช้ภาพหลายขนาดที่สร้างขึ้นระหว่างการอัปโหลดเพื่อให้เบราว์เซอร์สามารถเลือกทรัพยากรที่เหมาะสมที่สุดในการโหลดตามเงื่อนไขของหน้าจอ
• การโหลดแบบเนทีฟแบบขี้เกียจ: ตั้งแต่ WordPress 5.5 เป็นต้นไป การโหลดภาพแบบเลื่อนช้า (lazy loading) จะถูกเปิดใช้งานโดยค่าเริ่มต้นสำหรับรูปภาพ ตามมาตรฐาน HTML loading การดำเนินการของคุณสมบัติ
• รองรับการอัปโหลดไฟล์ WebP: ตั้งแต่ WordPress 5.8 เป็นต้นไป คุณสามารถอัปโหลดและใช้ไฟล์ WebP ได้เช่นเดียวกับไฟล์ JPEG และ PNG (หากสภาพแวดล้อมโฮสติ้งของคุณรองรับ WebP)
• รองรับการอัปโหลดไฟล์ AVIF: ตั้งแต่ WordPress 6.5 เป็นต้นไป คุณสามารถอัปโหลดและใช้ไฟล์ AVIF ได้เช่นเดียวกับไฟล์ JPEG และ PNG (ทั้งนี้ขึ้นอยู่กับสภาพแวดล้อมโฮสติ้งของคุณที่รองรับฟีเจอร์นี้)

อย่างไรก็ตาม โปรดทราบ:
“การสนับสนุนการอัปโหลด/การใช้งาน” ≠ “การแปลง/การส่งโดยอัตโนมัติ”
กล่าวอีกนัยหนึ่ง: แม้ว่าคุณจะใช้ WP 6.5 อยู่แล้ว ไฟล์ JPG/PNG ในคลังสื่อของคุณจะไม่ถูกแปลงเป็น WebP/AVIF โดยอัตโนมัติ และคุณจะไม่ได้รับฟังก์ชันการทำงานเต็มรูปแบบของ “การส่ง AVIF/WebP ตามความสามารถของเบราว์เซอร์และใช้ภาพต้นฉบับเป็นค่าสำรองสำหรับเบราว์เซอร์ที่ไม่รองรับ” โดยอัตโนมัติ—สิ่งนี้มักจะต้องใช้ปลั๊กอินหรือบริการเพื่อเติมเต็มช่องว่างนี้

2. แผนที่นำทาง: คู่มือ 5 ขั้นตอนสำหรับการปรับแต่งภาพให้เหมาะสม

ควรทำอย่างไร ทำไปทำไม อะไรถือว่าผ่าน และข้อผิดพลาดที่พบบ่อยคืออะไร

2.1 ให้ได้ “ขนาด” ที่ถูกต้องก่อน (สิ่งที่ง่ายที่สุดที่จะมองข้าม แต่ให้ประโยชน์มากที่สุด)

เว็บไซต์จำนวนมากทำงานช้าไม่ใช่เพราะไม่ได้ถูกบีบอัด แต่เป็นเพราะดาวน์โหลดภาพที่มีขนาดใหญ่กว่าพื้นที่แสดงผลมาก：
ตัวอย่างเช่น หากหน้าเว็บมีความกว้างเพียง 900 พิกเซล แต่คุณทำให้ผู้เข้าชมดาวน์โหลดภาพต้นฉบับที่มีความกว้าง 3000 พิกเซล เบราว์เซอร์ก็จะดาวน์โหลดภาพนั้นแล้วปรับขนาดให้เล็กลงเพื่อแสดงผลอยู่ดี วิธีนี้ทำให้สิ้นเปลืองแบนด์วิดท์ เพิ่มเวลาในการถอดรหัส และทำให้เนื้อหาปรากฏบนหน้าจอแรกช้าลง

สำหรับ WordPress 4.4 และเวอร์ชันใหม่กว่ากลไกการแสดงภาพที่ตอบสนอง（srcset/sizes) ถูกออกแบบมาอย่างแม่นยำเพื่อแก้ไขปัญหานี้

อะไรที่ถือว่าเป็นการผ่าน:

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

ข้อผิดพลาดที่พบบ่อยที่สุด:

• ธีมหรือผู้สร้างบางรายอาจจัดการรูปภาพเป็นภาพพื้นหลัง CSS หรือแสดงผลในรูปแบบที่กำหนดเอง ซึ่งอาจทำให้ข้าม srcsetส่งผลให้มีการดาวน์โหลดภาพขนาดใหญ่อย่างต่อเนื่อง
• หากคุณใช้บริการโฮสต์ภาพภายนอกหรือบล็อกภาพจากบุคคลที่สาม คุณอาจหลีกเลี่ยงระบบหลายขนาดที่สร้างโดยไลบรารีสื่อได้เช่นกัน

---

2.2 การบีบอัด (ลดขนาดไฟล์โดยไม่ลดคุณภาพ)

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

กฎมีดังนี้:

• ภาพถ่าย/ภาพจริง (ภาพบุคคล, ผลิตภัณฑ์, ทิวทัศน์): ให้ความสำคัญกับการบีบอัดแบบสูญเสียข้อมูล (เพื่อประโยชน์สูงสุด)
• ภาพหน้าจอของอินเทอร์เฟซ / ภาพที่มีข้อความจำนวนมาก: ใช้การตั้งค่าการบีบอัดที่ระมัดระวังมากขึ้นเพื่อหลีกเลี่ยงการทำให้ข้อความเบลอ
• โลโก้/ไอคอน: ให้ความสำคัญกับ SVG หรือใช้การบีบอัดแบบไม่สูญเสียข้อมูลด้วยความระมัดระวัง (การบีบอัดแบบสูญเสียข้อมูลอาจทำให้ขอบภาพเบลอได้ง่าย)

อะไรที่ถือว่าเป็นการผ่าน:

• ขนาดไฟล์ของภาพหน้าส่วนใหญ่ได้ถูกลดลงอย่างมีนัยสำคัญ
• ไม่มีเสียงรบกวนที่สังเกตได้ ขอบภาพไม่คมชัด สีเป็นแถบ หรือข้อความเบลอ

---

2.3 WebP / AVIF (นโยบายรูปแบบ: ขนาดไฟล์เล็กกว่าสำหรับความคมชัดในระดับเดียวกัน)

WordPress รองรับการอัปโหลดไฟล์แล้ว WebP (5.8) และ AVIF (6.5)。
อย่างไรก็ตาม เพื่อให้สามารถนำ “รูปแบบยุคถัดไป” ไปใช้ในทางปฏิบัติได้ มักจะต้องแก้ไขปัญหาสองประการ:

1. วิธีแปลงไฟล์ในคลังสื่อประวัติศาสตร์แบบกลุ่ม(มิฉะนั้น คุณจะได้ปรับแต่งเฉพาะ “ภาพใหม่ที่อัปโหลดในอนาคต”)
2. ฉันควรสร้างสำเนาหรือแทนที่รูปภาพต้นฉบับ?(นี่คือจุดสำคัญ; เราจะมุ่งเน้นไปที่ฟีเจอร์ “แทนที่และลบภาพต้นฉบับ” ของ Plus WebP ในภายหลัง)

คำแนะนำในการใช้คำ:

• WebP: โดยทั่วไปเป็นตัวเลือกเริ่มต้น (มีความเข้ากันได้ที่น่าเชื่อถือมากกว่า)
• AVIF: รูปแบบการบีบอัดขั้นสูงกว่า เหมาะสำหรับภาพขนาดใหญ่ ภาพขนาดใหญ่บนหน้าจอแรก และภาพในแกลเลอรี (แต่ใช้ทรัพยากรมากกว่า)การพึ่งพาการสนับสนุนจากสิ่งแวดล้อม）

---

2.4 ใช้การโหลดแบบตามต้องการอย่างถูกต้อง (หลีกเลี่ยงการใช้แนวทางเดียวสำหรับทุกกรณี)

ตั้งแต่ WordPress 5.5 เป็นต้นไปการโหลดแบบขี้เกียจเริ่มต้นภาพ
มันช่วยลดการใช้แบนด์วิดท์ในระหว่างการเรนเดอร์ครั้งแรก:

• การโหลดแบบเลื่อนตามการใช้งานเหมาะสำหรับ “ทรัพยากรที่อยู่นอกหน้าจอ”
• ภาพขนาดใหญ่ที่ด้านบนของหน้า (ซึ่งมักเป็นภาพที่สำคัญที่สุดบนหน้าจอแรก) โดยทั่วไปไม่เหมาะสำหรับการโหลดแบบเลื่อนออกไป

---

2.5 ชั้นการส่งมอบ: CDN / CDN รูปภาพ

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

สองแนวทางทั่วไป:

• Cloudflare โปแลนด์：เอกสารประกอบ Cloudflareส่วนนี้แนะนำวิธีการบีบอัดที่แตกต่างกันสำหรับภาษาโปแลนด์ (แบบไม่สูญเสียข้อมูล, แบบสูญเสียข้อมูล และ WebP) และกล่าวถึงการใช้ format=auto อนุญาตให้ใช้รูปแบบ WebP และ AVIF
• เจ็ตแพ็ก ไซต์ อคเซเลเรเตอร์：เอกสารประกอบ Jetpackซึ่งหมายความว่ามันจะปรับภาพให้เหมาะสมและกระจายผ่านเครือข่ายของมันพร้อมกับทรัพยากรแบบคงที่

การปรับแต่งภาพให้เหมาะสมช่วยให้ภาพมีขนาดเล็กลงและจัดรูปแบบได้อย่างถูกต้องCDNs ช่วยให้การส่งมอบรวดเร็วและเชื่อถือได้มากขึ้น

3. การเลือกเส้นทาง: ให้ยึดเพียงสองเส้นทางหลักเท่านั้น

ข้อผิดพลาดที่พบบ่อยที่สุดในการปรับแต่งภาพไม่ใช่ “การไม่ติดตั้งปลั๊กอิน” แต่เป็นการติดตั้งปลั๊กอินมากเกินไป ซึ่งนำไปสู่การประมวลผลซ้ำซ้อน:
A กำลังบีบอัด, B ก็กำลังบีบอัดเช่นกัน; A กำลังแปลงเป็น WebP/AVIF, B ก็กำลังทำเช่นเดียวกัน; A กำลังเปลี่ยน URL, B กำลังเขียน URL ใหม่—สุดท้ายแล้ว แม้แต่คุณเองก็ไม่สามารถเข้าใจได้ว่าเกิดอะไรขึ้นกับเว็บไซต์จริงๆ

กฎ:

มีเพียงตัวเลือกเดียว: คือการจัดเก็บในพื้นที่ท้องถิ่นแบบไม่เสียค่าใช้จ่ายอย่างสมบูรณ์ หรือหนึ่งในสามตัวเลือกการบีบอัดข้อมูลบนคลาวด์

• เส้นทาง A (บริการท้องถิ่นฟรีทั้งหมด):เพิ่ม WebP หรือ AVIF + EWWW Image Optimizer(หรือเลือกเพียงหนึ่งอย่าง)
• ตัวเลือก B (เลือกวิธีบีบอัดคลาวด์หนึ่งในสามวิธี):ShortPixel / Imagify / TinyPNG

---

3.1 ตัวเลือก A: โซลูชันท้องถิ่นฟรีทั้งหมด (พร้อม WebP หรือ AVIF หรือ EWWW)

คุณสมบัติหลักของเส้นทางนี้คือ:

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

3.1.1 เพิ่ม WebP หรือ AVIF: แนวคิดหลักคือ “การสร้าง/ทดแทน”; ไม่ใช่ “เครื่องมือบีบอัด” ในความหมายดั้งเดิม”

• เมื่อสร้างชุดภาพทั้งหมด:ไฟล์ ID ของภาพต้นฉบับจะถูกเขียนทับโดยไฟล์ WebP/AVIF ไฟล์ต้นฉบับจะถูกลบ และ URL ในเนื้อหาจะถูกแทนที่ด้วย。
• ปลั๊กอินนี้ให้บริการคำสั่ง WP-CLI และแนะนำให้ใช้ WP-CLI เมื่อต้องจัดการกับไฟล์จำนวนมาก เนื่องจากมีความน่าเชื่อถือมากกว่า

นี่หมายความว่า: มันไม่ได้เพียงแค่ “สร้างไฟล์ WebP ให้คุณอย่างเงียบๆ” แต่เป็นไปได้มากกว่านั้นการโอนสินทรัพย์(โดยเฉพาะเมื่อคุณเปิดใช้งานตัวเลือก “แทนที่และลบต้นฉบับ”)

ความแตกต่างระหว่างสองโหมด

โหมด 1: เก็บภาพต้นฉบับไว้ + สร้างสำเนา WebP/AVIF (เชื่อถือได้มากกว่า)

• ข้อได้เปรียบ: สามารถย้อนกลับได้ง่ายหากเกิดปัญหาความเข้ากันไม่ได้
• ข้อเสีย: การใช้พื้นที่ดิสก์เพิ่มขึ้น (ภาพต้นฉบับ + รูปแบบใหม่ + ขนาดภาพย่อหลายขนาด)

วิธี 2: แทนที่และลบภาพต้นฉบับ (รุนแรงกว่า)

• ข้อดี: แผ่นดิสก์จะไม่เต็มเร็วเกินไป; ลิงก์ภายในจะถูกแปลงเป็นรูปแบบใหม่โดยอัตโนมัติ
• ความเสี่ยง: หากคุณแก้ไขทั้งสินทรัพย์และการอ้างอิงของสินทรัพย์นั้น การแก้ไขปัญหาความเข้ากันได้จะมีค่าใช้จ่ายสูงขึ้น (โดยเฉพาะหากระบบภายนอกหรือตรรกะของธีมบางระบบพึ่งพาชื่อไฟล์, เส้นทาง หรือรูปแบบไฟล์เดิม)

ข้อผิดพลาดที่พบบ่อยกับ WebP หรือ AVIF

1. หลังจากทำการแทนที่ห้องสมุดทั้งหมดแล้ว รูปภาพในบางหน้าแสดงผลไม่ถูกต้อง
   สาเหตุมักไม่ใช่เพราะ “ภาพเสียหาย” แต่เป็นเพราะมีบางอย่างผิดพลาดในกระบวนการ เช่น การเปลี่ยนแปลง URL การแคช หรือนโยบายของภาพขนาดย่อ
2. ยิ่งมีภาพขนาดย่อมากเท่าใด ขอบเขตของการเปลี่ยนแปลงก็จะยิ่งมากขึ้นเท่านั้น
   การอัปโหลดรูปภาพไปยัง WordPress จะสร้างขนาดรูปภาพหลายขนาด; ธีมและปลั๊กอินอาจเพิ่มขนาดเพิ่มเติมได้อีก การแทนที่ทั้งหมดหมายความว่าคุณอาจกำลังแก้ไขไฟล์จำนวนมาก
3. การดำเนินการย้ายรูปแบบเพียงอย่างเดียวไม่จำเป็นต้องส่งผลให้มีขนาดไฟล์ที่เล็กที่สุด
   ไฟล์ WebP และ AVIF มักจะมีขนาดเล็กกว่า แต่การ “กำหนดขนาด” และ “การบีบอัด” ยังคงมีความสำคัญ อย่าใช้ Plus WebP เป็น “โซลูชันแบบคลิกเดียว” สำหรับการโหลดที่เร็วขึ้น

---

3.1.2 EWWW Image Optimizer: ผู้ให้บริการชั้นนำด้านการบีบอัดข้อมูลในท้องถิ่นฟรี

หน้าปลั๊กอิน EWWW มีวัตถุประสงค์ที่ชัดเจนมาก:

• สามารถปรับแต่งไฟล์บนเซิร์ฟเวอร์ของคุณให้เหมาะสมโดยใช้เครื่องมือหลากหลาย (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, เป็นต้น)
• หากคุณต้องการการบีบอัดที่สูงขึ้นหรือต้องการลดการใช้ CPU คุณสามารถถ่ายโอนการประมวลผลที่ใช้ CPU หนักไปยังเซิร์ฟเวอร์ของพวกเขาได้ (ไม่บังคับ)

บทบาทของ EWWW ในเส้นทาง A ควรเป็นอย่างไร?

หากคุณกำลังใช้ Plus WebP สำหรับ “กลยุทธ์การย้าย/แทนที่รูปแบบ” แล้ว EWWW จะเหมาะสมกว่าสำหรับ:

• การบีบอัดและการปรับปริมาณให้เหมาะสม(โดยเฉพาะการเพิ่มประสิทธิภาพของสินทรัพย์ดิบ เช่น ไฟล์ JPG และ PNG)
• การเพิ่มประสิทธิภาพแบบกลุ่มของคลังสื่อในอดีต(มุ่งเน้นการ “ลดปริมาณ” มากกว่า “การแทนที่ URL”)

ข้อผิดพลาดทั่วไปของ EWWW

1. โหลดเซิร์ฟเวอร์เพิ่มขึ้นระหว่างการปรับให้เหมาะสมแบบกลุ่ม
   เนื่องจากการบีบอัดข้อมูลในเครื่องใช้ทรัพยากร CPU และ I/O อย่างมาก วิธีแก้ไขจึงไม่ใช่การ “หยุดใช้งาน” แต่ควร “ประมวลผลเป็นชุดในช่วงเวลาที่ไม่ใช่ชั่วโมงเร่งด่วน และเลือกใช้การถ่ายโอนข้อมูลหรือโซลูชันบนคลาวด์เมื่อจำเป็น”
2. “WebP ถูกสร้างขึ้น” ไม่จำเป็นต้องหมายความว่า WebP กำลังถูกให้บริการบนหน้าเว็บ
   ปลั๊กอินจำนวนมากทำงานภายใต้ความเข้าใจผิดว่าการสร้างเนื้อหาเป็นเพียงเรื่องเดียว ในขณะที่กลยุทธ์การส่งมอบ (เช่น การเขียนใหม่, แท็ก `picture`, การเข้าถึงแคช ฯลฯ) เป็นอีกเรื่องหนึ่งโดยสิ้นเชิง
3. ทำหน้าที่ซ้ำกับปลั๊กอินอื่น
   หากคุณเลือกตัวเลือก A ให้หลีกเลี่ยงการใช้บริการบีบอัดข้อมูลบนคลาวด์เพิ่มเติม เช่น ShortPixel, Imagify หรือ TinyPNG; หากคุณเลือกตัวเลือก B อย่าเปิดใช้งานตรรกะการแทนที่สำหรับ Plus WebP หลักการสำคัญคือ:ยึดมั่นในแนวทางเดียว

---

3.2 ตัวเลือก B: เลือกหนึ่งในสามบริการบีบอัดคลาวด์ (ShortPixel / Imagify / TinyPNG)

แผนนี้เหมาะอย่างยิ่งสำหรับผู้ที่ต้องการประหยัดทรัพยากรเซิร์ฟเวอร์ ชอบวิธีการประมวลผลแบบกลุ่มที่ไม่ต้องยุ่งยาก และพอใจกับรูปแบบการเรียกเก็บเงินตามการใช้งานจริงหรือแบบจ่ายตามการใช้งาน
อย่างไรก็ตาม ความเข้าใจผิดที่พบบ่อยที่สุดเกี่ยวกับการบีบอัดข้อมูลบนคลาวด์คือ:การให้สิทธิ์ฟรีไม่ใช่เพียงแค่เรื่องของ “หน้าฟรี”จำนวนขนาดของภาพขนาดย่อ, การสร้างรูปแบบ WebP/AVIF, และการบีบอัดภาพซ้ำ ๆ จะมีผลกระทบอย่างมากต่อการใช้งานทรัพยากร

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

---

3.2.1 ShortPixel: เครดิตฟรี 100 เครดิตต่อเดือน แต่เครดิตจะถูกใช้ไปกับการสร้างภาพขนาดย่อและการขยายภาพ WebP/AVIF

อะไรคือความแตกต่างระหว่างตัวเลือกฟรีและตัวเลือกที่ต้องเสียเงิน?

คำอธิบายของปลั๊กอิน ShortPixel ระบุไว้อย่างชัดเจนว่า:

• 100 เครดิตฟรีต่อเดือน
• นอกจากนี้ยังมี “เครดิตรายเดือนไม่จำกัดเพิ่มเติม” (รายละเอียดราคาจะแสดงอยู่ในหน้าปลั๊กอิน)
• เรายังมี “แพ็กเกจเครดิตแบบครั้งเดียวที่ไม่หมดอายุ” (พร้อมข้อมูลเกี่ยวกับราคาเริ่มต้น)

คำแนะนำ:

• ฟรี: จำนวนเครดิตที่กำหนดไว้ให้ทุกเดือน เหมาะสำหรับเว็บไซต์ที่มีการใช้งานน้อยหรือการทดสอบ
• แพ็กเกจครั้งเดียว: เหมาะสำหรับเว็บไซต์ที่มีคลังสื่อขนาดใหญ่ที่ต้องการเคลียร์สต็อกทั้งหมดในครั้งเดียว (ซื้อครั้งเดียวและใช้ได้จนหมด; โดยทั่วไปไม่มีวันหมดอายุ)
• รายเดือน/ไม่จำกัด: เหมาะสำหรับเว็บไซต์ที่ต้องการอัปเดตภาพเป็นประจำและต้องการการปรับแต่งให้เหมาะสมในระยะยาว

ฐานความรู้อย่างเป็นทางการของ ShortPixel ยังมีข้อมูลเกี่ยวกับ “แพ็กเกจครั้งเดียว vs แพ็กเกจรายเดือนไม่จำกัด”คำอธิบายที่ชัดเจน: แผนรายเดือนไม่จำกัดจะเรียกเก็บเงินเป็นรายเดือน (หรือรายปี) โดยให้เครดิตไม่จำกัดและโควต้า CDN คงที่ เครดิตแบบครั้งเดียวจะไม่หมดอายุ ทำให้คุณมีการควบคุมการใช้งานตามความต้องการได้มากขึ้น

สิ่งที่สำคัญที่สุด: เครดิตของ ShortPixel คำนวณอย่างไร?

เอกสารทางการของ ShortPixel เคบีพูดอย่างตรงไปตรงมา:

• เมื่อคุณอัปโหลดรูปภาพไปยัง WordPress ระบบจะสร้างภาพขนาดย่อหลายภาพโดยอัตโนมัติ
• การเพิ่มประสิทธิภาพภาพขนาดย่อแต่ละภาพจะนับเป็นเครดิตหนึ่งครั้ง；
• หากคุณเลือกที่จะสร้างไฟล์ WebP หรือ AVIFแต่ละเวอร์ชัน WebP/AVIF ของภาพต้นฉบับและภาพขนาดย่อจะนับเป็นเครดิตเพิ่มเติม；
• คุณสามารถยกเว้นภาพขนาดย่อบางภาพจากการปรับให้เหมาะสมเพื่อลดการใช้เครดิต

ตัวอย่างเครดิต：

สมมติว่าคุณอัปโหลดรูปภาพหนึ่งรูป และธีมหรือปลั๊กอินจะสร้างภาพขนาดย่อแปดภาพ:

• ปรับแต่งเฉพาะภาพต้นฉบับและภาพขนาดย่อ: 1 (ภาพต้นฉบับ) + 8 (ภาพขนาดย่อ) = 9 เครดิต
• หากคุณต้องการสร้างไฟล์ WebP/AVIF ด้วย: ให้เพิ่มเวอร์ชันใหม่ในไฟล์แต่ละไฟล์จาก 9 ไฟล์ข้างต้น → บวกกับเครดิต 9 เครดิต
  กล่าวอีกนัยหนึ่ง คุณอาจคิดว่ามันเป็น “ภาพเดียว” แต่จริงๆ แล้วอาจมีค่าใช้จ่ายเกือบ “เครดิตสองหลัก”

ดังนั้น:“100 เครดิตฟรี” ไม่ได้หมายถึง “100 รูปภาพฟรี”

ข้อผิดพลาดที่พบบ่อยที่สุดของ ShortPixel

1. เครดิตฟรี 100 เครดิตจะหมดอายุในเร็ว ๆ นี้
   สาเหตุหลัก: มีภาพขนาดย่อจำนวนมาก + เครดิตเพิ่มเติมสำหรับการสร้างไฟล์ WebP/AVIF
   แนะนำ：

• ขั้นแรก ประเมินจำนวนภาพขนาดย่อของเว็บไซต์
• ยกเว้นขนาดภาพขนาดย่อที่ไม่จำเป็น (ปรับขนาดเฉพาะที่ใช้จริงเท่านั้น)
• ตัดสินใจเลือกกลยุทธ์การบีบอัดก่อน จากนั้นจึงดำเนินการเป็นชุดเพื่อหลีกเลี่ยงการเสียเวลาในการลองผิดลองถูก

2. ใช้ร่วมกับปลั๊กอินการแปลงรูปแบบอื่น ๆ
   หากคุณเปิดใช้งานการแทนที่ Plus WebP และให้ ShortPixel สร้างและแทร็กแท็ก `next-gen` ด้วย ตรรกะจะทับซ้อนกัน ทำให้การแก้ไขปัญหาทำได้ยากขึ้น ด้วยตัวเลือก B, ShortPixel จะจัดการงานนี้ด้วยตัวเอง
3. ผมเข้าใจว่าเมื่อติดตั้งเสร็จแล้ว ส่วนหน้าจะสร้างไฟล์ WebP/AVIF โดยอัตโนมัติ“
   หน้าปลั๊กอิน ShortPixelควรสังเกตว่ามันสามารถแปลงไฟล์ WebP/AVIF และรวมภาพรุ่นใหม่เข้ากับหน้าเว็บส่วนหน้าได้ (เช่น ผ่านแท็ก)
   อย่างไรก็ตาม เมื่อคุณทำเสร็จแล้ว คุณยังต้องตรวจสอบว่ามันทำงานได้

---

3.2.2 Imagify: ฟรี 20MB/เดือน; โควตาจะถูกหักตาม “ขนาดภาพต้นฉบับ + จำนวนภาพขนาดย่อ”; การอัปโหลดซ้ำจะทำให้เกิดการหักโควตาซ้ำ

ค่าเบี้ยเลี้ยงและสถานที่

หน้าแสดงราคาอย่างเป็นทางการของ Imagifyมีการระบุไว้อย่างชัดเจนว่า:บัญชีฟรีมีโควต้าต่อเดือน 20MB。
หน้าปลั๊กอินของมันยังระบุว่าสามารถบีบอัด, ปรับขนาด และแปลงเป็น WebP/AVIF ได้

โควตาถูกหักอย่างไร?

เอกสารทางการของ Imagify “วิธีการคำนวณการใช้งานโควต้า” อธิบายกลไกการเรียกเก็บเงินอย่างชัดเจนมาก:

• จำนวนของภาพขนาดย่อมีผลต่อการใช้งานทรัพยากรตัวอย่างเช่น หากคุณมีขนาดภาพขนาดย่อ 10 ขนาด การปรับภาพให้เหมาะสมอย่างมีประสิทธิภาพหมายถึงการปรับภาพ 11 ภาพ (ภาพต้นฉบับบวกกับภาพขนาดย่อ 10 ภาพ) ซึ่งทั้งหมดนี้จะถูกนับรวมในโควตาของคุณ
• หักโควตาตามขนาดไฟล์ต้นฉบับตัวอย่างเช่น หากคุณอัปโหลดภาพขนาด 100KB ไปยัง Imagify จะมีการหักโควตาของคุณ 100KB
• การเปลี่ยนระดับการบีบอัดและการปรับให้เหมาะสมใหม่อีกครั้งจะใช้โควต้าอีกครั้ง。
• คีย์ API เดียวสามารถใช้ได้กับหลายเว็บไซต์ แต่โควตาจะถูกใช้ร่วมกัน

นี่คือ “แนวทางหลัก” ของ Imagify:
มันเหมือนกับแพ็กเกจแบบจ่ายตามการใช้งาน: ยิ่งคุณอัปโหลดมาก คุณก็ยิ่งถูกเรียกเก็บเงินมาก; ยิ่งคุณสร้างภาพตัวอย่างมาก คุณก็ยิ่งถูกเรียกเก็บเงินมาก; และหากคุณอัปโหลดเนื้อหาเดิมซ้ำ ๆ คุณจะถูกเรียกเก็บเงินอีกครั้งทุกครั้ง

ตัวอย่างที่เข้าใจง่ายของโควตาของ Imagify

สมมติว่าคุณอัปโหลดภาพต้นฉบับขนาด 800 KB และเว็บไซต์สร้างภาพขนาดย่อแปดภาพ

• เมื่อทำการปรับให้เหมาะสมด้วย Imagify ทั้ง “ภาพต้นฉบับและภาพขนาดย่อ 8 ภาพ” จะถูกรวมอยู่ด้วย (หากคุณเลือก “ปรับให้เหมาะสมทั้งหมด”) ซึ่งหมายความว่าการดำเนินการนี้จะใช้โควต้าเท่ากับเกือบ 'ขนาดรวมของไฟล์ทั้งหมดเหล่านี้'
  นี่คือเหตุผลที่บางเว็บไซต์พบว่า “20MB หมดเร็วมาก”: ไม่ใช่ว่า Imagify ไม่ทรงพลังพอ แต่เป็นเพราะภาพที่คุณอัปโหลดมีขนาดใหญ่เกินไป คุณกำลังสร้างภาพขนาดย่อมากเกินไป และคุณอาจกำลังทดลองใช้ระดับการบีบอัดที่แตกต่างกันซ้ำๆ

ข้อผิดพลาดที่พบบ่อยที่สุดกับ Imagify

1. โควต้าฟรี 20MB ไม่เพียงพอสำหรับการทำ “การล้างประวัติเว็บไซต์ทั้งหมด”
   20MB โดยทั่วไปเหมาะสำหรับการทดสอบและการอัปเดตเล็กน้อย; หากไลบรารีมีเดียของคุณมีขนาดใหญ่แล้ว การล้างทั้งหมดในครั้งเดียวอาจจำเป็นต้องอัปเกรด
2. การปรับระดับการบีบอัดซ้ำหลายครั้งส่งผลให้มีการใช้โควต้าซ้ำซ้อน
   Imagify: คำอธิบายที่ชัดเจนการปรับให้เหมาะสมใหม่อีกครั้งจะใช้โควต้าอีกครั้ง
   เราขอแนะนำให้คุณระบุ “กลยุทธ์” อย่างชัดเจนในหน้านี้:

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

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

---

3.2.3 TinyPNG(บีบอัดภาพขนาดเล็ก): เครดิตฟรี 500 เครดิตต่อเดือน; การแปลงเป็น WebP/AVIF จะมีค่าใช้จ่ายเพิ่มเติม 1 เครดิตต่อขนาด“

สิทธิประโยชน์ที่ได้รับโดยไม่มีค่าใช้จ่ายและวิธีการคำนวณ

หน้าปลั๊กอิน TinyPNG สำหรับ WordPress เขียนไว้อย่างชัดเจนมาก:

• 500 เครดิตฟรีทุกเดือน
• ในการติดตั้ง WordPress แบบมาตรฐาน คุณอาจสามารถบีบอัดได้ ประมาณ 100 ภาพต่อเดือน
• อย่างไรก็ตาม หากการแปลงเป็น AVIF หรือ WebP ถูกเปิดใช้งาน:ขนาดภาพแต่ละขนาดจะมีค่าใช้จ่ายเพิ่มอีกหนึ่งเครดิตดังนั้น ฉันคิดว่าทางเลือกเดียวคือบีบอัดและแปลงไฟล์ ประมาณ 50 ภาพต่อเดือน(สิ่งนี้ขึ้นอยู่กับจำนวนขนาดของภาพขนาดย่อที่คุณมี)

ในขณะเดียวกัน Tinify (ผู้พัฒนา TinyPNG และ TinyJPG) ก็ได้ หน้าการกำหนดราคา APIโปรดทราบ: ลงทะเบียนเพื่อรับการบีบอัดฟรี 500 ครั้งต่อเดือน; เมื่อเกินขีดจำกัดนี้ คุณจะถูกเรียกเก็บเงินตามจำนวนการบีบอัดที่สำเร็จ โดยไม่มีการสมัครสมาชิกบังคับ

เพื่อสรุปความเข้าใจของฉันเกี่ยวกับ TinyPNG ในประโยคเดียว:
คำนวณเป็นเครดิต; ยิ่งมีขนาดภาพขนาดย่อมากและยิ่งเปิดใช้งาน WebP/AVIF มาก เครดิตของคุณจะหมดเร็วขึ้น

ตัวอย่างเครดิตของ TinyPNG ที่เข้าใจง่าย

สมมติว่าเว็บไซต์ของคุณสร้างขนาดภาพขนาดย่อแปดขนาดสำหรับแต่ละภาพ:

• บีบอัดเท่านั้น: รูปภาพต้นฉบับ + 8 ภาพขนาดย่อ → ต้องใช้ 9 เครดิต
• หากการแปลงเป็น WebP/AVIF เปิดใช้งาน: เครดิตเพิ่มเติมจะถูกหักออกสำหรับแต่ละขนาด → ซึ่งอาจทำให้ยอดรวมเพิ่มขึ้นเกือบสองเท่า
  สิ่งนี้ตรงกับคำอธิบายในหน้าปลั๊กอินอย่างสมบูรณ์: เมื่อเปิดใช้งานการแปลงแล้ว หน่วยโควต้าฟรีจะเปลี่ยนจากประมาณ “100 ต่อเดือน” เป็น “50 ต่อเดือน”

ข้อผิดพลาดที่พบบ่อยที่สุดกับ TinyPNG

1. ฉันคิดว่า 500 เครดิต หมายถึง 500 ภาพ
   ไม่. มันถูกใช้บนพื้นฐานของ “ขนาดภาพ/รูปแบบ”. หน้าของปลั๊กอินระบุไว้ชัดเจนว่า “การแปลงจะหักเครดิตเพิ่มเติม 1 เครดิตสำหรับแต่ละขนาดภาพ”.
2. ปลั๊กอินธีม/อีคอมเมิร์ซสร้างขนาดรูปภาพมากเกินไป และโควต้าฟรีลดลงอย่างมาก
   ยิ่งมีมิติมากเท่าไร เครดิตก็ยิ่งถูกใช้หมดได้ง่ายขึ้นเท่านั้น
3. หลังจากเปิดใช้งานการแปลงแล้ว ฉันพบว่าวงเงินเครดิตของฉันไม่เพียงพอทันที
   นี่ไม่ใช่ข้อผิดพลาด; นี่คือวิธีการทำงานของการเรียกเก็บเงิน
   คำแนะนำด้านกลยุทธ์:

• หากเฟสฟรีมีวัตถุประสงค์หลักเพื่อการบีบอัดและลดน้ำหนัก คุณสามารถเริ่มต้นด้วยการบีบอัดเพียงอย่างเดียว เมื่อคุณยืนยันแล้วว่าโครงสร้างของเว็บไซต์มีความเสถียรและคุณจำเป็นต้องใช้ Next.js จริง ๆ คุณสามารถเริ่มการย้ายข้อมูลได้

4. ข้อเสนอแนะตามสถานการณ์: วิธีการเลือกประเภทของสถานที่ที่แตกต่างกัน

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

4.1 เว็บไซต์เนื้อหา/บล็อก (มีรูปภาพและบทความจำนวนมาก พร้อมความถี่ในการอัปเดตปานกลาง)

คำแนะนำที่มีความสำคัญลำดับแรก:

1. กลยุทธ์การกำหนดขนาด (ขั้นตอนที่ 1)
2. การบีบอัด (ขั้นตอนที่ 2)
3. WebP (ขั้นตอนที่ 3)

เส้นทางที่เหมาะสมกว่า:

• หากคุณต้องการตัวเลือกที่ไม่ต้องยุ่งยาก: เลือกหนึ่งในสามตัวเลือกในตัวเลือก B (ShortPixel / Imagify / TinyPNG)
• หากคุณต้องการตัวเลือกฟรี: เส้นทาง A (พร้อม WebP + EWWW) แต่เราขอแนะนำให้เริ่มต้นด้วย “โหมดอนุรักษ์ (ไม่ลบภาพต้นฉบับ)” เพื่อประเมินความเสี่ยงก่อน

ข้อผิดพลาดที่พบบ่อย:

• ภาพที่แสดงที่ด้านบนของบทความมีขนาดใหญ่มาก และกลยุทธ์การโหลดแบบเลื่อนดูไม่เหมาะสมมันจะชะลอหน้าจอแรก

4.2 เว็บไซต์อีคอมเมิร์ซ/ผลิตภัณฑ์ (มีภาพขนาดย่อและภาพหลากหลายรูปแบบจำนวนมาก; ความเสถียรเป็นสิ่งสำคัญสูงสุด)

ปัญหาที่พบบ่อยที่สุดในอีคอมเมิร์ซไม่ใช่เรื่องที่ “การบีบอัดไม่มีประสิทธิภาพ” แต่เป็นเรื่องที่ “ขนาดบางอย่างไม่ถูกต้องหลังการปรับให้เหมาะสม, ภาพขนาดย่อหายไป, หรือส่วนประกอบหน้าเว็บไม่สามารถดึงภาพได้”

คำแนะนำที่มีความสำคัญลำดับแรก:

1. เริ่มต้นอย่างระมัดระวัง: ใช้กลยุทธ์การบีบอัดแบบอนุรักษ์นิยม และอย่าแทนที่ฐานข้อมูลทั้งหมดในทันที
2. การประเมินขนาดภาพขนาดย่อ: ธีมอีคอมเมิร์ซมักจะสร้างขนาดภาพมากขึ้น ซึ่งอาจเพิ่มการใช้ข้อมูลอย่างมาก (สิ่งนี้สังเกตเห็นได้ชัดเจนโดยเฉพาะกับ ShortPixel และ TinyPNG)
3. ดำเนินการทดลองในขนาดเล็กก่อน จากนั้นจึงขยายขนาด (ขั้นตอนนี้สำคัญอย่างยิ่ง)

เส้นทางที่เหมาะสมกว่า:

• ตัวเลือก B มักจะเป็นตัวเลือกที่ยุ่งยากน้อยกว่า: ShortPixel, Imagify และ TinyPNG ทั้งหมดรองรับการประมวลผลแบบกลุ่ม; สิ่งสำคัญคือการทำความเข้าใจระบบโควต้าและประเมินค่าใช้จ่ายล่วงหน้า
• ตัวเลือก A ก็ยอมรับได้เช่นกัน แต่คุณควรใช้ความระมัดระวังมากขึ้นเกี่ยวกับพฤติกรรมของ Plus WebP ในเรื่อง “การเขียนทับ ID, การลบภาพต้นฉบับ และการแทนที่ URL”: เนื่องจากนี่ถือเป็นการย้ายทรัพยากร เราไม่แนะนำให้แทนที่ทุกอย่างในคราวเดียวตั้งแต่เริ่มต้น

4.3 เว็บไซต์พอร์ตโฟลิโอ/ภาพถ่าย (ที่ความคมชัดของภาพมีความสำคัญ, ไฟล์มีขนาดใหญ่, และความสวยงามทางสายตาเป็นสิ่งสำคัญที่สุด)

คำแนะนำที่มีความสำคัญลำดับแรก:

1. กลยุทธ์การกำหนดขนาด (การควบคุมพื้นที่แสดงผล)
2. กลยุทธ์การบีบอัด (ดีกว่าที่จะมีไฟล์ใหญ่ขึ้นเล็กน้อยกว่าที่จะสูญเสียรายละเอียด)
3. WebP/AVIF (ประโยชน์ชัดเจนสำหรับภาพขนาดใหญ่ แต่คุณภาพทางสายตาต้องตรวจสอบ)

เส้นทางที่เหมาะสมกว่า:

• Imagify: เนื่องจากโควตาถูกหักตามขนาดภาพต้นฉบับ เว็บไซต์ประเภทนี้จึงช่วยให้ควบคุมค่าใช้จ่ายได้ง่ายขึ้น (เนื่องจากคุณสามารถประมาณค่าใช้จ่ายของภาพขนาดใหญ่แต่ละภาพได้) อย่างไรก็ตาม คุณควรหลีกเลี่ยงการบีบอัดภาพซ้ำหลายครั้ง
• ShortPixel: หากขนาดภาพขนาดย่อไม่มากเกินไป เครดิตจะค่อนข้างตรงไปตรงมา อย่างไรก็ตาม หากคุณสร้างขนาดจำนวนมากรวมถึงเวอร์ชันรุ่นใหม่ด้วย เครดิตจะเพิ่มขึ้นอย่างมาก ดังนั้นคุณจำเป็นต้องวางแผนล่วงหน้า

5. โควตา vs. การเรียกเก็บเงิน: การพิจารณาอย่างละเอียดว่าโควตาฟรีเพียงพอหรือไม่

อันไหนคุ้มค่ากว่ากัน และระยะเวลาทดลองใช้ฟรีจะนานแค่ไหน?

5.1 รูปแบบการเรียกเก็บเงินสามแบบ

• ShortPixel(เครดิต): เครดิตจะถูกคำนวณตาม “ภาพต้นฉบับบวกกับจำนวนภาพขนาดย่อ”; การสร้างไฟล์ WebP/AVIF จะมีค่าใช้จ่ายเครดิตเพิ่มเติมสำหรับแต่ละเวอร์ชันที่สอดคล้องกัน
• Imagify(เบี้ยเลี้ยง MB): โควตาจะถูกหักตาม “ขนาดไฟล์ต้นฉบับ”; ยิ่งมีภาพขนาดย่อมาก โควตาก็จะถูกใช้มากขึ้น; การบีบอัดใหม่จะทำให้ใช้โควตามากขึ้นอีก
• TinyPNG(เครดิต): 500 เครดิตต่อเดือน; การเปิดใช้งานการแปลงเป็น WebP/AVIF จะมีค่าใช้จ่ายเพิ่มเติมตามขนาดของภาพ

5.2 วิธีการประมาณการอย่างรวดเร็ว

คุณสามารถประมาณได้ดังนี้:

1. เพียงเลือก “ภาพต้นฉบับที่คุณอัปโหลดบ่อย” และตรวจสอบขนาดโดยประมาณ (เช่น 300 KB / 1 MB / 3 MB)
2. ขึ้นอยู่กับขนาดของภาพขนาดย่อที่เว็บไซต์ของคุณสร้างขึ้นโดยปกติ (เช่น 5, 10 หรือ 20)
3. ตัดสินใจว่าคุณต้องการสร้างไฟล์ WebP/AVIF (ใช่/ไม่)

จากนั้นใช้ “การคำนวณทางจิต” ด้านล่างเพื่อทำความเข้าใจการบริโภค:

• ShortPixel: แต่ละภาพ ≈ (1 + จำนวนภาพขนาดย่อ) เครดิต; หากมีการสร้าง WebP/AVIF จะเพิ่มเป็น ≈ สองเท่า (เนื่องจากเวอร์ชันถัดไปก็ต้องการเครดิตเช่นกัน)
• Imagify: โควตาจะถูกหักออกสำหรับแต่ละภาพตามประมาณการ (ขนาดภาพต้นฉบับ + ขนาดรวมของภาพขนาดย่อทั้งหมด); การเปลี่ยนระดับการบีบอัดและการบีบอัดภาพใหม่อีกครั้งจะส่งผลให้มีการหักโควตาเพิ่มเติม
• TinyPNG: เครดิตฟรี 500 เครดิต; หากเว็บไซต์ของคุณสร้างขนาดรูปภาพจำนวนมากต่อภาพ และการแปลงรูปภาพถูกเปิดใช้งาน จำนวนรูปภาพฟรีจะลดลงอย่างมาก (หน้าปลั๊กอินให้ประมาณการคร่าว ๆ ว่า “ประมาณ 100 ต่อเดือน” และ “ประมาณ 50 ต่อเดือน”)

6. การเปิดเผยความเสี่ยง

ความเสี่ยง 1: หลีกเลี่ยงการมีปลั๊กอินหลายตัวที่ทำงานเดียวกัน

นี่คือ “ต้นเหตุของหายนะ” ที่พบได้บ่อยที่สุด”

• เส้นทาง A:บวก WebP หรือ AVIF + EWWW(กรุณาตรวจสอบให้แน่ใจว่าทั้งสองงานนี้ดำเนินการแยกกัน; อย่าทำการแปลงและส่งมอบในเวลาเดียวกัน หรือติดตั้งเพียงอย่างใดอย่างหนึ่งเท่านั้น)
• ตัวเลือก B: ShortPixel / Imagify / TinyPNG เลือกหนึ่งจากสาม(เลือกหนึ่งเพื่อจัดการกับการบีบอัดและเทคโนโลยีรุ่นใหม่)

ความเสี่ยง 2: คุณสมบัติ “เขียนทับ ID / ลบภาพต้นฉบับ / แทนที่ URL” ของ WebP เป็นส่วนหนึ่งของการโยกย้ายสินทรัพย์

เพื่อย้ำอีกครั้ง:พลัส เว็บพี คำอธิบายระบุไว้อย่างชัดเจนว่า ในระหว่างการสร้างรุ่นเต็ม ภาพ ID ต้นฉบับจะถูกเขียนทับ ไฟล์ต้นฉบับจะถูกลบ และ URL ของเนื้อหาจะถูกแทนที่
ซึ่งหมายความว่านี่ไม่ใช่ “การปรับเปลี่ยนเล็กน้อยที่สามารถย้อนกลับได้ตลอดเวลา” แต่เป็นการเปลี่ยนแปลงในระดับสินทรัพย์

กลยุทธ์ที่แนะนำควรเป็น:

• เริ่มต้นด้วยการทดสอบขนาดเล็ก (ไม่กี่สิบถึงไม่กี่ร้อย)
• ยืนยันว่าการแสดงผลส่วนหน้า, รูปภาพขนาดย่อ และการอัปเดตแคชทำงานได้อย่างถูกต้อง
• พิจารณาการประมวลผลฐานข้อมูลทั้งหมด

ความเสี่ยง 3: การใช้ประโยชน์จริงของ “ระดับฟรี” ของการบีบอัดบนคลาวด์ขึ้นอยู่กับจำนวนภาพขนาดย่อและการเลือกตัวเลือกเจเนอเรชั่นถัดไป

• ShortPixel: ภาพขนาดย่อและเทคโนโลยีรุ่นใหม่จะมีผลกระทบอย่างมากต่อเครดิต
• TinyPNG: การเปิดใช้งาน WebP/AVIF จะส่งผลให้มีการหักเครดิตเพิ่มเติมสำหรับขนาดภาพแต่ละขนาด
• Imagify: ค่าบริการตามขนาดภาพต้นฉบับ; ยิ่งมีภาพขนาดย่อมาก ค่าบริการก็จะสูงขึ้น; การดาวน์โหลดซ้ำจะมีค่าบริการเพิ่มเติม

ความเสี่ยง 4: “มีการสร้าง WebP/AVIF แล้ว” ไม่ได้หมายความว่า “ส่วนหน้าของเว็บไซต์กำลังให้บริการ WebP/AVIF”

หลายคนรู้สึกว่าสิ่งต่าง ๆ ไม่ได้เร็วขึ้นหลังจากการเปลี่ยนแปลง สาเหตุหลักคือส่วนหน้าของระบบยังคงให้บริการไฟล์ JPG/PNG (เนื่องจากความไม่ตรงกันในสิ่งต่อไปนี้: การแคช, การเขียนใหม่, แท็ก หรือการเจรจาของเบราว์เซอร์)

7. ฉันจะตรวจสอบได้อย่างไรว่ามันได้ผลหรือไม่เมื่อฉันทำเสร็จแล้ว?

4 จุดตรวจสอบง่าย ๆ:

1. เมื่อรีเฟรชหน้าเดิมเป็นครั้งที่สอง กระบวนการโหลดมีความเสถียรและรวดเร็วกว่าเดิมหรือไม่?(ผลกระทบจากการแคชและการปรับแต่งประสิทธิภาพนั้นสังเกตเห็นได้ชัดเจนเพียงใด?)
2. มีความแตกต่างที่สังเกตได้หรือไม่ในขนาดของภาพที่โหลดบนอุปกรณ์มือถือและคอมพิวเตอร์เดสก์ท็อป?(ตอบสนองต่อ srcset/sizes (ไม่ว่ามันจะได้ผลหรือไม่)
3. สุ่มตรวจสอบรูปภาพบางภาพ: มีไฟล์หรือทรัพยากรประเภท WebP หรือ AVIF อยู่หรือไม่?(เว็บไซต์นี้กำลังใช้งานจริงหรือไม่ next-gen）
4. ลองดูภาพตัวอย่างสักสองสามภาพ: ขยายดูให้ใกล้เพื่อสังเกตว่าภาพเบลออย่างเห็นได้ชัดหรือไม่ หรือตัวอักษรดูพร่ามัวหรือเปล่า(การบีบอัดแรงเกินไปหรือไม่?)

หากทั้งสี่ข้อเหล่านี้ตรงกัน หมายความว่าเส้นทางที่คุณเลือกนั้นได้ดำเนินการไปแล้ว ต่อไปให้ดำเนินการต่อที่ CDN “เลเยอร์การส่งมอบ”... มันจะมีความเสถียรมากขึ้นโดยรวม

8. ข้อเสนอแนะเพื่อการดำเนินการ

1. ก่อนอื่น เลือกเส้นทาง:

• ฉันต้องการให้มันฟรีมากที่สุดเท่าที่จะเป็นไปได้: บวก WebP หรือ AVIF + EWWW (หรือติดตั้งเพียงหนึ่งในนั้น)
• ต้องการประหยัดทรัพยากรเซิร์ฟเวอร์หรือไม่? การจ่ายตามการใช้งานสะดวกกว่า: เลือกหนึ่งใน ShortPixel, Imagify หรือ TinyPNG

2. เริ่มต้นด้วยการทดสอบขนาดเล็ก (ไม่กี่โหล)
3. ตรวจสอบให้แน่ใจว่าทุกอย่างเรียบร้อยก่อนดำเนินการเป็นชุด
4. ความน่าเชื่อถือของการจัดส่งจำเป็นต้องได้รับการปรับปรุงเพิ่มเติม:อ่าน การเร่งความเร็วของ CDN

คำถามที่พบบ่อย

1. ฉันควรติดตั้งปลั๊กอินกี่ตัว? ฉันสามารถติดตั้งทั้งหมดได้หรือไม่?

พยายามยึดเส้นทางเดียว

• ตัวเลือก A: เพิ่ม WebP หรือ AVIF + EWWW Image Optimizer (หรือติดตั้งเพียงอย่างใดอย่างหนึ่ง)
• ตัวเลือก B: เลือกหนึ่งใน ShortPixel, Imagify หรือ TinyPNG
  การมีปลั๊กอินหลายตัวในเว็บไซต์เดียวกันที่ทำงานเช่น “การบีบอัด, การแปลงเป็น WebP หรือ AVIF, การแก้ไข URL และการเขียนใหม่ของการส่งมอบ” ทั้งหมดพร้อมกันเป็นวิธีที่แน่นอนที่สุดในการสร้างความยุ่งเหยิงและยากที่สุดในการแก้ไขปัญหา

2. WordPress ไม่รองรับ WebP/AVIF อยู่แล้วหรือ? ฉันยังต้องการปลั๊กอินอยู่หรือไม่?

สิ่งสำคัญคือต้องแยกแยะระหว่าง:
“การสนับสนุนการอัปโหลด/การใช้งาน” ≠ “การแปลง/การส่งโดยอัตโนมัติ”
WordPress 6.5 จะไม่ทำการแปลงไฟล์ JPG/PNG ที่มีอยู่เป็น WebP/AVIF โดยอัตโนมัติในปริมาณมาก และจะไม่จัดการกระบวนการทั้งหมดของ “การให้บริการ AVIF/WebP ตามความสามารถของเบราว์เซอร์และกลับไปใช้รูปแบบเดิม” โดยอัตโนมัติเช่นกัน เพื่อให้แน่ใจว่าคลังสื่อที่มีอยู่ของคุณได้รับการอัปเดตด้วย คุณจะต้องใช้ปลั๊กอินหรือบริการเพื่อเติมเต็มช่องว่างนี้

3. เมื่อพูดถึงการปรับแต่งภาพให้เหมาะสม มีขั้นตอนใดที่ให้ผลตอบแทนจากการลงทุนสูงที่สุด?

โดยปกติ วัดขนาดให้ถูกต้องก่อน (srcset/sizes)。
เว็บไซต์หลายแห่งทำงานช้าไม่ใช่เพราะไม่ได้บีบอัด แต่เพราะแสดงหน้าเว็บที่มีความกว้างเพียง 900 พิกเซล ในขณะที่ให้ผู้ใช้ดาวน์โหลดภาพต้นฉบับขนาด 3000 พิกเซล การบีบอัดอาจช่วยประหยัดข้อมูลได้ไม่กี่กิโลไบต์ แต่ “ขนาดที่ไม่ถูกต้อง” จะทำให้คุณดาวน์โหลดข้อมูลมากกว่าเดิมหลายเท่าโดยไม่มีเหตุผล

4. ฉันจะมั่นใจได้อย่างไรว่า “เวอร์ชันที่เล็กลง” ถูกโหลดแทนที่จะเป็นภาพต้นฉบับทุกครั้ง?

มาดูสองปรากฏการณ์กัน:

• เมื่อดูบนอุปกรณ์มือถือ รูปภาพที่ดาวน์โหลดจะมีขนาดเล็กกว่าบนเดสก์ท็อปอย่างเห็นได้ชัด
• ขนาดไฟล์ของภาพเดียวกันอาจแตกต่างกันขึ้นอยู่กับอุปกรณ์ที่โหลด
  หากภาพต้นฉบับถูกดาวน์โหลดอยู่เสมอ สาเหตุที่พบบ่อยคือธีมหรือผู้สร้างเว็บไซต์อาจมองภาพนั้นเป็นภาพพื้นหลัง CSS หรือผลลัพธ์ที่กำหนดเอง ซึ่งทำให้ระบบข้ามการรองรับขนาดหลายขนาดของไลบรารีมีเดียและแอตทริบิวต์ `srcset` ไป

5. “WebP/AVIF ที่สร้างขึ้น” จำเป็นต้องหมายความว่า WebP/AVIF กำลังถูกให้บริการบนส่วนหน้าหรือไม่?

ไม่เท่ากับ
การสร้างไฟล์จะเสร็จสมบูรณ์เฉพาะในระดับ “ไฟล์” เท่านั้น; การที่ WebP/AVIF จะถูกส่งไปยังฝั่งหน้าเว็บจริงหรือไม่นั้น ขึ้นอยู่กับปัจจัยต่าง ๆ เช่น การเขียนทับ URL, นโยบายแท็ก `picture`, การถูกแคช, และประสิทธิภาพของการเจรจาระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ เมื่อดำเนินการเสร็จสิ้นแล้ว อย่าลืม “ตรวจสอบประเภทของทรัพยากรในภาพบางภาพ” ด้วย

6. ความเสี่ยงของ WebP หรือ AVIF คืออะไรกันแน่? ฉันสามารถทำการสแกนทั้งฐานข้อมูลด้วยคลิกเดียวได้หรือไม่?

ความเสี่ยงไม่ได้อยู่ที่ “การบีบอัด” แต่ที่การเปลี่ยนแปลงระดับการโยกย้ายสินทรัพย์：

• เมื่อสร้างชุดข้อมูลทั้งหมด อาจมีการเขียนทับรหัสไฟล์ภาพต้นฉบับ ไฟล์ต้นฉบับอาจถูกลบ และ URL ภายในเนื้อหาอาจถูกแทนที่
  ดังนั้นเราไม่แนะนำให้ทำการแทนที่ฐานข้อมูลทั้งหมดทันที: เริ่มต้นด้วยการทดสอบขนาดเล็ก (ไม่กี่สิบถึงไม่กี่ร้อยรายการ) และตรวจสอบให้แน่ใจว่าคุณมีข้อมูลสำรองที่ใช้งานได้ก่อนที่จะดำเนินการกับฐานข้อมูลทั้งหมด

7. ฉันจะเลือกโหมดใดใน Plus WebP ระหว่างการเก็บภาพต้นฉบับไว้หรือแทนที่และลบภาพต้นฉบับ?

ในคำง่ายๆ:

• โหมด 1: เก็บภาพต้นฉบับไว้ + สร้างสำเนา WebP/AVIF (เชื่อถือได้มากกว่า): สามารถย้อนกลับได้ง่าย แต่จะใช้พื้นที่ดิสก์มากขึ้น (ภาพต้นฉบับ + รูปแบบใหม่ + ขนาดภาพย่อหลายขนาด)
• วิธี 2: แทนที่และลบภาพต้นฉบับ (รุนแรงกว่า): แผ่นดิสก์ไม่น่าจะบวมขึ้น แต่หากคุณแก้ไขทั้งสินทรัพย์และการอ้างอิง การแก้ไขปัญหาความเข้ากันได้จะมีค่าใช้จ่ายสูงขึ้น
  ยิ่งเว็บไซต์มีความซับซ้อนมาก (เช่น อีคอมเมิร์ซ, ปลั๊กอินหลายตัว, ขนาดหลายขนาด) ยิ่งแนะนำให้เริ่มต้นด้วยวิธีการที่มั่นคงมากขึ้น

8. การบีบอัดไฟล์แบบท้องถิ่นที่ให้บริการฟรีโดย EWWW Image Optimizer เพียงพอหรือไม่? อาจทำให้เซิร์ฟเวอร์ทำงานหนักเกินไปหรือไม่?

EWWW เป็นเหมือน “เครื่องมือบีบอัดข้อมูลในเครื่อง” มากกว่า: มันอาจใช้ทรัพยากร CPU และ I/O ค่อนข้างมาก
โดยทั่วไปแล้ว ภาระงานมักจะเพิ่มขึ้นในระหว่างการปรับแต่งประสิทธิภาพแบบเป็นชุด (batch optimisation) ซึ่งไม่ได้หมายความว่าระบบกำลัง “ล้มเหลว” แต่เป็นเพียงสัญญาณว่าจำเป็นต้องใช้วิธีการที่เหมาะสม: ควรดำเนินการเป็นชุดในช่วงเวลาที่ไม่ใช่ชั่วโมงเร่งด่วน และเลือกใช้การถ่ายโอนงานไปยังระบบอื่นหรือโซลูชันบนคลาวด์เมื่อจำเป็น
หากคุณกำลังมองหาวิธีแก้ปัญหาที่ไร้ความยุ่งยาก หรือหากทรัพยากรเซิร์ฟเวอร์ของคุณมีจำกัด ตัวเลือก B จะเป็นมิตรกับเซิร์ฟเวอร์มากกว่า

9. ShortPixel ให้เครดิตฟรี 100 เครดิตต่อเดือน แล้วทำไมฉันรู้สึกว่าใช้หมดแล้วหลังจากอัปโหลดรูปภาพเพียงไม่กี่รูป?

เพราะว่า “เครดิต” ไม่ได้หมายถึง 'จำนวนภาพ'... จะถูกขยายใหญ่ขึ้นโดยภาพขนาดย่อและเทคโนโลยีรุ่นใหม่:

• ภาพต้นฉบับ + เครดิตสำหรับแต่ละภาพขนาดย่อ
• หากไฟล์ WebP/AVIF ถูกสร้างขึ้น แต่ละเวอร์ชันที่เกี่ยวข้องจะมีค่าใช้จ่ายเพิ่มเติมในรูปแบบของเครดิต
  ดังนั้น สิ่งที่คุณอาจคิดว่าเป็น “ภาพเดียว” อาจใช้เครดิตเกือบ “สองหลัก” จริงๆ ShortPixel

10. ทำไมโควต้าฟรี 20MB/เดือนของ Imagify ถึงหมดเร็วมาก?

Imagify คล้ายกับ “แพ็กเกจข้อมูล” มากกว่า

• ตามข้อความของคุณขนาดไฟล์ต้นฉบับการหักโควตา
• ยิ่งมีภาพขนาดย่อมากเท่าใด การบริโภคทรัพยากรก็จะยิ่งมากขึ้นเท่านั้น
• การเปลี่ยนระดับการบีบอัดและการปรับให้เหมาะสมใหม่อีกครั้งจะใช้โควต้าอีกครั้ง
• ใช้คีย์ API เดียวสำหรับหลายเว็บไซต์ โดยมีการแชร์โควตา
  ดังนั้น ข้อเท็จจริงที่ว่า “20MB หมดเร็ว” มักเกิดจากภาพมีขนาดใหญ่เกินไป มีภาพขนาดย่อมากเกินไป หรือการลองผิดลองถูกซ้ำๆ

11. TinyPNG ให้บริการเครดิตฟรี 500 เครดิตต่อเดือน แล้วทำไมปลั๊กอินถึงบอกว่ามีเพียงประมาณ 100 รูปภาพต่อเดือน และทำไมถึงลดลงเหลือ 50 รูปภาพต่อเดือนเมื่อเปิดใช้งาน WebP/AVIF?

เนื่องจากเครดิตของ TinyPNG จะถูกขยายขนาดด้วยเช่นกันภายใต้ “ขนาด/รูปแบบ”:

• การติดตั้ง WordPress มาตรฐานโดยทั่วไปจะบีบอัดรูปภาพประมาณ 100 รูปต่อเดือน
• เปิดใช้งานการแปลงเป็น AVIF หรือ WebP:ขนาดภาพแต่ละขนาดจะมีค่าใช้จ่ายเพิ่มอีกหนึ่งเครดิตดังนั้นเราอาจสามารถบีบอัดและแปลงได้เพียงประมาณ 50 รูปภาพต่อเดือน (ขึ้นอยู่กับจำนวนขนาดของภาพย่อ)
  ดังนั้น 500 เครดิต ≠ 500 ภาพ

12. มีภาพขนาดย่อ (thumbnails) บนเว็บไซต์ของฉันกี่ภาพ? ทำไมภาพขนาดย่อจึงมีผลกระทบอย่างมาก?

การอัปโหลดรูปภาพไปยัง WordPress จะสร้างขนาดรูปภาพหลายขนาด; ธีมและปลั๊กอิน (โดยเฉพาะปลั๊กอินสำหรับอีคอมเมิร์ซ) อาจเพิ่มขนาดรูปภาพได้มากขึ้น
ด้วยการบีบอัดข้อมูลบนคลาวด์ เครดิต/โควตาจะถูกคำนวณโดยปกติจาก “ภาพต้นฉบับบวกกับภาพขนาดย่อที่รวมกัน” ดังนั้นยิ่งคุณมีภาพขนาดย่อมากเท่าไร ปริมาณการใช้งานฟรีของคุณก็จะหมดเร็วขึ้นเท่านั้น

13. การโหลดแบบเลื่อนช้า (Lazy Loading) ช่วยเพิ่มความเร็วเสมอหรือไม่? ทำไมบางคนถึงบอกว่า Lazy Loading กลับทำให้ช้าลง?

การโหลดแบบขี้เกียจเหมาะสำหรับ “ทรัพยากรที่อยู่นอกหน้าจอ”
หากภาพขนาดใหญ่ที่สำคัญที่สุดบนหน้าจอแรกถูกเลื่อนออกไปเช่นกัน อาจทำให้ประสบการณ์การโหลดครั้งแรกช้าลงได้ แม้ว่าการโหลดแบบเลื่อนช้า (lazy loading) ที่ตั้งค่าไว้เป็นค่าเริ่มต้นใน WordPress 5.5 ขึ้นไปจะใช้งานได้ดี แต่คุณไม่ควรนำไปใช้กับทุกหน้าของเว็บไซต์

14. ฉันควรใช้ CDN หรือ image CDN เมื่อใดหากฉันกำลังทำตามเส้นทาง A หรือ B?

การบีบอัด ขนาดไฟล์ และรูปแบบไฟล์ช่วยให้ไฟล์มีขนาดเล็กลงและเหมาะสมยิ่งขึ้น
CDN ช่วยให้การส่งมอบรวดเร็วและเชื่อถือได้มากขึ้น。
หากมีความล่าช้าอย่างมีนัยสำคัญเมื่อดึงภาพจากเซิร์ฟเวอร์ต้นทางในระยะทางไกล การเพิ่ม CDN หรือ CDN สำหรับภาพ (เช่น Cloudflare Polish หรือ Jetpack Site Accelerator) จะส่งผลให้ประสบการณ์การใช้งานมีความเสถียรมากขึ้นโดยทั่วไป อ่านเพิ่มเติม การเร่งความเร็ว CDN ของ WordPress。

15. เมื่อฉันทำเสร็จแล้ว วิธีที่ง่ายที่สุดในการตรวจสอบว่ามันทำงานได้จริงคืออะไร?

วิธีการตรวจสอบที่รวดเร็วที่สุด:

• เมื่อรีเฟรชหน้าเดิมเป็นครั้งที่สอง กระบวนการโหลดมีความเสถียรและรวดเร็วกว่าเดิมหรือไม่?
• มีความแตกต่างที่สังเกตได้หรือไม่ในขนาดของภาพที่โหลดบนอุปกรณ์มือถือและเดสก์ท็อป (คุณลักษณะ `srcset` และ `sizes` ทำงานตามที่ตั้งใจไว้หรือไม่)?
• สุ่มตรวจสอบรูปภาพบางภาพ: มีไฟล์หรือทรัพยากรประเภท WebP หรือ AVIF อยู่หรือไม่?
• ลองดูภาพตัวอย่างสักสองสามภาพ: ขยายดูให้ใกล้เพื่อสังเกตว่าภาพเบลออย่างเห็นได้ชัดหรือไม่ หรือตัวอักษรดูพร่ามัวหรือเปล่า