ຕົນເອງເປັນເຈົ້າພາບຊັບພະຍາກອນຂອງພາກສ່ວນທີສາມ: ດີ, ບໍ່ດີ, ugly

ໃນຊຸມປີມໍ່ໆມານີ້, ແພລະຕະຟອມຫຼາຍຂື້ນສໍາລັບການເພີ່ມປະສິດທິພາບໂຄງການດ້ານຫນ້າສະເຫນີໂອກາດສໍາລັບການໂຮດຕົວເອງຫຼືຕົວແທນຊັບພະຍາກອນຂອງພາກສ່ວນທີສາມ. Akamai ອະນຸຍາດໃຫ້ທ່ານຕັ້ງ ຕົວກໍານົດການສະເພາະ ສໍາລັບ URL ທີ່ຜະລິດເອງ. Cloudflare ມີເທກໂນໂລຍີ Edge Workers. Fasterzine ສາມາດເຮັດໄດ້ ຂຽນໃໝ່ URLs ໃນຫນ້າຕ່າງໆເພື່ອໃຫ້ພວກເຂົາຊີ້ໃຫ້ເຫັນຊັບພະຍາກອນຂອງພາກສ່ວນທີສາມທີ່ຕັ້ງຢູ່ໃນໂດເມນຕົ້ນຕໍຂອງເວັບໄຊທ໌.

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

ດີ: ປັບປຸງປະສິດທິພາບ

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

ຊັບພະຍາກອນພາກສ່ວນທີສາມຖືກດາວໂຫຼດຈາກແຫຼ່ງພາຍນອກ (ເອົາມາຈາກ ຈາກນີ້)

ຊັບພະຍາກອນຂອງພາກສ່ວນທີສາມຖືກເກັບໄວ້ໃນສະຖານທີ່ດຽວກັນກັບສ່ວນທີ່ເຫຼືອຂອງອຸປະກອນການສະຖານທີ່ (ເອົາມາຈາກ ຈາກນີ້)

ສະຖານະການຍັງຖືກປັບປຸງໂດຍຄວາມຈິງທີ່ວ່າຕົວທ່ອງເວັບຈະໃຊ້ຄວາມສາມາດໃນການ multiplex ແລະຈັດລໍາດັບຄວາມສໍາຄັນຂອງຂໍ້ມູນຈາກການເຊື່ອມຕໍ່ HTTP / 2 ທີ່ໄດ້ສ້າງຕັ້ງຂຶ້ນແລ້ວກັບໂດເມນຕົ້ນຕໍ.

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

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

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

• ທ່ານສາມາດຮັບປະກັນວ່າວິທີການບີບອັດຂໍ້ມູນທີ່ເຫມາະສົມກັບແຕ່ລະຕົວທ່ອງເວັບແມ່ນຖືກນໍາໃຊ້ (Brotli/gzip).
• ທ່ານສາມາດເພີ່ມເວລາແຄດສໍາລັບຊັບພະຍາກອນທີ່ປົກກະຕິແລ້ວບໍ່ດົນໂດຍສະເພາະ, ເຖິງແມ່ນວ່າຜູ້ໃຫ້ບໍລິການທີ່ມີຊື່ສຽງຫຼາຍທີ່ສຸດ (ຕົວຢ່າງ, ມູນຄ່າທີ່ສອດຄ້ອງກັນສໍາລັບແທໍກ GA ຖືກກໍານົດເປັນ 30 ນາທີ).

ທ່ານຍັງສາມາດຂະຫຍາຍ TTL ສໍາລັບຊັບພະຍາກອນທີ່ຈະ, ເວົ້າ, ປີໂດຍການລວມເອົາເນື້ອຫາທີ່ກ່ຽວຂ້ອງເຂົ້າໄປໃນຍຸດທະສາດການຈັດການຖານຄວາມຈໍາຂອງທ່ານ (URL hashes, versioning, ແລະອື່ນໆ). ພວກເຮົາຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້ຂ້າງລຸ່ມນີ້.

▍ ການປ້ອງກັນການຂັດຂວາງໃນການດໍາເນີນງານຂອງການບໍລິການພາກສ່ວນທີສາມຫຼືການປິດຂອງພວກເຂົາ

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

