ປັບແຕ່ງຮູບພາບເວັບໄຊທ໌

ການປັບແຕ່ງຮູບພາບໃຫ້ດີແມ່ນຫນຶ່ງໃນການປັບປຸງປະສິດທິພາບ WordPress ທີ່ “ໄດ້ຜົນຄຸ້ມຄ່າສູງ” ທີ່ສຸດ: ໂຄງສ້າງໜ້າເວັບເດີມ, ທີມເດີມ, ພຽງແຕ່ເຮັດໃຫ້ຂະໜາດໄຟລ໌, ມິຕິ, ຮູບແບບ ແລະ ວິທີສົ່ງຮູບພາບຖືກຕ້ອງ ປະສົບການການໂຫຼດມັກຈະດີຂຶ້ນທັນທີ.

ແຕ່ການປັບແຕ່ງຮູບພາບກໍເປັນສິ່ງທີ່ເຮັດໃຫ້ຄົນ “ຍິ່ງຈັດຍິ່ງຍຸ່ງ” ໄດ້ງ່າຍທີ່ສຸດ, ສາເຫດບໍ່ແມ່ນເພາະເທັກໂນໂລຢີຍາກເກີນໄປ, ແຕ່ເປັນເພາະຂໍ້ມູນກະຈັດກະຈາຍເກີນໄປ:
ເຈົ້າໄດ້ອ່ານບົດຄວາມໄປຫຼາຍບົດ ຈົນຮູ້ວ່າຕ້ອງ “ບີບອັດ” “WebP/AVIF” “ໂຫຼດແບບຊ້າ” ແລ້ວພໍໄປເບິ່ງແນະນຳປລັກອິນ ກໍບອກອີກວ່າ “ຟຣີ 100 credits ຕໍ່ເດືອນ” “ຟຣີ 20MB” “ຮູບລະ 1 credit” ຜົນຄືຍິ່ງອ່ານຍິ່ງສັບສົນ——ຕົກລົງແລ້ວ ຟຣີພໍບໍ? ຄິດຄ່າໃຊ້ຈ່າຍແນວໃດ? ຫຼືວ່າເຈົ້າເຂົ້າໃຈ “ສິ່ງດຽວກັນ” ຜິດ? ແລະທີ່ສຳຄັນທີ່ສຸດ:ຫຼັງຈາກເຈົ້າເຮັດສຳເລັດແລ້ວ ສຸດທ້າຍມັນໄດ້ຜົນແທ້ບໍ?

ບົດຄວາມນີ້ເຮັດພຽງສາມຢ່າງ:

1. ໃຫ້ທ່ານຫນຶ່ງຂໍ້ທີ່ສາມາດດຳເນີນການໄດ້ແຜນຜັງ(ເຮັດຫຍັງກ່ອນ, ເຮັດຫຍັງຫຼັງ)
2. ອະທິບາຍໃຫ້ຊັດເຈນກ່ຽວກັບແຜນທີ່ຈະເລືອກ (ຟຣີ/ເສຍເງິນແຕກຕ່າງກັນແນວໃດ ແລະ ເໝາະກັບໃຜແຕ່ລະແຜນ)
3. ຂຽນບັນຫາທີ່ພົບບ່ອຍໄວ້ລ່ວງໜ້າ (ເພື່ອບໍ່ໃຫ້ທ່ານເຮັດສຳເລັດແລ້ວຍັງຕ້ອງໄປຄົ້ນຫາແກ້ໄຂອີກ)

1. ຊັ້ນພື້ນຖານ: WordPress ມີອັນໃດຕິດມາໃນຕົວ, ບໍ່ມີອັນໃດຕິດມາໃນຕົວ

ຖ້າທ່ານບໍ່ເຂົ້າໃຈກ່ອນວ່າແກນຫຼັກຂອງ WordPress ໄດ້ເຮັດຫຍັງໄປແລ້ວ ກໍຈະເກີດຂຶ້ນໄດ້ງ່າຍ 2 ກໍລະນີ:

• ຄວາມສາມາດ “ຟຣີ” ທີ່ຄວນໄດ້ຮັບບໍ່ໄດ້ໃຊ້, ແທ
• ຄິດວ່າ WordPress ຈະປ່ຽນຮູບເກົ່າເປັນ WebP/AVIF ອັດຕະໂນມັດ ແຕ່ສຸດທ້າຍພົບວ່າບໍ່ໄດ້

WordPress ໄດ້ຝັງຄວາມສາມາດສຳຄັນເຫຼົ່ານີ້ໄວ້ໃນແກນລະບົບແລ້ວ:

• ຮູບພາບແບບຕອບສະໜອງ (srcset/sizes)ຕັ້ງແຕ່ WordPress 4.4 ເປັນຕົ້ນໄປ, ເຄື່ອງມືຫຼັກຈະສົ່ງອອກຮູບພາບ srcset ກັບ sizesແລະໃຊ້ຮູບຫຼາຍຂະໜາດທີ່ສ້າງຂຶ້ນໃນເວລາອັບໂຫຼດ ເພື່ອໃຫ້ບຣາວເຊີເລືອກໂຫຼດຊັບພະຍາກອນທີ່ເໝາະກວ່າຕາມເງື່ອນໄຂຂອງໜ້າຈໍ.
• ໂຫຼດແບບຕົ້ນສະບັບອັດຕະໂນມັດWordPress 5.5 ຂຶ້ນໄປເປີດໃຊ້ການໂຫຼດແບບ lazy ດັ້ງເດີມສຳລັບຮູບພາບໂດຍຄ່າເລີ່ມຕົ້ນ, ໃຊ້ມາດຕະຖານ HTML loading ການນຳໃຊ້ຄຸນສົມບັດ។
• ຮອງຮັບການອັບໂຫຼດ WebPWordPress 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 ກ່ອນອື່ນ ໃຫ້ເຮັດ “ຂະໜາດ” ໃຫ້ຖືກຕ້ອງ (ສິ່ງທີ່ຖືກມອງຂ້າມງ່າຍທີ່ສຸດ ແຕ່ໄດ້ຜົນປະໂຫຍດຫຼາຍທີ່ສຸດ)

ຫຼາຍເວັບຊ້າ ບໍ່ແມ່ນເພາະບໍ່ໄດ້ບີບອັດ ແຕ່ເປັນເພາະດາວໂຫຼດຮູບໃຫຍ່ເກີນພື້ນທີ່ສະແດງผล：
ຕົວຢ່າງເຊັ່ນ ໜ້າເວັບຈິງໆສະແດງກວ້າງພຽງ 900px ແຕ່ທ່ານກັບໃຫ້ຜູ້ເຂົ້າຊົມດາວໂຫຼດຮູບຕົ້ນສະບັບ 3000px, ບຣາວເຊີພຽງແຕ່ “ດາວໂຫຼດໃຫ້ສຳເລັດແລ້ວຄ່ອຍຫຍໍ້ເພື່ອສະແດງ”. ສິ່ງນີ້ຈະເສຍແບນວິດ, ເພີ່ມເວລາຖອດລະຫັດ, ແລະເຮັດໃຫ້ໜ້າຈໍທຳອິດຊ້າລົງ.

ຂອງ 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ໂຫຼດແບບຂີ້ຄ້ານເລີ່ມຕົ້ນຮູບພາບ។
ມັນສາມາດຫຼຸດການໃຊ້ແບນວິດໃນເວລາເຣັນເດີເບື້ອງຕົ້ນ:

• Lazy load ເໝາະສຳລັບ “ຊັບພະຍາກອນນອກໜ້າຈໍ”
• ຮູບໃຫຍ່ທີ່ສຳຄັນທີ່ສຸດໃນໜ້າຈໍທຳອິດມັກບໍ່ເໝາະສຳລັບການໂຫຼດແບບລ່າຊ້າ

---

2.5 ຊັ້ນສົ່ງມອບ: CDN / ຮູບພາບ CDN

ການບີບອັດ, ຂະໜາດ, ແລະ ຮູບແບບ ແກ້ໄຂບັນຫາ “ໃຫ້ໄຟລ໌ນ້ອຍລົງ ແລະ ເໝາະສົມກວ່າ”.
ແຕ່ຖ້າຮູບພາບຖືກດຶງມາຈາກແຫຼ່ງຕົ້ນທາງໄກຢູ່ສະເໝີ ຄວາມລ່າຊ້າຂອງເຄືອຂ່າຍຍັງຈະສົ່ງຜົນຕໍ່ປະສົບການຢ່າງຊັດເຈນ ໃນເວລານີ້ຈຶ່ງຕ້ອງໃຊ້ໂຊລູຊັນ “ຊັ້ນການສົ່ງມອບ” (CDN/ຮູບພາບ CDN)

ສອງທິດທາງທົ່ວໄປ:

• ປັບແຕ່ງ Cloudflare：ເອກະສານ Cloudflareແນະນຳວິທີບີບອັດຂອງ Polish (ແບບບໍ່ເສຍຄຸນນະພາບ/ແບບເສຍຄຸນນະພາບ/WebP) ແລະກ່າວເຖິງການໃຊ້ format=auto ອະນຸຍາດໃຫ້ໃຊ້ຮູບແບບ WebP/AVIF ໄດ້
• ຕົວເລັ່ງເວັບໄຊ Jetpack：ເອກະສານ Jetpackອະທິບາຍວ່າມັນຈະປັບປຸງຮູບພາບໃຫ້ເໝາະສົມ ແລະແຈກຈ່າຍມັນຜ່ານເຄືອຂ່າຍຂອງມັນພ້ອມກັບຊັບພະຍາກອນຄົງທີ່

ຮັບຜິດຊອບປັບຮູບພາບໃຫ້ນ້ອຍແລະເໝາະສົມCDN ຮັບຜິດຊອບການຈັດສົ່ງທີ່ໃກ້ກວ່າ ແລະ

3. ການເລືອກແນວທາງ: ມີພຽງສອງເສັ້ນທາງຫຼັກເທົ່ານັ້ນ

