ການຕັ້ງຄ່າປລັກອິນ W3 Total Cache Minify: ວິທີການເລືອກປະເພດການຝັງ? ປະສົບການການແກ້ໄຂບັນຫາຂອງຂ້ອຍ ແລະ ຄຳແນະນຳໃນການຊ່ວຍຊີວິດ

ມີບັນຫາໃນການເລືອກປະເພດການຝັງທີ່ເໝາະສົມສຳລັບ W3 Total Cache Minify ບໍ? ບົດຄວາມນີ້ແບ່ງປັນປະສົບການຕົວຈິງຂອງຜູ້ດູແລເວັບ ແລະ ໃຫ້ຄຳແນະນຳແບບເທື່ອລະຂັ້ນຕອນເພື່ອເລືອກປະເພດການຝັງ Minify ທີ່ເໝາະສົມຢ່າງຖືກຕ້ອງ, ຫຼີກລ່ຽງຄວາມຜິດພາດຂອງຮູບແບບເວັບໄຊທ໌ ແລະ ການໂຫຼດຂັດຂ້ອງ. ມັນຍັງປະກອບມີວິທີແກ້ໄຂການຕັ້ງຄ່າທີ່ງ່າຍຕໍ່ການໃຊ້ງານ ເຊິ່ງແມ່ນແຕ່ຜູ້ເລີ່ມຕົ້ນກໍ່ສາມາດນຳໃຊ້ໄດ້ງ່າຍ.WordPress ເລັ່ງຄວາມໄວໂດຍບໍ່ຕ້ອງຕຳ!

ຂ້ອຍກຳລັງປັບແຕ່ງເວັບໄຊທ໌ ແລະ ເມື່ອຂ້ອຍເປີດການຕັ້ງຄ່າ Minify ໃນ W3 Total Cache, ຂ້ອຍຮູ້ສຶກງົງຫຼາຍ. ເມນູເລື່ອນລົງສຳລັບປະເພດທີ່ຝັງຢູ່ມີສີ່ຕົວເລືອກຄື: Default (Block), Use JS for Non-Blocking, Use "Asynchronous" for Non-Blocking, ແລະ Use "Delayed" for Non-Blocking.

ຂ້ອຍຄິດກ່ຽວກັບມັນຢູ່ບຶດໜຶ່ງ, ນີ້ມັນກ່ຽວກັບຫຍັງ?

ເຊື່ອຂ້ອຍເຖາະ, ເຈົ້າບໍ່ໄດ້ຢູ່ຄົນດຽວ. ສີ່ທາງເລືອກນີ້ອາດຈະເຮັດໃຫ້ແມ່ນແຕ່ຜູ້ເລີ່ມຕົ້ນກໍ່ສັບສົນ, ບໍ່ຕ້ອງເວົ້າເຖິງຄົນທີ່ໃຊ້ WordPress ມາຫຼາຍປີແລ້ວ. ບົດຄວາມນີ້ນຳສະເໜີຂໍ້ບົກຜ່ອງທີ່ຂ້ອຍໄດ້ພົບ ແລະ ບົດຮຽນທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ໂດຍກົງ. ເຈົ້າບໍ່ຈຳເປັນຕ້ອງປຶກສາເອກະສານ; ພຽງແຕ່ປະຕິບັດຕາມຄຳແນະນຳຂອງຂ້ອຍ.

ປະເພດການຝັງທັງສີ່ນີ້ແມ່ນຫຍັງແທ້?

ກ່ອນອື່ນໝົດ, ໃຫ້ພວກເຮົາມາລົມກັນກ່ຽວກັບລັກສະນະນິໄສຂອງສີ່ຕົວເລືອກນີ້.

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

