สคริปต์ภายนอก: แท็ก พิกเซล และวิดเจ็ต ทำให้เว็บช้าได้อย่างไร

แท็กวิเคราะห์ พิกเซลโฆษณา วิดเจ็ตแชต และวิดีโอที่ฝังไว้ทุกตัวบนเว็บไซต์ของคุณ คือสคริปต์ภายนอก (third-party script) หรือโค้ดที่คนอื่นเขียน ซึ่งทำงานบนมือถือของผู้เข้าชม ขณะที่หน้าเว็บของคุณเองกำลังพยายามโหลด ถ้ามีแค่หนึ่งหรือสองตัวมักไม่เป็นปัญหา แต่ถ้ามี 15 ตัวที่เพิ่มเข้ามาตลอดหลายปีสำหรับแคมเปญต่าง ๆ ก็มักเป็นปัญหา และเป็นสาเหตุที่พบบ่อยที่ทำให้เว็บไซต์ที่เคยเร็วตอนเปิดตัว กลับรู้สึกอืดในภายหลัง

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

คำตอบสั้น ๆ

สคริปต์ภายนอกทำให้เว็บไซต์ช้าลงได้ 4 ทาง:

• แย่งเธรดหลัก ซึ่งเบราว์เซอร์ใช้รับการแตะด้วย การโต้ตอบจึงหน่วง และค่า INP (ระยะเวลาจากการโต้ตอบ ถึงการแสดงผลถัดไป) แย่ลง
• หน่วงเนื้อหาหลัก ด้วยการบล็อกการแสดงผล ซ่อนหน้าเว็บระหว่างการทดสอบ หรือแย่งแบนด์วิดท์ ซึ่งทำให้ Largest Contentful Paint หรือ LCP แย่ลง
• เพิ่มการเชื่อมต่อและคำขอ เพราะแท็กหนึ่งตัวมักโหลดไฟล์อื่นอีกหลายไฟล์จากโดเมนอื่น
• ทำให้ของบนหน้าขยับ เมื่อวิดเจ็ตและแบนเนอร์มาถึงช้า ทำให้ Cumulative Layout Shift หรือ CLS สูงขึ้น

วิธีแก้: ทำรายการสิ่งที่โหลด เอาสิ่งที่ไม่มีใครใช้ออก โหลดที่เหลือเฉพาะหน้าและจังหวะที่จำเป็น เปลี่ยนเนื้อหาฝังที่หนักเป็น “facade” ที่เบา และชั่งแท็กใหม่ทุกตัวเทียบกับ performance budget

สคริปต์ภายนอกทำให้หน้าเว็บช้าอย่างไร

แย่งเธรดหลัก

หน้าเว็บมีเธรดหลักเพียงหนึ่งเธรด ซึ่งรัน JavaScript คำนวณเลย์เอาต์ วาดหน้าจอ และตอบสนองต่อการแตะ ทีละงาน งานใดที่ใช้เวลาเกิน 50 มิลลิวินาที ถือเป็นงานยาว (long task) และระหว่างที่งานนั้นยังรันอยู่ การแตะของผู้เข้าชมต้องรอ

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

อาจหน่วงเนื้อหาหลักไว้

• สคริปต์ที่บล็อก แท็ก <script> ธรรมดาในส่วน head ของหน้า ที่ไม่มี async หรือ defer จะหยุดเบราว์เซอร์ไม่ให้สร้างหน้าต่อ จนกว่าจะดาวน์โหลดและรันเสร็จ ถ้าเซิร์ฟเวอร์ของผู้ให้บริการช้า หน้าเว็บของคุณก็ต้องรอ อธิบายทรัพยากรที่บล็อกการแสดงผล อธิบายกลไกนี้
• โค้ดกันกะพริบ (anti-flicker) เครื่องมือ A/B testing ฝั่งเบราว์เซอร์มักซ่อนหน้าเว็บไว้จนกว่าสคริปต์จะมาถึงหรือจนหมดเวลา ระหว่างที่หน้าถูกซ่อน เนื้อหาหลักของคุณยังไม่ถูกนับว่าแสดงผลแล้ว LCP จึงต้องรอ
• แบนด์วิดท์ บนการเชื่อมต่อที่ช้า สคริปต์ที่โหลดก่อนจะแย่งแบนด์วิดท์กับภาพฮีโร่ของคุณ
• แบนเนอร์กลายเป็นเนื้อหาหลัก บนมือถือ แบนเนอร์คุกกี้ที่มีข้อความยาวหนึ่งย่อหน้า อาจเป็นองค์ประกอบที่ใหญ่ที่สุดบนจอ LCP จึงต้องรอให้สคริปต์ขอความยินยอมวาดแบนเนอร์นั้นขึ้นมา

