ให้คะแนนแท็กของบุคคลที่สามทั้งหมด จากนั้นจึงทำการปิด ยกเลิก หรือย้ายแท็กนั้นทางฝั่งเซิร์ฟเวอร์

จากข้อมูลของ HTTP Archive พบว่า มากกว่า 90% ของหน้าเว็บมีการโหลดลิงก์จากภายนอกอย่างน้อยหนึ่งลิงก์ และเว็บไซต์ 1,000 อันดับแรกมีค่าเฉลี่ยการร้องขอจากภายนอก 106 ครั้งบนอุปกรณ์มือถือ ซึ่งมากกว่าปีที่แล้วถึง 15 ครั้ง ปฏิทินออนไลน์ปี 2025สคริปต์คิดเป็นสัดส่วนที่ใหญ่ที่สุดของคำขอทั้งหมด คิดเป็น 24.8%

แทบทั้งหมดไม่ได้เกิดขึ้นจากการตัดสินใจ มันเกิดขึ้นทีละเล็กทีละน้อย และไม่มีใครเป็นเจ้าของทั้งหมดนั้น ต้นทุนนั้นวัดได้: คลังกรณีศึกษาของ Google บันทึกไว้ว่า Vodafone Italy ปรับปรุง LCP ได้ 31% และรับ ยอดขายเพิ่มขึ้น 8%.

คู่มือนี้จัดทำขึ้นสำหรับผู้ที่ได้รับมอบหมายให้แก้ไข Core Web Vitals และไม่สามารถลบแท็กการตลาดได้ด้วยตนเอง เมื่ออ่านจบแล้ว คุณจะได้คะแนนห้าเกณฑ์สำหรับบุคคลที่สามทุกรายบนเว็บไซต์ของคุณ กฎการกำหนดเส้นทางที่แปลงคะแนนแต่ละรายการให้เป็นการกระทำเฉพาะอย่าง และตัวเลขที่สมเหตุสมผลสำหรับการประชุมที่บุคคลใดบุคคลหนึ่งชี้แจงเกี่ยวกับแท็กซึ่งใช้เวลา 380 มิลลิวินาที

สร้างคลังสินค้าให้พร้อมก่อนที่จะได้อะไรมา

คุณต้องมีรายการสองรายการ เพราะรายการใดรายการหนึ่งไม่สมบูรณ์หากขาดไป

รายการตู้คอนเทนเนอร์ ส่งออกข้อมูลคอนเทนเนอร์ Google Tag Manager ของคุณ: แท็ก ทริกเกอร์ และตัวแปร พร้อมด้วยเจ้าของและเงื่อนไขการทำงาน นี่คือจุดประสงค์หลัก

รายชื่อเครือข่าย โหลดหน้าเว็บใน Chrome DevTools โดยปิดใช้งานแคช จากนั้นเรียกใช้ Lighthouse และอ่านรายงานการตรวจสอบ "ลดผลกระทบของโค้ดจากภายนอก" นี่คือสิ่งที่ทำงานจริง รวมถึงแท็กที่ถูกแทรกโดยแท็กอื่น ๆ ซึ่งจะไม่ปรากฏในการส่งออกคอนเทนเนอร์

สำหรับบุคคลที่สามทุกรายในรายชื่อใดรายชื่อหนึ่ง ให้บันทึกข้อมูลเจ็ดรายการดังนี้:

• ผู้ขายและสิ่งที่ผู้ขายอ้างว่าจะทำ
• ระบุชื่อเจ้าของธุรกิจ (บุคคล ไม่ใช่แผนก)
• ขนาดการถ่ายโอนสคริปต์
• เวลาที่เธรดหลักถูกบล็อกเนื่องจากสาเหตุนี้
• ไม่ว่าจะอยู่บนเส้นทางวิกฤตไปยังองค์ประกอบ LCP หรือไม่
• เทมเพลตหน้าเว็บใดบ้างที่จะถูกเรียกใช้งาน
• ครั้งสุดท้ายที่มีคนตัดสินใจโดยใช้ข้อมูลนี้คือเมื่อไหร่