ການໃຊ້ JS ສຳລັບການບໍ່ບລັອກນີ້ແມ່ນສິ່ງທີ່ໜ້າສົນໃຈຫຼາຍ. ແທນທີ່ຈະຂຽນແທັກ `<script>` ໂດຍກົງໃສ່ໜ້າເວັບ, ມັນຈະສົ່ງສະຄຣິບຂະໜາດນ້ອຍອອກມາກ່ອນ, ແລະຫຼັງຈາກນັ້ນຈະສົ່ງສະຄຣິບທີ່ຕ້ອງການໂຫຼດເຂົ້າໃນໜ້າເວັບຜ່ານ JavaScript ຫຼັງຈາກໜ້າເວັບເຮັດວຽກແລ້ວ. ວິທີນີ້, ໜ້າເວັບສາມາດສະແດງຜົນໄດ້ກ່ອນ, ແລະສະຄຣິບສາມາດໂຫຼດໄດ້ເທື່ອລະກ້າວ. ຟັງແລ້ວດີຫຼາຍ, ແມ່ນບໍ? ຢ່າງໃດກໍຕາມ, ບັນຫາແມ່ນວ່າຂະບວນການສີດແບບໄດນາມິກນີ້ອາດຈະລົບກວນລຳດັບການປະຕິບັດເດີມຂອງສະຄຣິບ. ຖ້າສະຄຣິບບາງອັນໃນໜ້າເວັບຂອງທ່ານອີງໃສ່ລຳດັບການປະຕິບັດຢ່າງຫຼວງຫຼາຍ, ບັນຫາອາດຈະເກີດຂຶ້ນ.

ໃຊ້ "asynchronous" ສຳລັບການບໍ່ບລັອກນີ້ກ່ຽວຂ້ອງກັບການເພີ່ມຄຸນລັກສະນະ `async` ໃສ່ແທັກ `<script>`. ສະຄຣິບຈະດາວໂຫຼດແບບບໍ່ຕໍ່ເນື່ອງໃນພື້ນຫຼັງ ແລະ ຈະດຳເນີນການທັນທີຫຼັງຈາກດາວໂຫຼດ, ໂດຍທີ່ໜ້າເວັບບໍ່ລໍຖ້າມັນ. ຢ່າງໃດກໍຕາມ, ຂໍ້ເສຍແມ່ນວ່າລຳດັບການປະຕິບັດແມ່ນບໍ່ສາມາດຄວບຄຸມໄດ້ໝົດ; ສະຄຣິບໃດກໍຕາມທີ່ດາວໂຫຼດສຳເລັດກ່ອນຈະດຳເນີນການກ່ອນ, ໂດຍບໍ່ຄຳນຶງເຖິງລຳດັບທີ່ທ່ານລະບຸໄວ້ໃນລະຫັດ.

ການໃຊ້ "delay" ສຳລັບການບໍ່ບລັອກນີ້ແມ່ນສິ່ງທີ່ການເພີ່ມຄຸນລັກສະນະ `defer` ໝາຍຄວາມວ່າ. ສະຄຣິບຈະລໍຖ້າຈົນກວ່າໜ້າເວັບທັງໝົດຈະຖືກວິເຄາະກ່ອນທີ່ຈະປະຕິບັດ, ແລະສິ່ງສຳຄັນ, ມັນຈະຮັກສາລຳດັບເດີມທີ່ທ່ານຂຽນມັນໄວ້. ນີ້ແມ່ນງ່າຍຕໍ່ການໃຊ້, ເພາະມັນບໍ່ໄດ້ບລັອກໜ້າຈໍທຳອິດ ແລະ ລົບກວນລຳດັບ.

ຂ້ອຍຄວນເລືອກອັນໃດ?

ເວົ້າງ່າຍໆ, ສີ່ທາງເລືອກນີ້ແມ່ນຄ້າຍຄືກັບຄຳຖາມທີ່ມີຫຼາຍທາງເລືອກ:ເຈົ້າຕ້ອງການຄວາມໄວ ຫຼື ຄຳສັ່ງ?

ຄຳແນະນຳຂອງຂ້ອຍມີດັ່ງນີ້:

ຖ້າເວັບໄຊທ໌ຂອງທ່ານມີຂະໜາດນ້ອຍ, ມີສະຄຣິບໜ້ອຍ, ແລະ ທ່ານບໍ່ມີຄວາມຕ້ອງການຄວາມໄວໃນການໂຫຼດສູງຫຼາຍ, ການໃຊ້ການຕັ້ງຄ່າເລີ່ມຕົ້ນ (ຖືກບລັອກ) ແມ່ນທາງເລືອກທີ່ງ່າຍທີ່ສຸດ. ເຖິງແມ່ນວ່າມັນຈະຊ້າກວ່າໜ້ອຍໜຶ່ງ, ແຕ່ມັນຈະບໍ່ກໍ່ໃຫ້ເກີດບັນຫາໃດໆ.