เพิ่มคำขอ และทำให้ของบนหน้าขยับ

ทุกโดเมนใหม่ต้องมีการค้นหา DNS การเชื่อมต่อ และการยืนยันความปลอดภัย (handshake) และแท็กที่คุณเพิ่มมักเป็นแค่ตัวโหลดสำหรับไลบรารีที่ใหญ่กว่า iframe และ beacon สำหรับติดตาม แท็ก 10 ตัวใน tag manager อาจหมายถึงคำขอหลายสิบรายการในเบราว์เซอร์ วิดเจ็ตที่มาถึงหลังหน้าวาดเสร็จแล้ว ยังดันเนื้อหาลงในจังหวะที่คนกำลังจะแตะพอดี

ตัวการที่พบบ่อย และต้นทุนของแต่ละตัว

ต้นทุนต่างกันไปตามผู้ให้บริการและการตั้งค่า แต่นี่คือจุดที่ควรดูก่อน:

ผู้ช่วยแชต AI ควรถูกตรวจอย่างเข้มงวดเหมือนวิดเจ็ตอื่น ๆ บทความ เพิ่ม AI ให้เว็บไซต์ พิจารณาว่าฟีเจอร์ AI ไหนคุ้มค่าที่จะมี

วิธีดูว่ามีอะไรโหลดอยู่จริง

เริ่มจาก tag manager แล้วดูให้ไกลกว่านั้น

ทำรายการแท็กทุกตัวใน Google Tag Manager หรือ tag manager ที่คุณใช้ พร้อม trigger ของแต่ละตัว แต่อย่าหยุดแค่นั้น เพราะสคริปต์ยังเข้ามาทางธีม ปลั๊กอิน WordPress โค้ดที่แปะในส่วนหัว และบล็อกของ page builder มีแค่เบราว์เซอร์ที่แสดงรายการได้ครบทั้งหมด

PageSpeed Insights: ผู้ให้บริการไหนกินทรัพยากรมากที่สุด

ทดสอบหน้าแรก และเทมเพลตสำคัญหนึ่งหรือสองแบบบนมือถือ โดยใช้ผลตรงกลางจาก 3 ครั้ง ผลจากแล็บมีตารางแยกบริการภายนอกตามผู้ให้บริการ พร้อมขนาดที่ส่งผ่านและเวลาบนเธรดหลัก ชื่อหัวข้อนี้เปลี่ยนไปตามเวอร์ชันของ Lighthouse จึงควรค้นหาคำว่า “third-party” หรือ “3rd parties” ในรายงาน วิธีอ่านรายงาน PageSpeed Insights อธิบายส่วนที่เหลือ

Chrome DevTools: รายการครบทั้งหมด

1. เปิดหน้าเว็บในหน้าต่างส่วนตัว คลิกขวา เลือก Inspect แล้วเปิดแผง Network
2. ติ๊ก “Disable cache” เลือกค่าจำลองความเร็วแบบมือถือ แล้วโหลดใหม่
3. ใน “More filters” ติ๊ก “3rd-party requests” (หรือพิมพ์ -domain:*yourdomain.com ในช่องกรอง) เรียงที่เหลือตามโดเมน เพื่อจัดกลุ่มแต่ละผู้ให้บริการ แล้วเรียงตามขนาด
4. กดยอมรับแบนเนอร์คุกกี้ แล้วโหลดใหม่ แท็กจำนวนมากโหลดหลังได้รับความยินยอมเท่านั้น คุณจึงกำลังทดสอบหน้าเว็บ 2 เวอร์ชัน
5. ในแผง Performance บันทึกการโหลดใหม่ โดยจำลอง CPU ให้ช้าลง แล้วมองหางานยาวที่ถูกทำเครื่องหมายสีแดง ใน Chrome เวอร์ชันใหม่ ๆ แท็บ Summary ยังแสดงเวลาบนเธรดหลักและขนาดที่ส่งผ่านของแต่ละบริการภายนอกด้วย