ເພື່ອຊອກຫາວິທີການເຮັດວຽກຂອງເວັບໄຊທ໌ຂອງທ່ານເມື່ອການບໍລິການພາຍນອກບາງອັນບໍ່ສາມາດໃຊ້ໄດ້, ທ່ານສາມາດນໍາໃຊ້ SPOF ພາກ webpagetest.org.

ພາກສ່ວນ SPOF ໃນ webpagetest.org

▍ ແມ່ນຫຍັງກ່ຽວກັບບັນຫາໃນການເກັບຂໍ້ມູນໃນຕົວທ່ອງເວັບ? (ຄໍາ​ແນະ​ນໍາ​: ມັນ​ເປັນ myth​)

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

ໃຫ້ເວົ້າວ່າພວກເຮົາມີເວັບໄຊທ໌ທີ່ແຕກຕ່າງກັນຫຼາຍ: website1.com, website2.com, website3.com. ເວັບໄຊທ໌ທັງຫມົດເຫຼົ່ານີ້ໃຊ້ຫ້ອງສະຫມຸດ jQuery. ພວກເຮົາເຊື່ອມຕໍ່ມັນກັບພວກເຂົາໂດຍໃຊ້ CDN, ຕົວຢ່າງ - googleapis.com . ທ່ານສາມາດຄາດຫວັງວ່າຕົວທ່ອງເວັບຈະດາວໂຫລດແລະ cache ຫ້ອງສະຫມຸດຫນຶ່ງຄັ້ງ, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ມັນໃນທົ່ວສາມເວັບໄຊທ໌. ນີ້ສາມາດຫຼຸດຜ່ອນການໂຫຼດໃນເຄືອຂ່າຍ. ບາງທີນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດປະຫຍັດເງິນຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງແລະຊ່ວຍປັບປຸງປະສິດທິພາບຂອງຊັບພະຍາກອນ. ຈາກທັດສະນະຂອງການປະຕິບັດ, ທຸກສິ່ງທຸກຢ່າງເບິ່ງແຕກຕ່າງກັນ. ຕົວຢ່າງ, Safari ມີຄຸນສົມບັດທີ່ເອີ້ນວ່າ ການປ້ອງກັນການຕິດຕາມທີ່ສະຫຼາດ: cache ໃຊ້ປຸ່ມສອງໂດຍອີງໃສ່ແຫຼ່ງຂອງເອກະສານແລະແຫຼ່ງຂອງຊັບພະຍາກອນພາກສ່ວນທີສາມ. ທີ່ນີ້ ບົດຄວາມທີ່ດີກ່ຽວກັບຫົວຂໍ້ນີ້.

ການສຶກສາເກົ່າ Yahoo и ເຟສບຸກ, ເຊັ່ນດຽວກັນກັບທີ່ຜ່ານມາຫຼາຍ ການສຶກສາ Paul Calvano, ສະແດງໃຫ້ເຫັນວ່າຊັບພະຍາກອນບໍ່ໄດ້ເກັບຮັກສາໄວ້ໃນຖານຄວາມຈໍາຂອງຕົວທ່ອງເວັບເປັນເວລາດົນເທົ່າທີ່ພວກເຮົາອາດຈະຄາດຫວັງວ່າ: "ມີຊ່ອງຫວ່າງທີ່ຮ້າຍແຮງລະຫວ່າງເວລາເກັບຂໍ້ມູນຂອງໂຄງການຂອງຕົນເອງແລະຊັບພະຍາກອນຂອງພາກສ່ວນທີສາມ. ພວກເຮົາເວົ້າກ່ຽວກັບ CSS ແລະຕົວອັກສອນເວັບ. ຄື, 95% ຂອງຕົວອັກສອນພື້ນເມືອງມີ cache ຫຼາຍກວ່າຫນຶ່ງອາທິດ, ໃນຂະນະທີ່ 50% ຂອງຕົວອັກສອນພາກສ່ວນທີສາມມີ cache ຫນ້ອຍກວ່າຫນຶ່ງອາທິດ! ນີ້ເຮັດໃຫ້ຜູ້ພັດທະນາເວັບມີເຫດຜົນທີ່ຫນ້າສົນໃຈທີ່ຈະເປັນເຈົ້າພາບໄຟລ໌ຕົວອັກສອນດ້ວຍຕົນເອງ!”

