เรียนรู้สาเหตุที่เครื่องมือที่ตรวจสอบเมตริก Core Web Vitals อาจรายงานตัวเลขที่แตกต่างกัน และวิธีตีความความแตกต่างเหล่านั้น
Google มีเครื่องมือมากมายเพื่อช่วยเจ้าของเว็บไซต์ตรวจสอบ คะแนน Core Web Vitals เครื่องมือเหล่านี้จัดอยู่ใน 2 หมวดหมู่หลัก ได้แก่
- เครื่องมือที่รายงานข้อมูลห้องทดลอง ซึ่งเป็นข้อมูลที่รวบรวมในสภาพแวดล้อมที่มีการควบคุม การตั้งค่าอุปกรณ์และเครือข่ายที่กำหนดไว้ล่วงหน้า
- เครื่องมือที่รายงานข้อมูลภาคสนาม - ข้อมูลที่รวบรวมจากผู้ใช้จริงที่เข้าชม เว็บไซต์ของคุณ
ปัญหาคือบางครั้งข้อมูลที่เครื่องมือของห้องทดลองรายงานอาจใช้เวลาเล็กน้อย แตกต่างจากข้อมูลที่เครื่องมือภาคสนามรายงาน ข้อมูลในห้องทดลองอาจบ่งชี้ว่า ว่าเว็บไซต์ของคุณทำงานได้ดี แต่ข้อมูลภาคสนามกลับแนะนำว่าจำเป็นต้องมี ของคุณ หรืออีกทางหนึ่ง ข้อมูลฟิลด์ของคุณอาจระบุว่า หน้าเว็บทั้งหมดของคุณดี แต่ จากข้อมูลของห้องทดลองอาจรายงานคะแนนที่ต่ำมาก
ตัวอย่างจริงของรายงาน PageSpeed Insights ต่อไปนี้จาก web.dev แสดงให้เห็นว่า ในบางกรณี ข้อมูลในห้องทดลองและภาคสนามอาจต่างกันไปในทุกแอป เมตริกของ Web Vitals
ความแตกต่างระหว่างเครื่องมือต่างๆ เป็นที่มาของความสับสนที่เข้าใจได้สำหรับ โพสต์นี้จะอธิบายสาเหตุหลักๆ ที่ความแตกต่างเหล่านี้ ซึ่งมีตัวอย่างที่เฉพาะเจาะจงซึ่งครอบคลุมเมตริก Core Web Vitals แต่ละรายการ และ สิ่งที่ต้องทำเมื่อพบความแตกต่างในหน้าเว็บ
ข้อมูลห้องปฏิบัติการเทียบกับข้อมูลภาคสนาม
เพื่อให้เข้าใจว่าทำไมห้องทดลองและเครื่องมือภาคสนามอาจรายงานค่าที่ต่างกัน แม้กระทั่งสำหรับ หน้าเว็บที่เหมือนกันทุกประการ คุณต้องเข้าใจความแตกต่างระหว่าง Lab และภาคสนาม
ข้อมูลในห้องทดลอง
ข้อมูลห้องทดลองจะกำหนดโดยการโหลดหน้าเว็บในสภาพแวดล้อมที่มีการควบคุม เงื่อนไขของเครือข่ายและอุปกรณ์ที่กำหนดไว้ล่วงหน้า เงื่อนไขเหล่านี้เรียกว่า lab หรือบางครั้งเรียกว่าสภาพแวดล้อมสังเคราะห์
โดยทั่วไปแล้ว เครื่องมือ Chrome ที่รายงานข้อมูลห้องทดลองทำงานอยู่ Lighthouse
วัตถุประสงค์ของการทดสอบในห้องทดลองคือการควบคุมปัจจัยให้ได้มากที่สุด ดังนั้น จะให้ผลลัพธ์ที่สอดคล้องกัน (มากที่สุด) และเกิดซ้ำได้ตั้งแต่การเรียกใช้ไปจนถึงการเรียกใช้
ข้อมูลในช่อง
ข้อมูลในช่องจะกำหนดโดยการตรวจสอบผู้ใช้ทั้งหมดที่เข้าชมหน้าเว็บหนึ่งๆ และวัดผล ชุดเมตริกประสิทธิภาพสำหรับผู้ใช้แต่ละคน บุคคลธรรมดา ได้ง่ายขึ้น เนื่องจากข้อมูลภาคสนามอ้างอิงจากการเข้าชมของผู้ใช้จริง ข้อมูลนี้สะท้อนให้เห็นถึง อุปกรณ์จริง เงื่อนไขเครือข่าย และสถานที่ตั้งทางภูมิศาสตร์ของผู้ใช้
ข้อมูลภาคสนามยังเรียกอีกอย่างหนึ่งว่า การตรวจสอบผู้ใช้จริง (RUM) ข้อกำหนดทั้งสอง แทนกันได้
โดยทั่วไปแล้ว เครื่องมือ Chrome ที่รายงานข้อมูลในภาคสนามจะได้รับข้อมูลดังกล่าวจาก Chrome รายงานประสบการณ์ของผู้ใช้ (CrUX) นอกจากนี้ เจ้าของเว็บไซต์ก็มักรวบรวมข้อมูลภาคสนามด้วย) ด้วยเช่นกัน (และแนะนำให้ทำ) ด้วยตนเอง เนื่องจากสามารถให้ ข้อมูลเชิงลึกที่นำไปใช้ได้จริงมากกว่าแค่การใช้ CrUX เพียงอย่างเดียว
สิ่งสำคัญที่สุดในการทำความเข้าใจเกี่ยวกับข้อมูลภาคสนามก็คือ ไม่ใช่แค่เพียง สำหรับตัวเลข 1 ตัว ถือเป็นการกระจายตัวของตัวเลข กล่าวคือ สำหรับคนที่เข้าชม เว็บไซต์ของคุณ อาจโหลดได้เร็วในขณะที่สำหรับเว็บไซต์อื่น ๆ อาจโหลดช้ามาก ข้อมูลในช่องของเว็บไซต์เป็นชุดข้อมูลประสิทธิภาพทั้งหมดที่สมบูรณ์ ที่รวบรวมจากผู้ใช้ของคุณ
ตัวอย่างเช่น รายงาน 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 ที่ถูกต้องอยู่ ค่าสำหรับหน้านี้ เป็นหนึ่งในหลายๆ ค่าที่ทำให้เกิดการกระจายทั้งหมด ของประสบการณ์การโหลด
เหตุใดข้อมูลห้องปฏิบัติการและภาคสนามจึงแตกต่างกัน
ดังที่อธิบายไว้ข้างต้น ข้อมูลห้องทดลองและข้อมูลภาคสนามจะวัดข้อมูล สิ่งต่างๆ มากมาย
ข้อมูลในช่องประกอบด้วยเงื่อนไขของเครือข่ายและอุปกรณ์ที่หลากหลาย รวมถึง พฤติกรรมของผู้ใช้มากมายหลายประเภท นอกจากนี้ยังรวมถึงปัจจัยอื่นๆ ที่ส่งผลต่อประสบการณ์ของผู้ใช้ เช่น การเพิ่มประสิทธิภาพเบราว์เซอร์ back/Forward Cache (bfcache) หรือการเพิ่มประสิทธิภาพแพลตฟอร์มอย่างเช่น แคช AMP
ในทางตรงกันข้าม ข้อมูลห้องทดลองจะจำกัดจำนวนตัวแปรที่เกี่ยวข้อง ต การตรวจในห้องทดลองประกอบด้วย
- อุปกรณ์เครื่องเดียว...
- เชื่อมต่อกับเครือข่ายเดียว...
- แสดงจากตำแหน่งที่ตั้งทางภูมิศาสตร์เดียว
รายละเอียดของการทดสอบในห้องทดลองที่กำหนดอาจแสดงหรือไม่ถูกต้อง เปอร์เซ็นไทล์ที่ 75 ของข้อมูลช่องสำหรับหน้าเว็บหรือเว็บไซต์ที่ระบุ
สภาพแวดล้อมที่มีการควบคุมของห้องทดลองจะมีประโยชน์ในการแก้ไขข้อบกพร่องหรือการทดสอบ ก่อนการทำให้ใช้งานได้ แต่เมื่อคุณควบคุมปัจจัยเหล่านี้ คุณไม่ได้แสดงถึงความแปรปรวนอย่างที่เห็นในชีวิตจริง ในเครือข่าย ความสามารถของอุปกรณ์ หรือสถานที่ตั้งทางภูมิศาสตร์ทุกประเภท คุณ ก็มักจะไม่ให้ผลกระทบด้านประสิทธิภาพจากพฤติกรรมของผู้ใช้จริง เช่น การเลื่อน เลือกข้อความ หรือการแตะองค์ประกอบในหน้า
นอกเหนือจากความไม่สัมพันธ์กันระหว่างเงื่อนไขของห้องปฏิบัติการกับภาวะต่างๆ ของผู้ใช้งานจริงส่วนใหญ่ ยังมีความแตกต่างที่ละเอียดกว่า ที่ควรทำความเข้าใจเพื่อใช้ประโยชน์จากห้องทดลองให้ดีที่สุด และข้อมูลภาคสนาม ตลอดจนความแตกต่างที่คุณอาจพบ
ข้อมูลในส่วนต่อๆ ไปจะลงรายละเอียดเพื่อไฮไลต์สาเหตุที่พบบ่อยที่สุด ความแตกต่างระหว่างข้อมูลในห้องทดลองและข้อมูลภาคสนามสำหรับแต่ละเว็บหลัก เมตริกของ 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
เว็บไซต์ที่สร้างด้วย AMP หรือที่ใช้ Signed Exchange (SXG) ผู้รวบรวมเนื้อหาอย่าง Google จะโหลดไว้ล่วงหน้าได้ ค้นหา ซึ่งอาจส่งผลให้ผู้ใช้มีประสิทธิภาพการโหลดดีขึ้นอย่างมาก ที่เข้าชมหน้าเว็บของคุณจากแพลตฟอร์มเหล่านั้น
นอกเหนือจากการโหลดล่วงหน้าแบบข้ามต้นทางแล้ว เว็บไซต์เองยังทำสิ่งต่อไปนี้ได้ โหลดล่วงหน้าสำหรับเนื้อหา สำหรับหน้าต่อๆ ไปในเว็บไซต์ ซึ่งจะช่วยปรับปรุง LCP ของหน้าเว็บเหล่านั้นด้วย
เครื่องมือในห้องทดลองไม่ได้จำลองประโยชน์ที่ได้จากการเพิ่มประสิทธิภาพเหล่านี้ และแม้ว่า แต่ไม่รู้ว่าการเข้าชมของคุณมาจากกี่เปอร์เซ็นต์ อย่าง Google Search เมื่อเทียบกับแหล่งที่มาอื่นๆ
ผลกระทบของ bfcache ต่อ LCP
เมื่อหน้าเว็บถูกคืนค่าจาก bfcache ประสบการณ์การโหลดเกือบจะเป็น แบบทันที และประสบการณ์เหล่านี้จะรวมอยู่ในขอบเขตของคุณ ข้อมูล
การทดสอบในห้องทดลองจะไม่พิจารณา Bfcache ดังนั้นหากหน้าเว็บของคุณ bfcache-friendly มีแนวโน้มที่จะใช้ จะส่งผลให้มีการรายงานคะแนน 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 Loading โดยไม่มี ขนาดที่เหมาะสม และอาจทำให้เลย์เอาต์ เปลี่ยนเมื่อผู้ใช้เลื่อนไปที่ส่วนเหล่านั้นของหน้า แต่การเปลี่ยนแปลงเหล่านั้นอาจ จะเกิดขึ้นเฉพาะเมื่อผู้ใช้เลื่อนลง ซึ่งมักจะไม่พบในห้องทดลอง
เนื้อหาแบบปรับแต่งเอง
เนื้อหาที่ปรับเปลี่ยนในแบบของคุณ รวมถึงโฆษณาที่ตรงเป้าหมายและการทดสอบ A/B ส่งผลต่อองค์ประกอบใดบ้าง ในหน้าเว็บ การตั้งค่านี้ยังส่งผลต่อวิธีการโหลดอีกด้วยเนื่องจากมีการปรับเปลี่ยนในแบบของคุณ เนื้อหามักจะโหลดในภายหลังและแทรกลงในเนื้อหาหลักของหน้าเว็บ ซึ่งทำให้ การเปลี่ยนเลย์เอาต์
ในห้องทดลอง หน้าเว็บมักจะโหลดโดยไม่มีเนื้อหาที่ปรับเปลี่ยนในแบบของคุณ หรือ กับเนื้อหาสำหรับ "ผู้ใช้ทดสอบ" ทั่วไป ซึ่งอาจทริกเกอร์การเปลี่ยนแปลงหรือไม่ก็ได้ ที่ผู้ใช้จริงได้เห็น
เนื่องจากข้อมูลภาคสนามจะรวมประสบการณ์ของผู้ใช้ทุกคน จำนวน (และระดับการศึกษา) ของการเปลี่ยนเลย์เอาต์ที่เกิดขึ้นในหน้าเว็บหนึ่งๆ จะขึ้นอยู่กับว่าเนื้อหาใด โหลดแล้ว
ผลกระทบของสถานะแคชและ bfcache ต่อ CLS
สาเหตุทั่วไป 2 ประการที่ทำให้เกิดการเปลี่ยนเลย์เอาต์ระหว่างการโหลดคือรูปภาพและ iframe ที่ไม่มีมิติข้อมูล (ดังที่กล่าวไว้ข้างต้น) และเว็บที่โหลดช้า แบบอักษร และทั้ง 2 ปัญหานี้ ส่งผลต่อประสบการณ์ครั้งแรกที่ผู้ใช้เข้าชมเว็บไซต์ เมื่อแคช ว่างเปล่า
หากมีการแคชทรัพยากรของหน้าเว็บ หรือมีการคืนค่าหน้าดังกล่าวจาก bfcache ปกติแล้วเบราว์เซอร์จะ แสดงผลรูปภาพและแบบอักษรได้ในทันที ที่รอดาวน์โหลดอยู่ ซึ่งอาจส่งผลให้ค่า CLS ลดลงในช่อง ข้อมูลที่เครื่องมือในห้องทดลองรายงาน
สิ่งที่ต้องทำเมื่อผลลัพธ์แตกต่างกัน
ตามกฎทั่วไป หากคุณมีทั้งข้อมูลภาคสนามและข้อมูลห้องทดลองสำหรับหน้าเว็บหนึ่งๆ ข้อมูลภาคสนามคือสิ่งที่คุณควรใช้เพื่อจัดลำดับความสำคัญของงาน ตั้งแต่ข้อมูลภาคสนาม แสดงถึงประสบการณ์ของผู้ใช้จริง นั่นเป็นวิธีที่ถูกต้องที่สุด เข้าใจอย่างถ่องแท้ว่าผู้ใช้กำลังประสบปัญหากับอะไร และจำเป็นต้องทำอะไร ได้รับการปรับปรุงแล้ว
ในทางกลับกัน ถ้าข้อมูลภาคสนามของคุณแสดงผลได้ดีทั่วทั้งกระดาน แต่ ข้อมูลจากห้องทดลองชี้ว่าคุณยังควรปรับปรุงอยู่ ก็คุ้มค่า รู้ว่าจะเพิ่มประสิทธิภาพอะไรได้อีกบ้าง
นอกจากนี้ แม้ว่าข้อมูลภาคสนามจะสามารถเก็บข้อมูลประสบการณ์ของผู้ใช้จริง แต่ข้อมูล สำหรับผู้ใช้ที่โหลดเว็บไซต์ได้สำเร็จ ข้อมูลจากห้องทดลอง จะช่วยระบุโอกาส ในการเข้าถึงเว็บไซต์ของคุณและทำให้ ผู้ใช้ที่มีเครือข่ายช้าหรืออุปกรณ์ระดับล่างจะเข้าถึงได้มากขึ้น
โดยรวมแล้ว ทั้งข้อมูลในห้องทดลองและข้อมูลภาคสนามต่างก็เป็นส่วนสำคัญในการสร้างประสิทธิภาพ การวัดประสิทธิภาพ ทั้งคู่ต่างก็มีจุดแข็งและขีดจำกัดของตนเอง แสดงว่าคุณอาจพลาดโอกาสในการปรับปรุง สำหรับผู้ใช้ของคุณ