วัดต้นทุนของสคริปต์ทีละตัว คลิกขวาที่คำขอหนึ่งของผู้ให้บริการ บล็อกโดเมนนั้น (ในเมนู “Block request” ของเวอร์ชันใหม่ ๆ) โหลดใหม่ แล้วเปรียบเทียบ นี่คือวิธีที่เร็วที่สุดในการดูว่าวิดเจ็ตตัวเดียวมีต้นทุนเท่าไร และอย่าลืมยกเลิกการบล็อกหลังจากนั้น เพราะ DevTools จะจำไว้ ถ้ายังไม่แน่ใจว่าบริการภายนอกคือปัญหาหลักหรือไม่ ทำไมเว็บไซต์ช้า? อธิบายการวินิจฉัยแบบครบถ้วน

จัดทำทะเบียนแท็ก

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

วิธีลดโค้ดจากภายนอก โดยไม่เสียการติดตามผล

ทำตามลำดับนี้ สองข้อแรกไม่ต้องใช้เครื่องมือใหม่ และมักได้ผลมากที่สุด

1. เอาแท็กที่ไม่ใช้แล้วและแท็กซ้ำออก

สิ่งที่มักเจอบนเว็บไซต์เก่า:

• พิกเซลจากแคมเปญที่จบแล้ว และเครื่องมือที่หลงเหลือจากช่วงทดลองใช้ฟรี
• แท็ก Universal Analytics ซึ่ง Google หยุดประมวลผลไปตั้งแต่กรกฎาคม 2023 (กรกฎาคม 2024 สำหรับ property แบบ 360)
• โค้ด Google Optimize รวมถึงโค้ดกันกะพริบที่ทำได้แค่ซ่อนหน้าเว็บ ซึ่งหลงเหลืออยู่ตั้งแต่ผลิตภัณฑ์ปิดตัวในเดือนกันยายน 2023
• GA4 ที่ติดตั้งซ้ำ 2 ครั้ง ทั้งจากปลั๊กอินและจาก tag manager ซึ่งทำให้นับการดูหน้าเว็บซ้ำด้วย

ปิดการทำงานของแท็กที่ไม่มีเจ้าของไว้ 2 สัปดาห์ ถ้าไม่มีใครบ่น ก็เอาออก ประวัติเวอร์ชันของ Tag Manager เก็บการตั้งค่าเดิมไว้ เผื่อต้องการใช้อีก

2. โหลดเฉพาะในหน้าที่ต้องใช้

แผนที่ควรอยู่ในหน้าติดต่อ วิดเจ็ตจองควรอยู่ในหน้าจอง แพลตฟอร์มโฆษณาต้องระวังมากกว่านั้น เพราะ event คอนเวอร์ชันทำงานเฉพาะเมื่อส่งฟอร์มสำเร็จ แต่ base tag (หรือ conversion linker ของ Google) มักทำงานในทุกหน้า เพื่อบันทึกว่าโฆษณาไหนพาผู้เข้าชมมา และการทำ retargeting ต้องใช้ข้อมูลจากทุกหน้าเพื่อสร้างกลุ่มเป้าหมาย ให้ทำตามคำแนะนำของแต่ละแพลตฟอร์ม

3. โหลดทีหลัง

ใน Google Tag Manager ย้ายแท็กที่ไม่จำเป็นต้องใช้ทันที จาก trigger แบบ Page View ไปเป็น Window Loaded หรือให้ทำงานหลังการเลื่อนหรือคลิกครั้งแรก ส่วนเครื่องมือขอความยินยอมและระบบวิเคราะห์หลักให้โหลดตั้งแต่ต้น เพื่อให้การเข้าชมสั้น ๆ ยังถูกนับ สำหรับสคริปต์ที่ใส่ในหน้าโดยตรง ใช้ defer หรือ async ถ้าคำแนะนำของผู้ให้บริการอนุญาต

อะไรที่โหลดทีหลังจะพลาดผู้เข้าชมที่ออกไปภายในไม่กี่วินาที ซึ่งแทบไม่มีผลกับ heatmap และ key event ก็ยังทำงานเมื่อเกิดการกระทำนั้นจริง

4. เปลี่ยนเนื้อหาฝังที่หนักเป็น facade

Facade คือตัวแทนน้ำหนักเบาที่หน้าตาเหมือนของจริง และจะโหลดของจริงเมื่อมีการโต้ตอบเท่านั้น ซึ่งเป็นรูปแบบที่คำแนะนำด้านประสิทธิภาพของ Google แนะนำ