ช่องสุดท้ายเป็นช่องที่คนส่วนใหญ่มองข้าม และเป็นช่องที่ยุติข้อโต้แย้งได้มากที่สุด การให้คะแนนเทียบกับข้อมูลในแต่ละช่อง: Core Web Vitals จะถูกประเมินที่... เปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้าเว็บจริงและการทดสอบในห้องปฏิบัติการที่ใช้การเชื่อมต่อความเร็วสูงจะช่วยเพิ่มประสิทธิภาพของชุดข้อมูลของคุณ

เกณฑ์การให้คะแนนทั้งห้าข้อ

ให้คะแนนบุคคลที่สามแต่ละราย 0-3 ในทั้งห้าข้อ คะแนนรวมที่สูงกว่าหมายถึงเหตุผลที่หนักแน่นกว่าสำหรับการถอดถอน

มีการแก้ไขเพิ่มเติมอีกสองรายการเหนือยอดรวมทั้งหมด:

1. ได้คะแนน 3 จากการใช้งานเส้นทางการฆ่าที่แสดงให้เห็นแล้ว โดยไม่คำนึงถึงผลรวมทั้งหมด ไม่มีค่าใช้จ่ายใดคุ้มค่าที่จะจ่ายสำหรับป้ายที่ไม่มีใครใช้
2. ตำแหน่ง 3 บนเส้นทางวิกฤตอย่างน้อยระดับ 3 สคริปต์ที่ขัดขวางการแสดงผลในส่วนหัวนั้นถือเป็นโครงสร้าง แม้ว่าผู้ขายจะมีคุณค่าก็ตาม

ตารางเส้นทาง

ภายในกลุ่มผลิตภัณฑ์เดียวกัน คะแนนความสามารถในการทดแทนจะเป็นตัวเลือกกลยุทธ์: หากได้คะแนน 3 หมายความว่ามีผลิตภัณฑ์ที่เทียบเท่าจากฝั่งผู้พัฒนาเองหรือฝั่งเซิร์ฟเวอร์อยู่แล้ว ดังนั้นควรเลือกใช้ผลิตภัณฑ์เหล่านั้นแทนที่จะใช้ค่าเริ่มต้นของกลุ่มผลิตภัณฑ์

คอลัมน์ผู้ลงนามมีความสำคัญ เพราะแต่ละวงดนตรีจะระบุชื่อบุคคลหนึ่งคน "เว็บไซต์ช้าเพราะแท็ก" คือข้อร้องเรียน "แท็กนี้ได้คะแนน 11 ​​คะแนน นี่คือผู้ที่ลงนามรับรอง" คือตั๋วแจ้งปัญหา

ตัวอย่างการใช้งาน

ภาพรวมขั้นตอนการชำระเงินออนไลน์สำหรับตลาดระดับกลาง ข้อมูลนี้ไม่ใช่ข้อมูลลูกค้า เป็นเพียงตัวเลขประกอบการอธิบายเท่านั้น

วิดเจ็ตแชทเป็นแถวที่ให้คำแนะนำ มันถูกใช้งานจริงและไม่สามารถทดแทนได้ และมันยังคงเชื่อมโยงไปยังส่วนหน้าอยู่ดี เพราะหลักเกณฑ์แยกแยะระหว่าง "เราจำเป็นต้องใช้สิ่งนี้หรือไม่" กับ "เราจำเป็นต้องใช้มันภายใน 2.5 วินาทีแรกหรือไม่"

[INTERNAL DATA NEEDED: replace this composite table with a real anonymised inventory from a Switas engagement — vendor category, measured blocking time, post-change field metric.]

วิธีแก้ไขทั้งสามวิธี เรียงลำดับตามความถี่ที่ได้ผลจริง