ຄວາມລົ້ມເຫຼວທີ່ພົບເຫັນບ່ອຍທີ່ສຸດໃນການປັບແຕ່ງຮູບພາບ ບໍ່ແມ່ນ “ບໍ່ໄດ້ຕິດຕັ້ງປລັກອິນ” ແຕ່ແມ່ນຕິດຕັ້ງປລັກອິນຫຼາຍເກີນໄປຈົນເຮັດໃຫ້ປະມວນຜົນຊ້ຳຊ້ອນ:
A ກຳລັງບີບອັດ, B ກໍກຳລັງບີບອັດ; A ກຳລັງແປງເປັນ WebP/AVIF, B ກໍກຳລັງແປງ; A ກຳລັງປ່ຽນ URL, B ຍັງຂຽນໃໝ່ອີກ—ສຸດທ້າຍແມ່ນແຕ່ຕົວທ່ານເອງກໍຍັງອະທິບາຍບໍ່ໄດ້ວ່າໃນເວັບຕອນນີ້ກຳລັງເກີດຫຍັງຢູ່

ກົດລະບຽບ៖

ໃຊ້ພຽງເສັ້ນທາງດຽວ: ບໍ່ກໍໃຊ້ແບບທ້ອງຖິ່ນຟຣີທັງໝົດ, ບໍ່ກໍເລືອກ 1 ໃນ 3 ຂອງການບີບອັດເທິງຄລາວ.

• ເສັ້ນທາງ A (ທ້ອງຖິ່ນຟຣີທັງໝົດ):Plus WebP ຫຼື AVIF + EWWW Image Optimizer(ຫຼືເລືອກພຽງອັນດຽວ)
• ເສັ້ນທາງ B (ບີບອັດຄລາວ ເລືອກໜຶ່ງໃນສາມ)ShortPixel / Imagify / TinyPNG

---

3.1 ເສັ້ນທາງ A: ທ້ອງຖິ່ນຟຣີທັງໝົດ (Plus WebP or AVIF ຫຼື EWWW)

ຈຸດເດັ່ນຂອງເສັ້ນທາງນີ້ແມ່ນ:

• ທ່ານບໍ່ຕ້ອງພຶ່ງພາບໍລິການບີບອັດຈາກບຸກຄົນທີສາມແບບ “ໂຄຕ້າລາຍເດືອນ/ຄິດຄ່າຕໍ່ຮູບ” (ແນ່ນອນວ່າບາງຟັງຊັນອາດມີບໍລິການເສີມໃຫ້ເລືອກ)
• ຄ່າແລກປ່ຽນແມ່ນ: ການປະມວນຜົນແບບຊຸດອາດໃຊ້ເຊີບເວີ CPU/IO ຫຼາຍຂຶ້ນ, ຕ້ອງໃຫ້ຄວາມສຳຄັນກັບ “ຍຸດທະສາດ ແລະ ຄວາມສ່ຽງ” ຫຼາຍຂຶ້ນ”

3.1.1 Plus WebP ຫຼື AVIFຫົວໃຈຄື “ສ້າງ/ແທນທີ່” ມັນບໍ່ແມ່ນ “ເຄື່ອງມືບີບອັດ” ແບບດັ້ງເດີມ”

• ເມື່ອສ້າງຮູບພາບທັງໝົດ:ID ໄຟລ໌ຮູບຕົ້ນສະບັບຈະຖືກຂຽນທັບໂດຍ WebP/AVIF, ໄຟລ໌ຕົ້ນສະບັບຈະຖືກລຶບ ແລະ URL ໃນເນື້ອຫາກໍຈະຖືກແທນທີ່。
• ປລັກອິນນີ້ມີຄຳສັ່ງ WP-CLI ແລະແຈ້ງເຕືອນວ່າ: ເມື່ອມີໄຟລ໌ຫຼາຍ ການໃຊ້ WP-CLI ນ່າເຊື່ອຖືກວ່າ.

ນີ້ໝາຍຄວາມວ່າ: ມັນບໍ່ແມ່ນ “ສ້າງ WebP ໃຫ້ທ່ານແບບເງົາໆ” ແຕ່ອາດຈະເປັນການໂອນຊັບສິນ(ໂດຍສະເພາະເມື່ອທ່ານເປີດຕົວເລືອກ “ແທນທີ່ ແລະ ລຶບຮູບຕົ້ນສະບັບ”).

ຄວາມແຕກຕ່າງຂອງສອງໂໝດ

ໂໝດ 1: ເກັບຮູບຕົ້ນສະບັບໄວ້ + ສ້າງສຳເນົາ WebP/AVIF (ເສຖີຍກວ່າ)

• ຂໍ້ດີ: ເມື່ອພົບບັນຫາຄວາມເຂົ້າກັນໄດ້ ຈະຖອຍກັບໄດ້ງ່າຍກວ່າ
• ຂໍ້ເສຍ: ການໃຊ້ພື້ນທີ່ດິສກ໌ຈະເພີ່ມຂຶ້ນ (ຮູບຕົ້ນສະບັບ + ຮູບແບບໃໝ່ + ຮູບຫຍໍ້ຫຼາຍຂະໜາດ)

ໂໝດ 2: ແທນທີ່ ແລະ ລຶບຮູບຕົ້ນສະບັບ (ເຂັ້ມຂຶ້ນ)

• ຂໍ້ດີ: ດິສກ໌ຈະບໍ່ຂະຫຍາຍໄວປານນັ້ນ; ການອ້າງອີງພາຍໃນເວັບຈະກາຍເປັນຮູບແບບໃໝ່ໂດຍກົງ
• ຄວາມສ່ຽງ: ທ່ານກຳລັງ “ປ່ຽນຊັບສິນ + ປ່ຽນການອ້າງອີງ”, ຄ່າໃຊ້ຈ່າຍໃນການກວດຫາບັນຫາຄວາມເຂົ້າກັນໄດ້ຈະສູງຂຶ້ນ (ໂດຍສະເພາະເມື່ອບາງລະບົບພາຍນອກ ຫຼື ຕາມຕະກະຂອງທີມ ພຶ່ງພາຊື່ໄຟລ໌/ເສັ້ນທາງ/ຮູບແບບເດີມ)

ຂໍ້ຄວນລະວັງທົ່ວໄປຂອງ Plus WebP ຫຼື AVIF

1. ຫຼັງຈາກປ່ຽນແທນໄລບຣາຣີທັງໝົດແລ້ວ ຮູບພາບໃນບາງໜ້າສະແດງຜິດປົກກະຕິ
   ເຫດຜົນປົກກະຕິບໍ່ແມ່ນວ່າ “ຮູບເສຍແລ້ວ” ແຕ່ເປັນເພາະມີບາງຂັ້ນຕອນໃນຂະບວນການເຊັ່ນ URL ທີ່ຖືກແທນທີ່, ແຄຊ, ນະໂຍບາຍຮູບຫຍໍ້ ແລະອື່ນໆ ທີ່ບໍ່ກົງກັນ.
2. ຍິ່ງມີຮູບຫຍໍ້ຫຼາຍ ຂອບເຂດການປ່ຽນແປງຍິ່ງກວ້າງ
   WordPress ອັບໂຫຼດຮູບ 1 ຮູບຈະສ້າງຫຼາຍຂະໜາດ; ທີມ/ປລັກອິນອາດເພີ່ມຂະໜາດອື່ນອີກ. ການແທນທີ່ທັງໝົດໝາຍເຖິງທ່ານອາດກຳລັງແກ້ໄຂຊຸດໄຟລ໌ຂະໜາດໃຫຍ່ຫຼາຍ.
3. ຍ້າຍຮູບແບບເທົ່ານັ້ນ ບໍ່ໄດ້ໝາຍຄວາມວ່າຂະໜາດຈະນ້ອຍສຸດເສມໄປ
   WebP/AVIF ມັກຈະນ້ອຍກວ່າ, ແຕ່ “ນະໂຍບາຍຂະໜາດ” ແລະ “ນະໂຍບາຍການບີບອັດ” ຍັງສຳຄັນຫຼາຍ. ຢ່າຄິດວ່າ Plus WebP ແມ່ນ “ຄລິກດຽວແລ້ວໄວຂຶ້ນ”.

---

3.1.2 EWWW ປັບແຕ່ງຮູບພາບໃຫ້ດີຂຶ້ນ: ຕົວແທນຂອງການບີບອັດໃນທ້ອງຖິ່ນຟຣີ

ໜ້າປລັກອິນ EWWW ມີການວາງຕຳແໜ່ງທີ່ຊັດເຈນຫຼາຍ៖

• ມັນສາມາດຖືກປັບແຕ່ງໃຫ້ເໝາະສົມໄດ້ດ້ວຍການໃຊ້ຊຸດເຄື່ອງມືຕ່າງໆເທິງເຊີບເວີຂອງທ່ານ (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp ແລະອື່ນໆ)
• ຖ້າທ່ານຕ້ອງການການບີບອັດທີ່ສູງກວ່າ ຫຼື ປະຢັດ CPU ຫຼາຍຂຶ້ນ, ທ່ານກໍສາມາດຍ້າຍການປະມວນຜົນທີ່ໃຊ້ CPU ໄປໄວ້ໃນເຊີບເວີຂອງມັນໄດ້ (ທາງເລືອກ).

EWWW ຄວນຮັບບົດບາດຫຍັງໃນເສັ້ນທາງ A?

ຖ້າທ່ານໃຊ້ Plus WebP ເພື່ອເຮັດ “ການຍ້າຍຮູບແບບ/ຍຸດທະສາດການແທນທີ່”, EWWW ຈະເໝາະສົມກວ່າສຳລັບຮັບໜ້າທີ່:

• ບີບອັດ ແລະ ປັບປຸງຂະໜາດ(ໂດຍສະເພາະການຫຼຸດຂະໜາດໄຟລ໌ຕົ້ນສະບັບເຊັ່ນ JPG/PNG)
• ປະຫວັດການປັບປຸງເປັນຊຸດຂອງຫ້ອງສື່(ເນັ້ນ “ຫຼຸດຂະໜາດ” ແທນ “ແທນ URL”)

ຂໍ້ຜິດພາດທົ່ວໄປຂອງ EWWW

1. ໃນຂະນະທີ່ປັບປຸງແບບເປັນຊຸດ ພາລະການໂຫຼດຂອງເຊີບເວີເພີ່ມຂຶ້ນ
   ເນື່ອງຈາກການບີບອັດໃນເຄື່ອງຈະໃຊ້ CPU/IO. ແນວທາງແກ້ໄຂບໍ່ແມ່ນ “ບໍ່ໃຊ້” ແຕ່ແມ່ນ “ເຮັດເປັນຊຸດ, ເຮັດຕອນຊ່ວງໂຫຼດຕ່ຳ, ແລະເລືອກ offload/ຄລາວ ເມື່ອຈຳເປັນ”
