Google Analytics ทำให้ Core Web Vitals ล้มเหลว: ขั้นตอนถัดไป

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

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

• Largest Contentful Paint (LCP) วัดเวลาโหลดเริ่มต้น
• การโต้ตอบกับ Next Paint (INP) วัดการตอบสนอง
• Cumulative Layout Shift (CLS) วัดความเสถียรของโครงร่าง

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

ดังนั้นจึงเป็นเรื่องที่น่าประหลาดใจอย่างยิ่งเมื่อ Analytics ของ Google ดูเหมือนจะทำให้การประเมิน Core Web Vitals ล้มเหลว

มาสอบสวนกันเถอะ!

Google Analytics ทำงานอย่างไร?

Google Analytics ทำงานโดยติดตามการโต้ตอบของผู้ใช้บนเว็บไซต์และให้ข้อมูลเชิงลึกเกี่ยวกับพฤติกรรมผู้ใช้ แหล่งที่มาของการเข้าชม และ Conversion มีการใช้งานบนเว็บไซต์โดยการเพิ่มข้อมูลโค้ดติดตามที่ได้รับจาก Google Analytics

ข้อมูลโค้ด JavaScript นี้หรือที่เรียกว่าแท็กที่ติดทั่วเว็บไซต์ (gtag.js) จะเข้าไปอยู่ในส่วนของเว็บไซต์ในทุกหน้าเว็บที่คุณต้องการติดตาม

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

จนถึงตอนนี้ดีมาก

ตอนนี้เรามาดูกันว่าเกิดอะไรขึ้นภายใต้ประทุน

ผลกระทบต่อประสิทธิภาพ (มองใกล้)

เมื่อตรวจสอบอย่างใกล้ชิดกับแคชที่ปิดใช้และไม่มีการเพิ่มประสิทธิภาพที่ทำงานอยู่ เราพบว่า gtag.js โหลดเป็นคำขอ HTTP เดียวซึ่งมีน้ำหนักเพียง 111kB พร้อมด้วย Microsoft Clarity gtag ที่ 769B

เท่าที่การโหลดหน้าเว็บครั้งแรกดำเนินไป โค้ดติดตามของ Google Analytics จะแสดงพฤติกรรมที่คาดหวัง และไม่สนับสนุนคำขอ HTTP ที่มากเกินไป, JavaScript ที่ไม่ได้ใช้ หรือเธรดหลักที่ถูกบล็อก

แล้วความเข้าใจผิดมันมาจากไหน?

Google Analytics ส่งผลต่อ Core Web Vitals จริงหรือ

การเพิ่มการติดตามของ Google Analytics ลงในเว็บไซต์ของคุณเพียงอย่างเดียวไม่เสี่ยงที่จะล้มเหลวในการประเมิน Core Web Vitals (หรือ Lagest Contentful Paint โดยเฉพาะ) นี่เป็นเพียงเพราะว่าตัวอย่างข้อมูลที่วางอยู่ใน ส่วนหัว ของหน้าเว็บมีน้ำหนักเบามาก และไม่ปิดกั้นกระบวนการสำคัญใดๆ ในการแสดงเนื้อหาของหน้าเว็บ

แล้วเหตุใดเจ้าของเว็บไซต์จึงลิงก์ Core Web Vitals กับ Google Analytics ไม่สำเร็จ

ความแตกต่างระหว่างข้อมูลห้องปฏิบัติการและข้อมูลภาคสนาม

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

มาเคลียร์ความสับสนกันดีกว่า

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

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

การประเมิน Core Web Vitals ตามข้อมูลภาคสนามสำหรับ amazon.com

ก่อนที่ Core Web Vitals ของ Google จะกลายเป็นมาตรฐานสำหรับประสบการณ์ผู้ใช้ที่ยอดเยี่ยม เราใช้คะแนนประสิทธิภาพ (วัดจาก 0 ถึง 100) ซึ่งปัจจุบันแสดงหลังการประเมิน CWV