ດັ່ງນັ້ນ, ຖ້າທ່ານເປັນເຈົ້າພາບເນື້ອຫາຂອງຄົນອື່ນ, ທ່ານຈະບໍ່ສັງເກດເຫັນບັນຫາການປະຕິບັດໃດໆທີ່ເກີດຈາກການເກັບຂໍ້ມູນຂອງຕົວທ່ອງເວັບ.

ໃນປັດຈຸບັນທີ່ພວກເຮົາໄດ້ກວມເອົາຈຸດແຂງຂອງການເປັນເຈົ້າພາບຂອງບຸກຄົນທີສາມ, ໃຫ້ພວກເຮົາສົນທະນາກ່ຽວກັບວິທີການບອກການປະຕິບັດທີ່ດີຂອງວິທີການນີ້ຈາກທີ່ບໍ່ດີ.

ບໍ່ດີ: ມານແມ່ນຢູ່ໃນລາຍລະອຽດ

ການເຄື່ອນຍ້າຍຊັບພະຍາກອນຂອງພາກສ່ວນທີສາມໄປຫາໂດເມນຂອງທ່ານເອງບໍ່ສາມາດເຮັດໄດ້ໂດຍອັດຕະໂນມັດໂດຍບໍ່ມີການຮັບປະກັນວ່າຊັບພະຍາກອນດັ່ງກ່າວຖືກເກັບໄວ້ຢ່າງຖືກຕ້ອງ.

ຫນຶ່ງໃນບັນຫາຕົ້ນຕໍຢູ່ທີ່ນີ້ແມ່ນເວລາເກັບຂໍ້ມູນ. ຕົວຢ່າງ, ຂໍ້ມູນສະບັບແມ່ນລວມຢູ່ໃນຊື່ສະຄຣິບພາກສ່ວນທີສາມເຊັ່ນນີ້: jquery-3.4.1.js. ໄຟລ໌ດັ່ງກ່າວຈະບໍ່ປ່ຽນແປງໃນອະນາຄົດ, ແລະດັ່ງນັ້ນ, ນີ້ຈະບໍ່ເຮັດໃຫ້ເກີດບັນຫາໃດໆກັບຖານຄວາມຈໍາຂອງມັນ.

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

ແທ້ຈິງແລ້ວ, ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບອຸປະກອນທີ່ຖືກປັບປຸງເລື້ອຍໆ (ຜູ້ຈັດການແທັກ, ວິທີແກ້ໄຂສໍາລັບການທົດສອບ A / B), ຫຼັງຈາກນັ້ນການເກັບຮັກສາພວກມັນໂດຍໃຊ້ເຄື່ອງມື CDN ແມ່ນວຽກງານທີ່ສາມາດແກ້ໄຂໄດ້, ແຕ່ມີຄວາມຊັບຊ້ອນຫຼາຍ. ການບໍລິການເຊັ່ນ: Commanders Act, ການແກ້ໄຂການຈັດການແທັກ, ໃຊ້ webhooks ເມື່ອເຜີຍແຜ່ສະບັບໃຫມ່. ນີ້ເຮັດໃຫ້ເຈົ້າສາມາດບັງຄັບ cache flush ໃນ CDN, ຫຼືດີກວ່າ, ຄວາມສາມາດໃນການບັງຄັບໃຫ້ມີການອັບເດດ hash ຫຼື URL.

▍ ການຈັດສົ່ງວັດສະດຸໃຫ້ລູກຄ້າແບບປັບຕົວໄດ້

ນອກຈາກນັ້ນ, ເມື່ອພວກເຮົາສົນທະນາກ່ຽວກັບຖານຄວາມຈໍາ, ພວກເຮົາຈໍາເປັນຕ້ອງຄໍານຶງເຖິງຄວາມຈິງທີ່ວ່າການຕັ້ງຄ່າຖານຄວາມຈໍາທີ່ໃຊ້ໃນ CDN ອາດຈະບໍ່ເຫມາະສົມສໍາລັບບາງຊັບພະຍາກອນຂອງພາກສ່ວນທີສາມ. ຕົວຢ່າງ, ຊັບພະຍາກອນດັ່ງກ່າວອາດຈະໃຊ້ເທກໂນໂລຍີ sniffing (adaptive serving) ຕົວແທນຜູ້ໃຊ້ເພື່ອຮັບໃຊ້ຕົວທ່ອງເວັບສະເພາະທີ່ມີສະບັບຂອງເນື້ອຫາທີ່ເຫມາະສົມໂດຍສະເພາະສໍາລັບຕົວທ່ອງເວັບເຫຼົ່ານັ້ນ. ເຕັກໂນໂລຢີເຫຼົ່ານີ້ອີງໃສ່ການສະແດງອອກເປັນປົກກະຕິ, ຫຼືຖານຂໍ້ມູນຂອງຂໍ້ມູນສ່ວນຫົວ HTTP, ເພື່ອຄິດໄລ່ຄວາມສາມາດຂອງຕົວທ່ອງເວັບ. User-Agent. ເມື່ອພວກເຂົາຮູ້ວ່າຕົວທ່ອງເວັບໃດທີ່ພວກເຂົາກໍາລັງຈັດການກັບ, ພວກເຂົາໃຫ້ອຸປະກອນທີ່ຖືກອອກແບບມາສໍາລັບມັນ.