2. “ສ້າງ WebP ແລ້ວ” ບໍ່ໄດ້ໝາຍຄວາມວ່າຫນ້າເວັບຈະສະແດງ WebP ສະເໝີ
   ປລັກອິນຫຼາຍຕົວມັກເຂົ້າໃຈຜິດໃນເລື່ອງນີ້: ການສ້າງແມ່ນເລື່ອງໜຶ່ງ, ແຕ່ຍຸດທະສາດການສົ່ງມອບ (ການຂຽນທັບ, ແທັກ picture, ການຕົງກັບແຄດ ແລະອື່ນໆ) ແມ່ນອີກເລື່ອງໜຶ່ງ.
3. ເຮັດວຽກຊ້ຳກັບປລັກອິນອື່ນ
   ຖ້າທ່ານໃຊ້ແນວທາງ A, ພະຍາຍາມຢ່າເພີ່ມການບີບອັດຜ່ານຄລາວແບບ ShortPixel/Imagify/TinyPNG ອີກ; ຖ້າທ່ານໃຊ້ແນວທາງ B, ກໍຢ່າເປີດຕັກກະການແທນທີ່ Plus WebP ອີກ. ຫຼັກການສຳຄັນ:ເດີນຕາມເສັ້ນທາງດຽວຈົນສຸດ។

---

3.2 ທາງເລືອກ B: ເລືອກ 1 ໃນ 3 ສໍາລັບການບີບອັດຄລາວ (ShortPixel / Imagify / TinyPNG)

ເໝາະສຳລັບຜູ້ທີ່ຢາກປະຢັດຊັບພະຍາກອນເຊີບເວີ, ຈັດການງ່າຍເມື່ອເຮັດແບບເປັນຊຸດ, ແລະຍອມຮັບການຄິດຄ່າຕາມໂຄຕາ/ຕາມປະລິມານ
ແຕ່ຈຸດທີ່ເຮັດໃຫ້ເກີດຄວາມເຂົ້າໃຈຜິດໄດ້ງ່າຍທີ່ສຸດຂອງການບີບອັດຄລາວແມ່ນ:ໂຄຕ້າຟຣີບໍ່ໄດ້ໝາຍເຖິງພຽງແຕ່ “ຈຳນວນແຜ່ນຟຣີ” ເທົ່ານັ້ນຈຳນວນ ແລະ ຂະໜາດຮູບຫຍໍ້, ການສ້າງ WebP/AVIF, ແລະການບີບອັດຊ້ຳ ລ້ວນສົ່ງຜົນຕໍ່ການໃຊ້ຊັບພະຍາກອນຢ່າງຫຼາຍ

ຂ້າງລຸ່ມນີ້ຈະອະທິບາຍ: ຟຣີ/ເສຍຄ່າແມ່ນແນວໃດ, ໂຄຕາຖືກຫັກແນວໃດ, ຂໍ້ຜິດພາດທີ່ພົບງ່າຍທີ່ສຸດ, ແລະ ເໝາະກັບປະເພດເວັບໄຊໃດ

---

3.2.1 ShortPixelຟຣີ 100 ເຄຣດິດ/ເດືອນ, ແຕ່ເຄຣດິດຈະໃຊ້ຫຼາຍຂຶ້ນກັບຮູບຫຍໍ້ ແລະ WebP/AVIF

ຟຣີ/ເສຍເງິນ ແມ່ນຫຍັງ

ແນະນຳປລັກອິນ ShortPixel ໄດ້ຂຽນໄວ້ຢ່າງຊັດເຈນວ່າ៖

• ຮັບເຄຣດິດຟຣີ 100 ໜ່ວຍຕໍ່ເດືອນ
• ຍັງມີ “credits ລາຍເດືອນແບບບໍ່ຈຳກັດເພີ່ມເຕີມ” (ໜ້າປລັກອິນມີຂໍ້ມູນລາຄາທີ່ກ່ຽວຂ້ອງ)
• ຍັງມີແພັກ credits ແບບໃຊ້ຄັ້ງດຽວທີ່ບໍ່ໝົດອາຍຸ ພ້ອມລາຄາເລີ່ມຕົ້ນ

ແນະນຳ៖

• ຟຣີ: ໃຫ້ credits ຈຳນວນໜຶ່ງທຸກເດືອນ ສຳລັບເວັບໄຊທ໌ຂະໜາດນ້ອຍ ຫຼື ການທົດສອບ
• ແພັກແບບໃຊ້ຄັ້ງດຽວ: ເໝາະສຳລັບເວັບໄຊທ໌ທີ່ “ຄັງສື່ໃຫຍ່ຫຼາຍ ແລະຢາກເຄຍສະຕັອກໃຫ້ໝົດໃນຄັ້ງດຽວ” (ຊື້ຄັ້ງດຽວແລ້ວໃຊ້ຈົນໝົດ, ປົກກະຕິແລ້ວຈະບໍ່ໝົດອາຍຸ)
• ລາຍເດືອນ/ບໍ່ຈຳກັດ: ເໝາະສຳລັບເວັບໄຊທີ່ອັບເດດຮູບພາບຕໍ່ເນື່ອງ ແລະ ປັບປຸງລະຍະຍາວຢ່າງສະໝ່ຳສະເໝີ

KB ທາງການຂອງ ShortPixel ກໍໄດ້ໃຫ້ກ່ຽວກັບ “ແພັກເກດແບບຄັ້ງດຽວ ກັບ ບໍ່ຈຳກັດລາຍເດືອນ” ເຊັ່ນກັນອະທິບາຍຊັດເຈນ: ແພັກລາຍເດືອນແບບບໍ່ຈຳກັດແມ່ນຈ່າຍເງິນລາຍເດືອນ (ຫຼືລາຍປີ), ມີ credits ບໍ່ຈຳກັດ ແລະມີໂຄຕາ CDN ແບບຄົງທີ່; credits ແບບຊື້ຄັ້ງດຽວຈະບໍ່ໝົດອາຍຸ, ຊ່ວຍໃຫ້ທ່ານຄວບຄຸມການໃຊ້ງານຕາມຄວາມຕ້ອງການໄດ້ດີຂຶ້ນ.

ສິ່ງສຳຄັນທີ່ສຸດ: credits ຂອງ ShortPixel ຄິດໄລ່ແນວໃດ?

ເອກະສານທາງການຂອງ ShortPixel KB ເວົ້າໄວ້ຢ່າງກົງໄປກົງມາຫຼາຍ:

• WordPress ອັບໂຫຼດຮູບໜຶ່ງຮູບຈະສ້າງຮູບຫຍໍ້ຫຼາຍຮູບ;
• ທຸກການປັບປຸງຮູບຫຍໍ້ຈະນັບເປັນ 1 credit；
• ຖ້າທ່ານເລືອກສ້າງ WebP ຫຼື AVIFແຕ່ລະເວີຊັນ WebP/AVIF ຂອງຮູບຕົ້ນສະບັບແລະຮູບຫຍໍ້ຈະໃຊ້ 1 credit ເພີ່ມອີກ；
• ທ່ານສາມາດຍົກເວັ້ນຮູບຫຍໍ້ບາງຮູບບໍ່ໃຫ້ປັບແຕ່ງເພື່ອຫຼຸດການໃຊ້ credits.

ເຄຣດິດ ຕົວຢ່າງ：

ສົມມຸດວ່າທ່ານອັບໂຫຼດ 1 ຮູບ, ທີມ/ປລັກອິນໄດ້ສ້າງ 8 ຮູບຫຍໍ້:

• ພຽງແຕ່ປັບປຸງຮູບຕົ້ນສະບັບ + ຮູບຍ່ອຍ: 1 (ຮູບຕົ້ນສະບັບ) + 8 (ຮູບຍ່ອຍ) = 9 ຄຣີດິດ
• ຖ້າຍັງຕ້ອງການສ້າງ WebP/AVIF: 9 ອັນຂ້າງເທິງແຕ່ລະອັນເພີ່ມອີກ 1 ເວີຊັນ next-gen → ບວກອີກ 9 credits
  ນັ້ນກໍໝາຍຄວາມວ່າ, ສິ່ງທີ່ເຈົ້າຄິດວ່າແມ່ນ “1 ຮູບ”, ແທ້ຈິງແລ້ວອາດໃຊ້ credits ເກືອບເຖິງ “2 ຫຼັກ”.

ດັ່ງນັ້ນ:“100 ເຄຣດິດຟຣີ” ບໍ່ໄດ້ໝາຍຄວາມວ່າ “100 ຮູບຟຣີ”.

ຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍຂອງ ShortPixel

1. 100 credits ຟຣີໃຊ້ໝົດໄວ
   ສາເຫດຫຼັກ: ຮູບຫຍໍ້ຫຼາຍ + ສ້າງ WebP/AVIF ໃຊ້ credits ເພີ່ມเติม
   ແນະນຳ：

• ກວດຈຳນວນຮູບຫຍໍ້ເວັບໄຊກ່ອນ
• ຍົກເວັ້ນຂະໜາດຮູບຫຍໍ້ທີ່ບໍ່ຈຳເປັນ (ປັບໃຫ້ເໝາະສະເພາະຂະໜາດທີ່ໃຊ້ຈິງເທົ່ານັ້ນ)
• ກຳນົດກົດການບີບອັດກ່ອນ ແລ້ວຄ່ອຍປະມວນຜົນເປັນຊຸດ ເພື່ອຫຼີກລ້ຽງການລອງຜິດລອງຖືກຊ້ຳໆໃຫ້ເສຍຊັບພະຍາກອນ

2. ພ້ອມກັນຊ້ອນປລັກອິນແປງຮູບແບບອື່ນໆ
   ຖ້າທ່ານເປີດ Plus WebP ແທນທີ່ ແລະໃຫ້ ShortPixel ສ້າງ/ແຊກແທັກ next-gen ດ້ວຍ ຕາມຫຼັກການຈະຊ້ອນກັນ ເຮັດໃຫ້ການກວດຫາບັນຫາຍາກຂຶ້ນ. ແນວທາງ B ໃຫ້ ShortPixel ຮັບຜິດຊອບພຽງຢ່າງດຽວ.