ຖ້າທ່ານຕ້ອງການປັບປຸງຄວາມໄວໃນໜ້າຈໍທຳອິດ ແລະ ສະຄຣິບຂອງທ່ານບໍ່ມີການເພິ່ງພາອາໄສທີ່ເຂັ້ມແຂງເຊັ່ນ "A ຕ້ອງປະຕິບັດກ່ອນ B", ໃຫ້ຈັດລຳດັບຄວາມສຳຄັນ...ການໃຊ້ "delay" ສຳລັບການບໍ່ບລັອກ(ເລື່ອນເວລາ). ນີ້ເກືອບຈະເປັນທາງອອກທີ່ດີທີ່ສຸດໃນປະຈຸບັນ, ເພາະມັນບໍ່ໄດ້ກີດຂວາງການສະແດງຜົນ ຫຼື ລົບກວນຄຳສັ່ງ.

ຖ້າທ່ານພະຍາຍາມເລື່ອນເວລາແລ້ວ ແລະຍັງພົບວ່າບາງໜ້າທີ່ມີບັນຫາ, ໃຫ້ພິຈາລະນາ...ການໃຊ້ JS ສຳລັບການບໍ່ບລັອກວິທີແກ້ໄຂນີ້ແມ່ນຮາກຖານຫຼາຍກວ່າ, ແຕ່ຄວາມເຂົ້າກັນໄດ້ຂອງມັນຮ້າຍແຮງກວ່າເລັກນ້ອຍ.

ໃຊ້ "asynchronous" ສຳລັບການບໍ່ບລັອກ(async) ແມ່ນທາງເລືອກທີ່ຂ້ອຍແນະນຳໜ້ອຍທີ່ສຸດ. ເນື່ອງຈາກລຳດັບການປະຕິບັດແມ່ນສັບສົນໝົດ, ມັນງ່າຍທີ່ຈະເກີດຂໍ້ຜິດພາດ ເວັ້ນເສຍແຕ່ວ່າທ່ານແນ່ໃຈຢ່າງແທ້ຈິງວ່າສະຄຣິບຂອງທ່ານທັງໝົດເຮັດວຽກເປັນອິດສະຫຼະ.

ສອງອຸປະສັກໃຫຍ່ທີ່ຂ້ອຍຕົກຢູ່ໃນ

ການເວົ້າແມ່ນລາຄາຖືກ. ຂ້ອຍໄດ້ຂຽນຄວາມຜິດພາດສອງຢ່າງທີ່ຂ້ອຍເຮັດລົງ; ເຈົ້າສາມາດກວດສອບພວກມັນທຽບກັບປະສົບການຂອງເຈົ້າເອງເພື່ອເບິ່ງວ່າເຈົ້າສາມາດຫຼີກລ່ຽງພວກມັນໄດ້ຫຼືບໍ່.

ຂໍ້ເສຍປຽບທຳອິດ: ຫົວຂໍ້ WordPress ທີ່ກຳນົດເອງບໍ່ສາມາດສະແດງຕົວຢ່າງໄດ້ໃນເວລາຈິງ.

ໃນໄລຍະໜຶ່ງ, ເມື່ອປັບແຕ່ງຮູບແບບ, ຫຼັງຈາກຄລິກບັນທຶກ, ຕົວຢ່າງຈະບໍ່ໂຫຼດຄືນໃໝ່. ຂ້ອຍຈະເຮັດການປ່ຽນແປງບາງຢ່າງ, ໂຫຼດໜ້າເວັບຄືນໃໝ່, ແລະມັນກໍຍັງຄືເກົ່າ.

ຫຼັງຈາກການສືບສວນບາງຢ່າງ, ຂ້ອຍໄດ້ຄົ້ນພົບວ່າຟັງຊັນການບີບອັດຂອງ Minify ແມ່ນຕົວການ. ວິທີແກ້ໄຂແມ່ນງ່າຍດາຍ:

ເຂົ້າເຖິງປລັກອິນ W3 Total Cache常规设置, ຫັນຂຶ້ນ"ການບີບອັດ"ຍົກເລີກການເລືອກຕົວເລືອກນັ້ນ. ຈາກນັ້ນຄລິກລູກສອນນ້ອຍໆຢູ່ລຸ່ມ "ບັນທຶກການຕັ້ງຄ່າ" ຢູ່ມຸມຂວາເທິງ ແລະ ເລືອກ "..."ບັນທຶກການຕັ້ງຄ່າ ແລະ ລຶບລ້າງແຄສຂັ້ນຕອນນີ້ແມ່ນສຳຄັນຫຼາຍ; ຖ້າທ່ານບໍ່ລຶບລ້າງແຄດ, ທ່ານຍັງຈະເຫັນເວີຊັນເກົ່າຢູ່.