ໃນທີ່ນີ້ທ່ານສາມາດຈື່ສອງການບໍລິການ. ອັນທໍາອິດແມ່ນ googlefonts.com. ອັນທີສອງແມ່ນ polyfill.io. ບໍລິການ Google Fonts ໃຫ້, ສໍາລັບຊັບພະຍາກອນທີ່ແນ່ນອນ, ລະຫັດ CSS ຕ່າງໆ, ຂຶ້ນກັບຄວາມສາມາດຂອງຕົວທ່ອງເວັບ (ການໃຫ້ການເຊື່ອມຕໍ່ກັບຊັບພະຍາກອນ woff2 ໂດຍໃຊ້. unicode-range).

ນີ້ແມ່ນຜົນໄດ້ຮັບຂອງສອງສາມຄໍາຖາມ Google Fonts ທີ່ເຮັດຈາກຕົວທ່ອງເວັບທີ່ແຕກຕ່າງກັນ.

ຜົນການຄົ້ນຫາຂອງ Google Fonts ຈາກ Chrome

ຜົນການຄົ້ນຫາຂອງ Google Fonts ດໍາເນີນການຈາກ IE10

Polyfill.io ໃຫ້ຕົວທ່ອງເວັບພຽງແຕ່ polyfills ທີ່ມັນຕ້ອງການ. ນີ້ແມ່ນເຮັດສໍາລັບເຫດຜົນການປະຕິບັດ.

ຕົວຢ່າງ, ໃຫ້ພິຈາລະນາສິ່ງທີ່ຈະເກີດຂື້ນຖ້າທ່ານດໍາເນີນການຮ້ອງຂໍຕໍ່ໄປນີ້ຈາກຕົວທ່ອງເວັບທີ່ແຕກຕ່າງກັນ: https://polyfill.io/v3/polyfill.js?features=default

ໃນການຕອບສະຫນອງຕໍ່ການຮ້ອງຂໍດັ່ງກ່າວປະຕິບັດຈາກ IE10, 34 KB ຂອງຂໍ້ມູນຈະໄດ້ຮັບ. ແລະຄໍາຕອບກັບມັນ, ປະຕິບັດຈາກ Chrome, ຈະຫວ່າງເປົ່າ.

ໃຈຮ້າຍ: ການພິຈາລະນາຄວາມເປັນສ່ວນຕົວບາງຢ່າງ

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

ຖ້າລະບົບ CDN ຂອງທ່ານບໍ່ຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ, ທ່ານອາດຈະສິ້ນສຸດການສົ່ງ cookies ຂອງໂດເມນຂອງທ່ານໄປຫາບໍລິການພາກສ່ວນທີສາມ. ຖ້າການກັ່ນຕອງທີ່ເຫມາະສົມບໍ່ໄດ້ຖືກຈັດຢູ່ໃນລະດັບ CDN, ຫຼັງຈາກນັ້ນ cookies ເຊດຊັນຂອງທ່ານ, ເຊິ່ງປົກກະຕິບໍ່ສາມາດຖືກນໍາໃຊ້ໃນ JavaScript (ກັບ httponly), ອາດຈະຖືກສົ່ງໄປຫາເຈົ້າພາບຕ່າງປະເທດ.

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