3. ຄິດວ່າຕິດຕັ້ງແລ້ວ ໜ້າບ້ານຈະສົ່ງອອກ WebP/AVIF ແນ່ນອນ“
   ໜ້າປລັກອິນ ShortPixelຮອງຮັບການແປງ WebP/AVIF ແລະເພີ່ມຮູບແບບ next-gen ເຂົ້າໃນໜ້າເວັບດ້ານໜ້າ ເຊັ່ນ ຜ່ານແທັກ
   ແຕ່ເຮັດສຳເລັດແລ້ວຍັງຕ້ອງກວດສອບຜົນໄດ້ຮັບຢູ່.

---

3.2.2 Imagifyຟຣີ 20MB/ເດືອນ; ຫັກໂຄຕ້າຕາມ “ຂະໜາດຮູບຕົ້ນສະບັບ + ຈຳນວນຮູບຫຍໍ້”, ບີບອັດຊ້ຳຈະຖືກຫັກຊ້ຳ

ໂຄຕ້າຟຣີ ແລະ ການກຳນົດຕຳແໜ່ງ

ໜ້າລາຄາທາງການຂອງ Imagifyຂຽນໄວ້ຊັດເຈນຫຼາຍ:ບັນຊີຟຣີມີໂຄຕາ 20MB ຕໍ່ເດືອນ。
ໜ້າປລັກອິນຂອງມັນກໍລະບຸຊັດເຈນວ່າ ມັນສາມາດບີບອັດ ປັບຂະໜາດ ແລະປ່ຽນເປັນ WebP/AVIF ได้

ໂຄຕ້າຖືກຫັກແນວໃດ?

ເອກະສານທາງການຂອງ Imagify “ການໃຊ້ໂຄຕ້າຖືກຄຳນວນແນວໃດ?” ອະທິບາຍກົນໄກການຫັກຄ່າໃຊ້ຈ່າຍໄວ້ຢ່າງຊັດເຈນ៖

• ຈຳນວນຮູບຫຍໍ້ມີຜົນຕໍ່ການໃຊ້ງານຕົວຢ່າງເຊັ່ນ ຖ້າທ່ານມີຂະໜາດຮູບຫຍໍ້ 10 ຂະໜາດ, ການປັບແຕ່ງຮູບ 1 ຮູບຈະກາຍເປັນການປັບແຕ່ງ 11 ຮູບ (ຮູບຕົ້ນສະບັບ + ຮູບຫຍໍ້ 10 ຮູບ), ແລະທັງໝົດນີ້ຈະນັບເຂົ້າໃນການໃຊ້ໂຄຕາ.
• ຫັກໂຄຕາຕາມຂະໜາດໄຟລ໌ຕົ້ນສະບັບຕົວຢ່າງ: ຖ້າທ່ານສົ່ງຮູບພາບຂະໜາດ 100KB ໜຶ່ງຮູບໄປຫາ Imagify, ລະບົບຈະຫັກ 100KB ອອກຈາກໂຄວຕາຂອງທ່ານ.
• ປ່ຽນລະດັບການບີບອັດແລະປັບແຕ່ງໃໝ່ ຈະໃຊ້ໂຄຕ້າອີກຄັ້ງ。
• API Key ດຽວກັນສາມາດໃຊ້ກັບຫຼາຍເວັບໄຊໄດ້, ແຕ່ໂຄຕ້າຈະຖືກແບ່ງປັນລະຫວ່າງເວັບໄຊເຫຼົ່ານັ້ນ.

ນີ້ແມ່ນ “ແນວທາງການເຂົ້າໃຈຫຼັກ” ຂອງ Imagify:
ມັນຄ້າຍກັບແພັກເກັດດາຕ້າ: ເຈົ້າສົ່ງເທົ່າໃດ ກໍຫັກເທົ່ານັ້ນ; ຍິ່ງມີຮູບຫຍໍ້ຫຼາຍ ຍິ່ງຖືກຫັກຫຼາຍ; ຖ້າເຈົ້າບີບອັດຊ້ຳຫຼາຍຄັ້ງ ກໍຈະຖືກຫັກຊ້ຳອີກ.

ຕົວຢ່າງໂຄຕ້າ Imagify ທີ່ເຂົ້າໃຈງ່າຍ

ສົມມຸດວ່າທ່ານອັບໂຫຼດຮູບຕົ້ນສະບັບ 800KB ໜຶ່ງຮູບ, ເວັບໄຊສ້າງຮູບຫຍໍ້ 8 ຮູບ.

• ເມື່ອ Imagify ປັບແຕ່ງຮູບ ມັນຈະນຳ “ຮູບຕົ້ນສະບັບ + 8 ຮູບຫຍໍ້” ທັງໝົດເຂົ້າຮ່ວມດ້ວຍ (ຖ້າທ່ານເລືອກປັບແຕ່ງທັງໝົດ), ນັ້ນໝາຍຄວາມວ່າການດຳເນີນການຄັ້ງນີ້ຈະໃຊ້ໂຄຕ້າໃກ້ຄຽງກັບ “ຜົນລວມຂອງຂະໜາດຕົ້ນສະບັບຂອງໄຟລ໌ທັງໝົດເຫຼົ່ານີ້”.
  ນີ້ແມ່ນເຫດຜົນວ່າເປັນຫຍັງບາງເວັບໄຊຈຶ່ງຮູ້ສຶກວ່າ “20MB ໝົດໄວ”: ບໍ່ແມ່ນ Imagify ໃຫ້ໃຊ້ບໍ່ພໍ, ແຕ່ເປັນເພາະຮູບທີ່ທ່ານອັບໂຫຼດແຕ່ລະຄັ້ງມີຂະໜາດໃຫຍ່ເກີນໄປ, ມີຮູບຫຍໍ້ຫຼາຍເກີນໄປ, ແລະທ່ານອາດຈະທົດລອງລະດັບການບີບອັດຊ້ຳໆອີກດ້ວຍ។

ຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍຂອງ Imagify

1. ຟຣີ 20MB ບໍ່ພໍສຳລັບເຮັດ “ລ້າງປະຫວັດທັງເວັບ”
   20MB ໂດຍທົ່ວໄປແລ້ວເໝາະສຳລັບການທົດສອບ ແລະອັບເດດແບບເບົາໆ; ຖ້າຄັງສື່ຂອງທ່ານມີຂະໜາດໃຫຍ່ຢູ່ແລ້ວ, ການລ້າງຄັງທັງໝົດໃນຄັ້ງດຽວມີແນວໂນ້ມສູງທີ່ຈະຕ້ອງອັບເກຣດ.
2. ການປັບລະດັບການບີບອັດຊ້ຳໆເຮັດໃຫ້ໃຊ້ໂຄຕາຊ້ຳຊ້ອນ
   Imagify ລະບຸຢ່າງຊັດເຈນການປັບໃໝ່ອີກຄັ້ງຈະໃຊ້ໂຄຕ້າເພີ່ມອີກ
   ແນະນຳໃຫ້ທ່ານຂຽນ “ຍຸດທະສາດ” ໃຫ້ຊັດເຈນໃນໜ້ານີ້ເລີຍ៖

• ໃຊ້ຮູບຈຳນວນນ້ອຍກ່ອນເພື່ອກຳນົດລະດັບການບີບອັດ ແລະ ຄຸນນະພາບທີ່ເຫັນ
• ກຳນົດກົນລະຍຸດກ່ອນແລ້ວຄ່ອຍດຳເນີນແບບກຸ່ມ
  ຫຼີກລ້ຽງການທົດລອງຜິດຊ້ຳໆໃນຄັງທັງໝົດ

3. ການໃຊ້ API Key ຮ່ວມກັນຫຼາຍເວັບເຮັດໃຫ້ໂຄຕ້າຫຼຸດລົງແບບບໍ່ຮູ້ສາເຫດ“
   ຖ້າທ່ານໃຊ້ API Key ອັນດຽວກັນໃນຫຼາຍເວັບໄຊ, ໂຄຕ້າຈະຖືກໃຊ້ຮ່ວມກັນ.
   ດັ່ງນັ້ນໃນສະຖານະການທີມ/ຫຼາຍເວັບ ຄວນກຳນົດໃຫ້ຊັດວ່າ: ເວັບໃດໃຊ້ຮ່ວມກັນ ແລະ ເວັບໃດໃຊ້ແຍກ ເພື່ອຫຼີກລ້ຽງງົບປະມານຄວບຄຸມບໍ່ໄດ້

---

3.2.3 TinyPNG(Tiny Compress Images): ຟຣີ 500 ເຄຣດິດ/ເດືອນ; ແປງເປັນ WebP/AVIF ຈະ “ຫັກເພີ່ມ 1 ເຄຣດິດຕໍ່ຂະໜາດ”

ໂຄວຕ້າຟຣີ ແລະ ຫຼັກການຄິດຄ່າບໍລິການ

ໜ້າປລັກອິນ WordPress ຂອງ TinyPNG ຂຽນໄວ້ຢ່າງຊັດເຈນຫຼາຍ:

• ຟຣີ 500 ເຄຣດິດ ຕໍ່ເດືອນ
• ໃນ “ການຕິດຕັ້ງ WordPress ທົ່ວໄປ” ສາມາດບີບອັດໄດ້ປະມານ ປະມານ 100 ຮູບ/ເດືອນ
• ແຕ່ຖ້າເປີດໃຊ້ການແປງເປັນ AVIF ຫຼື WebP:ແຕ່ລະຂະໜາດຮູບຈະໃຊ້ 1 credit ເພີ່ມເຕີມດັ່ງນັ້ນ ອາດຈະໄດ້ແຕ່ບີບອັດແລະແປງຮູບແບບ ປະມານ 50 ຮູບ/ເດືອນ(ຂຶ້ນກັບວ່າທ່ານມີຂະໜາດຮູບຫຍໍ້ຫຼາຍປານໃດ)។

ພ້ອມກັນນັ້ນ, Tinify (ຜູ້ພັດທະນາ TinyPNG/TinyJPG) ກໍ່ຢູ່ໃນລ ໜ້າລາຄາ APIຂຽນໃຫ້ຊັດເຈນ: ພຽງແຕ່ລົງທະບຽນກໍຈະໄດ້ຮັບສິດບີບອັດຟຣີ 500 ຄັ້ງຕໍ່ເດືອນ; ເກີນຈາກນັ້ນຈະຄິດຄ່າຕາມຈຳນວນຄັ້ງທີ່ບີບອັດສຳເລັດ, ແລະບໍ່ມີການບັງຄັບສະໝັກໃຊ້ລາຍເດືອນ.

