ดูสาเหตุที่เครื่องมือที่ตรวจสอบเมตริก Core Web Vitals อาจรายงานตัวเลขที่แตกต่างกัน และวิธีตีความความแตกต่างเหล่านั้น
Google มีเครื่องมือจํานวนหนึ่งที่ช่วยให้เจ้าของเว็บไซต์ตรวจสอบคะแนน Core Web Vitals ได้ เครื่องมือเหล่านี้แบ่งออกเป็น 2 หมวดหมู่หลัก ดังนี้
- เครื่องมือที่รายงานข้อมูลห้องทดลอง ซึ่งเป็นข้อมูลที่รวบรวมในสภาพแวดล้อมที่มีการควบคุมโดยมีการตั้งค่าอุปกรณ์และเครือข่ายที่กำหนดไว้ล่วงหน้า
- เครื่องมือที่รายงานข้อมูลภาคสนาม ซึ่งเป็นข้อมูลที่รวบรวมจากผู้ใช้งานจริงที่เข้าชมเว็บไซต์
ปัญหาคือบางครั้งข้อมูลที่รายงานโดยเครื่องมือในห้องทดลองอาจแตกต่างจากข้อมูลที่รายงานโดยเครื่องมือภาคสนามค่อนข้างมาก ข้อมูลของห้องทดลองอาจระบุว่าเว็บไซต์มีประสิทธิภาพดี แต่ข้อมูลจริงกลับระบุว่าต้องมีการปรับปรุง หรือข้อมูลภาคสนามอาจระบุว่าหน้าเว็บทั้งหมดของคุณอยู่ในเกณฑ์ดี แต่ข้อมูลในเครื่องมือทดสอบอาจรายงานคะแนนต่ำมาก
ตัวอย่างจริงต่อไปนี้ของรายงาน PageSpeed Insights จาก web.dev แสดงให้เห็นว่าในบางกรณี ข้อมูลในเครื่องมือทดสอบและข้อมูลในช่องอาจแตกต่างกันสำหรับเมตริก Core Web Vitals ทั้งหมด
ความแตกต่างระหว่างเครื่องมือต่างๆ เป็นสิ่งที่นักพัฒนาแอปอาจสับสนได้ โพสต์นี้จะอธิบายสาเหตุหลักที่อาจทําให้เกิดความแตกต่างกันนี้ พร้อมตัวอย่างที่เจาะจงซึ่งครอบคลุมเมตริก Core Web Vitals แต่ละรายการ และสิ่งที่ควรทําเมื่อพบความแตกต่างในหน้าเว็บ
ข้อมูลห้องทดลองเทียบกับข้อมูลภาคสนาม
หากต้องการทําความเข้าใจสาเหตุที่เครื่องมือในแล็บและภาคสนามอาจรายงานค่าที่แตกต่างกัน แม้ว่าจะเป็นหน้าเว็บเดียวกันก็ตาม คุณจําเป็นต้องทําความเข้าใจความแตกต่างระหว่างข้อมูลในแล็บและภาคสนาม
ข้อมูลห้องปฏิบัติการ
ข้อมูลห้องทดลองจะกำหนดโดยการโหลดหน้าเว็บในสภาพแวดล้อมที่มีการควบคุมโดยมีชุดเงื่อนไขของเครือข่ายและอุปกรณ์ที่กำหนดไว้ล่วงหน้า เงื่อนไขเหล่านี้เรียกว่าสภาพแวดล้อมห้องทดลอง ซึ่งบางครั้งก็เรียกว่าสภาพแวดล้อมสังเคราะห์
โดยทั่วไปเครื่องมือของ Chrome ที่รายงานข้อมูลในการทดสอบจะเรียกใช้ Lighthouse
วัตถุประสงค์ของการทดสอบในห้องทดลองคือการควบคุมปัจจัยต่างๆ ให้ได้มากที่สุด เพื่อให้ผลลัพธ์สอดคล้องกันและทําซ้ำได้ (มากที่สุด) จากการทดสอบแต่ละครั้ง
ข้อมูลภาคสนาม
ข้อมูลภาคสนามจะกำหนดโดยการติดตามผู้ใช้ทุกคนที่เข้าชมหน้าเว็บและวัดชุดเมตริกประสิทธิภาพหนึ่งๆ สําหรับประสบการณ์การใช้งานแต่ละรายการของผู้ใช้แต่ละราย เนื่องจากข้อมูลภาคสนามอิงตามการเข้าชมของผู้ใช้จริง จึงแสดงอุปกรณ์จริง สภาพเครือข่าย และสถานที่ตั้งทางภูมิศาสตร์ของผู้ใช้
ข้อมูลภาคสนามมักเรียกกันว่าข้อมูลการตรวจสอบผู้ใช้จริง (RUM) ซึ่งทั้ง 2 วลีนี้ใช้แทนกันได้
โดยทั่วไปเครื่องมือของ Chrome ที่รายงานข้อมูลในช่องจะได้รับข้อมูลจากรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) นอกจากนี้ เจ้าของเว็บไซต์ยังรวบรวมข้อมูลภาคสนามด้วยตนเองได้อีกด้วย (และเราขอแนะนําให้ทํา) เนื่องจากข้อมูลนี้สามารถให้ข้อมูลเชิงลึกที่นําไปใช้ได้จริงมากกว่าการใช้ CrUX เพียงอย่างเดียว
สิ่งสำคัญที่สุดที่ควรทราบเกี่ยวกับข้อมูลภาคสนามคือข้อมูลนี้ไม่ใช่แค่ตัวเลขเดียว แต่เป็นชุดตัวเลข กล่าวคือ เว็บไซต์อาจโหลดเร็วมากสําหรับผู้ใช้บางรายที่เข้าชม แต่อาจโหลดช้ามากสําหรับผู้ใช้รายอื่น ข้อมูลภาคสนามของเว็บไซต์คือชุดข้อมูลประสิทธิภาพทั้งหมดที่รวบรวมจากผู้ใช้
ตัวอย่างเช่น รายงาน CrUX จะแสดงการแจกแจงเมตริกประสิทธิภาพจากผู้ใช้ Chrome จริงในช่วง 28 วัน หากดูรายงาน CrUX เกือบทุกฉบับ คุณจะเห็นว่าผู้ใช้บางรายที่เข้าชมเว็บไซต์อาจได้รับประสบการณ์การใช้งานที่ดีมาก ขณะที่ผู้ใช้รายอื่นๆ อาจได้รับประสบการณ์การใช้งานที่แย่มาก
หากเครื่องมือรายงานตัวเลขเดียวสําหรับเมตริกหนึ่งๆ โดยทั่วไปตัวเลขดังกล่าวจะแสดงจุดที่เฉพาะเจาะจงในการแจกแจง เครื่องมือที่รายงานคะแนนในสนามของ Core Web Vitals จะใช้เปอร์เซ็นต์ไทล์ที่ 75
เมื่อดู LCP จากข้อมูลภาคสนามในภาพหน้าจอด้านบน คุณจะเห็นการกระจายดังนี้
- การเข้าชม 88% มี LCP ไม่เกิน 2.5 วินาที (ดี)
- การเข้าชม 8% มี LCP ระหว่าง 2.5 ถึง 4 วินาที (ต้องปรับปรุง)
- การเข้าชม 4% มี LCP นานกว่า 4 วินาที (แย่)
ที่เปอร์เซ็นไทล์ที่ 75 LCP คือ 1.8 วินาที
ข้อมูลห้องทดลองจากหน้าเดียวกันแสดงค่า LCP ที่ 3.0 วินาที แม้ว่าค่านี้จะมากกว่า 1.8 วินาทีที่แสดงในข้อมูลภาคสนาม แต่ก็ยังถือเป็นค่า LCP ที่ถูกต้องสําหรับหน้านี้ เนื่องจากเป็นหนึ่งในค่าหลายค่าที่ประกอบกันเป็นประสบการณ์การโหลดโดยรวม
สาเหตุที่ข้อมูลในห้องทดลองและภาคสนามแตกต่างกัน
ตามที่อธิบายไว้ในส่วนด้านบน ข้อมูลห้องทดลองและข้อมูลภาคสนามนั้นวัดสิ่งที่แตกต่างกันมาก
ข้อมูลภาคสนามประกอบด้วยเงื่อนไขเครือข่ายและอุปกรณ์ที่หลากหลาย รวมถึงพฤติกรรมของผู้ใช้ที่หลากหลาย รวมถึงปัจจัยอื่นๆ ที่ส่งผลต่อประสบการณ์ของผู้ใช้ เช่น การเพิ่มประสิทธิภาพเบราว์เซอร์ เช่น แคชย้อนกลับ/ไปข้างหน้า (bfcache) หรือการเพิ่มประสิทธิภาพแพลตฟอร์ม เช่น แคช AMP
ในทางตรงกันข้าม ข้อมูลห้องทดลองจะจํากัดจํานวนตัวแปรที่เกี่ยวข้อง การทดสอบในห้องทดลองประกอบด้วยขั้นตอนต่อไปนี้
- อุปกรณ์เครื่องเดียว…
- เชื่อมต่อกับเครือข่ายเดียว…
- ดำเนินการจากสถานที่ตั้งทางภูมิศาสตร์แห่งเดียว
รายละเอียดของการทดสอบในแล็บอาจแสดงถึงเปอร์เซ็นต์ไทล์ 75 ของข้อมูลภาคสนามของหน้าเว็บหรือเว็บไซต์หนึ่งๆ อย่างถูกต้องหรือไม่ก็ได้
สภาพแวดล้อมที่มีการควบคุมของห้องทดลองมีประโยชน์เมื่อแก้ไขข้อบกพร่องหรือทดสอบฟีเจอร์ก่อนนำไปใช้งานจริง แต่การควบคุมปัจจัยเหล่านี้ไม่ได้แสดงถึงความแตกต่างที่คุณเห็นในชีวิตจริงอย่างชัดเจน ไม่ว่าจะเป็นเครือข่ายทุกประเภท ความสามารถของอุปกรณ์ หรือสถานที่ตั้งทางภูมิศาสตร์ นอกจากนี้ โดยทั่วไปแล้วคุณจะไม่บันทึกผลกระทบด้านประสิทธิภาพของพฤติกรรมของผู้ใช้จริง เช่น การเลื่อน การเลือกข้อความ หรือการแตะองค์ประกอบในหน้า
นอกจากความแตกต่างที่อาจเกิดขึ้นระหว่างเงื่อนไขในห้องทดลองกับเงื่อนไขของผู้ใช้ส่วนใหญ่ในชีวิตจริงแล้ว ยังมีความแตกต่างที่ละเอียดอ่อนอีกมากมายที่ควรทำความเข้าใจเพื่อให้ได้รับประโยชน์สูงสุดจากข้อมูลในห้องทดลองและข้อมูลภาคสนาม รวมถึงความแตกต่างที่คุณอาจพบ
ส่วนถัดไปจะอธิบายสาเหตุที่พบบ่อยที่สุดซึ่งอาจทําให้ข้อมูลในเครื่องมือทดสอบและข้อมูลในช่องของเมตริก Core Web Vitals แต่ละรายการแตกต่างกัน
LCP
องค์ประกอบ LCP ที่แตกต่างกัน
องค์ประกอบ LCP ที่ระบุในการทดสอบในแท็บทดสอบอาจไม่ใช่องค์ประกอบ LCP เดียวกันกับที่ผู้ใช้เห็นเมื่อเข้าชมหน้าเว็บ
หากคุณเรียกใช้รายงาน Lighthouse สําหรับหน้าหนึ่งๆ รายงานจะแสดงผลลัพธ์ขององค์ประกอบ LCP เดียวกันทุกครั้ง แต่หากดูข้อมูลภาคสนามของหน้าเดียวกัน คุณมักจะเห็นองค์ประกอบ LCP ที่แตกต่างกัน ซึ่งขึ้นอยู่กับสถานการณ์ต่างๆ เฉพาะการเข้าชมแต่ละหน้า
ตัวอย่างเช่น ปัจจัยต่อไปนี้อาจทําให้ระบบระบุองค์ประกอบ LCP ที่แตกต่างกันสําหรับหน้าเดียวกัน
- ขนาดหน้าจอของอุปกรณ์ที่แตกต่างกันจะทำให้องค์ประกอบต่างๆ ปรากฏในวิวพอร์ตแตกต่างกัน
- หากผู้ใช้เข้าสู่ระบบอยู่ หรือหากมีการแสดงเนื้อหาที่ปรับเปลี่ยนในแบบของคุณในลักษณะใดลักษณะหนึ่ง องค์ประกอบ LCP อาจแตกต่างกันอย่างมากในแต่ละผู้ใช้
- เช่นเดียวกับประเด็นก่อนหน้า หากการทดสอบ A/B ทำงานอยู่ในหน้าเว็บ ก็อาจส่งผลให้องค์ประกอบที่แสดงแตกต่างกันมาก
- ชุดแบบอักษรที่ติดตั้งในระบบของผู้ใช้อาจส่งผลต่อขนาดข้อความในหน้าเว็บ (และทำให้ทราบว่าองค์ประกอบใดคือองค์ประกอบ LCP)
- โดยปกติการทดสอบในแล็บจะทําใน URL "ฐาน" ของหน้าเว็บ โดยไม่มีการเพิ่มพารามิเตอร์การค้นหาหรือแฮช แต่ในชีวิตจริง ผู้ใช้มักแชร์ URL ที่มีตัวระบุส่วนย่อยหรือส่วนย่อยของข้อความ ดังนั้นองค์ประกอบ LCP อาจมาจากตรงกลางหรือด้านล่างของหน้า (แทนที่จะเป็น "เหนือบรรทัดแรก")
เนื่องจาก LCP ในช่องคำนวณเป็นเปอร์เซ็นต์ที่ 75 ของการเข้าชมหน้าเว็บทั้งหมดของผู้ใช้ หากผู้ใช้จำนวนมากมีองค์ประกอบ LCP ที่โหลดอย่างรวดเร็ว เช่น ย่อหน้าข้อความที่แสดงผลด้วยแบบอักษรของระบบ แม้ว่าผู้ใช้บางรายจะมีรูปภาพขนาดใหญ่ที่โหลดช้าเป็นองค์ประกอบ LCP ก็ตาม แต่อาจไม่ส่งผลต่อคะแนนของหน้านั้นหากเกิดกับผู้เข้าชมน้อยกว่า 25%
หรือในทางกลับกัน การทดสอบในเครื่องอาจระบุว่าบล็อกข้อความเป็นองค์ประกอบ LCP เนื่องจากเป็นการจําลองโทรศัพท์ Moto G4 ซึ่งมีวิวพอร์ตค่อนข้างเล็ก และรูปภาพหลักของหน้าเว็บแสดงผลนอกหน้าจอในตอนแรก อย่างไรก็ตาม ข้อมูลภาคสนามของคุณอาจรวมผู้ใช้ Pixel XL ที่มีหน้าจอขนาดใหญ่เป็นส่วนใหญ่ ดังนั้นรูปภาพหลักที่โหลดช้าจึงเป็นองค์ประกอบ LCP ของผู้ใช้กลุ่มนี้
ผลของสถานะแคชต่อ LCP
การทดสอบในแล็บมักจะโหลดหน้าเว็บด้วยแคชแบบเย็น แต่เมื่อผู้ใช้จริงเข้าชมหน้านั้น ผู้ใช้อาจแคชทรัพยากรบางส่วนของหน้าไว้แล้ว
หน้าเว็บอาจโหลดช้าเมื่อผู้ใช้โหลดหน้าเว็บเป็นครั้งแรก แต่หากหน้าเว็บมีการกําหนดค่าการแคชอย่างเหมาะสม หน้าเว็บอาจโหลดทันทีเมื่อผู้ใช้กลับมาในครั้งถัดไป
แม้ว่าเครื่องมือทดสอบบางรายการจะรองรับการเรียกใช้หน้าเดียวกันหลายครั้ง (เพื่อจําลองประสบการณ์สําหรับผู้เข้าชมที่กลับมา) แต่เครื่องมือทดสอบจะไม่ทราบเปอร์เซ็นต์การเข้าชมในชีวิตจริงที่เกิดขึ้นจากผู้ใช้ใหม่เทียบกับผู้ใช้ที่กลับมา
เว็บไซต์ที่มีการกําหนดค่าแคชที่เพิ่มประสิทธิภาพอย่างดีและมีผู้เข้าชมซ้ำจํานวนมากอาจพบว่า LCP ในชีวิตจริงเร็วกว่าที่ข้อมูลในห้องทดลองระบุไว้มาก
การเพิ่มประสิทธิภาพ AMP หรือ Signed Exchange
ผู้รวบรวมเนื้อหาอย่าง Google Search สามารถโหลดเว็บไซต์ที่สร้างด้วย AMP หรือใช้ Signed Exchange (SXG) ล่วงหน้าได้ ซึ่งอาจส่งผลให้ประสิทธิภาพการโหลดดีขึ้นอย่างมากสําหรับผู้ใช้ที่เข้าชมหน้าเว็บจากแพลตฟอร์มเหล่านั้น
นอกจากการโหลดล่วงหน้าข้ามแหล่งที่มาแล้ว เว็บไซต์เองก็สามารถโหลดล่วงหน้าเนื้อหาสําหรับหน้าเว็บต่อๆ ไปในเว็บไซต์ได้ ซึ่งอาจปรับปรุง LCP สําหรับหน้าเหล่านั้นด้วย
เครื่องมือในแท็บห้องทดลองไม่ได้จําลองผลลัพธ์ที่ได้จากการเพิ่มประสิทธิภาพเหล่านี้ และแม้ว่าจะจําลองได้ ก็จะไม่ทราบเปอร์เซ็นต์ของการเข้าชมที่มาจากแพลตฟอร์มต่างๆ เช่น Google Search เมื่อเทียบกับแหล่งที่มาอื่นๆ
ผลกระทบของ bfcache ต่อ LCP
เมื่อมีการกู้คืนหน้าเว็บจาก bfcache ประสบการณ์การโหลดจะเกือบจะทันทีทันใด และประสบการณ์เหล่านี้จะรวมอยู่ในข้อมูลภาคสนาม
การทดสอบในห้องทดลองจะไม่พิจารณา bfcache ดังนั้นหากหน้าเว็บเหมาะกับ bfcache ก็อาจมีแนวโน้มที่จะส่งผลให้คะแนน LCP ที่รายงานในสนามเร็วขึ้น
ผลกระทบของการโต้ตอบของผู้ใช้ต่อ LCP
LCP จะระบุเวลาในการแสดงผลของรูปภาพหรือบล็อกข้อความที่ใหญ่ที่สุดในวิวพอร์ต แต่องค์ประกอบที่ใหญ่ที่สุดนั้นอาจเปลี่ยนแปลงไปเมื่อหน้าเว็บโหลด หรือเมื่อมีการเพิ่มเนื้อหาใหม่ลงในวิวพอร์ตแบบไดนามิก
ในเครื่องมือทดสอบเบราว์เซอร์จะรอจนกว่าหน้าเว็บจะโหลดเสร็จสมบูรณ์ก่อนจึงจะระบุองค์ประกอบ LCP แต่ในทางปฏิบัติ เบราว์เซอร์จะหยุดตรวจสอบองค์ประกอบขนาดใหญ่หลังจากผู้ใช้เลื่อนหรือโต้ตอบกับหน้าเว็บ
การดำเนินการนี้มีความสมเหตุสมผล (และจำเป็น) เนื่องจากโดยทั่วไปผู้ใช้จะรอโต้ตอบกับหน้าเว็บจนกว่าหน้าเว็บจะ "ดูเหมือน" โหลด ซึ่งก็คือสิ่งที่เมตริก LCP มุ่งตรวจหา นอกจากนี้ การพิจารณาองค์ประกอบที่เพิ่มลงในวิวพอร์ตหลังจากที่ผู้ใช้โต้ตอบก็ไม่มีเหตุผลเช่นกัน เนื่องจากองค์ประกอบเหล่านั้นอาจโหลดเพราะสิ่งที่ผู้ใช้ทํา
อย่างไรก็ตาม ผลที่ตามมาคือข้อมูลภาคสนามของหน้าเว็บอาจรายงานเวลา LCP ที่เร็วขึ้น ทั้งนี้ขึ้นอยู่กับลักษณะการทํางานของผู้ใช้ในหน้านั้น
INP
INP ต้องมีการโต้ตอบกับผู้ใช้จริง
เมตริก INP จะวัดการตอบสนองของหน้าเว็บต่อการโต้ตอบของผู้ใช้ในขณะที่ผู้ใช้เลือกโต้ตอบกับหน้าเว็บจริงๆ
ส่วนที่สองของประโยคนี้สำคัญมากเนื่องจากการทดสอบในห้องทดลอง แม้กระทั่งการทดสอบที่รองรับพฤติกรรมของผู้ใช้สคริปต์ ก็ไม่สามารถคาดการณ์ได้อย่างแม่นยำว่าเมื่อใดที่ผู้ใช้จะเลือกโต้ตอบกับหน้าเว็บ และด้วยเหตุนี้จึงไม่สามารถวัด FID ได้อย่างแม่นยำ
TBT ไม่พิจารณาพฤติกรรมของผู้ใช้
เมตริกเวลาการบล็อกทั้งหมด (TBT) ของห้องทดลองมีไว้เพื่อช่วยวิเคราะห์ปัญหาเกี่ยวกับ INP เนื่องจากจะระบุปริมาณการบล็อกของเธรดหลักระหว่างการโหลดหน้าเว็บ
แนวคิดคือหน้าเว็บที่มี JavaScript แบบซิงค์จำนวนมากหรืองานอื่นๆ ในการเรนเดอร์ที่ต้องใช้ทรัพยากรมากมีแนวโน้มที่จะมีคําสั่งของของเธรดหลักที่ถูกบล็อกเมื่อผู้ใช้โต้ตอบเป็นครั้งแรก อย่างไรก็ตาม หากผู้ใช้รอโต้ตอบกับหน้าเว็บจนกว่า JavaScript จะทํางานเสร็จสิ้น INP อาจต่ำมาก
การที่ผู้ใช้จะเลือกโต้ตอบกับหน้าเว็บหรือไม่นั้นขึ้นอยู่กับว่าหน้าเว็บดูเป็นแบบอินเทอร์แอกทีฟหรือไม่ ซึ่ง TBT ไม่สามารถวัดได้
TBT ไม่พิจารณาเวลาหน่วงของการแตะ
หากเว็บไซต์ไม่ได้เพิ่มประสิทธิภาพสำหรับการดูบนอุปกรณ์เคลื่อนที่ เบราว์เซอร์จะเพิ่มการหน่วงเวลา 300 มิลลิวินาทีหลังจากการแตะก่อนที่จะเรียกใช้ตัวแฮนเดิลเหตุการณ์ การดำเนินการนี้เนื่องจากต้องพิจารณาว่าผู้ใช้พยายามแตะสองครั้งเพื่อซูมหรือไม่ก่อนที่จะเรียกใช้เหตุการณ์เมาส์หรือการคลิกได้
ความล่าช้านี้นับรวมอยู่ใน INP ของหน้า เนื่องจากส่งผลต่อเวลาในการตอบสนองของอินพุตจริงที่ผู้ใช้ได้รับ แต่เนื่องจากความล่าช้านี้ไม่ใช่งานที่ใช้เวลานานในทางเทคนิค จึงไม่มีผลกระทบต่อ TBT ของหน้าเว็บ ซึ่งหมายความว่าหน้าเว็บอาจมี INP ไม่ดีแม้จะได้คะแนน TBT ดีมากก็ตาม
ผลกระทบของสถานะแคชและ bfcache ต่อ INP
แคชที่เหมาะสมช่วยปรับปรุง LCP ในพื้นที่ได้เช่นเดียวกับที่จะช่วยปรับปรุง INP
ในชีวิตจริง ผู้ใช้อาจมี JavaScript สําหรับเว็บไซต์อยู่ในแคชอยู่แล้ว การประมวลผลจึงอาจใช้เวลาน้อยลงและส่งผลให้เกิดความล่าช้าน้อยลง
เช่นเดียวกันกับหน้าเว็บที่กู้คืนจาก bfcache ในกรณีดังกล่าว ระบบจะกู้คืน JavaScript จากหน่วยความจำ ดังนั้นจึงอาจใช้เวลาประมวลผลเพียงเล็กน้อยหรือไม่มีเลย
CLS
ผลกระทบของการโต้ตอบของผู้ใช้ต่อ CLS
CLS ที่วัดในห้องทดลองจะพิจารณาเฉพาะการเปลี่ยนแปลงเลย์เอาต์ที่เกิดขึ้นเหนือส่วนที่มีการแบ่งหน้าเว็บและระหว่างการโหลดเท่านั้น แต่นี่เป็นเพียงข้อมูลชุดย่อยของสิ่งที่ CLS วัดได้จริง
ในทางปฏิบัติ CLS จะพิจารณาการเปลี่ยนแปลงเลย์เอาต์ที่ไม่คาดคิดทั้งหมดที่เกิดขึ้นตลอดอายุการใช้งานของหน้าเว็บ ซึ่งรวมถึงเนื้อหาที่เลื่อนไปมาขณะที่ผู้ใช้เลื่อนหรือตอบสนองต่อคําขอเครือข่ายที่ช้าหลังจากการโต้ตอบของผู้ใช้
ตัวอย่างเช่น การที่หน้าเว็บโหลดรูปภาพหรือ iframe แบบ Lazy Load โดยไม่มีมิติข้อมูลนั้นเป็นเรื่องปกติ ซึ่งอาจทําให้เลย์เอาต์เปลี่ยนเมื่อผู้ใช้เลื่อนไปยังส่วนนั้นๆ ของหน้า แต่การเปลี่ยนแปลงเหล่านั้นอาจเกิดขึ้นเฉพาะเมื่อผู้ใช้เลื่อนลง ซึ่งมักจะไม่พบในการทดสอบในห้องทดลอง
เนื้อหาแบบปรับแต่งเอง
เนื้อหาที่ปรับตามโปรไฟล์ของผู้ใช้ในแบบของคุณ ซึ่งรวมถึงโฆษณาที่กำหนดเป้าหมายและการทดสอบ A/B จะส่งผลต่อองค์ประกอบที่โหลดในหน้าเว็บ และยังส่งผลต่อวิธีโหลดด้วย เนื่องจากเนื้อหาที่ปรับตามโปรไฟล์ของผู้ใช้มักจะโหลดในภายหลังและแทรกลงในเนื้อหาหลักของหน้าเว็บ ซึ่งทําให้เลย์เอาต์เปลี่ยน
ในเวอร์ชันทดลอง หน้าเว็บมักจะโหลดโดยไม่มีเนื้อหาที่ปรับเปลี่ยนในแบบของคุณ หรือมีเนื้อหาสําหรับ "ผู้ใช้ทดสอบ" ทั่วไป ซึ่งอาจทริกเกอร์การเปลี่ยนแปลงที่ผู้ใช้จริงเห็นหรือไม่ก็ได้
เนื่องจากข้อมูลในช่องประกอบด้วยประสบการณ์ของผู้ใช้ทั้งหมด จํานวน (และระดับ) ของการเปลี่ยนเลย์เอาต์ที่ผู้ใช้พบในหน้าหนึ่งๆ จึงขึ้นอยู่กับเนื้อหาที่โหลด
ผลของสถานะแคชและ bfcache ต่อ CLS
สาเหตุที่พบบ่อยที่สุด 2 ประการของการเปลี่ยนเลย์เอาต์ระหว่างการโหลดคือรูปภาพและ iframe ที่ไม่มีมิติข้อมูล (ตามที่ได้กล่าวไว้ข้างต้น) และแบบอักษรในเว็บที่โหลดช้า และทั้ง 2 ปัญหานี้ก็มีแนวโน้มที่จะส่งผลต่อประสบการณ์ของผู้ใช้เมื่อเข้าชมเว็บไซต์เป็นครั้งแรกเมื่อแคชว่างเปล่า
หากมีการแคชทรัพยากรของหน้าเว็บ หรือหากมีการกู้คืนหน้าเว็บจากแคช โดยทั่วไปเบราว์เซอร์จะแสดงผลรูปภาพและแบบอักษรได้ทันทีโดยไม่ต้องรอให้ดาวน์โหลด ซึ่งอาจส่งผลให้ค่า CLS ในพื้นที่ทำงานต่ำกว่าที่เครื่องมือทดสอบอาจรายงาน
สิ่งที่ต้องทำเมื่อผลลัพธ์แตกต่างกัน
โดยทั่วไปแล้ว หากคุณมีทั้งข้อมูลภาคสนามและข้อมูลห้องทดลองสําหรับหน้าเว็บหนึ่งๆ คุณควรใช้ข้อมูลภาคสนามเพื่อจัดลําดับความสําคัญของงาน เนื่องจากข้อมูลภาคสนามแสดงถึงสิ่งที่ผู้ใช้จริงได้รับ จึงถือเป็นวิธีที่แม่นยำที่สุดในการทำความเข้าใจสิ่งที่ผู้ใช้พบปัญหาและสิ่งที่ควรปรับปรุง
ในทางกลับกัน หากข้อมูลภาคสนามแสดงคะแนนที่ดีในทุกด้าน แต่ข้อมูลในร้านทดลองชี้ว่ายังมีโอกาสปรับปรุงได้อีก คุณควรทำความเข้าใจว่าสามารถเพิ่มประสิทธิภาพเพิ่มเติมได้อย่างไร
นอกจากนี้ แม้ว่าข้อมูลภาคสนามจะบันทึกประสบการณ์ของผู้ใช้จริง แต่ข้อมูลดังกล่าวจะบันทึกเฉพาะผู้ใช้ที่โหลดเว็บไซต์ของคุณได้สําเร็จ บางครั้งข้อมูลในเครื่องมือทดสอบอาจช่วยระบุโอกาสในการขยายการเข้าถึงของเว็บไซต์และทําให้ผู้ใช้ที่มีเครือข่ายช้าหรืออุปกรณ์รุ่นล่างเข้าถึงเว็บไซต์ได้ง่ายขึ้น
โดยรวมแล้ว ทั้งข้อมูลห้องทดลองและข้อมูลภาคสนามเป็นส่วนสําคัญในการวัดประสิทธิภาพที่มีประสิทธิภาพ ทั้ง 2 รูปแบบมีข้อดีและข้อจำกัดของตัวเอง และหากคุณใช้เพียงรูปแบบเดียว คุณอาจพลาดโอกาสในการปรับปรุงประสบการณ์ของผู้ใช้