• วิดีโอ: แสดงภาพตัวอย่างและปุ่มเล่น แล้วโหลดตัวเล่นเมื่อคลิก facade สำหรับวิดีโอ YouTube ที่ฝังไว้ คือหนึ่งในวิธีที่ได้ผลง่ายที่สุด
• แผนที่: แสดงภาพแผนที่นิ่ง พร้อมลิงก์ “ดูเส้นทาง” หรือโหลดแผนที่เมื่อคลิก
• แชต: ปุ่มที่หน้าตาเหมือนตัวเปิดแชต จะโหลดวิดเจ็ตเมื่อถูกกด ข้อความทักทายอัตโนมัติจะไม่ปรากฏ จึงควรดูประวัติแชตของคุณ ถ้าผู้เข้าชมเป็นฝ่ายเริ่มบทสนทนาเป็นส่วนใหญ่ คุณก็เสียไม่มาก

สร้าง facade แต่ละตัวเป็น <button> จริง พร้อมป้ายกำกับที่ชัดเจน (“เล่นวิดีโอ: ขั้นตอนการทำงานของเรา”) เพื่อให้คนที่ใช้คีย์บอร์ดและโปรแกรมอ่านหน้าจอใช้งานได้ สำหรับเนื้อหาฝังที่อยู่ลึกลงไป ใส่ loading="lazy" ใน iframe เพื่อให้รอจนผู้เข้าชมเลื่อนเข้าไปใกล้

5. พิจารณา server-side tagging ในกรณีที่เหมาะสม

ด้วย server-side tagging หน้าเว็บจะส่ง event ชุดเดียวไปยังเซิร์ฟเวอร์ที่คุณควบคุม เช่น server container ของ Google Tag Manager ซึ่งส่งต่อไปยังระบบวิเคราะห์และแพลตฟอร์มโฆษณา สคริปต์ของผู้ให้บริการที่รันบนมือถือของผู้เข้าชมจึงน้อยลง และคุณควบคุมได้ว่าข้อมูลอะไรถูกส่งออกไป

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

หลังเปลี่ยนแปลงใด ๆ ให้ตรวจการติดตามผล ทดสอบในโหมด preview ของ Tag Assistant แล้วเทียบ key event กับการติดต่อสอบถามจริง เป็นเวลาสัก 2 สัปดาห์ บทความ การติดตามคอนเวอร์ชันใน GA4 ของเรา แสดงวิธีทำ

ตั้ง performance budget สำหรับโค้ดจากภายนอก

Performance budget (งบประสิทธิภาพ) คือชุดข้อจำกัดสั้น ๆ ที่ตกลงกันไว้ก่อนจะเพิ่มอะไรใหม่ วัดค่าฐานบนมือถือจากเทมเพลตสำคัญ 3 หรือ 4 แบบ แล้วตั้งกฎเทียบกับค่านั้น ไม่ใช่เทียบกับค่าในอุดมคติ

มีแค่บรรทัดแรกที่ใช้เกณฑ์ที่ Google เผยแพร่ ส่วนที่เหลือเป็นกฎภายในที่เปลี่ยนความรู้สึกว่า “เว็บดูช้าลง” ให้เป็นคำถามที่ตอบได้ว่าใช่หรือไม่

ขั้นตอนอนุมัติแท็ก ที่กันไม่ให้เว็บกลับมาช้า

เว็บไซต์ที่ช้าแทบไม่เคยเกิดจากการตัดสินใจแย่ ๆ ครั้งเดียว แต่เกิดจากการตัดสินใจที่ฟังขึ้น 20 ครั้งที่ไม่มีใครกลับไปทบทวน

ก่อนแท็กใหม่จะเริ่มทำงาน:

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

ทุกไตรมาส ไล่ดูทะเบียนแท็ก เอาสิ่งที่หมดอายุออก รันการทดสอบค่าฐานใหม่ และตรวจรายงาน Core Web Vitals ใน Search Console

จำกัดคนที่เผยแพร่ได้ Google Tag Manager แยกสิทธิ์แก้ไขออกจากสิทธิ์เผยแพร่ จึงควรให้สิทธิ์เผยแพร่เฉพาะคนหนึ่งหรือสองคนที่ดูแลเว็บไซต์และรู้เรื่องงบ

ขั้นตอนถัดไป

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

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