คะแนนประสิทธิภาพขึ้นอยู่กับข้อมูลห้องปฏิบัติการสำหรับ amazon.com

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

ดังที่คุณเห็นจากภาพหน้าจอด้านบน Amazon กำลังส่ง Core Web Vitals ด้วยสีพิเศษ แต่ในสภาพแวดล้อมที่มีการควบคุม ปัญหา Total Blocking Time (TBT), ดัชนีความเร็ว (SI) และ LCP จะถูกตั้งค่าสถานะเพื่อการปรับปรุงเพิ่มเติม นั่นเป็นวิธีที่ดีในการแยกปัญหาเฉพาะและดำเนินการเพิ่มประสิทธิภาพ

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

คำตัดสินสุดท้าย

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

แล้ว Google Tag Manager และ Google AdSense ล่ะ?

ในความเป็นจริง เจ้าของไซต์แทบจะไม่ได้ทำการตั้งค่าการวิเคราะห์และเรียกมันเลยซักวัน

Google Tag Manager และ Google AdSense เป็นเครื่องมือยอดนิยมสำหรับธุรกิจออนไลน์ที่ต้องการติดตามเหตุการณ์เฉพาะและแสดงโฆษณาบนเว็บไซต์ของตนเพื่อเพิ่มรายได้จากการเข้าชมที่เข้ามา

แม้ว่า Google Analytics จะไม่ใช่สาเหตุของปัญหาด้านประสิทธิภาพ แต่วิศวกรของเราที่ NitroPack จะทำการวิเคราะห์เชิงลึกเพื่อระบุผู้กระทำผิดที่แท้จริงเสมอ

จากตัวอย่างก่อนหน้านี้กับ kiteworks.com เราจะเห็นว่าเมื่อมีการโต้ตอบกับหน้าแรก แท็กเหตุการณ์พิเศษ (gtm.js) จากเครื่องจัดการแท็กจะเริ่มทำงาน

และนั่นคือแท็ก gtm.js ที่เพิ่มขึ้นจำนวนมาก จึงมีคำขอ HTTP มากเกินไป

เนื่องจากโค้ด Google Analytics จะโหลดก่อนสิ่งอื่นใด เมื่อเว็บไซต์ของคุณมีแท็กเหตุการณ์จำนวนมาก คุณสามารถคาดหวังได้ว่าข้อมูลโค้ด GA จะเรียกใช้ gtm.js อื่นๆ ทั้งหมด ส่งผลให้เกิดความล่าช้าในการโหลดและทำให้ผลลัพธ์ในเมตริกแย่ลง เช่น:

• สีที่เต็มไปด้วยความพึงพอใจที่ใหญ่ที่สุด
• เวลาการบล็อกทั้งหมด
• สีความพึงพอใจครั้งแรก (FCP)

ในรายงาน PSI ของคุณ สตริงดังกล่าวจะถูกทำเครื่องหมายโดยคำเตือน "ลด JavaScript ที่ไม่ได้ใช้":

และหาก Google Tag Manager ของคุณมีลักษณะเช่นนี้จากระยะไกล ก็ถึงเวลาที่จะจัดระเบียบและจัดระเบียบใหม่:

แก้ไข “ลด JavaScript ที่ไม่ได้ใช้” ที่เกิดจาก Google Tag Manager

ขั้นตอนแรกของคุณคือการหน่วงเวลาสคริปต์บุคคลที่สามด้วยแอตทริบิวต์ async หรือ defer และปล่อยให้สคริปต์โหลดในเบื้องหลัง คุณลักษณะเหล่านี้เปลี่ยนสคริปต์ให้ไม่ปิดกั้นและลดผลกระทบโดยรวมของโค้ดของบุคคลที่สาม

แม้ว่าจะคล้ายกัน แต่แอตทริบิวต์เหล่านี้มีความแตกต่างที่สำคัญ:

• สคริปต์ที่มีแอตทริบิวต์ defer จะรักษาลำดับที่สัมพันธ์กัน เบราว์เซอร์ไม่รอให้แสดงผลหน้าเว็บ แต่ดำเนินการตามลำดับ ตัวอย่างเช่น เรามีสองสคริปต์ — สคริปต์ 1 และสคริปต์ 2 — ตามลำดับนั้น หากเราเลื่อนทั้งสองอย่างออกไป เบราว์เซอร์จะเรียกใช้สคริปต์ 1 ก่อนเสมอ แม้ว่าสคริปต์ 2 จะถูกดาวน์โหลดก่อนก็ตาม
• สคริปต์ที่มีแอตทริบิวต์ async มีความเป็นอิสระอย่างสมบูรณ์ ขึ้นอยู่กับว่าโหลดใดก่อนจะถูกดำเนินการก่อน

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

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

ลด JavaScript ที่ไม่ได้ใช้และเพิ่มประสิทธิภาพทรัพยากรทั้งหมดของเว็บไซต์ของคุณด้วย NitroPack →

ความเสี่ยงและการแลกเปลี่ยนกับ Google AdSense

เมื่อเจ้าของไซต์กำหนดหน่วยโฆษณาในรูปแบบต่างๆ บนหน้าเว็บ Google AdSense จะจัดเตรียมข้อมูลโค้ด (HTML/JavaScript) ให้กับหน่วยโฆษณาแต่ละหน่วยซึ่งวางลงใน HTML ของหน้าเว็บไซต์ของตนในตำแหน่งที่โฆษณาควรปรากฏ

เมื่อผู้ใช้เยี่ยมชมหน้าเว็บที่มีโค้ดโฆษณา AdSense เบราว์เซอร์จะรันโค้ด JavaScript ที่ AdSense ให้มา ซึ่งสร้างรายได้ให้กับเจ้าของไซต์เมื่อแสดงผล

ขออภัย เนื่องจากคุณสมบัติในการบล็อกการแสดงผล โฆษณา AdSense จึงอาจส่งผลกระทบต่อประสิทธิภาพของไซต์ (และโดยเฉพาะ Web Vitals เช่น LCP และ CLS)

ด้วย NitroPack เจ้าของไซต์สามารถเลือก "เพิ่มประสิทธิภาพโฆษณา" ซึ่งจะทำให้ JS ล่าช้าจนกว่าจะมีการโต้ตอบกับผู้ใช้ แต่เนื่องจาก AdSense ทำงานตามการแสดงผล จึงอาจส่งผลให้สูญเสียรายได้จากโฆษณาบางส่วน

ในกรณีนี้ คุณควรตัดสินใจว่าอะไรเป็นประโยชน์ต่อธุรกิจของคุณมากกว่า โดยพิจารณาจากพฤติกรรมของผู้ชมของคุณ:

1) ประสิทธิภาพสูงสุดเพื่อประสบการณ์การท่องเว็บที่ดีขึ้น

หรือ

2) สร้างรายได้จากโฆษณาให้ได้มากที่สุดเท่าที่จะเป็นไปได้ แต่ในที่สุดก็สูญเสียการเข้าชมเนื่องจากพฤติกรรมของไซต์ที่ไม่เสถียร

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

Google Analytics ที่โฮสต์เองนั้นคุ้มค่าหรือไม่

แม้ว่าเจ้าของเว็บไซต์บางรายจะพิจารณาการติดตาม Google Analytics แบบโฮสต์เองเพื่อให้ได้ Core Web Vitals ที่เหมาะสมที่สุด แต่ก็ไม่จำเป็นต้องดำเนินการใดๆ เลย แทนที่จะเพิ่มความซับซ้อน ต้นทุน และข้อจำกัดที่อาจเกิดขึ้นเมื่อเทียบกับการพึ่งพาโครงสร้างพื้นฐานของ Google ให้มุ่งเน้นที่การเพิ่มประสิทธิภาพเหตุการณ์ Google Tag Manager เพื่อให้เป็นไปตามมาตรฐาน Core Web Vitals