ສະຫຼຸບວິທີການເຂົ້າໃຈ TinyPNG ດ້ວຍປະໂຫຍກດຽວ:
ນັບຕາມ credits; ຍິ່ງມີຂະໜາດຮູບຫຍໍ້ຫຼາຍ ແລະ ຍິ່ງເປີດໃຊ້ WebP/AVIF ຫຼາຍ ກໍຍິ່ງໃຊ້ credits ໄວຂຶ້ນ

ຕົວຢ່າງ TinyPNG credits ທີ່ເຂົ້າໃຈງ່າຍ

ສົມມຸດວ່າເວັບໄຊຂອງທ່ານສ້າງຂະໜາດຮູບຫຍໍ້ 8 ຂະໜາດສຳລັບແຕ່ລະຮູບ:

• ບີບອັດເທົ່ານັ້ນ: ຮູບຕົ້ນສະບັບ + 8 ຮູບຫຍໍ້ → ຕ້ອງໃຊ້ 9 credits
• ຖ້າເປີດການແປງ WebP/AVIF: ແຕ່ລະຂະໜາດຈະຖືກຫັກ credit ເພີ່ມອີກ 1 ຄັ້ງ → ອາດເກືອບເພີ່ມເປັນສອງເທົ່າ
  ນີ້ກົງກັບຄຳອະທິບາຍໃນໜ້າປັກອິນ: ຫຼັງຈາກເປີດການແປງແລ້ວ ໂຄຕ້າຟຣີຈະປະມານປ່ຽນຈາກ “100 ຮູບ/ເດືອນ” ເປັນ “50 ຮູບ/ເດືອນ”.

ບັນຫາທົ່ວໄປຂອງ TinyPNG

1. ຄິດວ່າ 500 credits = 500 ຮູບ
   ບໍ່ແມ່ນ ມັນຖືກນັບຕາມ “ຂະໜາດຮູບ/ຮູບແບບຍ່ອຍ” ໜ້າປລັກອິນໄດ້ແຈ້ງໄວ້ແລ້ວວ່າ “ການແປງຈະຫັກເພີ່ມ 1 credit ຕໍ່ແຕ່ລະຂະໜາດຮູບ”
2. ຫົວຂໍ້/ປລັກອິນອີຄອມເມີຊສ້າງຂະໜາດຫຼາຍເກີນໄປ, ໂຄຕ້າຟຣີຫຼຸດລົງຢ່າງຊັດເຈນ
   ຍິ່ງມີຂະໜາດຫຼາຍ ການໃຊ້ credits ຍິ່ງຖືກຂະຫຍາຍໃຫ້ໃຊ້ໝົດໄວຂຶ້ນ
3. ເປີດການແປງແລ້ວພົບວ່າວົງເງິນໃຊ້ໝົດໄວຂຶ້ນ
   ນີ້ບໍ່ແມ່ນ bug, ແຕ່ແມ່ນກົນໄກການຄິດຄ່າຂອງມັນ។
   ຄຳແນະນຳກົນລະຍຸດ:

• ຖ້າໄລຍະຟຣີໃຊ້ເປັນຫຼັກສໍາລັບການບີບອັດແລະຫຼຸດຂະໜາດ ສາມາດບີບອັດກ່ອນໄດ້ ເມື່ອທ່ານຢືນຢັນວ່າໂຄງສ້າງເວັບໄຊຄົງທີ່ແລະຈໍາເປັນຕ້ອງໃຊ້ next-gen ຈຶ່ງເປີດການແປງຮູບແບບ

4. ຄໍາແນະນໍາຕາມສະຖານການ: ຄວນເລືອກເວັບໄຊປະເພດຕ່າງໆແນວໃດ

ຄືກັນກັບ WordPress, ຈຸດກົດດັນຮູບພາບຂອງເວັບໄຊທ໌ເນື້ອຫາ, ການຄ້າອອນໄລນ໌, ຜົນງານ, ແລະເວັບໄຊທ໌ສະມາຊິກບໍ່ຄືກັນ.

4.1 ເນື້ອຫາ/ບລັອກ (ບົດຄວາມມີຮູບຫຼາຍ, ອັບເດດຄວາມຖີ່ປານກາງ)

ຄຳແນະນຳລຳດັບຄວາມສຳຄັນ៖

1. ນະໂຍບາຍຂະໜາດ (ຂັ້ນຕອນ 1)
2. ບີບອັດ (Step 2)
3. WebP (ຂັ້ນຕອນ 3)

ເສັ້ນທາງທີ່ເໝາະສົມກວ່າ:

• ຢາກປະຢັດແຮງ: ທາງເລືອກ B ເລືອກ 1 ໃນ 3 (ShortPixel / Imagify / TinyPNG)
• ຢາກໄດ້ຟຣີ: ແນວທາງ A (Plus WebP + EWWW), ແຕ່ແນະນຳໃຫ້ເລີ່ມປະເມີນຄວາມສ່ຽງຈາກ “ໂໝດອະນຸລັກ (ບໍ່ລຶບຮູບຕົ້ນສະບັບ)” ກ່ອນ

ຂຸມທີ່ພົບເລື້ອຍ:

• ຮູບຫົວບົດຄວາມໃຫຍ່ເກີນໄປ, ນະໂຍບາຍ lazy load ບໍ່ເໝາະສົມຈະເຮັດໃຫ້ໜ້າທຳອິດຊ້າ

4.2 ເວັບຮ້ານຄ້າ/ສິນຄ້າ (ຮູບຫຍໍ້ຫຼາຍ, ຮູບແບບຮູບຫຼາຍ, ຄວາມສະຖຽນສຳຄັນທີ່ສຸດ)

ຈຸດທີ່ຮ້ານຄ້າອອນໄລນ໌ເກີດບັນຫາໄດ້ງ່າຍທີ່ສຸດ ບໍ່ແມ່ນ “ຜົນການບີບອັດບໍ່ດີ” ແຕ່ແມ່ນ “ຫຼັງຈາກປັບແຕ່ງແລ້ວ ຂະໜາດບາງຢ່າງບໍ່ຖືກ, ຮູບຫຍໍ້ຫາຍໄປ, ແລະຄອມໂພເນັນຢູ່ໜ້າເວັບບໍ່ສາມາດດຶງຮູບໄດ້”.

ຄຳແນະນຳລຳດັບຄວາມສຳຄັນ៖

1. ກ່ອນອື່ນໃຫ້ໝັ້ນຄົງກ່ອນ: ນະໂຍບາຍການບີບອັດໃຫ້ອະນຸລັກໄວ້ໜ່ອຍ ຢ່າຟ້າວເຮັດການແທນທີ່ທັງຖານຂໍ້ມູນຕັ້ງແຕ່ແຮກ
2. ປະເມີນຂະໜາດຮູບຫຍໍ້: ທີມອີຄອມເມິດມັກສ້າງຫຼາຍຂະໜາດ, ເຮັດໃຫ້ໃຊ້ໂຄຕ້າຫຼາຍຂຶ້ນ (ShortPixel/TinyPNG ເຫັນຊັດເຈນພິເສດ)
3. ກວດສອບໃນຂອບເຂດນ້ອຍກ່ອນແລ້ວຄ່ອຍດຳເນີນເປັນຈຳນວນຫຼາຍ ສຳຄັນຫຼາຍ

ເສັ້ນທາງທີ່ເໝາະສົມກວ່າ:

• ເສັ້ນທາງ B ມັກຈະສະດວກກວ່າ: ShortPixel/Imagify/TinyPNG ລ້ວນແຕ່ປະມວນຜົນເປັນຊຸດໄດ້, ສິ່ງສຳຄັນແມ່ນທ່ານຕ້ອງເຂົ້າໃຈກົນໄກໂຄຕ້າ ແລະປະເມີນຕົ້ນທຶນລ່ວງໜ້າ
• ເສັ້ນທາງ A ກໍໃຊ້ໄດ້, ແຕ່ຄວນລະມັດລະວັງຫຼາຍຂຶ້ນຕໍ່ພຶດຕິກຳ “ຂຽນທັບ ID/ລຶບຮູບຕົ້ນສະບັບ/ແທນ URL” ຂອງ Plus WebP: ນີ້ແມ່ນການຍ້າຍຊັບສິນ, ບໍ່ແນະນຳໃຫ້ແທນທີ່ທັງໝົດຕັ້ງແຕ່ແລກ

4.3 ຜົນງານ/ເວັບຖ່າຍຮູບ (ເນັ້ນຄຸນນະພາບຮູບດຽວ, ຮູບໃຫຍ່, ຕ້ອງການຄຸນນະພາບການສະແດງສູງ)

ຄຳແນະນຳລຳດັບຄວາມສຳຄັນ៖

1. ນະໂຍບາຍຂະໜາດ (ຄວບຄຸມພື້ນທີ່ສະແດງ)
2. ນະໂຍບາຍບີບອັດ (ຍອມໃຫ້ໃຫຍ່ກວ່າໜ່ອຍ ແຕ່ຢ່າໃຫ້ລາຍລະອຽດເສຍ)
3. WebP/AVIF (ຮູບໃຫຍ່ເຫັນຜົນຊັດ ແຕ່ຕ້ອງກວດສອບຄຸນນະພາບການເບິ່ງ)

ເສັ້ນທາງທີ່ເໝາະສົມກວ່າ:

• Imagify: ຫັກໂຄຕາຕາມ “ຂະໜາດຮູບຕົ້ນສະບັບ”, ເວັບໄຊປະເພດນີ້ຈະເຮັດໃຫ້ “ຄວບຄຸມງົບປະມານໄດ້” ງ່າຍກວ່າ (ທ່ານຮູ້ໄດ້ປະມານວ່າຮູບໃຫຍ່ແຕ່ລະຮູບຈະຖືກຫັກເທົ່າໃດ), ແຕ່ຄວນຫຼີກລ້ຽງການບີບອັດຊ້ຳໆ.
• ShortPixelຖ້າຂະໜາດຮູບຫຍໍ້ມີບໍ່ຫຼາຍ, credits ກໍເຂົ້າໃຈງ່າຍ; ແຕ່ຖ້າທ່ານສ້າງຫຼາຍຂະໜາດ + next-gen, ການໃຊ້ credits ຈະເພີ່ມຂຶ້ນ, ຕ້ອງວາງແຜນລ່ວງໜ້າ.

