ໂຮດຕິ້ງ & ປະສິດທິພາບ
ວິທີທີ່ພວກເຮົາເຮັດໃຫ້ WordPress ໄວຂຶ້ນ: LiteSpeed Enterprise, LSCache ແລະ Redis ແຕ່ລະເວັບໄຊ
ການຮ້ອງຂໍ WordPress ທີ່ໄວທີ່ສຸດແມ່ນການຮ້ອງຂໍທີ່ບໍ່ເຄີຍໄດ້ດຳເນີນການ — ນີ້ແມ່ນວິທີທີ່ສະແຕັກຂອງພວກເຮົາມີຄຳຕອບໃຫ້ກັບການເຂົ້າຊົມສ່ວນໃຫຍ່ຈາກ cache ກ່ອນທີ່ PHP ຫຼື MySQL ຈະຖືກຮຽກໃຊ້, ແລະ ສິ່ງນັ້ນມີຄວາມໝາຍແນວໃດຕໍ່ Core Web Vitals.
ຄໍາຮ້ອງຂໍທີ່ໄວທີ່ສຸດແມ່ນຄໍາຮ້ອງຂໍທີ່ບໍ່ເຄີຍຖືກດໍາເນີນການ
คำขอ WordPress ມາດຕະຖານແມ່ນມີລາຄາແພງ. ເວັບເຊີບເວີສົ່ງຕໍ່ໃຫ້ PHP, PHP ເປີດລະບົບ WordPress, ດຳເນີນການປລັກອິນ, ສອບຖາມ MySQL ຫຼາຍສິບຄັ້ງ, ປະກອບ HTML, ແລະ ຫຼັງຈາກນັ້ນຈຶ່ງສົ່ງໄບຕ໌ກັບຄືນ. ໃນເວັບໄຊທີ່ມີຜູ້ໃຊ້ງານຫຼາຍ ຂະບວນການທັງໝົດນັ້ນເກີດຂຶ້ນສຳລັບຜູ້ເຂົ້າຊົມທຸກໆຄົນ, ແລະ ນັ້ນແມ່ນຈຸດທີ່ເວລາໄປເຖິງໄບຕ໌ທຳອິດສ່ວນໃຫຍ່ຂອງທ່ານເສຍໄປ.
ຄຳຕອບຂອງພວກເຮົາແມ່ນການເຮັດໃຫ້ແນ່ໃຈວ່າ, ສຳລັບການເຂົ້າຊົມສ່ວນໃຫຍ່, ຈະບໍ່ມີຫຍັງເກີດຂຶ້ນເລີຍ. ໃນທົ່ວເວັບໄຊທີ່ພວກເຮົາໂຮສ — ຫຼາຍກວ່າ 100,000 ເວັບໄຊ PBN ລວມທັງ WordPress ຫຼັກທີ່ຈັດການແບບແມເນດ — ໜ້າເວັບຟຣອນເອັນສ່ວນຫຼາຍແມ່ນຖືກເສີບເປັນໜ້າເຕັມທີ່ສະແດງຜົນໄວ້ລ່ວງໜ້າຈາກແຄຊໂດຍກົງ, ໂດຍບໍ່ຕ້ອງຮຽກໃຊ້ PHP ຫຼື ເຂົ້າເຖິງຖານຂໍ້ມູນ. ສ່ວນທີ່ເຫຼືອຂອງໂພສນີ້ແມ່ນກ່ຽວກັບວິທີທີ່ເລເຢີຕ່າງໆ ທີ່ເຮັດໃຫ້ສິ່ງນັ້ນເປັນຈິງປະກອບເຂົ້າກັນ, ແລະ ແຕ່ລະເລເຢີມີຄວາມ ສຳຄັນຢູ່ຈຸດໃດ.
ຈຸດສຳຄັນທີ່ຕ້ອງເຂົ້າໃຈຄື ສິ່ງເຫຼົ່ານີ້ບໍ່ແມ່ນແຄຊ໌ທີ່ແຂ່ງຂັນກັນເພື່ອໃຫ້ທ່ານເລືອກຢ່າງໃດຢ່າງໜຶ່ງ. ແຄຊ໌ທັງໝົດໜ້າ (Full-page cache), ແຄຊ໌ວັດຖຸ (object cache) ແລະ CDN edge ແຕ່ລະສ່ວນຈະຈັດການກັບປະເພດຄຳຮ້ອງຂໍທີ່ແຕກຕ່າງກັນ, ແລະ ຄຸນຄ່າຂອງມັນແມ່ນຢູ່ທີ່ວິທີການສົ່ງຕໍ່ຂໍ້ມູນໃຫ້ກັນແລະກັນ.
LiteSpeed Enterprise + LSCache: ຊັ້ນຄຳວ່າໜ້າເວັບເຕັມ (full-page layer)
ທຸກໆເວັບໄຊແມ່ນເຮັດວຽກຢູ່ເທິງ LiteSpeed Enterprise ພ້ອມກັບ LSCache ລະດັບເຊີບເວີ. ເມື່ອການຕອບຮັບຈາກຟຣອນທ໌ເອັນເປັນສິ່ງທີ່ສາມາດແຄຊ໌ໄດ້, ເຊີບເວີເວັບຈະປະທັບຕາຄຳສັ່ງຄວບຄຸມການແຄຊ໌ ແລະ ເຮດເດີແທັກຂອງ LiteSpeed ໃສ່, ແລະ LiteSpeed ຈະໃຫ້ບໍລິການໜ້າເວັບທັງໝົດນັ້ນໂດຍກົງໃນການໂຫຼດຄັ້ງຕໍ່ໄປ — ໂດຍບໍ່ມີການສ້າງຂະບວນການ PHP ຂຶ້ນມາ ແລະ ບໍ່ມີການສົ່ງຄຳສັ່ງຄົ້ນຫາ MySQL ອອກໄປ. ນັ້ນຄືກົນໄກສຳຄັນທີ່ສຸດສຳລັບ WordPress TTFB, ເພາະວ່າມັນຊ່ວຍລຶບການໂຫຼດແອັບພລິເຄຊັນທັງໝົດອອກຈາກເສັ້ນທາງການເຮັດວຽກຫຼັກ.
ຍ້ອນວ່າ LSCache ເຮັດວຽກຢູ່ພາຍໃນເວັບເຊີເວີໂດຍຕົ່ງ ແທນທີ່ຈະຢູ່ໃນປັັກອິນ PHP, ມັນຈຶ່ງເລີ່ມຕົ້ນທຳງານໄດ້ໄວກວ່າໃນວົງຈອນຊີວິດຂອງຄຳຮ້ອງຂໍ ແລະ ຮັກສາໜ້າເວັບໄວ້ໃນຮູບແບບທີ່ເຊີເວີສາມາດລຶບໄດ້ຢ່າງທັນທີ. ລະບົບ Cache crawler ຈະຊ່ວຍໃຫ້ໜ້າເວັບທີ່ໄດ້ຮັບຄວາມນິຍົມມີຄວາມພ້ອມໃຊ້ງານຢູ່ສະເໝີ, ດັ່ງນັ້ນ ຜູ້ເຂົ້າຊົມຄົນທຳອິດຫຼັງຈາກການລ້າງຂໍ້ມູນ ຈຶ່ງບໍ່ແມ່ນຜູ້ທີ່ຕ້ອງລໍຖ້າການສ້າງໜ້າເວັບໃໝ່. ຜົນລຶບທີ່ໄດ້ຄືຄ່າ TTFB ທີ່ຕ່ຳກວ່າ ແລະ ມີຄວາມສະໝ່ຳສະເໝີກວ່າຢ່າງເຫັນໄດ້ຊັດ ເມື່ອທຽບກັບ cache ທີ່ມີພຽງປັັກອິນທີ່ຕິດຕັ້ງໃສ່ກັບສະແຕັກທົ່ວໄປ, ເຊິ່ງ cache ຍັງຄົງເຮັດວຽກຢູ່ເບື້ອງຫຼັງ PHP.
ປລັກອິນແຄຊລະດັບ repo ຂອງພວກເຮົາແມ່ນຖືກຕິດຕັ້ງໄວ້ລ່ວງໜ້າ ແລະ ອັບເດດອັດໂນມັດໃນທຸກໆເວັບໄຊ, ໂດຍເຊື່ອມຕໍ່ WordPress ໃສ່ LSCache ຢ່າງຖືກຕ້ອງຕັ້ງແຕ່ເລີ່ມຕົ້ນ. ຢູ່ໃນ origin ທີ່ບໍ່ແມ່ນ LiteSpeed ມັນຈະບໍ່ສົ່ງ full-page headers ແລະ ຫຼີກທາງໃຫ້, ໃນຂະນະທີ່ object cache ແລະ ກົດລະບຽບການຍົກເວັ້ນຍັງຄົງເຮັດວຽກຂອງມັນຕໍ່ໄປ — ດັ່ງນັ້ນ ເວັບໄຊທີ່ຖືກຍ້າຍມາຈະບໍ່ຖືກປ່ອຍໄວ້ໃນສະພາບທີ່ເສຍຫາຍ ຫຼື ຕັ້ງຄ່າໄວ້ພຽງເຄິ່ງດຽວ.
ຮັກສາຄວາມໄວໂດຍບໍ່ໃຫ້ໃຊ້ຂໍ້ມູນເກົ່າ: ESI ແລະ ການລຶບລ້າງຂໍ້ມູນເກົ່າອັດຕະໂນມັດອັດສະລິຍະ
ການແຄຊແບບເຕັມໜ້າເວັບແບບຮຸກຮານມີຈຸດຜິດພາດຄລາສສິກສອງຢ່າງຄື: ການສະແດງໜ້າເວັບຂອງຜູ້ອື່ນໃຫ້ຜູ້ໃຊ້ທີ່ເຂົ້າສູ່ລະບົບແລ້ວ ແລະ ການສະແດງໜ້າເວັບທີ່ຄວນຈະມີການປ່ຽນແປງໃຫ້ກັບທຸກຄົນ. ທັງສອງຢ່າງນີ້ຖືກແກ້ໄຂຢູ່ຊັ້ນການແຄຊ ແທນທີ່ຈະເປັນການຫຼຸດຜ່ອນການແຄຊ.
ESI (Edge Side Includes) ຊ່ວຍໃຫ້ພວກເຮົາສາມາດເຮັດ cache ໜ້າເວັບໄດ້ ໃນຂະນະທີ່ເຈາະລູກຫຼົ່ນໄວ້ສຳລັບສ່ວນທີ່ຕ້ອງອັບເດດຢູ່ຕະຫຼອດ. ໃນຮ້ານຄ້າ WooCommerce, ໜ້າແຄັດຕາລັອກ, ໜ້າສິນຄ້າ ແລະ ໜ້າໝວດໝູ່ແມ່ນຖືກເສີບເປັນ full-page cache ເພື່ອໃຫ້ໄດ້ TTFB ທີ່ໄວທີ່ສຸດ, ໃນຂະນະທີ່ ESI ຈະປະມວນຜົນສ່ວນຂອງຕາຕະລ່າ, ຍອດລວມໃນ mini-cart ແລະ ສະຖານະບັນຊີຕາມການຮ້ອງຂໍ. ໜ້າ Cart, checkout, my-account ແລະ ໜ້າ nonce ຫຼື session ໃດໜຶ່ງຈະຖືກຍົກເວັ້ນໄວ້ໂດຍເລີ່ມຕົ້ນ. ຜູ້ຊື້ຈະເຫັນກະຕ່າສິນຄ້າຂອງຕົນເອງ ແລະ ໜ້າ ຊຳລະເງິນທີ່ໃຊ້ງານໄດ້ຢູ່ສະເໝີ; ໃນຂະນະທີ່ທຸກຄົນຍັງໄດ້ຮັບໜ້າຮ້ານຈາກ cache.
ຄວາມສົດໃໝ່ຂອງຂໍ້ມູນແມ່ນຖືກຈັດການໂດຍລະບົບລ້າງແຄຊອັດຕະໂນມັດອັດສະລິຍະ. Purge hooks ຈະທຳງານໂດຍອັດຕະໂນມັດເມື່ອເນື້ອຫາ, ສິນຄ້າ, ລາຄາ ຫຼື ຄຳສັ່ງຊື້ມີການປ່ຽນແປງ, ດັ່ງນັ້ນ ໜ້າເວັບທີ່ຖືກບັນທຶກໄວ້ໃນແຄຊທີ່ກ່ຽວຂ້ອງຈະອັບເດດທັນທີໂດຍບໍ່ຕ້ອງຖໍ້າຕາມເວລາທີ່ຕັ້ງໄວ້, ແລະ ທ່ານຍັງສາມາດສັ່ງລ້າງແຄຊຕາມຕ້ອງການໄດ້ຈາກແຜງຄວບຄຸມ ຫຼື ຈາກພາຍໃນ WordPress. ການລ້າງແຄຊຕາມແທັກ (Tag-based purging) ໝາຍຄວາມວ່າການແກ້ໄຂໂພສດຽວຈະລ້າງແຄຊສະເພາະໂພສນັ້ນແລະຄັງເກັບຂອງມັນ — ບໍ່ແມ່ນແຄຊທັງໝົດຂອງເວັບໄຊ — ດັ່ງນັ້ນການແກ້ໄຂພຽງຈຸດດຽວຈະບໍ່ສົ່ງຜົນໃຫ້ເວັບໄຊທັງໝົດຕ້ອງເລີ່ມຕົ້ນໂຫຼດໃໝ່ຢ່າງຊ້າໆ.
Redis object cache ສ່ວນຕົວຕໍ່ເວັບໄຊ: ສໍາລັບສິ່ງທີ່ບໍ່ສາມາດເປັນໜ້າເວັບເຕັມຮູບແບບໄດ້
ບໍ່ແມ່ນທຸກໆ ຄຳຮ້ອງຂໍທີ່ຈະສາມາດເປັນ ໜ້າເວັບແບບ ສະແຕຕິກ ໄດ້ທັງໝົດ. ເຊສຊັນທີ່ເຂົ້າສູ່ລະບົບແລ້ວ, ສ່ວນຜູ້ດູແລລະບົບ WordPress, ກະຕ່າສິນຄ້າ WooCommerce, ການຄົ້ນຫາ, ແລະ ສ່ວນປະກອບແບບ ໄດນາມິກ ທີ່ ESI ເຫຼືອໄວ້ ທັງໝົດແມ່ນຕ້ອງໄດ້ຮັນ PHP. ສຳລັບສິ່ງເຫຼົ່ານັ້ນ, ເປົ້າໝາຍຈະປ່ຽນຈາກ 'ຂ້າມແອັບພລິເຄຊັນ' ໄປເປັນ 'ຂ້າມຖານຂໍ້ມູນ'.
ເວັບໄຊແຕ່ລະເວັບຈະໄດ້ຮັບ dedicated Redis object cache ຂອງຕົນເອງ. WordPress ຈະເກັບຂໍ້ມູນຜົນການອ່ານຖານຂໍ້ມູນທີ່ຖືກເຮັດຊ້ຳໆ ເຊັ່ນ options, transients, ການຄົ້ນຫາ post ແລະ term, ລວມທັງຂໍ້ມູນສິນຄ້າ ແລະ session ຂອງ WooCommerce ໄວ້ໃນຫນ່ວຍຄວາມຈຳ, ເຮັດໃຫ້ບໍ່ຈຳເປັນຕ້ອງປະຕິບັດການຄຳຖາມ (query) ດຽວກັນນັ້ນໃສ່ MySQL ໃນທຸກໆການເຂົ້າຊົມ. ຜົນກະທົບດັ່ງກ່າວຈະເຫັນໄດ້ຊັດເຈນທີ່ສຸດໃນຈຸດທີ່ full-page cache ບໍ່ສາມາດຊ່ວຍໄດ້: ເຮັດໃຫ້ dashboards ໄວຂຶ້ນ, carts ໄວຂຶ້ນ, ແລະ ຫຼຸດຜ່ອນພາລະຂອງຖານຂໍ້ມູນລົງຢ່າງຫຼວງຫຼາຍພາຍໃຕ້ການສັນຈອນທີ່ມີການໃຊ້ງານສູງ.
ແຄຊ໌ວັດຖຸແມ່ນເປັນແບບແຍກຕາມແຕ່ລະເວັບໄຊ, ບໍ່ໄດ້ໃຊ້ຮ່ວມກັນ, ເຊິ່ງມີຄວາມສໍາຄັນທັງໃນດ້ານປະສິດທິພາບ ແລະ ການແຍກສ່ວນ. ເມື່ອລວມກັບການຈໍາກັດຄວາມໄວຖານຂໍ້ມູນແບບແຍກຕາມແຕ່ລະເວັບໄຊ, ຄໍາສັ່ງສອບຖາມທີ່ໜັກ ຫຼື ຂຽນບໍ່ດີຂອງເວັບໄຊໜຶ່ງ ຈະບໍ່ສາມາດແຍ່ງຊັບພະຍາກອນຖານຂໍ້ມູນຈາກເວັບໄຊອື່ນໆ ທີ່ຢູ່ໃກ້ກ່ຽອງໄດ້. ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບວິທີທີ່ການຕັ້ງຄ່າຫຼາຍຊັ້ນທັງໝົດນີ້ເຮັດວຽກຮ່ວມກັນໄດ້ຢູ່ທີ່ໜ້າຄຸນສົມບັດການເຮັດແຄຊ໌ຂອງພວກເຮົາ, ແລະ ກ່ຽວກັບຂອບເຂດລະຫວ່າງຜູ້ໃຊ້ງານພາຍໃຕ້ການແຍກສ່ວນ.
ຂອບ ແລະ ການຂົນສົ່ງທີ່ຢູ່ລຸ່ມສຸດ
ແຄຊທີ່ຢູ່ໃນເຊີເວີຕົ້ນທາງຍັງຕ້ອງໄດ້ຜ່ານເຄືອຂ່າຍ. ຂອບ CDN ຈະຢູ່ທາງໜ້າຂອງເຊີເວີ, ດັ່ງນັ້ນຊັບພະຍາກອນຄົງທີ່ ແລະ ໜ້າເວັບທີ່ສາມາດເຮັດແຄຊໄດ້ຈະຖືກເສີບຈາກຈຸດໃຫ້ບໍລິການທີ່ຢູ່ໃກ້ກັບຜູ້ເຂົ້າຊົມ, ແລະ ເຊີເວີຕົ້ນທາງຈະເຮັດວຽກຢ່າງງຽບໆແມ້ຈະມີການໂຫຼດຫຼາຍກໍຕາມ. ສຳລັບໂຮສຕິ້ງສາຍ Footprint-Free ຂອງພວກເຮົາ, ຂອບດັ່ງກ່າວຈະເປັນກຸ່ມ Multi-CDN ທີ່ກະຈາຍຢູ່ຫຼາຍຜູ້ໃຫ້ບໍລິການ, ຢ່າງທີ່ຕອບໂຈດທັງເປົ້າໝາຍ footprint ແລະ ປະສິດທິພາບ; ຢູ່ໃນ WordPress ທົ່ວໄປ, ມັນເປັນພຽງຊັ້ນທີ່ໄວ ແລະ ມີປະສິດທິພາບດີ ເຊິ່ງຊ່ວຍໃຫ້ເຊີເວີຕົ້ນທາງວ່າງ.
ພາຍໃຕ້ພື້ນຖານເຫຼົ່ານັ້ນ ບໍ່ມີການຫຼຸດຜ່ອນຄຸນນະພາບ. ເວັບໄຊຕ໌ເຮັດວຽກເທິງບ່ອນຈັດເກັບຂໍ້ມູນ NVMe ພ້ອມດ້ວຍ HTTP/3, ດັ່ງນັ້ນຂໍ້ມູນທີ່ແຄຊ (cache) ສົ່ງໄປຈຶ່ງມາຮອດຜ່ານລະບົບການຂົນສົ່ງແບບສະໄໝໝ່ທີ່ມີການສົ່ງຫຼາຍຊ່ອງທາງ ພ້ອມກັບບ່ອນຈັດເກັບຂໍ້ມູນທີ່ວ່ອງໄວໃນກໍລະນີທີ່ແຄຊ (cache) ບໍ່ພົບຂໍ້ມູນ. ບໍ່ມີຊັ້ນໃດເຫຼົ່ານີ້ທີ່ເປັນສ່ວນເສີມ: LiteSpeed, LSCache, Redis ຕໍ່ເວັບໄຊ, NVMe ແລະ HTTP/3 ແມ່ນພື້ນຖານໃນທຸກແພັກເກັດ, ບໍ່ແມ່ນຊັ້ນສຳລັບການຂາຍເພີ່ມ.
ສິ່ງທີ່ຂັບເຄື່ອນ Core Web Vitals ແທ້ໆ
ມັນຄຸ້ມຄ່າທີ່ຈະເຮັດໃຫ້ມີຄວາມຊັດເຈນ, ເພາະວ່າໂຮສຕິ້ງມັກຈະຖືກໂຄສະນາເກີນຈິງໃນເລື່ອງ Core Web Vitals. TTFB ແມ່ນສ່ວນໜຶ່ງຂອງສົມຜົນທີ່ເຊີເວີເປັນເຈົ້າຂອງ, ແລະ ສະແຕັກການທຳແຄຊທີ່ຢູ່ເທິງນັ້ນແມ່ນສິ່ງທີ່ຊ່ວຍຫຼຸດມັນລົງ — ໜ້າເວັບເຕັມທີ່ຖືກທຳແຄຊໄວ້ເຊິ່ງຖືກເສີບຜ່ານ HTTP/3 ຈາກ edge ແມ່ນຢູ່ໃນລະດັບທີ່ຕ່ຳທີ່ສຸດເທົ່າທີ່ TTFB ຈະເປັນໄປໄດ້. ເນື່ອງຈາກ TTFB ແມ່ນສ່ວນເລີ່ມຕົ້ນຂອງ Largest Contentful Paint, origin ທີ່ໄວຈຶ່ງເຮັດໃຫ້ທຸກໆ ເມຕຣິກປາຍນ້ຳມີຈຸດເລີ່ມຕົ້ນທີ່ດີກວ່າ ເຊິ່ງບໍ່ສາມາດມີໄດ້ດ້ວຍວິທີອື່ນ.
ແຕ່ LCP, CLS ແລະ INP ສ່ວນໃຫຍ່ແມ່ນຖືກກຳນົດຢູ່ໃນບຣາວເຊີ, ໂດຍຕົວໜ້າເວັບເອງ: ຮູບພາບທີ່ບໍ່ໄດ້ຮັບການປັບໃຫ້ເໝາະສົມ, CSS ແລະ JavaScript ທີ່ຂັດຂວາງການສະແດງຜົນ, ໂຄງຮ່າງໜ້າເວັບທີ່ປ່ຽນແປງເມື່ອຟອນ ແລະ ໂຄສະນາໂຫຼດ, ແລະ ການເຮັດວຽກຂອງເມນທຣຽດ (main-thread) ທີ່ໜັກໜ່ວງຈາກປລັກອິນ. ການເກັບແຄຊ໌ຝັ່ງເຊີເວີຫຼາຍປານໃດກໍ່ບໍ່ສາມາດແກ້ໄຂຮູບພາບຂະໜາດ 2 MB ຫຼື ຮູບແບບເວັບໄຊທີ່ມີ JavaScript ຂະໜາດຫຼາຍເມກາໄບຕ໌ໄດ້. ໂຮດຕິ້ງທີ່ຈິງໃຈເຮັດໃຫ້ສ່ວນຮ່ວມຂອງເຊີເວີສາມາດໃຊ້ງານໄດ້ຟຣີ ແລະ ມີຄວາມສະຖຽນຢ່າງແທ້ຈິງ, ຫຼັງຈາກນັ້ນມັນແມ່ນໜ້າທີ່ຂອງເວັບໄຊທີ່ຈະຮັກສາສ່ວນໜ້າ (front end) ໃຫ້ກະທັດຮັດ.
ການແບ່ງງານແບບນັ້ນແມ່ນຮູບແບບຄວາມຄິດທີ່ມີປະໂຫຍດ. ພວກເຮົົາຮັບປະກັນວ່າຄຳຮ້ອງຂໍຈະໄປເຖິງບຣາວເຊີຢ່າງໄວວາ ແລະ ຮັກສາຄວາມໄວໄວ້ໄດ້ແມ້ຈະມີທຣາຟິກຫຼາຍ; ທ່ານພຽງແຕ່ຮັກສາຂະໜາດຂໍ້ມູນໃຫ້ໜ້ອຍ ແລະ ສະໝ່ຳສະເໝີ. ຈຸດທີ່ທັງສອງມາພົບກັນ — ການອຸ່ນແຄຊ (cache warm-up), ການສົ່ງຂໍ້ມູນຜ່ານ edge, ແລະ ການຮັກສາຖານຂໍ້ມູນໃຫ້ຕອບສະໜອງໄດ້ດີເພື່ອບໍ່ໃຫ້ໜ້າເວັບແບບໄດນາມິກຊ້າ — ແມ່ນຈຸດທີ່ລະບົບຂອງພວກເຮົາຖືກປັບແຕ່ງມາໂດຍສະເພາະ, ແລະ ມັນແມ່ນສິ່ງທີ່ເຮັດໃຫ້ການຈັດການ WordPress ຢູ່ເທິງແພລດຟອມນີ້ໄວກວ່າເວັບໄຊດຽວກັນທີ່ຢູ່ເທິງໂຮສຕິງທົ່ວໄປ.
ຄຳຖາມທີ່ຖາມເລື້ອຍໆ
ຂ້ອຍຍັງຈຳເປັນຕ້ອງໃຊ້ປລັກອິນແຄຊິ່ງເຊັ່ນ WP Rocket ຢູ່ບໍ?
ບໍ່. ການທໍາ ແຄຊ໌ ທັງໜ້າເວັບ ແມ່ນຖືກຈັດການຢູ່ທີ່ ເວັບເຊີເວີ ໂດຍ LSCache ຂອງ LiteSpeed, ແລະ ປລັກອິນແຄຊ໌ ຂອງພວກເຮົາເອງ — ທີ່ຖືກຕິດຕັ້ງໄວ້ລ່ວງໜ້າ ແລະ ອັບເດດອັດຕະໂນມັດ — ຈະເຊື່ອມຕໍ່ WordPress ເຂົ້າກັບມັນຢ່າງຖືກຕ້ອງ, ໂດຍມີ ເວັບໄຊທ໌ Redis ວັດຖຸແຄຊ໌ ຢູ່ເບື້ອງຫຼັງ. ການຊ້ອນ ປລັກອິນແຄຊ໌ ທັງໜ້າເວັບ ອັນທີສອງ ເພີ່ມເຂົ້າໄປ ອາດຈະຂັດກັນກັບ ແຄຊ໌ ໃນລະດັບເຊີເວີ ຫຼາຍກວ່າທີ່ຈະຊ່ວຍ, ດັ່ງນັ້ນ ມັນຈຶ່ງບໍ່ຈໍາເປັນ ແລະ ບໍ່ແນະນໍາ.
ການເກັບຄຳສຳຮອງ (Caching) ຈະເຮັດໃຫ້ກະຕ່າສິນຄ້າ WooCommerce ຫຼື ໜ້າເຂົ້າສູ່ລະບົບຂອງຂ້ອຍເສຍຫາຍບໍ?
ບໍ່. ໜ້າ Cart, checkout, my-account ແລະ ໜ້າ nonce ຫຼື session ໃດໜຶ່ງຈະຖືກຍົກເວັ້ນຈາກແຄຊ໌ໂດຍຄ່າເລີ່ມຕົ້ນ, ແລະ ESI ຈະຮັກສາສ່ວນຂອງກະຕ່າ ແລະ ຍອດລວມໃຫ້ເປັນປັດຈຸບັນຢູ່ໃນໜ້າອື່ນໆທີ່ຖືກແຄຊ໌ໄວ້. ຜູ້ຊື້ຈະເຫັນກະຕ່າຂອງຕົນເອງ ແລະ ຫນ້າ checkout ທີ່ໃຊ້ງານໄດ້ສະເໝີ ໃນຂະນະທີ່ໜ້າຮ້ານຄ້າຮັກສາການໂຫຼດຈາກແຄຊ໌.
cache ຈະຄົງຄວາມສົດໃໝ່ໄດ້ແນວໃດ ເມື່ອຂ້ອຍເຜີຍແຜ່ ຫຼື ແກ້ໄຂ?
ລະບົບລ້າງແຄຊແບບອັດສະລິຍະອັດຕະໂນມັດເຮັດວຽກໃນ hook ທີ່ກ່ຽວຂ້ອງຂອງ WordPress ດັ່ງນັ້ນການເຜີຍແຜ່, ການແກ້ໄຂເນື້ອຫາ, ຫຼືການປ່ຽນແປງຜະລິດຕະພັນ, ລາຄາ ຫຼື ຄຳສັ່ງຊື້ຈຶ່ງລ້າງສະເພາະໜ້າທີ່ໄດ້ຮັບຜົນກະທົບ ແລະ ບ່ອນເກັບຂໍ້ມູນຂອງໜ້ານັ້ນໆ — ບໍ່ແມ່ນແຄຊທັງໝົດ — ແລະ ຕົວ crawlers ຈະໂຫຼດໜ້າເຫຼົ່ານັ້ນຄືນໃໝ່. ນອກຈາກນີ້ ທ່ານຍັງສາມາດລ້າງແຄຊຕາມຄວາມຕ້ອງການໄດ້ຈາກໜ້າຄວບຄຸມ ຫຼື ຈາກພາຍໃນ WordPress.
ການໂຮສຕ໌ຢ່າງດຽວສາມາດໃຫ້ຂ້ອຍມີ Core Web Vitals ທີ່ສົມບູນແບບໄດ້ບໍ?
ມັນໃຫ້ TTFB ທີ່ດີທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້, ວິທີນີ້ແມ່ນສ່ວນຂອງເຊີເວີ ແລະ ເປັນການເລີ່ມຕົ້ນທີ່ດີສຳລັບ Largest Contentful Paint. ແຕ່ LCP, CLS ແລະ INP ແມ່ນຂຶ້ນກັບຕົວໜ້າເວັບເອງເປັນສ່ວນໃຫຍ່ — ເຊັ່ນ ຂະໜາດຮູບພາບ, ຊັບພະຍາກອນທີ່ບລັອກການສະແດງຜົນ, ຄວາມສະໝ່ຳສະເໝີຂອງເລເອົາ ແລະ JavaScript ໃນ main-thread. ລະບົບຂອງພວກເຮົາເຮັດໃຫ້ສ່ວນຂອງເຊີເວີມີຄວາມໄວ ແລະ ສະໝ່ຳສະເໝີ; ການຮັກສາ payload ຂອງ front-end ໃຫ້ມີຂະໜາດນ້ອຍແມ່ນສິ່ງທີ່ຊ່ວຍປິດຊ່ອງຫວ່າງສ່ວນທີ່ເຫຼືອ.
ກ່ຽວຂ້ອງ
ທົດລອງໃຊ້ຟຣີ 14 ວັນ
ເປີດໃຊ້ງານເວັບໄຊທ໌ທຳອິດຂອງທ່ານຟຣີເປັນເວລາ 14 ວັນ — ບໍ່ຕ້ອງໃຊ້ບັດ. ຍ້າຍເຄືອຂ່າຍທີ່ມີຢູ່ແລ້ວບໍ? ທ່ານສາມາດຍ້າຍຂໍ້ມູນຄັ້ງທຳອິດໄດ້ຟຣີ.
ເລີ່ມຕົ້ນຟຣີ