เพิ่มประสิทธิภาพแท็กและเครื่องจัดการแท็กสำหรับ Core Web Vitals
แท็กคือข้อมูลโค้ดของบุคคลที่สามที่แทรกลงในเว็บไซต์ โดยทั่วไปจะใช้ผ่านเครื่องจัดการแท็ก แท็กที่ใช้กันมากที่สุดเพื่อการตลาดและการวิเคราะห์
ผลกระทบด้านประสิทธิภาพของแท็กและเครื่องจัดการแท็กจะแตกต่างกันไปในแต่ละเว็บไซต์ คุณสามารถเปรียบเทียบเครื่องจัดการแท็กกับเอนเวโลปได้ กล่าวคือ เครื่องจัดการแท็กจะให้เรือ แต่ส่วนใหญ่คุณจะกรอกข้อมูลอะไรและวิธีใช้งานจะขึ้นอยู่กับคุณ
บทความนี้จะกล่าวถึงเทคนิคในการเพิ่มประสิทธิภาพแท็กและ Tag Manager เพื่อประสิทธิภาพ รวมถึง Web Vitals แม้ว่าบทความนี้จะอ้างอิงถึง Google Tag Manager แต่ หลายๆ แนวคิดที่กล่าวถึงกันนั้นก็อาจใช้ได้กับเครื่องจัดการแท็กอื่นๆ ด้วยเช่นกัน
ผลกระทบต่อ Core Web Vitals
Tag Manager มักส่งผลต่อ Core Web Vitals โดยอ้อมได้ด้วยการใช้ทรัพยากรที่จําเป็นในการโหลดหน้าเว็บอย่างรวดเร็วและทําให้หน้าเว็บปรับเปลี่ยนตามอุปกรณ์อยู่เสมอ แบนด์วิดท์ใช้ในการดาวน์โหลด JavaScript ของเครื่องจัดการแท็กสำหรับเว็บไซต์หรือการเรียกใช้ครั้งต่อๆ ไป เวลา CPU ของเทรดหลักสามารถใช้ในการประเมินและเรียกใช้ JavaScript ที่อยู่ใน Tag Manager และแท็กได้
Largest Contentful Paint (LCP) มีความเสี่ยงที่จะมีการช่วงชิงแบนด์วิดท์ในช่วงการโหลดหน้าเว็บที่สำคัญ นอกจากนี้ การบล็อกเทรดหลักอาจหน่วงเวลาการแสดงผล LCP
Cumulative Layout Shift (CLS) อาจได้รับผลกระทบได้จากการหน่วงเวลาการโหลดทรัพยากรที่สำคัญก่อนการแสดงผลครั้งแรก หรือเมื่อ Tag Manager แทรกเนื้อหาลงในหน้า
การโต้ตอบกับ Next Paint (INP) มีแนวโน้มที่จะเกิดการช่วงชิง CPU ในเทรดหลัก และเราได้เห็นความสัมพันธ์ระหว่างขนาดของ Tag Manager และคะแนน INP ที่แย่ลง
ประเภทแท็ก
ผลกระทบที่แท็กมีต่อประสิทธิภาพจะแตกต่างกันไปตามประเภทแท็ก โดยทั่วไปแล้ว แท็กรูปภาพ ("พิกเซล") มีประสิทธิภาพสูงสุด รองลงมาคือเทมเพลตที่กำหนดเอง และสุดท้ายคือแท็ก HTML ที่กำหนดเอง แท็กผู้ให้บริการจะแตกต่างกันไปตามฟังก์ชันการทำงานที่อนุญาต
อย่างไรก็ตาม โปรดทราบว่าการใช้แท็กมีผลต่อประสิทธิภาพของแท็กอย่างมาก "พิกเซล" มีประสิทธิภาพส่วนใหญ่เนื่องจากลักษณะของแท็กประเภทนี้มีข้อจํากัดด้านการใช้งานอย่างเข้มงวด แท็ก HTML ที่กําหนดเองอาจไม่ดีต่อประสิทธิภาพเสมอไป แต่เนื่องจากระดับอิสระที่ผู้ใช้ได้รับ แท็กจึงอาจถูกนำไปใช้ในทางที่ผิดในลักษณะที่ส่งผลเสียต่อประสิทธิภาพได้ง่าย
ในการคิดเกี่ยวกับแท็ก ให้คำนึงถึงขนาดแท็ก: ผลกระทบด้านประสิทธิภาพของแท็กเดี่ยวๆ อาจมีนัยสำคัญน้อยมาก แต่อาจมีความสำคัญเมื่อมีการใช้แท็กหลายสิบหรือหลายร้อยแท็กในหน้าเดียวกัน
สคริปต์บางรายการไม่ควรโหลดโดยใช้ Tag Manager
โดยทั่วไปแล้ว Tag Manager ไม่ใช่กลไกที่ดีในการโหลดทรัพยากรที่นำลักษณะด้านภาพหรือฟังก์ชันการทำงานของประสบการณ์ของผู้ใช้มาใช้ในทันที เช่น ประกาศเกี่ยวกับคุกกี้ รูปภาพหลัก หรือฟีเจอร์ของเว็บไซต์ การใช้เครื่องจัดการแท็กเพื่อโหลดทรัพยากรเหล่านี้มักทำให้การแสดงโฆษณาล่าช้า ซึ่งจะส่งผลเสียต่อประสบการณ์ของผู้ใช้ และยังเพิ่มเมตริกอย่าง LCP และ CLS ได้ด้วย นอกจากนี้ อย่าลืมว่าผู้ใช้บางรายจะบล็อกเครื่องจัดการแท็ก การใช้เครื่องจัดการแท็กเพื่อใช้ฟีเจอร์ UX อาจทำให้ผู้ใช้บางคนเสียเว็บไซต์ได้
โปรดระวังแท็ก HTML ที่กำหนดเอง
แท็ก HTML ที่กำหนดเองมีมาหลายปีแล้วและมีการใช้งานมากในเว็บไซต์ส่วนใหญ่ แท็ก HTML ที่กำหนดเองให้คุณป้อนรหัสของคุณเองได้โดยมีข้อจำกัดอยู่เล็กน้อย เนื่องจากการใช้แท็กนี้เป็นการใช้หลักในการเพิ่มองค์ประกอบ <script> ที่กำหนดเองลงในหน้าเว็บ แม้ว่าจะมีชื่อเรียกก็ตาม
แท็ก HTML ที่กำหนดเองสามารถนำไปใช้ได้ในหลายลักษณะ และประสิทธิภาพของแท็กก็อาจแตกต่างกันอย่างมาก ขณะวัดประสิทธิภาพของเว็บไซต์ โปรดทราบว่าเครื่องมือส่วนใหญ่จะถือว่าผลกระทบด้านประสิทธิภาพของแท็ก HTML ที่กำหนดเองนั้นมาจากเครื่องจัดการแท็กที่ใส่แท็ก แทนที่จะเป็นตัวแท็กเอง
แท็ก HTML ที่กำหนดเองสามารถแทรกองค์ประกอบลงในหน้ารอบข้างได้ การแทรกองค์ประกอบในหน้าอาจเป็นแหล่งที่มาของปัญหาด้านประสิทธิภาพ และในบางกรณีก็อาจทำให้เลย์เอาต์เปลี่ยนแปลงได้เช่นกัน
- ในกรณีส่วนใหญ่ หากมีการแทรกองค์ประกอบลงในหน้า เบราว์เซอร์จะต้องคำนวณขนาดและตำแหน่งของแต่ละรายการในหน้าอีกครั้ง กระบวนการนี้เรียกว่าการออกแบบ เลย์เอาต์เดียวส่งผลต่อประสิทธิภาพเพียงเล็กน้อย แต่หากเกิดขึ้นมากเกินไปก็อาจกลายเป็นสาเหตุของปัญหาด้านประสิทธิภาพได้ ผลกระทบจากปรากฏการณ์นี้เกิดขึ้นในอุปกรณ์ระดับล่างและหน้าเว็บที่มีองค์ประกอบ DOM จำนวนมาก
- หากแทรกองค์ประกอบของหน้าที่มองเห็นได้ลงใน DOM หลังจากที่พื้นที่โดยรอบแสดงผลแล้ว อาจทำให้เลย์เอาต์เปลี่ยนแปลง ข้อผิดพลาดนี้ไม่ได้เกิดขึ้นเฉพาะกับผู้จัดการแท็ก แต่เนื่องจากแท็กมักจะโหลดช้ากว่าส่วนอื่นๆ ของหน้าเว็บ จึงเป็นเรื่องปกติที่จะมีการแทรกแท็กลงใน DOM หลังจากหน้าเว็บโดยรอบแสดงผลแล้ว
ลองใช้เทมเพลตที่กำหนดเอง
เทมเพลตที่กำหนดเองรองรับการดำเนินการบางอย่างเหมือนกับแท็ก HTML ที่กำหนดเอง แต่สร้างขึ้นจาก JavaScript เวอร์ชันแซนด์บ็อกซ์ที่มี API สำหรับกรณีการใช้งานทั่วไป เช่น การแทรกสคริปต์และการแทรกพิกเซล ซึ่งมีความหมายตามชื่อที่บอกเป็นนัยว่าผู้ใช้สามารถสร้างเทมเพลต โดยผู้ใช้ขั้นสูงที่สามารถสร้างเทมเพลตนี้ได้โดยคำนึงถึงประสิทธิภาพ จากนั้นผู้ใช้ด้านเทคนิคก็จะใช้เทมเพลตได้น้อยลง ซึ่งมักจะปลอดภัยกว่าการให้สิทธิ์เข้าถึง HTML แบบกำหนดเองเต็มรูปแบบ
แท็กเหล่านี้มีแนวโน้มที่จะแสดงปัญหาด้านประสิทธิภาพหรือปัญหาด้านความปลอดภัยน้อยลงมาก แต่ด้วยเหตุนี้ เทมเพลตที่กำหนดเองจึงจะทำงานได้กับทุก Use Case เนื่องจากเทมเพลตที่กำหนดเองมีข้อจำกัดที่มากขึ้น
แทรกสคริปต์อย่างถูกต้อง
การใช้เครื่องจัดการแท็กเพื่อแทรกสคริปต์เป็นกรณีการใช้งานทั่วไป วิธีที่แนะนำคือการใช้เทมเพลตที่กำหนดเองและ injectScript API
ดูข้อมูลเกี่ยวกับการใช้ injectScript API เพื่อแปลงแท็ก HTML ที่กำหนดเองที่มีอยู่ได้ที่แปลงแท็กที่มีอยู่
หากคุณต้องใช้แท็ก HTML ที่กำหนดเอง สิ่งที่ควรทราบมีดังนี้
- ควรโหลดไลบรารีและสคริปต์ของบุคคลที่สามขนาดใหญ่ผ่านแท็กสคริปต์ที่ดาวน์โหลดไฟล์ภายนอก (เช่น
<script src="external-scripts.js">) แทนการคัดลอกและวางเนื้อหาของสคริปต์ลงในแท็กโดยตรง แม้ว่าการใช้แท็ก<script>ที่ผ่านไปแล้วจะทำให้ระบบต้องดาวน์โหลดเนื้อหาของสคริปต์แบบไป-กลับแยกกัน แต่การดำเนินการนี้จะเพิ่มขนาดคอนเทนเนอร์และป้องกันไม่ให้เบราว์เซอร์แคชสคริปต์แยกไว้ต่างหาก - ผู้ให้บริการหลายรายแนะนำให้วางแท็ก
<script>ไว้ที่ด้านบนของ<head>อย่างไรก็ตาม สำหรับสคริปต์ที่โหลดผ่าน Tag Manager คำแนะนำนี้มักไม่จำเป็น โดยส่วนมาก เบราว์เซอร์จะแยกวิเคราะห์<head>เสร็จแล้วเมื่อถึงเวลาที่ Tag Manager ดำเนินการ
ใช้พิกเซล
ในบางสถานการณ์ สคริปต์ของบุคคลที่สามอาจถูกแทนที่ด้วยรูปภาพหรือ iframe "พิกเซล" เมื่อเทียบกับฟีเจอร์ที่ใช้สคริปต์แล้ว พิกเซลอาจรองรับฟังก์ชันการทำงานได้น้อยกว่า จึงมักมองว่าเป็นการใช้งานที่คล้ายกับการใช้งานจริงน้อยกว่าด้วยเหตุนี้ อย่างไรก็ตาม เมื่อใช้ภายในเครื่องจัดการแท็ก พิกเซลจะเปลี่ยนแปลงได้มากยิ่งขึ้นเนื่องจากสามารถเริ่มทำงานเมื่อทริกเกอร์และส่งตัวแปรต่างๆ ได้ ซึ่งเป็นแท็กประเภทที่มีประสิทธิภาพและปลอดภัยที่สุดเพราะไม่มีการดำเนินการ JavaScript หลังจากเริ่มทำงานแล้ว พิกเซลมีขนาดทรัพยากรที่เล็กมาก (น้อยกว่า 1 KB) และ ไม่ทำให้เกิดการเปลี่ยนแปลงของเลย์เอาต์
โปรดสอบถามผู้ให้บริการบุคคลที่สามสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการรองรับพิกเซล นอกจากนี้ คุณอาจลองตรวจสอบโค้ดของแท็ก <noscript> ด้วยก็ได้
หากผู้ให้บริการรองรับพิกเซล ก็มักจะรวมผู้ให้บริการไว้ในแท็ก <noscript>
ตัวเลือกพิกเซล
พิกเซลได้รับความนิยมอย่างมากเพราะ ณ เวลาหนึ่ง Pixel เป็นวิธีหนึ่งที่ถูกที่สุดและน่าเชื่อถือมากที่สุดในการสร้างคำขอ HTTP ในสถานการณ์ที่การตอบสนองของเซิร์ฟเวอร์ไม่เกี่ยวข้อง ( เช่น เมื่อส่งข้อมูลไปยังผู้ให้บริการวิเคราะห์) navigator.sendBeacon() และ fetch()
keepalive
API ออกแบบมาเพื่อรองรับกรณีการใช้งานเดียวกันนี้ แต่ก็เชื่อถือได้มากกว่าพิกเซล
การใช้พิกเซลต่อไปนั้นไม่ได้มีความผิดปกติแต่อย่างใด เพราะได้รับการสนับสนุนเป็นอย่างดีและส่งผลต่อประสิทธิภาพน้อยที่สุด อย่างไรก็ตาม หากคุณกำลังสร้างบีคอนของตัวเอง คุณควรลองใช้ API ตัวใดตัวหนึ่งเหล่านี้
sendBeacon()
navigator.sendBeacon() API ออกแบบมาเพื่อส่งข้อมูลจำนวนน้อยไปยังเว็บเซิร์ฟเวอร์ในกรณีที่การตอบสนองของเซิร์ฟเวอร์ไม่สำคัญ
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
navigator.sendBeacon(url, data);
sendBeacon() มี API ที่จำกัด: รองรับเฉพาะการสร้างคำขอ POST เท่านั้นและไม่รองรับการตั้งค่าส่วนหัวที่กำหนดเอง เนื่องจากรองรับเบราว์เซอร์ที่ทันสมัยทั้งหมด
fetch() keepalive
keepalive คือแฟล็กที่อนุญาตให้ใช้ API การดึงข้อมูลเพื่อสร้างคำขอที่ไม่จำกัดการบล็อก เช่น การรายงานเหตุการณ์และข้อมูลวิเคราะห์ ซึ่งจะใช้โดยการใส่ keepalive: true ในพารามิเตอร์ที่ส่งไปยัง fetch()
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
fetch(url, {
method: 'POST',
body: data,
keepalive: true
});
หาก fetch() keepalive กับ sendBeacon() ดูคล้ายคลึงกันมาก ก็เพราะคำเหล่านี้
เป็น "สิ่งเดียวกัน" อันที่จริงแล้ว ในเบราว์เซอร์ Chromium ปัจจุบัน sendBeacon() สร้างขึ้นบน fetch()
keepalive
เมื่อเลือกระหว่าง fetch() keepalive ถึง sendBeacon() คุณต้องพิจารณาฟีเจอร์และการสนับสนุนเบราว์เซอร์ที่ต้องการด้วย API ของFetch() มีความยืดหยุ่นมากกว่าอย่างมาก แต่ keepalive มีการรองรับเบราว์เซอร์น้อยกว่า sendBeacon()
ขอคำชี้แจง
แท็กมักจะสร้างขึ้นตามคำแนะนำจากผู้ให้บริการบุคคลที่สาม หากไม่ชัดเจนว่าโค้ดของผู้ให้บริการใช้ทำอะไร ให้ลองถามผู้ที่ทราบก่อน การขอความคิดเห็นเพิ่มเติมจะช่วยระบุว่าแท็กมีแนวโน้มที่จะสร้างปัญหาด้านประสิทธิภาพหรือความปลอดภัยหรือไม่
ขอแนะนำให้ติดป้ายกำกับแท็กโดยใช้เจ้าของใน Tag Manager ด้วยเช่นกัน การลืมว่าใครเป็นเจ้าของแท็กนั้นทำได้ง่ายมาก และกลัวที่จะนำออกหากจําเป็น
ทริกเกอร์
ในระดับสูง การเพิ่มประสิทธิภาพทริกเกอร์แท็กโดยทั่วไปนั้นประกอบด้วยการตรวจสอบว่าไม่ได้ทริกเกอร์แท็กมากเกินไป และการเลือกทริกเกอร์ที่สร้างความสมดุลระหว่างความต้องการทางธุรกิจกับต้นทุนด้านประสิทธิภาพ
ตัวทริกเกอร์คือโค้ด JavaScript ที่จะเพิ่มขนาดและต้นทุนการดำเนินการของเครื่องจัดการแท็ก แม้ว่าทริกเกอร์ส่วนใหญ่จะมีขนาดเล็ก แต่เอฟเฟกต์สะสมอาจเพิ่มขึ้นได้ เช่น การมีเหตุการณ์การคลิกจำนวนมากหรือทริกเกอร์ตัวจับเวลา อาจเพิ่มภาระงานของเครื่องจัดการแท็กได้อย่างมาก
เลือกเหตุการณ์ทริกเกอร์ที่เหมาะสม
ผลกระทบด้านประสิทธิภาพของแท็กไม่มีการเปลี่ยนแปลง โดยทั่วไปแล้ว ยิ่งแท็กเริ่มทำงานได้เร็วขึ้นเท่าใด ผลกระทบที่มีต่อประสิทธิภาพก็จะยิ่งมากขึ้นเท่านั้น โดยปกติทรัพยากรจะถูกจำกัดในระหว่างการโหลดหน้าเว็บครั้งแรก ดังนั้นการโหลดหรือการดำเนินการกับทรัพยากร (หรือแท็ก) หนึ่งๆ จะทำให้ทรัพยากรอื่นหมดไป
แม้ว่าจะต้องเลือกทริกเกอร์ที่เหมาะสมสำหรับแท็กทั้งหมด แต่โดยเฉพาะอย่างยิ่งสำหรับแท็กที่โหลดทรัพยากรขนาดใหญ่หรือเรียกใช้สคริปต์ยาวๆ
แท็กจะทริกเกอร์ได้ในการดูหน้าเว็บ (โดยทั่วไปคือ Page load ใน DOM Ready ใน Window Loaded) หรือตามเหตุการณ์ที่กำหนดเอง ขอแนะนำให้เริ่มการทำงานของแท็กที่ไม่จำเป็นหลังจากวันที่ Window Loaded เพื่อหลีกเลี่ยงไม่ให้เกิดผลกระทบต่อการโหลดหน้าเว็บ
ใช้เหตุการณ์ที่กำหนดเอง
เหตุการณ์ที่กำหนดเอง
ช่วยให้คุณเริ่มทำงานทริกเกอร์เพื่อตอบสนองต่อเหตุการณ์ในหน้าเว็บที่ไม่ได้ครอบคลุมโดยทริกเกอร์ในตัวของ Google Tag Manager ตัวอย่างเช่น แท็กจำนวนมากใช้ทริกเกอร์การดูหน้าเว็บ แต่ระยะเวลาระหว่าง DOM Ready ถึง Window Loaded อาจยาวนานในหลายหน้าเว็บ และอาจทำให้ปรับแต่งเมื่อแท็กเริ่มทำงานได้ยาก เหตุการณ์ที่กำหนดเองช่วยแก้ปัญหานี้ได้
หากต้องการใช้เหตุการณ์ที่กำหนดเอง ให้สร้างทริกเกอร์เหตุการณ์ที่กำหนดเองก่อน แล้วอัปเดตแท็กให้ใช้ทริกเกอร์นี้
ในการเริ่มการทำงานของทริกเกอร์ ให้พุชเหตุการณ์ที่สอดคล้องกันไปยังชั้นข้อมูล
// Custom event trigger that fires after 2 seconds
setTimeout(() => {
dataLayer.push({
'event' : 'my-custom-event'
});
}, 2000);
ใช้เงื่อนไขทริกเกอร์ที่เฉพาะเจาะจง
การใช้เงื่อนไขทริกเกอร์ที่เจาะจงช่วยหลีกเลี่ยงการเริ่มการทำงานของแท็กโดยไม่จำเป็น แม้ว่าจะมีหลายวิธีในการนำแนวคิดนี้ไปใช้ แต่หนึ่งในวิธีที่ง่ายแต่ได้ประโยชน์มากที่สุดที่คุณสามารถทำได้คือตรวจสอบว่าแท็กเริ่มทำงานเฉพาะในหน้าที่ใช้จริงๆ เท่านั้น
คุณยังรวมตัวแปรบิวท์อินไว้ในเงื่อนไขทริกเกอร์เพื่อจำกัดการเริ่มทำงานของแท็กได้ด้วย
อย่างไรก็ตาม โปรดทราบว่าเงื่อนไขทริกเกอร์หรือข้อยกเว้นที่ซับซ้อนต้องใช้เวลาในการประมวลผลด้วยตัวเอง ดังนั้นอย่าทำให้เงื่อนไขหรือข้อยกเว้นซับซ้อนเกินไป
โหลด Tag Manager ในเวลาที่เหมาะสม
การปรับเปลี่ยนเวลาที่เครื่องจัดการแท็กโหลดขึ้นเองอาจมีผลกระทบอย่างมากต่อประสิทธิภาพ ทริกเกอร์ ไม่ว่าจะมีการกำหนดค่าอย่างไร ทริกเกอร์จะไม่สามารถเริ่มทำงานได้จนกว่าเครื่องจัดการแท็กจะโหลดเสร็จ ถึงแม้ว่าคุณควรเลือกทริกเกอร์ที่ดีสำหรับแต่ละแท็ก (ตามที่อธิบายไว้ข้างต้น) แต่การทดสอบเมื่อคุณโหลดเครื่องจัดการแท็กมักจะมีผลกระทบเท่ากันหรือมากกว่า เนื่องจากการตัดสินใจครั้งเดียวจะส่งผลต่อแท็กทั้งหมดในหน้าเว็บ
การโหลด Tag Manager ในภายหลังจะเพิ่มระดับการควบคุมอีกชั้นและช่วยหลีกเลี่ยงปัญหาด้านประสิทธิภาพในอนาคตได้ เนื่องจากจะเป็นการป้องกันไม่ให้ผู้ใช้ Tag Manager โหลดแท็กเร็วเกินไปโดยไม่ทราบถึงผลกระทบที่อาจเกิดขึ้น
ตัวแปร
ตัวแปรช่วยให้อ่านข้อมูลจากหน้าเว็บได้ ซึ่งมีประโยชน์ในทริกเกอร์และ ในแท็กเอง
เช่นเดียวกับทริกเกอร์ ตัวแปรส่งผลให้มีการเพิ่มโค้ด JavaScript ลงในเครื่องจัดการแท็ก และอาจก่อให้เกิดปัญหาด้านประสิทธิภาพได้ ตัวแปรอาจเป็นประเภทในตัวที่ค่อนข้างเรียบง่าย เช่น สำหรับอ่านส่วนต่างๆ ของ URL, คุกกี้, ชั้นข้อมูล หรือ DOM หรืออาจเป็น JavaScript แบบกำหนดเองซึ่งสามารถทำได้แบบไม่จำกัด
รักษาตัวแปรให้เรียบง่ายและน้อยที่สุด เนื่องจาก Tag Manager จะต้องประเมินตัวแปรอย่างต่อเนื่อง นำตัวแปรเก่าที่ไม่ได้ใช้แล้วออกเพื่อลดทั้งขนาดของสคริปต์ Tag Manager และเวลาในการประมวลผลที่ใช้แล้ว
การจัดการแท็ก
การใช้แท็กอย่างมีประสิทธิภาพจะช่วยลดความเสี่ยงจากปัญหาด้านประสิทธิภาพได้
ใช้ชั้นข้อมูล
ชั้นข้อมูล "มีข้อมูลทั้งหมดที่คุณต้องการส่งไปยัง Google Tag Manager" หรือกล่าวให้ชัดเจนยิ่งขึ้นคือ เป็นอาร์เรย์ JavaScript ของออบเจ็กต์ที่มีข้อมูลเกี่ยวกับหน้าเว็บ และยังใช้เพื่อทริกเกอร์แท็กได้ด้วย
// Contents of the data layer
window.dataLayer = [{
'pageCategory': 'signup',
'visitorType': 'high-value'
}];
// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});
// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});
แม้ว่าเราจะใช้ Google Tag Manager ได้โดยไม่ต้องใช้ชั้นข้อมูล แต่เราขอแนะนำเป็นอย่างยิ่งให้ใช้ ชั้นข้อมูลจะให้วิธีรวมข้อมูลที่สคริปต์ของบุคคลที่สามเข้าถึงไว้ในที่เดียว คุณจึงดูข้อมูลการใช้งานได้ดียิ่งขึ้น วิธีนี้ช่วยลดการคำนวณตัวแปรและการเรียกใช้สคริปต์ที่ซ้ำซ้อนได้ การใช้ชั้นข้อมูลยังควบคุมข้อมูลที่แท็กจะเข้าถึง แทนที่จะให้สิทธิ์การเข้าถึงตัวแปร JavaScript หรือ DOM โดยสมบูรณ์
นำแท็กที่ซ้ำและแท็กที่ไม่ได้ใช้ออก
แท็กที่ซ้ำกันอาจเกิดขึ้นเมื่อมีการรวมแท็กไว้ในมาร์กอัป HTML ของหน้าเว็บ นอกเหนือจากการแทรกผ่านเครื่องจัดการแท็ก
คุณควรหยุดชั่วคราวหรือนำแท็กที่ไม่ได้ใช้ออก แทนที่จะบล็อกผ่านการใช้ข้อยกเว้นทริกเกอร์ การหยุดชั่วคราวหรือการนำแท็กออกจะนำโค้ดออกจากคอนเทนเนอร์ การบล็อกจะไม่มีผล
เมื่อนำแท็กที่ไม่ได้ใช้ออก คุณควรตรวจสอบทริกเกอร์และตัวแปรด้วยเพื่อดูว่าจะนำแท็กใดออกได้หรือไม่ หากแท็กเหล่านั้นใช้เฉพาะแท็ก
ใช้รายการอนุญาตและปฏิเสธ
อนุญาตและปฏิเสธรายการ ช่วยให้กำหนดค่าข้อจำกัดอย่างละเอียดเกี่ยวกับแท็ก ทริกเกอร์ และตัวแปรที่อนุญาตในหน้าเว็บได้ ซึ่งอาจนำไปใช้เพื่อช่วยบังคับใช้แนวทางปฏิบัติแนะนำด้านประสิทธิภาพและนโยบายอื่นๆ
การกำหนดค่ารายการอนุญาตและปฏิเสธผ่านชั้นข้อมูล
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
เช่น คุณอาจไม่อนุญาตให้มีแท็ก HTML ที่กำหนดเอง, ตัวแปร JavaScript หรือการเข้าถึง DOM โดยตรง ซึ่งหมายความว่าพิกเซลและแท็กที่กำหนดไว้ล่วงหน้าเท่านั้น ที่สามารถใช้ข้อมูลจากชั้นข้อมูล แม้ว่าการดำเนินการนี้จะมีข้อจำกัดแน่นอน แต่ก็อาจส่งผลให้การใช้งาน Tag Manager มีประสิทธิภาพและปลอดภัยมากยิ่งขึ้น
ลองใช้การติดแท็กฝั่งเซิร์ฟเวอร์
การเปลี่ยนไปใช้การติดแท็กฝั่งเซิร์ฟเวอร์อาจไม่ใช่งานง่ายๆ แต่ก็เป็นสิ่งที่ควรพิจารณา โดยเฉพาะอย่างยิ่งสำหรับเว็บไซต์ขนาดใหญ่ที่ต้องการควบคุมข้อมูลของตนเองมากขึ้น การติดแท็กฝั่งเซิร์ฟเวอร์จะนำโค้ดผู้ให้บริการออกจากไคลเอ็นต์ และด้วยการทำเช่นนี้ จะช่วยลดการประมวลผลจากไคลเอ็นต์ไปยังเซิร์ฟเวอร์
เช่น เมื่อใช้การติดแท็กฝั่งไคลเอ็นต์ การส่งข้อมูลไปยังบัญชี Analytics หลายบัญชีจำเป็นที่จะต้องเริ่มคำขอแยกกันสำหรับปลายทางแต่ละรายการ ในทางตรงกันข้าม ในการติดแท็กฝั่งเซิร์ฟเวอร์ ไคลเอ็นต์จะส่งคำขอเดียวไปยังคอนเทนเนอร์ฝั่งเซิร์ฟเวอร์ และจากนั้นจะมีการส่งต่อข้อมูลนี้ไปยังบัญชี Analytics อื่น
โปรดทราบว่าการติดแท็กฝั่งเซิร์ฟเวอร์ใช้งานได้กับบางแท็กเท่านั้น ความเข้ากันได้ของแท็กจะแตกต่างกันไปตามผู้ให้บริการ
ดูข้อมูลเพิ่มเติมได้ที่ข้อมูลเบื้องต้นเกี่ยวกับการติดแท็กฝั่งเซิร์ฟเวอร์
คอนเทนเนอร์
โดยปกติแล้ว เครื่องจัดการแท็กจะอนุญาตให้มีอินสแตนซ์หรือ "คอนเทนเนอร์" หลายรายการภายในการตั้งค่าของตน ซึ่งทำให้สามารถควบคุมคอนเทนเนอร์หลายรายการภายในบัญชีดูแลจัดการแท็กเดียวได้
ใช้คอนเทนเนอร์เพียง 1 รายการต่อหน้า
การใช้containersหลายรายการในหน้าเดียวอาจสร้างปัญหาด้านประสิทธิภาพที่สำคัญเนื่องจากทำให้เกิดค่าใช้จ่ายเพิ่มเติมและการดำเนินการสคริปต์ อย่างน้อยที่สุดโค้ดจะคัดลอกโค้ดแท็กหลักเอง ซึ่งไม่สามารถนำมาใช้ซ้ำระหว่างคอนเทนเนอร์ได้ เนื่องจากนำส่งโค้ดดังกล่าวเป็นส่วนหนึ่งของ JavaScript ของคอนเทนเนอร์
การใช้คอนเทนเนอร์หลายรายการอย่างมีประสิทธิภาพนั้นแทบจะไม่เกิดขึ้น แต่ก็มีบางกรณีที่การดำเนินการนี้ได้ผล เช่น หากควบคุมได้ดี
- การมีคอนเทนเนอร์ "โหลดล่วงหน้า" เบาและคอนเทนเนอร์ "โหลดภายหลัง" ที่หนักกว่า แทนที่จะเป็นคอนเทนเนอร์ขนาดใหญ่ 1 คอนเทนเนอร์
- การมีคอนเทนเนอร์ที่ถูกจํากัดซึ่งใช้โดยผู้ใช้ทางเทคนิคน้อย ซึ่งมีคอนเทนเนอร์ที่มีการจำกัดน้อยกว่า แต่มีการควบคุมอย่างเข้มงวดมากกว่าสำหรับแท็กที่ไม่สามารถใช้ในคอนเทนเนอร์ที่ถูกจํากัด
หากคุณต้องใช้หลายคอนเทนเนอร์ต่อหน้า ให้ทำตามคำแนะนำของ Google Tag Manager ในการตั้งค่าคอนเทนเนอร์หลายรายการ
ใช้คอนเทนเนอร์แยกกันหากจำเป็น
หากคุณใช้เครื่องจัดการแท็กสำหรับพร็อพเพอร์ตี้หลายรายการ (เช่น เว็บแอปและแอปบนอุปกรณ์เคลื่อนที่) จำนวนคอนเทนเนอร์ที่ใช้อาจส่งผลเสียต่อประสิทธิภาพการทำงานของเวิร์กโฟลว์ และอาจส่งผลต่อประสิทธิภาพด้วย
โดยทั่วไปแล้ว คอนเทนเนอร์เดียวสามารถใช้ในหลายๆ เว็บไซต์ได้อย่างมีประสิทธิภาพหากเว็บไซต์นั้นมีการใช้งานและโครงสร้างคล้ายกัน ตัวอย่างเช่น แม้ว่าแอปบนอุปกรณ์เคลื่อนที่และเว็บแอปของแบรนด์อาจทำหน้าที่คล้ายคลึงกัน แต่มีแนวโน้มว่าแอปจะมีโครงสร้างแตกต่างออกไป และทำให้มีการจัดการได้อย่างมีประสิทธิภาพมากขึ้นผ่านคอนเทนเนอร์ที่แยกกัน
การพยายามนำคอนเทนเนอร์เดียวกลับมาใช้ใหม่แบบกว้างเกินไปมักจะเพิ่มความซับซ้อนและขนาดของคอนเทนเนอร์โดยไม่จำเป็นโดยการบังคับให้ใช้ตรรกะที่ซับซ้อนเพื่อจัดการแท็กและทริกเกอร์
คอยตรวจสอบขนาดคอนเทนเนอร์
ขนาดของคอนเทนเนอร์จะกำหนดโดยแท็ก ทริกเกอร์ และตัวแปร แม้ว่าคอนเทนเนอร์ขนาดเล็กอาจยังส่งผลเสียต่อประสิทธิภาพของหน้าเว็บ แต่คอนเทนเนอร์ขนาดใหญ่มักจะส่งผลเสียอยู่แล้ว
ขนาดคอนเทนเนอร์ไม่ควรเป็นเมตริกที่ดาวเหนือเมื่อเพิ่มประสิทธิภาพการใช้แท็ก อย่างไรก็ตาม คอนเทนเนอร์ขนาดใหญ่มักเป็นเครื่องหมายเตือนว่าคอนเทนเนอร์ไม่ได้รับการดูแลที่ดีและอาจมีการนำไปใช้ในทางที่ผิด
ขีดจำกัดคอนเทนเนอร์ของ Google Tag Manager อยู่ที่ 200 KB และจะเตือนเกี่ยวกับขนาดคอนเทนเนอร์เริ่มต้นที่ 140 KB อย่างไรก็ตาม เว็บไซต์ส่วนใหญ่ควรให้คอนเทนเนอร์มีขนาดเล็กกว่านี้มาก ในมุมมองนี้ คอนเทนเนอร์เว็บไซต์ตามค่ามัธยฐานคือประมาณ 50 KB
หากต้องการกำหนดขนาดของคอนเทนเนอร์ ให้ดูที่ขนาดของการตอบกลับที่ส่งคืนโดย https://www.googletagmanager.com/gtag/js?id=YOUR_ID การตอบกลับนี้ประกอบด้วยไลบรารี Google Tag Manager รวมถึงเนื้อหาของคอนเทนเนอร์ โดยไลบรารีของ Google Tag Manager จะบีบอัดด้วยตัวเองประมาณ 33 KB
ตั้งชื่อเวอร์ชันคอนเทนเนอร์
เวอร์ชันคอนเทนเนอร์คือสแนปชอตเนื้อหาคอนเทนเนอร์ ณ เวลาใดเวลาหนึ่ง การใช้ชื่อที่สื่อความหมายและรวมถึงการใส่คำอธิบายสั้นๆ เกี่ยวกับการเปลี่ยนแปลงที่มีความหมายภายในอาจมีประโยชน์อย่างมากต่อการแก้ปัญหาด้านประสิทธิภาพในอนาคตได้ง่ายขึ้น
เวิร์กโฟลว์การติดแท็ก
การจัดการการเปลี่ยนแปลงแท็กเป็นสิ่งสำคัญในการตรวจสอบว่าการเปลี่ยนแปลงเหล่านั้นไม่มีผลกระทบเชิงลบต่อประสิทธิภาพของหน้าเว็บ
ทดสอบแท็กก่อนนำไปใช้งาน
การทดสอบแท็กก่อนทำให้ใช้งานได้จะช่วยแก้ปัญหาได้ (ประสิทธิภาพและอื่นๆ) ก่อนที่จะจัดส่ง
สิ่งที่ต้องพิจารณาเมื่อทดสอบแท็ก ได้แก่
- แท็กทำงานอย่างถูกต้องหรือไม่
- แท็กทําให้เลย์เอาต์เปลี่ยนแปลงไหม
- แท็กโหลดทรัพยากรใดๆ ไหม ทรัพยากรเหล่านี้ใหญ่แค่ไหน
- แท็กเรียกใช้สคริปต์ที่ใช้เวลานานไหม
โหมดแสดงตัวอย่าง
โหมดแสดงตัวอย่างช่วยให้คุณทดสอบการเปลี่ยนแปลงแท็กในเว็บไซต์จริงได้โดยไม่ต้องนำไปใช้กับสาธารณะก่อน โหมดแสดงตัวอย่างจะมีคอนโซลดีบักที่ให้ข้อมูลเกี่ยวกับแท็ก
เวลาดำเนินการของ Google Tag Manager จะแตกต่างกัน (ช้าลงเล็กน้อย) เมื่อทำงานในโหมดแสดงตัวอย่าง เนื่องจากต้องมีค่าใช้จ่ายเพิ่มเติมเพื่อแสดงข้อมูลในคอนโซลการแก้ไขข้อบกพร่อง เราจึงไม่แนะนําให้เปรียบเทียบการวัด Web Vitals ที่รวบรวมในโหมดแสดงตัวอย่างกับการวัดในเวอร์ชันที่ใช้งานจริง อย่างไรก็ตาม ความคลาดเคลื่อนนี้จะไม่ส่งผลต่อลักษณะการเรียกใช้แท็กด้วยตัวเอง
การทดสอบแบบสแตนด์อโลน
อีกทางเลือกหนึ่งในการทดสอบแท็กคือการตั้งค่าหน้าว่างซึ่งมีคอนเทนเนอร์ที่มีแท็กเดียว ซึ่งก็คือแท็กที่คุณกำลังทดสอบ การตั้งค่าการทดสอบนี้ไม่สมจริงและไม่พบปัญหาบางอย่าง (เช่น แท็กทําให้เลย์เอาต์เปลี่ยนหรือไม่) แต่จะช่วยให้แยกและวัดผลกระทบของแท็กกับสิ่งต่างๆ เช่น การเรียกใช้สคริปต์ได้ง่ายขึ้น ลองดูวิธีที่ Telegraph จะใช้แนวทางการแยกนี้เพื่อปรับปรุงประสิทธิภาพของโค้ดของบุคคลที่สาม
ตรวจสอบประสิทธิภาพของแท็ก
API การตรวจสอบของ Google Tag Manager สามารถใช้รวบรวมข้อมูลเกี่ยวกับเวลาดำเนินการของแท็กหนึ่งๆ ข้อมูลนี้จะรายงานไปยังปลายทางการเลือกของคุณ
ดูข้อมูลเพิ่มเติมได้ที่วิธีสร้างเครื่องมือตรวจสอบ Google Tag Manager
ต้องอนุมัติการเปลี่ยนแปลงคอนเทนเนอร์
โดยทั่วไปโค้ดของบุคคลที่หนึ่งจะผ่านการตรวจสอบและทดสอบก่อนการติดตั้งใช้งาน และคุณจะต้องพิจารณาแท็กในลักษณะเดียวกัน การเพิ่มการยืนยัน 2 ขั้นตอนซึ่งต้องมีการอนุมัติจากผู้ดูแลระบบสำหรับการเปลี่ยนแปลงคอนเทนเนอร์เป็นวิธีหนึ่งในการดำเนินการ หรือหากไม่ต้องการใช้การยืนยันแบบ 2 ขั้นตอน แต่ยังคงต้องการติดตามการเปลี่ยนแปลง คุณสามารถสร้างการแจ้งเตือนคอนเทนเนอร์เพื่อรับการแจ้งเตือนทางอีเมลเกี่ยวกับเหตุการณ์คอนเทนเนอร์ที่เลือกได้
ตรวจสอบการใช้แท็กเป็นระยะๆ
ความท้าทายอย่างหนึ่งของการทำงานกับแท็กคือ แท็กเหล่านี้มักจะเกิดสะสมมากขึ้นเมื่อเวลาผ่านไป: มีการเพิ่มแท็กแต่ไม่ค่อยถูกนำออก การตรวจสอบแท็กเป็นระยะๆ เป็นวิธีหนึ่ง ในการกลับแนวโน้มนี้ ความถี่ที่เหมาะสมในการดำเนินการนี้จะขึ้นอยู่กับความถี่ในการอัปเดตแท็กของเว็บไซต์
การติดป้ายกำกับแต่ละแท็กเพื่อให้เจ้าของเห็นได้ชัดเจนยิ่งขึ้นว่าผู้ใดบ้างที่ตอบสนองต่อแท็กนั้น และยังบอกได้ว่าจำเป็นต้องใช้หรือไม่
เมื่อตรวจสอบแท็ก อย่าลืมล้างทริกเกอร์และตัวแปรด้วย นอกจากนี้ ยังอาจเป็นสาเหตุของปัญหาด้านประสิทธิภาพได้อย่างง่ายดายเช่นกัน
ดูข้อมูลเพิ่มเติมได้ที่การควบคุมสคริปต์ของบุคคลที่สามให้อยู่ภายใต้การควบคุม