ຫຼັງຈາກເຮັດແລ້ວ, ໃຫ້ກັບໄປທີ່ການປັບແຕ່ງຮູບແບບ, ແລະການສະແດງຕົວຢ່າງສົດຈະກັບຄືນສູ່ສະພາບປົກກະຕິ.

ບັນຫາທີສອງ: ກ່ອງຄົ້ນຫາຮູບແບບ Astra ບໍ່ຕອບສະໜອງເມື່ອຄລິກ.

ຂ້ອຍໄດ້ພົບບັນຫານີ້ມາດົນແລ້ວ. ຂ້ອຍໃຊ້ຮູບແບບ Astra, ແລະມື້ໜຶ່ງຂ້ອຍກໍ່ພົບວ່າກ່ອງຄົ້ນຫາບໍ່ຕອບສະໜອງບໍ່ວ່າຂ້ອຍຈະຄລິກມັນແນວໃດກໍ່ຕາມ. ທຳອິດຂ້ອຍຄິດວ່າມັນເປັນບັນຫາກັບຮູບແບບນັ້ນເອງ, ແຕ່ຕໍ່ມາຂ້ອຍໄດ້ຄົ້ນພົບວ່າມັນເກີດຈາກການຕັ້ງຄ່າ Minify ຂອງ W3TC.

ວິທີແກ້ໄຂແມ່ນດັ່ງຕໍ່ໄປນີ້:

ໄປທີ່ W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings, ແລະປ່ຽນປະເພດການຝັງເປັນໜຶ່ງໃນສອງຢ່າງນີ້:

1. ກ່ອນໜ້ານີ້, ການບໍ່ບລັອກແມ່ນບັນລຸໄດ້ໂດຍໃຊ້ JavaScript.
2. ຫຼັງຈາກນັ້ນ, ໃຫ້ໃຊ້ JS ສຳລັບການບໍ່ບລັອກ

ໃນລັກສະນະດຽວກັນ, ການລຶບລ້າງແຄດ ແລະ ການໂຫຼດໜ້າເວັບຄືນໃໝ່ຈະຊ່ວຍໃຫ້ກ່ອງຄົ້ນຫາເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງ.

ສຳລັບເຫດຜົນທີ່ສອງທາງເລືອກນີ້ຖືກເລືອກແທນທີ່ຈະເປັນທາງເລືອກອື່ນ, ຂ້ອຍໄດ້ເຮັດການຄົ້ນຄວ້າບາງຢ່າງແລ້ວ. ເວົ້າງ່າຍໆ, ອົງປະກອບດ້ານໜ້າຂອງຮູບແບບ Astra ມີຄວາມອ່ອນໄຫວຕໍ່ເວລາຂອງການປະຕິບັດສະຄຣິບ, ແລະວິທີການທີ່ບໍ່ບລັອກບາງຢ່າງສາມາດເຮັດໃຫ້ການຜູກມັດເຫດການລົ້ມເຫຼວ. ການໃຊ້ໂໝດ "ບໍ່ບລັອກດ້ວຍ JS" ຮັບປະກັນວ່າສະຄຣິບຈະປະຕິບັດຫຼັງຈາກໜ້າເວັບໂຫຼດສຳເລັດແລ້ວ, ໃນຂະນະທີ່ຫຼີກລ່ຽງການປະຕິບັດທີ່ບໍ່ເປັນລະບຽບທີ່ເຫັນໄດ້ດ້ວຍ async.

ລາຍຊື່ສະຖານທີ່ທີ່ຄວນໄປຢ້ຽມຢາມ

ສຸດທ້າຍ, ນີ້ແມ່ນລາຍການກວດສອບທີ່ທ່ານສາມາດຕິດຕາມໄດ້ໂດຍກົງ:

ຂັ້ນຕອນທຳອິດແມ່ນການຊີ້ແຈງເປົ້າໝາຍຂອງທ່ານ. ທ່ານຕ້ອງການໂຫຼດໜ້າເວັບເບື້ອງຕົ້ນທີ່ໄວທີ່ສຸດ, ຫຼື ທ່ານໃຫ້ຄວາມສຳຄັນກັບຄວາມໝັ້ນຄົງ ແລະ ການດຳເນີນງານທີ່ບໍ່ມີຂໍ້ຜິດພາດ? ນີ້ຈະກຳນົດວ່າທ່ານຄວນໃຊ້ປະເພດການຝັງແບບໃດ.

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

ອັນທີສາມ, ໃຫ້ລຶບລ້າງແຄດຫຼັງຈາກການດັດແປງແຕ່ລະຄັ້ງສະເໝີ. ກົນໄກການເກັບຂໍ້ມູນແຄດຂອງ W3TC ຈະປ້ອງກັນບໍ່ໃຫ້ທ່ານເຫັນການປ່ຽນແປງລ່າສຸດ, ສະນັ້ນຂັ້ນຕອນ "ລຶບລ້າງແຄດແລະທົດສອບອີກຄັ້ງ" ແມ່ນສິ່ງຈຳເປັນຢ່າງແທ້ຈິງ.

ອັນທີສີ່, ໃຫ້ໃຊ້ເຄື່ອງມືນັກພັດທະນາຂອງບຣາວເຊີຂອງທ່ານ ຫຼື ເຄື່ອງມືຕ່າງໆເຊັ່ນ PageSpeed ​​​​Insights ເພື່ອປຽບທຽບຄວາມໄວໃນການໂຫຼດກ່ອນ ແລະ ຫຼັງ. ໃຫ້ຂໍ້ມູນເວົ້າດ້ວຍຕົວມັນເອງ, ບໍ່ພຽງແຕ່ຄວາມຮູ້ສຶກພາຍໃນຂອງທ່ານເທົ່ານັ້ນ.

ຂຽນທີ່ສຸດ

ເວົ້າແທ້ໆ, ເມື່ອຂ້ອຍເຫັນການຕັ້ງຄ່າປະເພດທີ່ຝັງຢູ່ນີ້ຄັ້ງທຳອິດ, ຂ້ອຍຮູ້ສຶກຕົກໃຈເປັນເວລາດົນນານ. ໂໝດບລັອກເລີ່ມຕົ້ນເບິ່ງຄືວ່າຊ້າເກີນໄປ, ໃນຂະນະທີ່ໂໝດ asynchronous ບໍ່ໄດ້ຮັບປະກັນລຳດັບ, ແລະ ການເລື່ອນເວລາອາດຈະເຮັດໃຫ້ເກີດບັນຫາຄວາມເຂົ້າກັນໄດ້. ຂ້ອຍຮູ້ສຶກບໍ່ແນ່ໃຈວ່າຈະເລືອກຕົວເລືອກໃດ.

ແຕ່ຕໍ່ມາຂ້ອຍຮູ້ວ່າມັນເປັນການແລກປ່ຽນ. ເຈົ້າບໍ່ສາມາດມີທັງສິ່ງທີ່ໄວທີ່ສຸດ ແລະ ໝັ້ນຄົງທີ່ສຸດ; ເຈົ້າຕ້ອງເສຍສະລະອັນໜຶ່ງສະເໝີ. ປະສົບການຂອງຂ້ອຍແມ່ນການໃຊ້ defer ກ່ອນ, ເຊິ່ງປະຈຸບັນນີ້ແມ່ນວິທີແກ້ໄຂທີ່ບໍ່ບລັອກທີ່ປອດໄພທີ່ສຸດ, ແລະ ຈາກນັ້ນໃຊ້ callback ຖ້າມີບັນຫາເກີດຂຶ້ນ.

ຖ້າທ່ານພົບບັນຫາທີ່ຄ້າຍຄືກັນ, ຫຼືຖ້າທ່ານຍັງມີບັນຫາອື່ນໆຫຼັງຈາກປະຕິບັດຕາມວິທີການຂອງຂ້ອຍ, ກະລຸນາປຶກສາຫາລືກ່ຽວກັບມັນ. ການພັດທະນາເວັບໄຊທ໌ແມ່ນກ່ຽວກັບການລອງຜິດລອງຖືກ; ບໍ່ມີໃຜເປັນຂໍ້ຍົກເວັ້ນ.

ຂອບໃຈທີ່ໄດ້ອ່ານບົດຄວາມຂອງຂ້ອຍ. ພົບກັນໃໝ່ໃນຄັ້ງຕໍ່ໄປ.