ส่วนหน้าอาคาร แทนที่การฝังโค้ดด้วยตัวยึดตำแหน่งแบบคงที่ซึ่งจะโหลดวิดเจ็ตจริงเมื่อมีการโต้ตอบ วิดเจ็ตแชท วิดีโอ แผนที่ และรีวิว มักได้รับผลดี การแก้ไขแบบนี้ให้ผลตอบแทนสูงสุดในการตรวจสอบส่วนใหญ่ เพราะช่วยลดต้นทุนโดยไม่ลบฟีเจอร์ออกไป ซึ่งเป็นเหตุผลที่ทำให้ผ่านการพิจารณาในที่ประชุม

เลื่อนออกไป มีประโยชน์ แต่ก็มีข้อควรระวังอยู่บ้าง Chrome ลดลำดับความสำคัญของเครือข่าย of async และ defer ทรัพยากรเหล่านั้นจึงโหลดช้ากว่าที่คุณคาดไว้ ซึ่งเหมาะสำหรับพิกเซล แต่ไม่เหมาะสำหรับสิ่งใดก็ตามที่ต้องแสดงผล นอกจากนี้ web.dev ยังระบุว่าการฝังเนื้อหา "สามารถบล็อกได้" window.onload หากเซิร์ฟเวอร์ของพวกเขามีการตอบสนองช้า แม้ว่าการฝังจะใช้ async หรือ defer ก็ตาม การใช้ defer จะย้ายต้นทุนไปที่อื่น ไม่ได้ขจัดต้นทุนออกไปเสมอไป

การติดแท็กฝั่งเซิร์ฟเวอร์ จำเป็นต้องแก้ไข เพราะสินค้าชิ้นนี้ถูกขายในฐานะผลิตภัณฑ์เพิ่มความเร็วในการโหลดหน้าเว็บ แต่จริงๆ แล้วไม่ใช่ นี่คือข้อมูลจาก Google เอง บทนำเกี่ยวกับการติดแท็กฝั่งเซิร์ฟเวอร์ อธิบายถึงความเป็นเจ้าของข้อมูล การจัดรูปแบบ และการกำหนดเส้นทางข้อมูล — "มีเพียงคุณเท่านั้นที่สามารถเข้าถึงข้อมูลในเซิร์ฟเวอร์ได้จนกว่าคุณจะเลือกส่งไปยังที่อื่น" — และไม่ได้กล่าวอ้างถึงประสิทธิภาพใดๆ เบราว์เซอร์ยังคงรันโค้ดการวัดและยังคงส่งเหตุการณ์ผ่านพิกเซลของภาพ fetchXHR หรือพนักงานบริการที่ให้บริการจากคุณ โดเมนคอนเทนเนอร์เซิร์ฟเวอร์.

สิ่งที่คุณจะได้รับคือบริบทจากแหล่งข้อมูลหลักและการควบคุมสิ่งที่จะออกจากโครงสร้างพื้นฐานของคุณ ความเร็วที่เพิ่มขึ้นใดๆ เป็นเพียงผลข้างเคียงจากสคริปต์ของผู้จำหน่ายที่คุณลบออกในระหว่างการย้ายระบบ หากผู้จำหน่ายสัญญาว่าจะปรับปรุง INP จากการติดแท็กฝั่งเซิร์ฟเวอร์เพียงอย่างเดียว ให้ถามว่าสคริปต์ใดที่หยุดโหลดในเบราว์เซอร์ หากคำตอบคือไม่มี แสดงว่าไม่มีการปรับปรุงใดๆ INP ประกอบด้วย ความล่าช้าในการป้อนข้อมูล ระยะเวลาในการประมวลผล และความล่าช้าในการแสดงผลและสคริปต์จะขยายสองอันแรกโดยการเข้าครอบครองเธรดหลัก การเปลี่ยนตำแหน่งที่คำขออยู่ ส่ง ไม่มีผลกระทบต่อสิ่งใดเลย

การเปลี่ยนแปลงการคำนวณจะเกิดขึ้นเมื่อชั้นการยินยอมเข้ามาเกี่ยวข้อง

