การปรับแต่งภาพเว็บไซต์

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

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

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

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

1. แกนหลัก: สิ่งที่ WordPress รวมไว้โดยค่าเริ่มต้น และสิ่งที่ไม่ได้รวมไว้

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

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

WordPress core ได้รวมเอาความสามารถที่จำเป็นเหล่านี้ไว้แล้ว:

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

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

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

ควรทำอย่างไร ทำไปเพื่ออะไร อะไรถือว่าเป็นการปฏิบัติงานที่น่าพอใจ และข้อผิดพลาดที่พบบ่อยคืออะไร

2.1 วัดขนาดให้ถูกต้องก่อน (สิ่งที่มองข้ามได้ง่ายที่สุด แต่ให้ผลลัพธ์ที่คุ้มค่าที่สุด)

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

WordPress 4.4 ขึ้นไปกลไกการแสดงภาพที่ตอบสนอง（srcset/sizes) เพื่อแก้ไขปัญหานี้โดยเฉพาะ

อะไรคือเกณฑ์การผ่าน:

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

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

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

---

2.2 การบีบอัด (ลดขนาด KB แต่ไม่ลดคุณภาพ)

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

กฎมีดังนี้:

• ภาพถ่าย/ภาพจริง (ภาพบุคคล, ผลิตภัณฑ์, ทิวทัศน์)ให้ความสำคัญกับการบีบอัดแบบสูญเสียข้อมูล (เพิ่มประสิทธิภาพสูงสุด)
• ภาพหน้าจอ/รูปภาพที่มีข้อความจำนวนมากการบีบอัดควรทำอย่างระมัดระวังเพื่อป้องกันไม่ให้ข้อความปรากฏเป็นภาพเบลอ
• โลโก้/ไอคอนให้ความสำคัญกับ 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/ภาพ CDN)

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

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

การปรับแต่งภาพมีหน้าที่ในการลดขนาดและรับประกันความเหมาะสมCDN: ส่งมอบที่ใกล้ชิดและเชื่อถือได้มากขึ้น

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

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

กฎ:

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

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

---

3.1 เส้นทาง A: ฟรีเต็มรูปแบบในท้องถิ่น (พร้อม WebP หรือ AVIF หรือ EWWW)

ลักษณะเด่นของเส้นทางนี้คือ:

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

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

---

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

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

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

---

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

เรื่องฟรี/เสียเงินนี่เป็นยังไง?

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

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

หมายเหตุ:

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

ฐานความรู้อย่างเป็นทางการของ ShortPixel ยังกล่าวถึงความแตกต่างระหว่าง “แพ็กเกจแบบครั้งเดียวกับแผนรายเดือนแบบไม่จำกัด”คำอธิบายที่ชัดเจน: แผนรายเดือนไม่จำกัดจะเรียกเก็บเงินรายเดือน (หรือรายปี) โดยให้เครดิตไม่จำกัดและโควต้าคงที่ 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 สร้าง/แทร็กแท็กเจเนอเรชันถัดไป ตรรกะจะซ้อนทับกัน ทำให้การแก้ไขปัญหาทำได้ยากขึ้น ทางเลือก B คือให้ ShortPixel จัดการอย่างอิสระ
3. สมมติว่าการติดตั้งเพียงอย่างเดียวรับประกันว่า “ส่วนหน้าเว็บกำลังให้บริการ WebP/AVIF”
   หน้าปลั๊กอิน ShortPixelสามารถแปลงรูปแบบ WebP/AVIF และผสานภาพยุคใหม่เข้ากับหน้าเว็บส่วนหน้าได้ (เช่น ผ่านการแท็ก)
   อย่างไรก็ตาม เมื่อเสร็จสิ้นแล้ว ผลลัพธ์ยังคงต้องได้รับการตรวจสอบ

---

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

ค่าเผื่อและการจัดตำแหน่งฟรี

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

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

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

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

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

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

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

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

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

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

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

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

---

3.2.3 TinyPNG(Tiny Compress Images): ฟรี 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. หลังจากเปิดใช้งานการแปลงแล้ว ฉันพบว่าวงเงินเครดิตไม่เพียงพออย่างกะทันหัน
   นี่ไม่ใช่ข้อบกพร่อง; แต่มันคือกลไกการเรียกเก็บเงินของมัน
   ข้อเสนอแนะเชิงกลยุทธ์:

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