ມື້ນີ້, ຕົວທ່ອງເວັບສ່ວນໃຫຍ່ປະກອບມີການປົກປ້ອງປະເພດຂອງພຶດຕິກໍາຕົວຕິດຕາມນີ້. ດັ່ງນັ້ນ, ບົບຕິດຕາມລຸດໃນປັດຈຸບັນໃຊ້ເຕັກໂນໂລຢີ CNAME Cloaking, masquerading ເປັນ scripts ຂອງຕົນເອງສໍາລັບໂຄງການຕ່າງໆ. ຄື, ບົບຕິດຕາມລຸດສະເຫນີໃຫ້ເຈົ້າຂອງເວັບໄຊທ໌ເພີ່ມ CNAME ເຂົ້າໃນການຕັ້ງຄ່າຂອງພວກເຂົາສໍາລັບໂດເມນທີ່ແນ່ນອນ, ທີ່ຢູ່ທີ່ປົກກະຕິແລ້ວເບິ່ງຄືວ່າເປັນຊຸດຕົວອັກສອນແບບສຸ່ມ.

ເຖິງແມ່ນວ່າມັນບໍ່ໄດ້ຖືກແນະນໍາໃຫ້ເຮັດໃຫ້ cookies ເວັບໄຊທ໌ມີຢູ່ໃນໂດເມນຍ່ອຍທັງຫມົດ (ຕົວຢ່າງ - *.website.com), ຫຼາຍໆເວັບໄຊທ໌ເຮັດສິ່ງນີ້. ໃນ​ກໍ​ລະ​ນີ​ນີ້, cookies ດັ່ງ​ກ່າວ​ຈະ​ຖືກ​ສົ່ງ​ອັດ​ຕະ​ໂນ​ມັດ​ກັບ​ຕົວ​ຕິດ​ຕາມ​ພາກ​ສ່ວນ​ທີ​ສາມ disguised. ດັ່ງນັ້ນ, ພວກເຮົາບໍ່ສາມາດເວົ້າກ່ຽວກັບຄວາມເປັນສ່ວນຕົວໄດ້ອີກຕໍ່ໄປ.

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

ຜົນໄດ້ຮັບ

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

• ໂຮດຫ້ອງສະຫມຸດ JS ທີ່ສໍາຄັນທີ່ສຸດຂອງທ່ານ, ຕົວອັກສອນແລະໄຟລ໌ CSS. ນີ້ຈະຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງຄວາມລົ້ມເຫຼວຂອງເວັບໄຊທ໌ຫຼືການເສື່ອມໂຊມປະສິດທິພາບເນື່ອງຈາກຊັບພະຍາກອນອັນສໍາຄັນທີ່ເວັບໄຊທ໌ບໍ່ສາມາດໃຊ້ໄດ້ເນື່ອງຈາກຄວາມຜິດຂອງການບໍລິການພາກສ່ວນທີສາມ.
• ກ່ອນທີ່ທ່ານຈະ cache ຊັບພະຍາກອນຂອງພາກສ່ວນທີສາມຢູ່ໃນ CDN, ໃຫ້ແນ່ໃຈວ່າບາງປະເພດຂອງລະບົບສະບັບພາສາໄດ້ຖືກນໍາໃຊ້ໃນເວລາທີ່ຕັ້ງຊື່ໄຟລ໌ຂອງເຂົາເຈົ້າ, ຫຼືວ່າທ່ານສາມາດຈັດການວົງຈອນຊີວິດຂອງຊັບພະຍາກອນເຫຼົ່ານີ້ດ້ວຍຕົນເອງຫຼືອັດຕະໂນມັດ reset cache CDN ໃນເວລາທີ່ເຜີຍແຜ່ສະບັບໃຫມ່ຂອງ. ສະຄຣິບ.
• ຈົ່ງລະມັດລະວັງຫຼາຍກ່ຽວກັບ CDN, ເຊີບເວີພຣັອກຊີ, ແລະການຕັ້ງຄ່າແຄສຂອງເຈົ້າ. ນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດປ້ອງກັນບໍ່ໃຫ້ໂຄງການຫຼືຫົວຂອງທ່ານຈາກການສົ່ງ cookies Client-Hints ການບໍລິການພາກສ່ວນທີສາມ.

ທ່ານຜູ້ອ່ານທີ່ຮັກແພງ! ເຈົ້າເປັນເຈົ້າພາບອຸປະກອນຂອງຄົນອື່ນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງເຈົ້າທີ່ມີຄວາມສໍາຄັນຫຼາຍສໍາລັບການປະຕິບັດງານຂອງໂຄງການຂອງເຈົ້າບໍ?

ແຫຼ່ງຂໍ້ມູນ: www.habr.com