5. ວົງເງິນ/ການຄິດຄ່າທຽບທຽມ: ອະທິບາຍໃຫ້ຊັດວ່າ “ໃຊ້ຟຣີພຽງພໍບໍ”

ແທ້ໆແລ້ວຄວນເລືອກອັນໃດຈຶ່ງຄຸ້ມກວ່າ, ໃຊ້ຟຣີໄດ້ດົນປານໃດ?

5.1 ສາມຮູບແບບການຫັກຄ່າ

• ShortPixelເຄຣດິດຄິດໄລ່ credits ຕາມ “ຮູບຕົ້ນສະບັບ + ຈຳນວນຮູບຫຍໍ້”; ການສ້າງ WebP/AVIF ຈະຫັກ credit ເພີ່ມສຳລັບແຕ່ລະເວີຊັນທີ່ກ່ຽວຂ້ອງ
• Imagify(ໂຄຕາ MB): ຈະຫັກໂຄຕ້າຕາມ “ຂະໜາດໄຟລ໌ຕົ້ນສະບັບ”; ຍິ່ງມີຮູບຫຍໍ້ຫຼາຍ ຍິ່ງຖືກຫັກຫຼາຍ; ບີບອັດຊ້ຳຈະຖືກຫັກອີກ.
• TinyPNGເຄຣດິດທຸກເດືອນ 500 ເຄຣດິດ; ການເປີດໃຊ້ການແປງ WebP/AVIF ຈະຫັກເພີ່ມອີກ 1 ເຄຣດິດຕໍ່ແຕ່ລະຂະໜາດຮູບພາບ

5.2 ວິທີການຄາດຄະເນຢ່າງໄວ

ທ່ານສາມາດຄາດຄະເນແບບນີ້:

1. ເລືອກຮູບຕົ້ນສະບັບທີ່ທ່ານມັກອັບໂຫຼດມາສັກຮູບ ແລ້ວເບິ່ງວ່າຂະໜາດປະມານເທົ່າໃດ (ເຊັ່ນ 300KB / 1MB / 3MB)
2. ເບິ່ງວ່າເວັບໄຊຂອງທ່ານສ້າງຂະໜາດຮູບຫຍໍ້ປະມານເທົ່າໃດ (ເຊັ່ນ 5 ຂະໜາດ / 10 ຂະໜາດ / 20 ຂະໜາດ)
3. ຕັດສິນໃຈວ່າທ່ານຕ້ອງການສ້າງ WebP/AVIF ຫຼືບໍ່ (ແມ່ນ/ບໍ່)

ແລ້ວໃຊ້ “ການຄິດໄລ່ໃນຫົວ” ດ້ານລຸ່ມນີ້ເພື່ອເຂົ້າໃຈການບໍລິໂພກ:

• ShortPixelຮູບລະປະມານ (1 + ຈຳນວນຮູບຫຍໍ້) credits; ຖ້າສ້າງ WebP/AVIF, ຈະເພີ່ມເປັນສອງເທົ່າອີກ (ເພາະວ່າ next-gen ກໍໃຊ້ credit ເຊັ່ນກັນ)
• Imagify: ແຕ່ລະຮູບ≈(ຂະໜາດຮູບຕົ້ນສະບັບ + ຂະໜາດຂອງຮູບຫຍໍ້ແຕ່ລະຮູບ) ຈະຫັກໂຄຕ້າ; ຖ້າປ່ຽນລະດັບການບີບອັດແລ້ວບີບອັດໃໝ່ ຈະຖືກຫັກອີກ
• TinyPNGຟຣີ 500 ເຄຣດິດ; ຖ້າແຕ່ລະຮູບໃນເວັບໄຊຂອງທ່ານສ້າງຫຼາຍຂະໜາດ ແລະເປີດໃຊ້ການແປງ, ຈຳນວນຮູບຟຣີຈະຫຼຸດລົງຢ່າງຫຼາຍ (ໜ້າປລັກອິນໃຫ້ການຄາດຄະເນແບບເຂົ້າໃຈງ່າຍວ່າ “ປະມານ 100 ຮູບ/ເດືອນ” ແລະ “ປະມານ 50 ຮູບ/ເດືອນ”)

6. ຄຳເຕືອນຄວາມສ່ຽງ

ຄວາມສ່ຽງ 1: ຢ່າໃຫ້ຫຼາຍປລັກອິນເຮັດສິ່ງດຽວກັນຊ້ຳກັນ

ນີ້ແມ່ນ “ຕົ້ນຕໍແຫ່ງໄພພິບັດ” ທີ່ພົບເຫັນບ່ອຍທີ່ສຸດ”

• ເສັ້ນທາງ A៖Plus WebP ຫຼື AVIF + EWWWແບ່ງໜ້າທີ່ກັນ ຢ່າເຮັດການແປງແລະການສົ່ງມອບປະເພດດຽວກັນພ້ອມກັນ ຫຼືຕິດຕັ້ງພຽງອັນດຽວ
• ເສັ້ນທາງ B：ShortPixel / Imagify / TinyPNG ເລືອກ 1 ໃນ 3ເລືອກໜຶ່ງອັນທີ່ຮັບຜິດຊອບການບີບອັດ ແລະ next-gen

ຄວາມສ່ຽງ 2: “ຂຽນທັບ ID / ລຶບຮູບຕົ້ນສະບັບ / ແທນທີ່ URL” ຂອງ Plus WebP ເປັນການຍ້າຍຊັບສິນ

ຂໍເນັ້ນອີກຄັ້ງ:ພລັສ WebP ຄຳອະທິບາຍໄດ້ລະບຸຢ່າງຊັດເຈນວ່າ ເມື່ອສ້າງແບບເຕັມຈຳນວນ ຈະຂຽນທັບ ID ຮູບຕົ້ນສະບັບ, ລົບໄຟລ໌ຕົ້ນສະບັບ, ແລະປ່ຽນແທນ URL ເນື້ອຫາ.
ນີ້ໝາຍຄວາມວ່າ ມັນບໍ່ແມ່ນ “ການຕັ້ງຄ່ານ້ອຍໆທີ່ສາມາດຖອນຄືນໄດ້ທຸກເວລາ”, ແຕ່ແມ່ນການປ່ຽນແປງໃນລະດັບຊັບສິນຄັ້ງໜຶ່ງ.

ຍຸດທະສາດທີ່ແນະນຳຄວນເປັນ:

• ທົດສອບກ່ອນໃນຂອບເຂດນ້ອຍ (ຫຼາຍສິບຮູບ～ຫຼາຍຮ້ອຍຮູບ)
• ຢືນຢັນວ່າການສະແດງໜ້າຫຼັກ, ຮູບຫຍໍ້ ແລະ ການອັບເດດແຄດ ເປັນປົກກະຕິ
• ພິຈາລະນາປະມວນຜົນທັງໝົດອີກຄັ້ງ

ຄວາມສ່ຽງ 3: ການໃຊ້ໂຄຕ້າຟຣີຂອງການບີບອັດຄລາວຂຶ້ນກັບຈຳນວນຮູບຫຍໍ້ ແລະ ການເລືອກ next-gen

• ShortPixelຮູບຫຍໍ້ ແລະ next-gen ຈະມີຜົນກະທົບຕໍ່ credits ຢ່າງຫຼາຍ
• TinyPNGການເປີດໃຊ້ WebP/AVIF ຈະຫັກ credit ເພີ່ມເຕີມສຳລັບຂະໜາດຮູບພາບແຕ່ລະອັນ
• Imagify: ຕັດຕາມຂະໜາດຮູບຕົ້ນສະບັບ, ຮູບຫຍໍ້ຍິ່ງຫຼາຍຍິ່ງຖືກຕັດຫຼາຍ, ກົດແຮງຈະຖືກຕັດຊ້ຳ

ຄວາມສ່ຽງ 4: “ສ້າງ WebP/AVIF ແລ້ວ” ບໍ່ໄດ້ໝາຍຄວາມວ່າ “ໜ້າເວັບກຳລັງສົ່ງມອບ WebP/AVIF”

ຫຼາຍຄົນຫຼັງຈາກແປງແລ້ວຮູ້ສຶກວ່າ “ບໍ່ໄວຂຶ້ນ”, ສາເຫດຫຼັກແມ່ນໜ້າເວັບຍັງສົ່ງ JPG/PNG ຢູ່ (ແຄດ, rewrite, tag, browser negotiation ແລະອື່ນໆ ມີຈຸດໃດຈຸດໜຶ່ງບໍ່ກົງກັນ).

7. ຫຼັງຈາກເຮັດສຳເລັດແລ້ວ ຈະກວດສອບໄດ້ແນວໃດວ່າມັນມີຜົນຫຼືບໍ່

4 ຈຸດກວດສອບທີ່ງ່າຍຫຼາຍ:

1. ໂຫຼດຄັ້ງທີສອງໃນໜ້າດຽວກັນ ເສຖີຍນແລະໄວຂຶ້ນບໍ່(ຮູ້ສຶກໄດ້ວ່າແຄດ ແລະ ການປັບແຕ່ງໃຊ້ໄດ້ຜົນຫຼືບໍ່)
2. ຂະໜາດຮູບທີ່ໂຫຼດໃນມືຖື ແລະ ເດັສທັອບ ແຕກຕ່າງກັນຊັດເຈນບໍ່ແບບຕອບສະໜອງ srcset/sizes ມີຜົນຫຼືບໍ່）
3. ສຸ່ມກວດສອບສອງສາມຮູບ: ມີໄຟລ໌/ຊັບພະຍາກອນ WebP ຫຼື AVIF ຫຼືບໍ່(ເວັບໄຊນີ້ໃຊ້ງານຢູ່ແທ້ບໍ? next-gen）
4. ສຸ່ມກວດສອບຮູບສອງສາມໃບ: ຂະຫຍາຍເບິ່ງວ່າມົວຊັດເຈນຫຼືບໍ່, ຕົວອັກສອນຟຸ້ງຫຼືບໍ່(ຄຸນນະພາບການບີບອັດສູງເກີນໄປບໍ)

ຖ້າທັງ 4 ຂໍ້ນີ້ກົງກັນ ກໍ່ສະແດງວ່າເສັ້ນທາງທີ່ເຈົ້າເລືອກໄດ້ເຮັດວຽກແລ້ວ. ຕໍ່ໄປຄ່ອຍໄປເຮັດ ຊັ້ນການຈັດສົ່ງ“ໂດຍລວມຈະມີຄວາມໝັ້ນຄົງກວ່າເກົ່າ។

8. ຄຳແນະນຳການດຳເນີນການ

1. ເລືອກເສັ້ນທາງກ່ອນ:

• ພະຍາຍາມໃຫ້ຟຣີທີ່ສຸດ: Plus WebP ຫຼື AVIF + EWWW (ຫຼືຕິດຕັ້ງພຽງແຕ່ອັນໃດອັນໜຶ່ງ)
• ຢາກປະຢັດຊັບພະຍາກອນເຊີບເວີ ຈ່າຍຕາມໂຄຕ້າສະບາຍໃຈກວ່າເລືອກ 1 ໃນ 3: ShortPixel / Imagify / TinyPNG

2. ທົດສອບກ່ອນໃນຂອບເຂດນ້ອຍ (ຫຼາຍສິບຮູບ)
3. ຢືນຢັນວ່າບໍ່ມີບັນຫາແລ້ວຄ່ອຍດຳເນີນການເປັນຊຸດ
4. ຈໍາເປັນຕ້ອງຍົກລະດັບຄວາມສະຖຽນໃນການສົ່ງມອບເພີ່ມອີກອ່ານ CDN ເລັ່ງ

ຄຳຖາມທີ່ພົບເຫັນບ່ອຍ

1. ຕົກລົງແລ້ວຂ້ອຍຕ້ອງຕິດຕັ້ງປລັກອິນຈັກອັນ? ສາມາດຕິດຕັ້ງທັງໝົດໄດ້ບໍ?

ພະຍາຍາມໃຊ້ພຽງແຕ່ເສັ້ນທາງດຽວເທົ່ານັ້ນ។

• ເສັ້ນທາງ A: Plus WebP ຫຼື AVIF + EWWW Image Optimizer (ຫຼືຕິດຕັ້ງພຽງແຕ່ອັນໃດອັນໜຶ່ງ)
• ທາງເລືອກ B: ເລືອກ 1 ໃນ 3
  ຢ່າໃຊ້ຫຼາຍປລັກອິນໃນເວັບດຽວກັນເພື່ອບີບອັດ ຫຼື ແປງເປັນ WebP/AVIF ຫຼື ແກ້ URL/ຂຽນທັບການຈັດສົ່ງ ເພາະຈະຍິ່ງສັບສົນ ແລະ ກວດຫາສາເຫດໄດ້ຍາກ

2. WordPress ບໍ່ໄດ້ຮອງຮັບ WebP/AVIF ແລ້ວບໍ? ຂ້ອຍຍັງຈຳເປັນຕ້ອງໃຊ້ປລັກອິນຢູ່ບໍ?

ຕ້ອງແຍກໃຫ້ຊັດ:
“ຮອງຮັບການອັບໂຫຼດ/ນຳໃຊ້” ≠ “ແປງອັດຕະໂນມັດ/ຈັດສົ່ງອັດຕະໂນມັດ”。
WordPress 6.5 ກໍຈະບໍ່ປ່ຽນ JPG/PNG ເກົ່າຈຳນວນຫຼາຍເປັນ WebP/AVIF ໂດຍອັດຕະໂນມັດເຊັ່ນກັນ, ແລະກໍຈະບໍ່ຊ່ວຍທ່ານສ້າງຂະບວນການແບບຄົບວົງຈອນ “ສົ່ງອອກ AVIF/WebP ຕາມຄວາມສາມາດຂອງບຣາວເຊີ ແລະມີການຖອຍກັບ” ໂດຍອັດຕະໂນມັດ. ຖ້າຢາກໃຫ້ຄັງສື່ເກົ່າຕາມທັນ, ປົກກະຕິແລ້ວຕ້ອງໃຊ້ປລັກອິນ ຫຼື ບໍລິການມາຊ່ວຍເຕີມ.

3. ໃນການປັບແຕ່ງຮູບພາບ, ຂັ້ນຕອນໃດກັນແນ່ທີ່ “ໄດ້ຜົນຄຸ້ມຄ່າທີ່ສຸດ”?

ປົກກະຕິ ຕັ້ງຄ່າ “ຂະໜາດ” ໃຫ້ຖືກກ່ອນ (srcset/sizes)。
ເວັບໄຊຫຼາຍແຫ່ງທີ່ຊ້າບໍ່ແມ່ນເພາະບໍ່ໄດ້ບີບອັດ, ແຕ່ເປັນເພາະໜ້າເວັບສະແດງພຽງ 900px ແຕ່ກັບໃຫ້ຜູ້ໃຊ້ດາວໂຫຼດຮູບຕົ້ນສະບັບ 3000px. ການບີບອັດຊ່ວຍປະຢັດ KB ໄດ້, ແຕ່ “ຂະໜາດບໍ່ຖືກຕ້ອງ” ຈະເຮັດໃຫ້ເຈົ້າດາວໂຫຼດຂໍ້ມູນເກີນໄປຫຼາຍເທົ່າໂດຍບໍ່ຈໍາເປັນ.

4. ຂ້ອຍຈະຢືນຢັນໄດ້ແນວໃດວ່າຕອນນີ້ກຳລັງໂຫຼດ “ຮູບທີ່ນ້ອຍກວ່ານັ້ນ” ແລະບໍ່ແມ່ນດາວໂຫຼດຮູບຕົ້ນສະບັບຢູ່ຕະຫຼອດ?

ເບິ່ງສອງປາກົດການ:

• ເມື່ອເປີດໜ້າເວັບໃນມືຖື ຮູບທີ່ດາວໂຫຼດມີຂະໜາດນ້ອຍກວ່າເທິງເດັສທັອບຢ່າງຊັດເຈນ
• ຮູບດຽວກັນໃຊ້ຂະໜາດຊັບພະຍາກອນຕ່າງກັນໃນແຕ່ລະອຸປະກອນ
  ຖ້າດາວໂຫລດຮູບຕົ້ນສະບັບສະເໝີ ສາເຫດທົ່ວໄປແມ່ນທີມ ຫຼື ຕົວສ້າງໜ້າໃຊ້ຮູບເປັນພື້ນຫຼັງ CSS ຫຼື ສົ່ງອອກແບບກຳນົດເອງ ເຮັດໃຫ້ຂ້າມຂະໜາດຫຼາຍແບບແລະ srcset ຂອງຄັງສື່

5. ການ “ສ້າງ WebP/AVIF” ໝາຍຄວາມວ່າໜ້າເວັບກຳລັງສະແດງ WebP/AVIF ແນ່ນອນບໍ?

ບໍ່ເທົ່າກັບ។
ການສ້າງແມ່ນສຳເລັດພຽງແຕ່ໃນ “ຊັ້ນໄຟລ໌” ເທົ່ານັ້ນ; ສ່ວນຫນ້າເວັບຈະສົ່ງມອບ WebP/AVIF ແທ້ຫຼືບໍ່ ຍັງຂຶ້ນກັບການຂຽນທັບ, ຍຸດທະສາດແທັກ picture, ແຄດຊ໌ຖືກໃຊ້ຫຼືບໍ່, ການເຈລະຈາຂອງບຣາວເຊີໃຊ້ໄດ້ຜົນຫຼືບໍ່ ແລະອື່ນໆ. ຫຼັງຈາກເຮັດສຳເລັດ ທ່ານຕ້ອງ “ສຸ່ມກວດເບິ່ງປະເພດຊັບພະຍາກອນຂອງຮູບບາງຮູບ” ໃຫ້ແນ່ນອນ.

6. Plus WebP ຫຼື AVIF ອັນຕະລາຍຢູ່ຈຸດໃດກັນແນ່? ຂ້ອຍສາມາດກົດຄັ້ງດຽວແລ້ວໃຫ້ທັງຄັງແລ່ນໄດ້ບໍ?

ຈຸດສ່ຽງຂອງມັນບໍ່ແມ່ນ “ການບີບອັດ” ແຕ່ແມ່ນການປ່ຽນແປງລະດັບການຍ້າຍຊັບສິນ：

• ເມື່ອສ້າງແບບເຕັມອາດຈະຂຽນທັບ ID ໄຟລ໌ຮູບພາບຕົ້ນສະບັບ, ລຶບໄຟລ໌ຕົ້ນສະບັບ, ແລະແທນທີ່ URL ໃນເນື້ອຫາ.
  ດັ່ງນັ້ນບໍ່ແນະນຳໃຫ້ແທນທີ່ທັງໝົດໃນຄັ້ງດຽວ: ທົດລອງກ່ອນໃນຂອບເຂດນ້ອຍ (ສິບກວ່າແຜ່ນຫາຫຼາຍຮ້ອຍແຜ່ນ) + ມີຂໍ້ມູນສຳຮອງທີ່ໃຊ້ໄດ້ແລ້ວ, ຈຶ່ງຄ່ອຍພິຈາລະນາປະມວນຜົນທັງຄັງ.

7. ຈະເລືອກສອງໂໝດຂອງ Plus WebP ແນວໃດ: ເກັບຮູບຕົ້ນສະບັບໄວ້ vs ແທນທີ່ແລະລຶບຮູບຕົ້ນສະບັບ?

ເຂົ້າໃຈງ່າຍໆ:

• ໂໝດ 1: ເກັບຮູບຕົ້ນສະບັບໄວ້ + ສ້າງສຳເນົາ WebP/AVIF (ເສຖີຍກວ່າ): ສະດວກໃນການຍ້ອນກັບ, ແຕ່ພື້ນທີ່ດິສກ໌ຈະເພີ່ມຂຶ້ນ (ຮູບຕົ້ນສະບັບ + ຮູບແບບໃໝ່ + ຮູບຫຍໍ້ຫຼາຍຂະໜາດ).
• ໂໝດ 2: ແທນທີ່ ແລະ ລຶບຮູບຕົ້ນສະບັບ (ເຂັ້ມຂຶ້ນ): ດິສບໍ່ຂະຫຍາຍຕົວງ່າຍ, ແຕ່ເຈົ້າກຳລັງ “ປ່ຽນຊັບສິນ + ປ່ຽນການອ້າງອີງ”, ເຮັດໃຫ້ຕົ້ນທຶນໃນການກວດຫາບັນຫາຄວາມເຂົ້າກັນໄດ້ສູງຂຶ້ນ.
  ເວັບໄຊຍິ່ງຊັບຊ້ອນ (ອີຄອມເມີຊ/ຫຼາຍປລັກອິນ/ຫຼາຍຂະໜາດ), ຍິ່ງແນະນຳໃຫ້ເລີ່ມຈາກໂໝດທີ່ເສຖີຍນກວ່າ

8. EWWW Image Optimizer ການບີບອັດພາບພາບທ້ອງຖິ່ນຟຣີພຽງພໍບໍ? ຈະເຮັດໃຫ້ເຊີບເວີລົ້ມລົງບໍ?

EWWW ຄ້າຍກັບ “ຕົວບີບອັດທີ່ເຮັດວຽກໃນເຄື່ອງ”: ຈະໃຊ້ CPU/IO។
ສະຖານະການທົ່ວໄປຄື ໃນເວລາປັບປຸງແບບຊຸດ ພາລະຈະສູງຂຶ້ນ ນີ້ບໍ່ໄດ້ໝາຍຄວາມວ່າມັນ “ໃຊ້ບໍ່ໄດ້” ແຕ່ຕ້ອງໃຊ້ກົດລະຍຸດໃຫ້ຖືກ: ແບ່ງເປັນຊຸດ, ເຮັດໃນຊ່ວງໂຫຼດຕ່ຳ, ແລະຖ້າຈຳເປັນໃຫ້ເລືອກຖ່າຍພາລະ/ໂຊລູຊັນຄລາວ
ຖ້າທ່ານຕ້ອງການຄວາມສະດວກໃຈ ຫຼື ຊັບພະຍາກອນເຊີບເວີມີຈຳກັດ ແນວທາງ B ປະຢັດຊັບພະຍາກອນເຊີບເວີຫຼາຍກວ່າ។

9. ເຄຣດິດຟຣີ 100 ຕໍ່ເດືອນຂອງ ShortPixel, ເປັນຫຍັງຂ້ອຍຮູ້ສຶກວ່າໃຊ້ກັບຮູບບໍ່ຈັກຮູບກໍໝົດແລ້ວ?

ຍ້ອນວ່າ credits ບໍ່ແມ່ນ “ຈໍານວນຮູບພາບ”ຮູບຫຍໍ້ ແລະ next-gen ຈະຂະຫຍາຍມັນ

• ຮູບຕົ້ນສະບັບ + ແຕ່ລະຮູບຫຍໍ້ນັບເປັນ 1 ເຄຣດິດ
• ຖ້າສ້າງ WebP/AVIF ແຕ່ລະເວີຊັນທີ່ສອດຄ່ອງຈະໃຊ້ credit ເພີ່ມອີກ
  ດັ່ງນັ້ນ ສິ່ງທີ່ເຈົ້າຄິດວ່າ “1 ຮູບ”, ອາດຈະໃຊ້ໄປໃກ້ຄຽງກັບ “credits ສອງຫຼັກ” ແທ້ໆ. ShortPixel

10. ເປັນຫຍັງ 20MB/ເດືອນ ຟຣີຂອງ Imagify ກໍໃຊ້ໝົດໄວ?

Imagify ຄ້າຍກັບ “ແພັກເກດການໃຊ້ງານ”:

• ຕາມທີ່ທ່ານສົ່ງຂະໜາດໄຟລ໌ເດີມຫັກໂຄຕ້າ
• ຍິ່ງມີຮູບຫຍໍ້ຫຼາຍ ຍິ່ງໃຊ້ຊັບພະຍາກອນຫຼາຍ
• ປັບລະດັບການບີບອັດແລະປັບປຸງໃໝ່ ຈະໃຊ້ໂຄຕາອີກຄັ້ງ
• API Key ດຽວກັນໃຊ້ຮ່ວມກັນຫຼາຍເວັບ, ແບ່ງປັນໂຄຕ້າຮ່ວມກັນ
  ດັ່ງນັ້ນ “20MB ໃຊ້ໝົດໄວ” ມັກເກີດຈາກຮູບພາບໃຫຍ່ເກີນໄປ, ມີຮູບຫຍໍ້ຫຼາຍເກີນໄປ, ຫຼືລອງຜິດລອງຖືກຊ້ຳໆ.

11. TinyPNG ຟຣີ 500 credits/ເດືອນ, ເປັນຫຍັງປລັກອິນຈຶ່ງບອກວ່າປະມານມີພຽງ 100 ຮູບ/ເດືອນ, ແລະເມື່ອເປີດ WebP/AVIF ແລ້ວຍັງເຫຼືອ 50 ຮູບ/ເດືອນ?

ເພາະວ່າ credits ຂອງ TinyPNG ກໍຈະຖືກ “ຂະໜາດ/ຮູບແບບຍ່ອຍ” ຂະຫຍາຍດ້ວຍ:

• ການຕິດຕັ້ງ WordPress ທົ່ວໄປບີບອັດໄດ້ປະມານ 100 ຮູບ/ເດືອນ
• ເປີດໃຊ້ການແປງເປັນ AVIF ຫຼື WebP៖ແຕ່ລະຂະໜາດຮູບຈະໃຊ້ 1 credit ເພີ່ມເຕີມດັ່ງນັ້ນ ອາດຈະບີບອັດ ແລະ ແປງໄດ້ປະມານ 50 ຮູບ/ເດືອນ (ຂຶ້ນກັບຈຳນວນ ແລະ ຂະໜາດຮູບຫຍໍ້)
  ດັ່ງນັ້ນ 500 ເຄຣດິດ ≠ 500 ຮູບ។

12. ຮູບຫຍໍ້ຢູ່ໃນເວັບໄຊຂອງຂ້ອຍມີທັງໝົດເທົ່າໃດ? ເປັນຫຍັງມັນຈຶ່ງມີຜົນກະທົບຫຼາຍຂະໜາດນີ້?

WordPress ອັບໂຫລດຮູບໜຶ່ງຮູບຈະສ້າງຫຼາຍຂະໜາດ; ທີມ/ປລັກອິນ (ໂດຍສະເພາະ e-commerce) ອາດເພີ່ມຂະໜາດອື່ນອີກ.
ເຄຣດິດ/ໂຄຕ້າການບີບອັດເທິງຄລາວມັກຈະຄິດລວມ “ຮູບຕົ້ນສະບັບ + ຮູບຫຍໍ້” ເຂົ້າດ້ວຍກັນ, ດັ່ງນັ້ນຍິ່ງມີຮູບຫຍໍ້ຫຼາຍ ໂຄຕ້າຟຣີກໍຍິ່ງໝົດໄວ

13. ການໂຫຼດແບບຂີ້ຄ້ານຈະຊ່ວຍໃຫ້ໄວຂຶ້ນແນ່ນອນບໍ? ເປັນຫຍັງບາງຄົນຈຶ່ງບອກວ່າການໂຫຼດແບບຂີ້ຄ້ານກັບຊ້າລົງ?

ການໂຫຼດແບບຊັກຊ້າເໝາະສຳລັບ “ຊັບພະຍາກອນນອກໜ້າຈໍ”。
ຖ້າຮູບໃຫຍ່ທີ່ສຳຄັນທີ່ສຸດໃນໜ້າຈໍທຳອິດກໍຖືກໂຫຼດຊ້າອອກໄປນຳ ອາດຈະເຮັດໃຫ້ປະສົບການໜ້າຈໍທຳອິດຊ້າລົງ. ຕັ້ງແຕ່ WordPress 5.5 ຂຶ້ນໄປ ການ lazy load ແບບຄ່າເລີ່ມຕົ້ນບໍ່ມີບັນຫາ ແຕ່ບໍ່ຄວນໃຊ້ແບບເໝົາລວມ.

14. ຂ້ອຍຄວນໃຊ້ CDN / ຮູບ CDN ເມື່ອໃດ ຖ້າຂ້ອຍໄປຕາມເສັ້ນທາງ A ຫຼື B?

ການບີບອັດ, ຂະໜາດ, ແລະ ຮູບແບບ ແກ້ໄຂເລື່ອງ “ໃຫ້ໄຟລ໌ນ້ອຍລົງ ແລະ ເໝາະສົມກວ່າ”;
CDN ແກ້ໄຂການຈັດສົ່ງໃຫ້ໃກ້ກວ່າ ແລະ ໝັ້ນຄົງກວ່າ。
ເມື່ອຮູບພາບຖືກດຶງມາຈາກເວັບຕົ້ນທາງທີ່ຢູ່ໄກ ແລະເຮັດໃຫ້ຄວາມໜ່ວງເຫັນໄດ້ຊັດ, ຈາກນັ້ນເສີມ CDN/ຮູບພາບ CDN (ເຊັ່ນ Cloudflare Polish / Jetpack Site Accelerator) ໂດຍລວມຈະສະຖຽນກວ່າ, ການອ່ານ ເລັ່ງ WordPress CDN。

15. ຫຼັງຈາກເຮັດສຳເລັດແລ້ວ ຂ້ອຍຈະໃຊ້ວິທີທີ່ງ່າຍທີ່ສຸດແນວໃດເພື່ອກວດສອບວ່າ “ໄດ້ຜົນແທ້”?

ວິທີການຢືນຢັນທີ່ປະຢັດເວລາທີ່ສຸດ:

• ໂຫຼດຄັ້ງທີສອງໃນໜ້າດຽວກັນ ເສຖີຍນແລະໄວຂຶ້ນບໍ່
• ຂະໜາດຮູບທີ່ໂຫຼດໃນມືຖື ແລະ ເດັສທັອບ ແຕກຕ່າງກັນຊັດເຈນບໍ (srcset/sizes ເຮັດວຽກບໍ)
• ສຸ່ມກວດສອບສອງສາມຮູບ: ມີໄຟລ໌/ຊັບພະຍາກອນ WebP ຫຼື AVIF ຫຼືບໍ່
• ສຸ່ມກວດສອບຮູບສອງສາມໃບ: ຂະຫຍາຍເບິ່ງວ່າມົວຊັດເຈນຫຼືບໍ່, ຕົວອັກສອນຟຸ້ງຫຼືບໍ່