แพลตฟอร์มการจัดการความยินยอมของคุณมักจะเป็นรายการที่มีคะแนนสูงสุดในรายการทั้งหมด: มันอยู่ส่วนหัวของโปรแกรม มันขัดขวางการแสดงผลตามการออกแบบ และแท็กอื่นๆ ทั้งหมดต่างรอการประมวลผลจากแพลตฟอร์มนี้ ให้คะแนนมันเหมือนกับรายการอื่นๆ ทั่วไป

จากนั้นให้ตัดสินใจว่าจะใช้โหมดการขอความยินยอมแบบใด เพราะทั้งสองแบบมีประสิทธิภาพการทำงานที่แตกต่างกัน ตามคำนิยามของ Google แล้ว โหมดการยินยอมขั้นพื้นฐาน หมายความว่าแท็กจะถูก "บล็อกจนกว่าผู้ใช้จะโต้ตอบกับแบนเนอร์ขอความยินยอม" ในขณะที่โหมดขั้นสูงจะ "โหลดด้วยค่าเริ่มต้นที่ตั้งไว้" denied"และส่งข้อมูลการวัดโดยไม่ใช้คุกกี้ก่อนที่จะได้รับความยินยอม โหมดพื้นฐานจะโหลดได้เร็วกว่าในครั้งแรก แต่ก็ใช้ข้อมูลของคุณเช่นกัน: ของ Google คำแนะนำของ EEA มีคำเตือนว่า หากคุณป้องกันไม่ให้แท็กโหลดจนกว่าจะมีการโต้ตอบกับแบนเนอร์ "Google จะไม่สามารถตรวจสอบตัวเลือกการยินยอมของผู้ใช้ได้ และอาจนำไปสู่การสูญเสียข้อมูล"

ในที่นี้มีรายละเอียดเฉพาะภูมิภาคที่สำคัญ ตุรกีไม่ได้อยู่ในเขตเศรษฐกิจยุโรป (EEA) ดังนั้นข้อกำหนดการขอความยินยอมของ Google สำหรับ EEA จึงไม่มีผลต่อการใช้งานในตุรกี แต่กฎหมายตุรกีมีผล คู่มือของ KVKK เกี่ยวกับแนวปฏิบัติด้านคุกกี้ถือว่าคุกกี้สำหรับการวิเคราะห์ต้องได้รับความยินยอมอย่างชัดเจน แทนที่จะเป็นเพียงสิ่งที่จำเป็นอย่างเคร่งครัด กำหนดให้หมวดหมู่ความยินยอมไม่ต้องถูกเลือกโดยค่าเริ่มต้น และ "ปฏิเสธทั้งหมด" มีความสำคัญเท่ากับ "ยอมรับทั้งหมด" และ ห้ามใช้กำแพงคุกกี้.

ผลที่ตามมาในทางปฏิบัติสำหรับผู้ค้าปลีกในตุรกีหรือผู้ค้าปลีกหลายตลาด: ตั้งค่าโหมดการยินยอมขั้นพื้นฐานสำหรับทราฟฟิกในตุรกี และตั้งค่าขั้นสูงสำหรับทราฟฟิกในเขตเศรษฐกิจยุโรป (EEA) คุณจะไม่สูญเสียสิทธิ์ใดๆ ที่คุณมีในทั้งสองตลาด CMP ส่วนใหญ่จะไม่ทำเช่นนี้โดยอัตโนมัติ นี่เป็นการตัดสินใจในการกำหนดค่าตามภูมิศาสตร์ ไม่ใช่ปลั๊กอิน

สิ่งที่หัวข้อนี้ไม่ครอบคลุม

