ทำไมข้อมูลในห้องทดลองและข้อมูลภาคสนามอาจแตกต่างกัน (และสิ่งที่ควรทำ)

ดูสาเหตุที่เครื่องมือที่ตรวจสอบเมตริก Core Web Vitals อาจรายงานตัวเลขที่แตกต่างกัน และวิธีตีความความแตกต่างเหล่านั้น

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

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

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

ตัวอย่างจริงของรายงาน PageSpeed Insights จาก web.dev แสดงให้เห็นว่าในบางกรณีข้อมูลในห้องปฏิบัติการและข้อมูลในภาคสนามอาจแตกต่างกันไปในเมตริก Core Web Vitals ทั้งหมด

ภาพหน้าจอของรายงาน PageSpeed Insights ที่มีข้อมูลห้องปฏิบัติการและข้อมูลในภาคสนามที่ขัดแย้งกัน

ความแตกต่างระหว่างเครื่องมือต่างๆ เป็นสาเหตุของความสับสนที่เข้าใจได้สำหรับนักพัฒนาซอฟต์แวร์ โพสต์นี้อธิบายเหตุผลหลักๆ ที่อาจทำให้เกิดความแตกต่างเหล่านี้ พร้อมด้วยตัวอย่างที่เจาะจงเกี่ยวกับเมตริก 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 ในภาคสนาม

ข้อมูลห้องทดลองจากหน้าเดียวกันแสดงค่า LCP ที่ 3.0 วินาที แม้ว่าค่านี้มากกว่า 1.8 วินาทีที่แสดงในข้อมูลของช่อง แต่ก็ยังคงเป็นค่า LCP ที่ถูกต้องสำหรับหน้านี้ ซึ่งเป็นค่าหนึ่งจากหลายๆ ค่าที่ทำให้เกิดการกระจายประสบการณ์การโหลดแบบเต็มรูปแบบ

คะแนน LCP ในห้องทดลอง

เหตุใดข้อมูลในห้องทดลองและข้อมูลภาคสนามจึงแตกต่างกัน

อย่างที่ส่วนด้านบนอธิบายไว้ ข้อมูลในห้องทดลองและข้อมูลภาคสนามในการวัด สิ่งต่างๆ ที่ต่างกันมาก

ข้อมูลภาคสนามมีเงื่อนไขของเครือข่ายและอุปกรณ์มากมาย รวมทั้งพฤติกรรมของผู้ใช้หลากหลายประเภท นอกจากนี้ยังมีปัจจัยอื่นๆ ที่ส่งผลต่อประสบการณ์ของผู้ใช้ เช่น การเพิ่มประสิทธิภาพเบราว์เซอร์อย่าง Back/Forward Cache (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

การทดสอบในห้องปฏิบัติการมักจะโหลดหน้าเว็บที่มี Cold Cache แต่เมื่อผู้ใช้จริงเข้าชมหน้าเว็บนั้น ผู้ใช้จริงอาจมีแคชทรัพยากรบางส่วนไว้อยู่แล้ว

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

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

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

การเพิ่มประสิทธิภาพ AMP หรือ Signed Exchange

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

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

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

ผลกระทบของ bfcache บน LCP

เมื่อคืนค่าหน้าจาก bfcache ประสบการณ์การโหลดจะเกือบจะทันที และประสบการณ์เหล่านี้จะรวมอยู่ในข้อมูลในช่อง

การทดสอบในห้องทดลองไม่พิจารณา bfcache ดังนั้นหากหน้าเว็บเหมาะสำหรับ bfcache ก็อาจทำให้มีการรายงานคะแนน LCP ในช่องได้เร็วขึ้น

ผลกระทบของการโต้ตอบของผู้ใช้ที่มีต่อ LCP

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

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

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

แต่ผลที่ตามมาคือข้อมูลในช่องของหน้าอาจรายงานเวลา LCP ที่เร็วขึ้น ทั้งนี้ขึ้นอยู่กับพฤติกรรมของผู้ใช้ในหน้าเว็บนั้น

INP

INP ต้องมีการโต้ตอบของผู้ใช้จริง

เมตริก INP จะวัดว่าหน้าเว็บตอบสนองต่อการโต้ตอบของผู้ใช้มากน้อยเพียงใดในตอนที่ผู้ใช้เลือกโต้ตอบกับหน้าเว็บจริงๆ

ส่วนที่ 2 ของประโยคนั้นมีความสำคัญอย่างยิ่ง เนื่องจากการทดสอบในห้องทดลอง แม้จะเป็นการทดสอบที่รองรับพฤติกรรมของผู้ใช้แบบสคริปต์ ก็ไม่สามารถคาดการณ์ได้อย่างแม่นยำว่าผู้ใช้จะเลือกที่จะโต้ตอบกับหน้าเว็บเมื่อใด ทำให้ไม่สามารถวัด 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 จะพิจารณาการเปลี่ยนเลย์เอาต์ที่ไม่คาดคิดทั้งหมดที่เกิดขึ้นตลอดอายุการใช้งานของหน้าเว็บ รวมถึงเนื้อหาที่เปลี่ยนไปเมื่อผู้ใช้เลื่อนหน้าจอ หรือตอบสนองต่อคําขอของเครือข่ายที่ช้าหลังจากผู้ใช้โต้ตอบ

เช่น เป็นเรื่องปกติที่หน้าเว็บจะโหลดรูปภาพแบบ Lazy Loading หรือ iframe โดยไม่มีขนาด และอาจส่งผลให้เลย์เอาต์เปลี่ยนแปลงเมื่อผู้ใช้เลื่อนไปยังส่วนต่างๆ ของหน้าเว็บ แต่การเปลี่ยนแปลงดังกล่าวอาจเกิดขึ้นได้เมื่อผู้ใช้เลื่อนลงเท่านั้น ซึ่งมักจะไม่ผ่านการตรวจในห้องทดลอง

เนื้อหาแบบปรับแต่งเอง

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

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

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

ผลกระทบของสถานะแคชและ bfcache ใน CLS

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

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

สิ่งที่ต้องทำเมื่อผลลัพธ์แตกต่างกัน

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

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

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

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

อ่านเพิ่มเติม