ລາຍການຫົວເລື່ອງ
ມີບັນຫາໃນການເລືອກປະເພດການຝັງທີ່ຖືກຕ້ອງສຳລັບ 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 ມາຫຼາຍປີແລ້ວ. ບົດຄວາມນີ້ນຳສະເໜີຂໍ້ບົກຜ່ອງທີ່ຂ້ອຍໄດ້ພົບ ແລະ ບົດຮຽນທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ໂດຍກົງ. ເຈົ້າບໍ່ຈຳເປັນຕ້ອງປຶກສາເອກະສານ; ພຽງແຕ່ປະຕິບັດຕາມຄຳແນະນຳຂອງຂ້ອຍ.
ປະເພດການຝັງທັງສີ່ນີ້ແມ່ນຫຍັງແທ້?
ກ່ອນອື່ນໝົດ, ໃຫ້ພວກເຮົາມາລົມກັນກ່ຽວກັບລັກສະນະນິໄສຂອງສີ່ຕົວເລືອກນີ້.
ການບລັອກ ຕາມຄ່າເລີ່ມຕົ້ນ ແມ່ນວິທີການທີ່ງ່າຍດາຍທີ່ສຸດ. ເມື່ອໂປຣແກຣມທ່ອງເວັບພົບສະຄຣິບ, ມັນຈະຢຸດ, ດາວໂຫຼດ ແລະ ປະຕິບັດສະຄຣິບຢ່າງສົມບູນ, ແລະ ຫຼັງຈາກນັ້ນສືບຕໍ່ສະແດງໜ້າເວັບ. ຟັງແລ້ວໜ້າເຊື່ອຖືໄດ້, ແມ່ນບໍ? ແຕ່ຂໍ້ໄດ້ປຽບແມ່ນວ່າການໂຫຼດໜ້າເວັບເບື້ອງຕົ້ນຂອງທ່ານຈະຖືກຊັກຊ້າ; ຜູ້ໃຊ້ຈະຕ້ອງລໍຖ້າໃຫ້ສະຄຣິບເຮັດວຽກສຳເລັດກ່ອນທີ່ພວກເຂົາຈະເຫັນຫຍັງໄດ້.
ການໃຊ້ JavaScript ສຳລັບການບໍ່ບລັອກ ແມ່ນໜ້າສົນໃຈຫຼາຍ. ແທນທີ່ຈະຂຽນແທັກ `<script>` ໂດຍກົງໃສ່ໜ້າເວັບ, ມັນຈະສົ່ງສະຄຣິບຂະໜາດນ້ອຍອອກມາກ່ອນ, ແລະຫຼັງຈາກນັ້ນຈະສັກສະຄຣິບທີ່ຈຳເປັນເຂົ້າໄປໃນໜ້າເວັບຜ່ານ JavaScript ຫຼັງຈາກໜ້າເວັບເຮັດວຽກແລ້ວ. ວິທີນີ້, ໜ້າເວັບສາມາດສະແດງຜົນກ່ອນ, ແລະສະຄຣິບຈະໂຫຼດເທື່ອລະກ້າວ. ຟັງແລ້ວດີຫຼາຍ, ແມ່ນບໍ? ຢ່າງໃດກໍຕາມ, ບັນຫາແມ່ນວ່າຂະບວນການສັກແບບໄດນາມິກນີ້ສາມາດລົບກວນລຳດັບການປະຕິບັດເດີມຂອງສະຄຣິບ. ຖ້າສະຄຣິບບາງອັນໃນໜ້າເວັບຂອງທ່ານອີງໃສ່ລຳດັບການປະຕິບັດຢ່າງຫຼວງຫຼາຍ, ບັນຫາອາດຈະເກີດຂຶ້ນ.
ການໃຊ້ "asynchronous" ສຳລັບການປະຕິບັດທີ່ບໍ່ບລັອກ ພຽງແຕ່ກ່ຽວຂ້ອງກັບການເພີ່ມຄຸນລັກສະນະ `async` ໃສ່ແທັກ `<script>`. ສະຄຣິບຈະດາວໂຫຼດແບບ asynchronous ໃນພື້ນຫຼັງ ແລະ ຈະປະຕິບັດທັນທີເມື່ອສຳເລັດ, ໂດຍບໍ່ຕ້ອງລໍຖ້າໜ້າເວັບ. ຢ່າງໃດກໍຕາມ, ຂໍ້ເສຍແມ່ນວ່າລຳດັບການປະຕິບັດແມ່ນບໍ່ສາມາດຄວບຄຸມໄດ້ໝົດ; ສິ່ງໃດກໍ່ຕາມທີ່ດາວໂຫຼດກ່ອນຈະຖືກປະຕິບັດ, ໂດຍບໍ່ຄຳນຶງເຖິງລຳດັບທີ່ທ່ານລະບຸໄວ້ໃນລະຫັດ.
ການໃຊ້ "delay" ສຳລັບການປະຕິບັດທີ່ບໍ່ບລັອກ ແມ່ນບັນລຸໄດ້ໂດຍການເພີ່ມຄຸນລັກສະນະ `defer`. ສະຄຣິບຈະລໍຖ້າຈົນກວ່າໜ້າທັງໝົດຈະຖືກວິເຄາະກ່ອນທີ່ຈະປະຕິບັດ, ແລະສິ່ງສຳຄັນ, ມັນຈະຮັກສາລຳດັບເດີມທີ່ທ່ານຂຽນມັນ. ນີ້ແມ່ນງ່າຍຕໍ່ການໃຊ້, ເພາະມັນບໍ່ໄດ້ບລັອກໜ້າຈໍທຳອິດ ແລະ ລົບກວນລຳດັບຂອງສະຄຣິບ.
ຂ້ອຍຄວນເລືອກອັນໃດ?
ເວົ້າງ່າຍໆ, ສີ່ທາງເລືອກນີ້ແມ່ນຄ້າຍຄືກັບຄຳຖາມທີ່ມີຫຼາຍທາງເລືອກ: ເຈົ້າຕ້ອງການຄວາມໄວ, ຫຼືເຈົ້າຕ້ອງການລຳດັບ?
ຄຳແນະນຳຂອງຂ້ອຍມີດັ່ງນີ້:
ຖ້າເວັບໄຊທ໌ຂອງທ່ານມີຂະໜາດນ້ອຍ, ມີສະຄຣິບໜ້ອຍ, ແລະ ທ່ານບໍ່ມີຄວາມຕ້ອງການຄວາມໄວໃນການໂຫຼດສູງຫຼາຍ, ການໃຊ້ການຕັ້ງຄ່າເລີ່ມຕົ້ນ (ຖືກບລັອກ) ແມ່ນທາງເລືອກທີ່ງ່າຍທີ່ສຸດ. ເຖິງແມ່ນວ່າມັນຈະຊ້າກວ່າໜ້ອຍໜຶ່ງ, ແຕ່ມັນຈະບໍ່ກໍ່ໃຫ້ເກີດບັນຫາໃດໆ.
ຖ້າທ່ານຕ້ອງການປັບປຸງຄວາມໄວໃນໜ້າຈໍທຳອິດ ແລະ ສະຄຣິບຂອງທ່ານບໍ່ມີການເພິ່ງພາອາໄສທີ່ເຂັ້ມແຂງເຊັ່ນ "A ຕ້ອງປະຕິບັດກ່ອນ B," ໃຫ້ຈັດລຳດັບຄວາມສຳຄັນ ໂດຍໃຊ້ "defer" ສຳລັບການປະຕິບັດທີ່ບໍ່ບລັອກ . ນີ້ເກືອບຈະເປັນທາງອອກທີ່ດີທີ່ສຸດທີ່ມີຢູ່ໃນປະຈຸບັນ, ຍ້ອນວ່າມັນຫຼີກລ່ຽງການບລັອກການສະແດງຜົນໃນຂະນະທີ່ຮັກສາລຳດັບການປະຕິບັດ.
ຖ້າທ່ານພົບວ່າບາງຟັງຊັນຍັງມີບັນຫາຫຼັງຈາກພະຍາຍາມ defer ແລ້ວ, ໃຫ້ພິຈາລະນາ ໃຊ້ JavaScript ສຳລັບການບໍ່ບລັອກ . ວິທີການນີ້ມີຄວາມກ້າວໜ້າຫຼາຍກວ່າ, ແຕ່ຄວາມເຂົ້າກັນໄດ້ຂອງມັນຮ້າຍແຮງກວ່າເລັກນ້ອຍ.
ການໃຊ້ "async" ສຳລັບການບໍ່ບລັອກ ແມ່ນທາງເລືອກທີ່ຂ້ອຍແນະນຳໜ້ອຍທີ່ສຸດ. ເນື່ອງຈາກລຳດັບການປະຕິບັດແມ່ນສັບສົນໝົດ, ມັນງ່າຍທີ່ຈະເກີດຂໍ້ຜິດພາດ ເວັ້ນເສຍແຕ່ວ່າທ່ານແນ່ໃຈວ່າສະຄຣິບຂອງທ່ານເຮັດວຽກຢ່າງເປັນອິດສະຫຼະ.
ສອງອຸປະສັກໃຫຍ່ທີ່ຂ້ອຍຕົກຢູ່ໃນ
ການເວົ້າແມ່ນລາຄາຖືກ. ຂ້ອຍໄດ້ຂຽນຄວາມຜິດພາດສອງຢ່າງທີ່ຂ້ອຍເຮັດລົງ; ເຈົ້າສາມາດກວດສອບພວກມັນທຽບກັບປະສົບການຂອງເຈົ້າເອງເພື່ອເບິ່ງວ່າເຈົ້າສາມາດຫຼີກລ່ຽງພວກມັນໄດ້ຫຼືບໍ່.
ຂໍ້ເສຍປຽບທຳອິດ: ຫົວຂໍ້ WordPress ທີ່ກຳນົດເອງບໍ່ສາມາດສະແດງຕົວຢ່າງໄດ້ໃນເວລາຈິງ.
ໃນໄລຍະໜຶ່ງ, ເມື່ອປັບແຕ່ງຮູບແບບ, ຫຼັງຈາກຄລິກບັນທຶກ, ຕົວຢ່າງຈະບໍ່ໂຫຼດຄືນໃໝ່. ຂ້ອຍຈະເຮັດການປ່ຽນແປງບາງຢ່າງ, ໂຫຼດໜ້າເວັບຄືນໃໝ່, ແລະມັນກໍຍັງຄືເກົ່າ.
ຫຼັງຈາກການສືບສວນບາງຢ່າງ, ຂ້ອຍໄດ້ຄົ້ນພົບວ່າຟັງຊັນການບີບອັດຂອງ Minify ແມ່ນຕົວການ. ວິທີແກ້ໄຂແມ່ນງ່າຍດາຍ:
ໄປທີ່ ການຕັ້ງຄ່າທົ່ວໄປ ຂອງປລັກອິນ W3 Total Cache , ຊອກຫາ ຕົວເລືອກ "ການບີບອັດ" , ແລະຍົກເລີກການເລືອກມັນ. ຈາກນັ້ນ, ຄລິກລູກສອນນ້ອຍໆຢູ່ລຸ່ມ "ບັນທຶກການຕັ້ງຄ່າ" ຢູ່ມຸມຂວາເທິງ, ແລະເລືອກ " ບັນທຶກການຕັ້ງຄ່າ ແລະ ລຶບແຄຊ ." ຂັ້ນຕອນນີ້ແມ່ນສຳຄັນຫຼາຍ; ໂດຍບໍ່ຕ້ອງລຶບແຄຊ, ທ່ານຍັງຈະເຫັນເວີຊັນເກົ່າຢູ່.
ຫຼັງຈາກເຮັດແລ້ວ, ໃຫ້ກັບໄປທີ່ການປັບແຕ່ງຮູບແບບ, ແລະການສະແດງຕົວຢ່າງສົດຈະກັບຄືນສູ່ສະພາບປົກກະຕິ.
ບັນຫາທີສອງ: ກ່ອງຄົ້ນຫາຮູບແບບ Astra ບໍ່ຕອບສະໜອງເມື່ອຄລິກ.
ຂ້ອຍໄດ້ພົບບັນຫານີ້ມາດົນແລ້ວ. ຂ້ອຍໃຊ້ຮູບແບບ Astra, ແລະມື້ໜຶ່ງຂ້ອຍກໍ່ພົບວ່າກ່ອງຄົ້ນຫາບໍ່ຕອບສະໜອງບໍ່ວ່າຂ້ອຍຈະຄລິກມັນແນວໃດກໍ່ຕາມ. ທຳອິດຂ້ອຍຄິດວ່າມັນເປັນບັນຫາກັບຮູບແບບນັ້ນເອງ, ແຕ່ຕໍ່ມາຂ້ອຍໄດ້ຄົ້ນພົບວ່າມັນເກີດຈາກການຕັ້ງຄ່າ Minify ຂອງ W3TC.
ວິທີແກ້ໄຂແມ່ນດັ່ງຕໍ່ໄປນີ້:
ໄປທີ່ W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings, ແລະປ່ຽນປະເພດການຝັງເປັນໜຶ່ງໃນສອງຢ່າງນີ້:
- ກ່ອນໜ້ານີ້, ການບໍ່ບລັອກແມ່ນບັນລຸໄດ້ໂດຍໃຊ້ JavaScript.
- ຫຼັງຈາກນັ້ນ, ໃຫ້ໃຊ້ JS ສຳລັບການບໍ່ບລັອກ
ໃນລັກສະນະດຽວກັນ, ການລຶບລ້າງແຄດ ແລະ ການໂຫຼດໜ້າເວັບຄືນໃໝ່ຈະຊ່ວຍໃຫ້ກ່ອງຄົ້ນຫາເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງ.
ສຳລັບເຫດຜົນທີ່ສອງທາງເລືອກນີ້ຖືກເລືອກແທນທີ່ຈະເປັນທາງເລືອກອື່ນ, ຂ້ອຍໄດ້ເຮັດການຄົ້ນຄວ້າບາງຢ່າງແລ້ວ. ເວົ້າງ່າຍໆ, ອົງປະກອບດ້ານໜ້າຂອງຮູບແບບ Astra ມີຄວາມອ່ອນໄຫວຕໍ່ເວລາຂອງການປະຕິບັດສະຄຣິບ, ແລະວິທີການທີ່ບໍ່ບລັອກບາງຢ່າງສາມາດເຮັດໃຫ້ການຜູກມັດເຫດການລົ້ມເຫຼວ. ການໃຊ້ໂໝດ "ບໍ່ບລັອກດ້ວຍ JS" ຮັບປະກັນວ່າສະຄຣິບຈະປະຕິບັດຫຼັງຈາກໜ້າເວັບໂຫຼດສຳເລັດແລ້ວ, ໃນຂະນະທີ່ຫຼີກລ່ຽງການປະຕິບັດທີ່ບໍ່ເປັນລະບຽບທີ່ເຫັນໄດ້ດ້ວຍ async.
ລາຍຊື່ສະຖານທີ່ທີ່ຄວນໄປຢ້ຽມຢາມ
ສຸດທ້າຍ, ນີ້ແມ່ນລາຍການກວດສອບທີ່ທ່ານສາມາດຕິດຕາມໄດ້ໂດຍກົງ:
ຂັ້ນຕອນທຳອິດແມ່ນການຊີ້ແຈງເປົ້າໝາຍຂອງທ່ານ. ທ່ານຕ້ອງການໂຫຼດໜ້າເວັບເບື້ອງຕົ້ນທີ່ໄວທີ່ສຸດ, ຫຼື ທ່ານໃຫ້ຄວາມສຳຄັນກັບຄວາມໝັ້ນຄົງ ແລະ ການດຳເນີນງານທີ່ບໍ່ມີຂໍ້ຜິດພາດ? ນີ້ຈະກຳນົດວ່າທ່ານຄວນໃຊ້ປະເພດການຝັງແບບໃດ.
ຂັ້ນຕອນທີສອງແມ່ນບໍ່ໃຫ້ປ່ຽນແປງທຸກຢ່າງໃນເທື່ອດຽວ. ກ່ອນອື່ນໝົດ, ຊອກຫາໜ້າເວັບທີ່ສຳຄັນໜ້ອຍກວ່າເພື່ອທົດສອບມັນ, ສັງເກດມັນປະມານໜຶ່ງ ຫຼື ສອງມື້, ແລະ ໂຄສະນາມັນໃຫ້ກັບເວັບໄຊທ໌ທັງໝົດພຽງແຕ່ຖ້າທ່ານແນ່ໃຈວ່າບໍ່ມີບັນຫາຫຍັງ.
ອັນທີສາມ, ໃຫ້ລຶບລ້າງແຄດຫຼັງຈາກການດັດແປງແຕ່ລະຄັ້ງສະເໝີ. ກົນໄກການເກັບຂໍ້ມູນແຄດຂອງ W3TC ຈະປ້ອງກັນບໍ່ໃຫ້ທ່ານເຫັນການປ່ຽນແປງລ່າສຸດ, ສະນັ້ນຂັ້ນຕອນ "ລຶບລ້າງແຄດແລະທົດສອບອີກຄັ້ງ" ແມ່ນສິ່ງຈຳເປັນຢ່າງແທ້ຈິງ.
ອັນທີສີ່, ໃຫ້ໃຊ້ເຄື່ອງມືນັກພັດທະນາຂອງບຣາວເຊີຂອງທ່ານ ຫຼື ເຄື່ອງມືຕ່າງໆເຊັ່ນ PageSpeed Insights ເພື່ອປຽບທຽບຄວາມໄວໃນການໂຫຼດກ່ອນ ແລະ ຫຼັງ. ໃຫ້ຂໍ້ມູນເວົ້າດ້ວຍຕົວມັນເອງ, ບໍ່ພຽງແຕ່ຄວາມຮູ້ສຶກພາຍໃນຂອງທ່ານເທົ່ານັ້ນ.
ຂຽນທີ່ສຸດ
ເວົ້າແທ້ໆ, ເມື່ອຂ້ອຍເຫັນການຕັ້ງຄ່າປະເພດທີ່ຝັງຢູ່ນີ້ຄັ້ງທຳອິດ, ຂ້ອຍຮູ້ສຶກຕົກໃຈເປັນເວລາດົນນານ. ໂໝດບລັອກເລີ່ມຕົ້ນເບິ່ງຄືວ່າຊ້າເກີນໄປ, ໃນຂະນະທີ່ໂໝດ asynchronous ບໍ່ໄດ້ຮັບປະກັນລຳດັບ, ແລະ ການເລື່ອນເວລາອາດຈະເຮັດໃຫ້ເກີດບັນຫາຄວາມເຂົ້າກັນໄດ້. ຂ້ອຍຮູ້ສຶກບໍ່ແນ່ໃຈວ່າຈະເລືອກຕົວເລືອກໃດ.
ແຕ່ຕໍ່ມາຂ້ອຍຮູ້ວ່າມັນເປັນການແລກປ່ຽນ. ເຈົ້າບໍ່ສາມາດມີທັງສິ່ງທີ່ໄວທີ່ສຸດ ແລະ ໝັ້ນຄົງທີ່ສຸດ; ເຈົ້າຕ້ອງເສຍສະລະອັນໜຶ່ງສະເໝີ. ປະສົບການຂອງຂ້ອຍແມ່ນການໃຊ້ defer ກ່ອນ, ເຊິ່ງປະຈຸບັນນີ້ແມ່ນວິທີແກ້ໄຂທີ່ບໍ່ບລັອກທີ່ປອດໄພທີ່ສຸດ, ແລະ ຈາກນັ້ນໃຊ້ callback ຖ້າມີບັນຫາເກີດຂຶ້ນ.
ຖ້າທ່ານພົບບັນຫາທີ່ຄ້າຍຄືກັນ, ຫຼືຖ້າທ່ານຍັງມີບັນຫາອື່ນໆຫຼັງຈາກປະຕິບັດຕາມວິທີການຂອງຂ້ອຍ, ກະລຸນາປຶກສາຫາລືກ່ຽວກັບມັນ. ການພັດທະນາເວັບໄຊທ໌ແມ່ນກ່ຽວກັບການລອງຜິດລອງຖືກ; ບໍ່ມີໃຜເປັນຂໍ້ຍົກເວັ້ນ.
ຂອບໃຈທີ່ໄດ້ອ່ານບົດຄວາມຂອງຂ້ອຍ. ພົບກັນໃໝ່ໃນຄັ້ງຕໍ່ໄປ.
ຂ້າພະເຈົ້າຫວັງວ່າ ບົດຄວາມ "ການຕັ້ງຄ່າປລັກອິນ W3 Total Cache Minify: ວິທີການເລືອກປະເພດການຝັງ? ຂໍ້ຜິດພາດ ແລະ ຄຳແນະນຳຊ່ວຍຊີວິດຂອງຂ້າພະເຈົ້າ" ທີ່ແບ່ງປັນໃນ ບລັອກຂອງ Chen Weiliang ( https://www.chenweiliang.com/ ) ຈະເປັນປະໂຫຍດຕໍ່ທ່ານ.
ຮູ້ສຶກວ່າບໍ່ເສຍຄ່າທີ່ຈະແບ່ງປັນລິ້ງຂອງບົດຄວາມນີ້: https://www.chenweiliang.com/cwl-34003.html