• โปรแกรมนี้ให้คะแนนแท็ก ไม่ใช่หน้าเว็บ แท็กที่ดูไม่เป็นอันตรายบนหน้าแรก อาจสร้างความเสียหายอย่างร้ายแรงบนหน้าแสดงรายการสินค้า หากมีการโหลดแท็กมากถึงสี่สิบแท็ก
• ต้นทุนของเธรดหลักไม่สามารถบวกเพิ่มได้ การลบแท็ก 100ms จำนวน 5 แท็กนั้น แทบจะไม่ส่งผลให้ได้ค่า 500ms กลับมาเลย ควรวัดค่าหลังจากการเปลี่ยนแปลงทุกครั้ง
• มันไม่สนใจโค้ดของคุณเอง งานที่ใช้เวลานานจากกระบวนการเติมน้ำในเฟรมเวิร์กมักเป็นส่วนสำคัญของ INP ที่ไม่ดี และการตรวจสอบจากบุคคลที่สามจะไม่สามารถตรวจพบได้
• มันให้ข้อมูลเฉพาะด้านต้นทุนเท่านั้น แท็กที่มีความยาว 380 มิลลิวินาที ซึ่งส่งผลให้เกิดรายได้ที่แท้จริง อาจคุ้มค่าที่จะเก็บไว้
• ไม่มีความเห็นใดๆ เกี่ยวกับความปลอดภัยหรือการจัดเก็บข้อมูลบางครั้งนั่นอาจเป็นเหตุผลที่แท้จริงที่ผู้ขายควรเลิกกิจการ
• แท็กที่ถูกส่งต่อจะซ่อนจากการส่งออกคอนเทนเนอร์ หากข้อมูลในทั้งสองรายการไม่ตรงกัน ให้เชื่อถือข้อมูลจากเครือข่ายหลัก

คำถามที่พบบ่อย

ฉันจะวัดต้นทุนของเธรดหลักสำหรับโปรแกรมของบุคคลที่สามรายใดรายหนึ่งได้อย่างไร? ใช้แผงประสิทธิภาพของ Chrome DevTools เพื่อระบุแหล่งที่มาของสคริปต์สำหรับงานที่ใช้เวลานาน และตรวจสอบซ้ำกับรายงานการตรวจสอบ "ลดผลกระทบของโค้ดจากภายนอก" ของ Lighthouse ยืนยันกับข้อมูลภาคสนาม เนื่องจากผลการทดสอบในห้องปฏิบัติการมักประเมินต้นทุนที่แท้จริงต่ำกว่าความเป็นจริง

การติดแท็กฝั่งเซิร์ฟเวอร์ช่วยปรับปรุง Core Web Vitals หรือไม่? มันเพียงอย่างเดียวไม่ได้ช่วยอะไร เอกสารของ Google เกี่ยวกับการติดแท็กฝั่งเซิร์ฟเวอร์อธิบายถึงการควบคุมข้อมูลและการกำหนดเส้นทาง ไม่ใช่ความเร็วของหน้าเว็บ และเบราว์เซอร์ยังคงโหลดโค้ดการวัดและส่งเหตุการณ์อยู่ การปรับปรุงใดๆ มาจากการลบสคริปต์ของผู้ให้บริการออกจากหน้าเว็บในระหว่างการย้ายระบบ

บุคคลที่สามสร้างความเสียหายให้กับ Core Web Vital ในส่วนใดมากที่สุด? โดยปกติแล้ว INP จะได้รับผลกระทบ เนื่องจากสคริปต์จะใช้เธรดหลักและทำให้เกิดความล่าช้าในการป้อนข้อมูลและระยะเวลาการประมวลผล แท็กที่บล็อกการเรนเดอร์ในส่วนหัวจะไปกระทบกับ LCP แทน และแบนเนอร์หรือวิดเจ็ตที่แทรกเข้ามาในภายหลังจะไปกระทบกับ CLS

ฉันควรโฮสต์สคริปต์ของบุคคลที่สามด้วยตนเองหรือไม่? บางครั้งก็เป็นอย่างนั้น แต่ก็เป็นการแลกเปลี่ยนกัน เซิร์ฟเวอร์ที่ติดตั้งเองจะไม่ได้รับการอัปเดต API และการแก้ไขด้านความปลอดภัยจากผู้ให้บริการจนกว่าคุณจะอัปเดตด้วยตนเอง ซึ่ง web.dev มองว่าเป็นความเสี่ยงด้านรายได้และความปลอดภัย