4. คำแนะนำตามบริบท: วิธีการเลือกสำหรับประเภทไซต์ที่แตกต่างกัน

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

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

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

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

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

• สำหรับตัวเลือกที่ไม่ต้องยุ่งยาก: เลือกหนึ่งในสามทางเลือก (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 (ให้ประโยชน์อย่างมากในกรณีของภาพขนาดใหญ่ อย่างไรก็ตาม คุณภาพทางสายตาต้องได้รับการตรวจสอบ)

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

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

5. การเปรียบเทียบค่าธรรมเนียม/การเรียกเก็บเงิน: อธิบายว่าค่าธรรมเนียมฟรีเพียงพอหรือไม่

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

5.1 รูปแบบการหักค่าธรรมเนียมสามประเภท

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

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

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

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

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

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

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

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

นี่คือแหล่งที่มาของภัยพิบัติที่พบได้บ่อยที่สุด“

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

ความเสี่ยง 2: ฟังก์ชัน “แทนที่ ID / ลบภาพต้นฉบับ / แทนที่ URL” ของ Plus WebP ถือเป็นการย้ายข้อมูลสินทรัพย์

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

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

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

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

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

ความเสี่ยง 4: “ไฟล์ WebP/AVIF ที่สร้างขึ้น” ไม่เท่ากับ “ไฟล์ WebP/AVIF ที่ส่งมอบโดย Frontend”

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

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

จุดตรวจสอบที่ตรงไปตรงมาอย่างยิ่งสี่ประการ:

1. เมื่อรีเฟรชหน้าเดิมเป็นครั้งที่สอง กระบวนการโหลดมีความเสถียรและรวดเร็วกว่าเดิมหรือไม่?(การรับรู้ถึงประสิทธิผลของการแคชและการเพิ่มประสิทธิภาพ)
2. มีความแตกต่างที่สังเกตได้หรือไม่ในขนาดของภาพระหว่างการโหลดบนมือถือและเดสก์ท็อป?(ตอบสนอง) srcset/sizes ไม่ว่าจะเป็นเรื่องที่มีประสิทธิภาพหรือไม่
3. ตรวจสอบภาพหลายภาพแบบสุ่ม: มีไฟล์/ทรัพยากร WebP หรือ AVIF อยู่หรือไม่?เว็บไซต์นี้ใช้งานจริงหรือไม่? รุ่นต่อไป）
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 จริงหรือไม่นั้นขึ้นอยู่กับปัจจัยต่างๆ เช่น การเขียนทับใหม่, กลยุทธ์แท็กภาพ, การเข้าถึงแคช, และการเจรจาของเบราว์เซอร์ เมื่อคุณเสร็จสิ้นแล้ว คุณต้อง “ตรวจสอบประเภทของทรัพยากรของภาพหลายๆ ภาพ”

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

จุดเสี่ยงของมันไม่ใช่ “การบีบอัด” แต่เป็นการปรับเปลี่ยนระดับการย้ายสินทรัพย์：

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

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

ในคำง่ายๆ:

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

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

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

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

เนื่องจาก เครดิตไม่ใช่ “จำนวนภาพ”จะถูกย่อเป็นภาพขนาดย่อและขยายแบบใหม่:

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

10. ทำไมบริการฟรีของ Imagify ที่ให้ 201 TP234T ต่อเดือนถึงหมดเร็วมาก?

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

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

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

เนื่องจากเครดิตของ TinyPNG ยังถูกขยายเพิ่มเติมโดย “ขนาด/รูปแบบ”:

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

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

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

13. การโหลดแบบเลื่อนช้าทำให้ทุกอย่างเร็วขึ้นเสมอหรือไม่? ทำไมบางคนถึงอ้างว่ามันทำให้ช้าลงจริงๆ?

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

14. เมื่อใดที่ฉันต้องการ CDN / ภาพ CDN หากฉันเลือกเส้นทาง A หรือ B?

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

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

วิธีการตรวจสอบที่ประหยัดเวลาที่สุด:

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