ฉันควรตั้งเป้าหมายอะไรไว้? ที่เปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้าเว็บจริง: LCP ไม่เกิน 2.5 วินาที, INP ไม่เกิน 200 มิลลิวินาที, CLS ไม่เกิน 0.1

ฉันจำเป็นต้องใช้โหมดขอความยินยอมจาก Google หรือไม่ หากปริมาณการเข้าชมเว็บไซต์ส่วนใหญ่มาจากภาษาตุรกี? ข้อกำหนดการส่งสัญญาณขอความยินยอมของ Google สำหรับ EEA ไม่ครอบคลุมการใช้งานในตุรกี แต่กฎเกี่ยวกับคุกกี้ของ KVKK ครอบคลุม ดังนั้นคุณยังคงต้องมีกลไกการขอความยินยอมที่ใช้งานได้ สิ่งที่เปลี่ยนแปลงคือคุณมีอิสระมากขึ้นในการเลือกการใช้งานพื้นฐานที่รวดเร็วกว่าสำหรับกลุ่มนั้น

ควรตรวจคะแนนใหม่บ่อยแค่ไหน? ตรวจสอบสินค้าคงคลังทั้งหมดทุกไตรมาส และทุกครั้งที่มีการเพิ่มผู้ขายรายใหม่ จำนวนแท็กเพิ่มขึ้นอีกครั้ง: ตัวเลขปีต่อปีของ Web Almanac แสดงให้เห็นว่าจำนวนคำขอจากบุคคลที่สามเพิ่มขึ้น

ฉันควรทำอย่างไรหากเจ้าของป้ายปฏิเสธ? ส่งคะแนนและรายชื่อวงดนตรี ไม่ใช่ข้อโต้แย้ง เกณฑ์การประเมินมีไว้เพื่อให้การสนทนาเน้นที่ตัวเลขและการกระทำที่ระบุไว้ มากกว่าการตัดสินว่าใครสำคัญกว่ากัน

หากหน้าชำระเงินหรือหน้าแสดงรายการสินค้าของคุณไม่ผ่านเกณฑ์ Core Web Vitals และคุณไม่ทราบว่าผู้ให้บริการรายใดเป็นผู้รับผิดชอบ ให้ลองใช้เกณฑ์นี้กับระบบของคุณเอง หรือให้เราช่วยตรวจสอบ โดยใช้ข้อมูลจริงและจัดลำดับความสำคัญของงานที่ค้างอยู่ บริการเพิ่มประสิทธิภาพเว็บของสวิตัส.

แหล่งที่มา

• บุคคลที่สาม — ปฏิทินเว็บปี 2025, คลังข้อมูล HTTP
• ข้อมูลสำคัญของเว็บไซต์ — web.dev
• Interaction to Next Paint (INP) — web.dev
• กำลังโหลด JavaScript จากภายนอก — web.dev
• ผลกระทบทางธุรกิจของ Core Web Vitals — กรณีศึกษาจาก web.dev
• บทนำเกี่ยวกับการติดแท็กฝั่งเซิร์ฟเวอร์ — แพลตฟอร์มแท็กของ Google
• ส่งข้อมูลไปยังคอนเทนเนอร์เซิร์ฟเวอร์ — Google Tag Platform
• แนวคิดโหมดการขอความยินยอม — Google Tag Platform
• การอัปเดตโหมดขอความยินยอมสำหรับทราฟฟิกจาก EEA — ความช่วยเหลือของ Google Ads
• แผนงานการปฏิบัติตามกฎระเบียบ KVKK Çerez Rehberi — Mondaq (วิเคราะห์จากคู่มือ 61 หน้าของหน่วยงาน; ไม่สามารถเข้าถึง kvkk.gov.tr ​​ได้ในขณะที่เขียนบทความนี้)