คำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับ SPA, Core Web Vitals และแผนของ Google เพื่อรับมือกับข้อจำกัดในการวัดผลในปัจจุบัน
นับตั้งแต่เปิดตัวโครงการริเริ่ม Web Vitals เป็นครั้งแรกเมื่อเดือนพฤษภาคม 2020 เรา ทีม Chrome ได้รับคำถามและความคิดเห็นดีๆ มากมายเกี่ยวกับ ของโปรแกรม
บางทีหัวข้อที่เราได้รับคำถามมากที่สุด ซึ่งก็คือ คำถามที่ตอบยากที่สุดคือวิธีวัด Core Web Vitals ใน แอปพลิเคชันหน้าเว็บเดียว (SPA) รวมถึงผลกระทบที่สถาปัตยกรรม SPA มีต่อคะแนน Core Web Vitals
คำถามเหล่านี้ตอบยาก เพราะปัญหานั้นค่อนข้างแตกต่างกันมาก ดังนั้น โพสต์นี้ เราจะพยายามอย่างเต็มที่เพื่อตอบคำถามที่พบบ่อยที่สุด โดยให้รายละเอียดและบริบทมากที่สุดเท่าที่จะทำได้
อย่างไรก็ตาม ก่อนที่จะพูดถึงข้อมูลจำเพาะ คุณควรระบุว่า Google มี ไม่มีความต้องการว่าสถาปัตยกรรมหรือเทคโนโลยีใดที่ใช้ในการสร้าง ของคุณ เราเชื่อว่า SPA และแอปพลิเคชันแบบหลายหน้า (MPA) ต่างมีความสามารถ ในการมอบประสบการณ์คุณภาพสูงให้แก่ผู้ใช้ และความตั้งใจของเราที่มีต่อเว็บ โครงการริเริ่มของ Vitals คือการนำเสนอเมตริกที่วัดประสบการณ์การใช้งานแบบอิสระ เกี่ยวกับเทคโนโลยี แม้ว่าปัจจุบันนี่จะเป็นไปไม่ได้ในทุกกรณี (เนื่องจาก ในแพลตฟอร์มเว็บ) เรากําลังพยายามอย่างเต็มที่เพื่อปิด ช่องโหว่
คำถามที่พบบ่อย
เมตริกของ Core Web Vitals รวมการเปลี่ยนเส้นทาง SPA ไหม
ไม่ เราจะวัดเมตริก Core Web Vitals แต่ละรายการเทียบกับเมตริกปัจจุบัน การนำทางหน้าเว็บระดับบนสุด หากหน้าเว็บโหลดแบบไดนามิก เนื้อหาและอัปเดต URL ของหน้าเว็บในแถบที่อยู่ URL นั้นจะไม่มี ผลกระทบต่อวิธีการวัดเมตริก Core Web Vitals ค่าเมตริกไม่ใช่ รีเซ็ต และ URL ที่เชื่อมโยงกับการวัดเมตริกแต่ละรายการจะเป็น URL ที่ผู้ใช้ ไปที่ URL ที่เริ่มต้นการโหลดหน้าเว็บ
เมตริกของ Core Web Vitals จะถือว่าการเปลี่ยนแปลงเส้นทาง SPA เหมือนกับการโหลดหน้าเว็บแบบดั้งเดิมได้ไหม
ไม่ได้ ต้องขออภัยด้วย ยังก่อน
ปัจจุบันไม่มีวิธีการที่เป็นมาตรฐานในการสร้าง SPA SPA และ Routing Library ยอดนิยม ประสบการณ์ของผู้ใช้จึงอาจแตกต่างกันมาก จากแอปหนึ่งไปอีกแอปหนึ่ง
- SPA บางรายการจะอัปเดต URL เฉพาะเมื่อโหลด "แบบเต็มหน้า" ใหม่เท่านั้น ขณะที่เนื้อหา เว็บไซต์อื่นๆ อัปเดต URL ด้วยการเปลี่ยนแปลงเนื้อหาเล็กๆ น้อยๆ หรือแม้แต่เพียงสถานะ UI การเปลี่ยนแปลง
- SPA บางรายการจะอัปเดต URL โดยใช้ API ประวัติ ขณะที่รายการอื่นๆ ใช้แฮช เปลี่ยนแปลงเพื่อรองรับเบราว์เซอร์รุ่นเก่า (และเบราว์เซอร์อื่นจะไม่อัปเดต URL เลย)
- SPA บางรายการจะโหลดเนื้อหาแล้วอัปเดต URL ขณะที่รายการอื่นๆ จะอัปเดต URL ก่อนที่จะโหลดเนื้อหา
- บาง SPA โหลดเนื้อหาทั้งหมดพร้อมกันแบบซิงโครนัสใน JavaScript เดียว งาน ขณะที่ผู้อื่นเปลี่ยนเนื้อหาเป็น ไม่พร้อมกัน ในหลายๆ ด้าน งาน (ที่ไม่มีเหตุการณ์สิ้นสุดการเปลี่ยนอย่างชัดเจน)
- SPA บางรายการโหลดเนื้อหาจากเครือข่ายเสมอ ขณะที่บางรายการโหลดเนื้อหาล่วงหน้าทั้งหมด เนื้อหาได้ล่วงหน้า เพื่อให้การเปลี่ยนแปลงเส้นทางโหลดจากหน่วยความจำได้ทันที
ความแตกต่างเหล่านี้เป็นตัวกำหนดและระบุสิ่งที่ประกอบขึ้นเป็นเส้นทาง SPA เปลี่ยนแปลง หรือแม้แต่ SPA เอง ก็ดำเนินการได้ยากในวงกว้าง
ในบางกรณี การเปลี่ยนเส้นทาง SPA จะเหมือนกันกับการโหลดหน้าเว็บ MPA และในกรณีเช่นนี้ ก็คงจะดีหากเมตริกของ Core Web Vitals ที่มีอยู่ ได้
แต่การไม่มีการประเมินที่มั่นคงเพื่อให้ระบุ "จริง" ได้อย่างน่าเชื่อถือ เปลี่ยนเส้นทางจาก การเปลี่ยนแปลง URL อื่นๆ ทั้งหมด และแสดงสัญญาณที่ชัดเจนซึ่งแสดงถึงจุดเริ่มต้นและจุดสิ้นสุดของ การเปลี่ยนผ่านนี้ เช่น การรายงานเมตริกของ Core Web Vitals ในกรณีเหล่านี้อาจดูไม่แน่นอน ข้อมูลและทำให้ข้อมูลนั้นไม่ค่อยมีประโยชน์หรือแสดงถึงประสบการณ์จริงของผู้ใช้ บนเว็บไซต์
SPA ใน Core Web Vitals มีประสิทธิภาพดีกว่า MPA หรือไม่
ไม่มีอะไรแฝงอยู่ในสถาปัตยกรรม SPA ที่จะทำให้หน้าเว็บใน SPA จากการโหลดเร็วพอๆ กับการทำคะแนนใน Core เมตริก Web Vitals เป็นหน้าที่คล้ายกันใน MPA
อย่างไรก็ตาม MPA ที่มีการเพิ่มประสิทธิภาพอย่างเหมาะสมก็มีข้อได้เปรียบบางประการในการปฏิบัติตาม Core Web เกณฑ์ของ Vitals ที่ SPA ยังไม่มีในขณะนี้ เนื่องจาก MPA แต่ละ "หน้า" จะโหลดแบบการนำทางแบบเต็มหน้า (ไม่ใช่ ดึงข้อมูลเนื้อหาแบบไดนามิกและแทรกเนื้อหาลงในหน้าที่มีอยู่) หมายความว่าผู้ใช้ที่เข้าชม MPA มีแนวโน้มที่จะโหลดหน้ามากกว่า 1 หน้าจาก ในทางกลับกัน ซึ่งหมายความว่าส่วนแบ่งการตลาดของคุณจะมีเปอร์เซ็นต์สูง การโหลดหน้าเว็บสำหรับ MPA จะเกี่ยวข้องกับทรัพยากรย่อยบางส่วนหรือทั้งหมดที่ถูก แคช
ระบุว่า MPA จะทำงานได้ดีกว่าเมตริกของ Core Web Vitals เมื่อเทียบกับ SPA คุณต้องดำเนินการบางอย่างดังต่อไปนี้
- MPA ต้องมีการแคชทรัพยากรย่อยให้เหมาะสมเพื่อให้มั่นใจว่า การโหลดหน้าเว็บจากต้นทางเดียวกันนั้นเร็วกว่าการโหลดหน้าเว็บแบบข้ามต้นทางที่ เปอร์เซ็นไทล์ที่ 75
- ผู้ใช้ที่เข้าชม MPA จำเป็นต้องเข้าชมหน้าเว็บหลายหน้าเพื่อให้ไซต์สามารถ ได้รับประโยชน์จากการแคชที่ทำให้โหลดหน้าเว็บได้เร็วขึ้น
เนื่องจากการประเมิน Core Web Vitals พิจารณาเป็นครั้งที่ 75 เปอร์เซ็นไทล์ของหน้า การเข้าชมหน้าเว็บ และการเข้าชมหน้าเว็บที่มีประสิทธิภาพดีในชุดข้อมูลจะเพิ่มขึ้น แนวโน้มที่การเข้าชมที่เปอร์เซ็นไทล์ที่ 75 ของการกระจายจะ ภายในเกณฑ์ที่แนะนำ
โปรดทราบว่าสิ่งสำคัญที่ต้องพิจารณาเมื่อเปรียบเทียบคะแนน Core Web Vitals คือวิธีรวมข้อมูล กล่าวคือ ชุดข้อมูลที่อยู่ในการกระจาย รวมหน้าเว็บทั้งหมดจากเว็บไซต์หรือต้นทาง หรือเฉพาะการโหลดหน้าเว็บ URL ของหน้าเว็บ
เมื่อรวมคะแนนของหน้าทั้งหมดในต้นทาง หน้าเว็บที่โหลดเร็วแต่ละหน้าจะ เพื่อปรับปรุงเปอร์เซ็นไทล์ที่ 75 ของต้นทางในภาพรวม แต่เมื่อรวบรวมข้อมูล ตามแต่ละหน้าเว็บ คะแนนของหน้าเว็บหนึ่งหน้าจะไม่ส่งผลต่อคะแนนของ ถัดไป กล่าวคือ เมื่อรวมคะแนน MPA ตามหน้าเว็บ แคชที่รวดเร็ว การโหลดที่เห็นในหน้าชำระเงินจะไม่ทำให้คะแนนเริ่มต้นที่ช้า การโหลดที่เกิดขึ้นในช่วง หน้า Landing Page ของเว็บไซต์ หน้าเว็บ
คุณสามารถตรวจสอบคะแนนของเว็บไซต์สำหรับวิธีการรวมข้อมูลแบบต่างๆ ได้โดยใช้ PageSpeed Insights หรือ รายงานประสบการณ์ของผู้ใช้ Chrome API ซึ่งจะรายงานคะแนนสำหรับทั้ง URL ของหน้าเว็บแต่ละหน้าและต้นทางทั้งหมด
อีกวิธีหนึ่งที่สถาปัตยกรรม SPA สามารถส่งผลต่อคะแนน Core Web Vitals ก็คือ เมตริกที่พิจารณาอายุการใช้งานทั้งหมดของหน้าเว็บ เนื่องจากผู้ใช้ที่เข้าชม SPA มีแนวโน้มที่จะอยู่ใน "หน้า" เดียวกัน สำหรับทั้งเซสชัน เมตริกที่รวบรวม เมื่อเวลาผ่านไปอาจรุนแรงใน SPA มากกว่า MPA
เมื่อเดือนเมษายน 2021 เราได้ประกาศการเปลี่ยนแปลงเกี่ยวกับเมตริก CLS ที่ แก้ปัญหานี้ได้บางส่วน ก่อนหน้านี้ CLS จะสะสมสะสมในช่วง อายุการใช้งานของทั้งหน้า แต่ปัจจุบันจะสะสมเฉพาะในกรอบเวลาที่กำหนด ซึ่งก็คือการเปลี่ยนแปลงเลย์เอาต์ที่แย่ที่สุดในหน้าเว็บหนึ่งๆ
อย่างไรก็ตาม แม้จะมีคำนิยาม CLS ใหม่ แต่ SPA ก็ยังเสียเปรียบ เนื่องจากค่า CLS ไม่ได้ "รีเซ็ต" หลังจากที่เส้นทางเปลี่ยนไป ด้วยการโหลดหน้าเต็มในรูปแบบ MPA ซึ่งอาจทำให้เกิดความสับสนเพราะการจัดวาง การเปลี่ยนแปลงที่เกิดขึ้นหลังจากการเปลี่ยนเส้นทางจะถือว่ามาจาก URL ของ เมื่อหน้าโหลดขึ้นมา ไม่ใช่ URL ในแถบที่อยู่เมื่อมีการเปลี่ยน (รายละเอียดเพิ่มเติม ที่ด้านล่าง)
หากสถาปัตยกรรม SPA ปรับปรุงประสบการณ์ของผู้ใช้ การปรับปรุงดังกล่าวไม่ควรแสดงในเมตริกใช่ไหม
ควร แม้ว่าอย่างที่กล่าวไปก่อนหน้านี้ การวัดปริมาณเท่าใดว่า ที่ดีขึ้นในวงกว้างนั้น หาก วิธีนำ SPA มาใช้งานบนเว็บในปัจจุบัน
ความจริงคืออุตสาหกรรมด้านประสิทธิภาพเว็บไซต์ (รวมถึง Google) ไม่ได้มี ได้ใช้เวลาและความพยายามเกือบเท่าๆ ไปกับการพัฒนาการเน้นผู้ใช้ เมตริก สำหรับประสิทธิภาพหลังการโหลดของ ตามที่มีอยู่สำหรับการโหลดหน้าเว็บ ไม่ได้เกิดจากการโหลดหลังการโหลด ประสิทธิภาพไม่สำคัญ เพราะ UX และการโต้ตอบหลังโหลดนั้น หลากหลายขึ้นมากและไม่ค่อยชัดเจน จึงทำให้ออกแบบเมตริกสำหรับ ให้พวกเขา
แม้ว่าเราจะกำหนดเมตริกหลังการโหลดไว้อย่างดีเพื่อวัดผล SPA ของประสิทธิภาพ เราไม่ต้องการมองข้ามประสบการณ์การโหลดเพียงเพราะ ประสบการณ์การโหลดโพสต์ดีขึ้นกว่าเดิม
เป้าหมายอย่างหนึ่งของโครงการริเริ่ม Web Vitals คือการส่งเสริมและจูงใจ ประสบการณ์ของผู้ใช้ในหลายๆ ด้านของการโหลดและใช้หน้าเว็บ เท่าที่จะเป็นไปได้ เราไม่ต้องการส่งเสริมให้เกิดประสบการณ์ที่ไม่ดี ถ้าคุณมีประสบการณ์ ที่ดีพอที่จะชดเชย ผู้ใช้ ต้องการให้หน้าเว็บโหลดเร็วและเปลี่ยนไปเป็นเนื้อหาใหม่ได้เร็ว และเราพยายาม ออกแบบเมตริกที่เหมาะกับประสบการณ์ประเภทดังกล่าว
ดังนั้น แม้ว่าเว็บไซต์เวอร์ชัน MPA อาจทำงานได้ดีกว่าในเว็บหลัก เมตริก Vitals ที่เปอร์เซ็นไทล์ที่ 75 เมื่อเทียบกับเวอร์ชัน SPA ที่เหมือนกันทุกประการ เวอร์ชัน SPA ยังควรพยายามตอบโจทย์ หาก เวอร์ชัน SPA ไม่ตรงตาม "ดี" สำหรับผู้ใช้ส่วนใหญ่ ประสบการณ์การโหลดอาจยังไม่ค่อยดีนัก แม้ว่า การนำทางในหน้าเว็บนั้นยอดเยี่ยมมาก
ในอนาคต เราวางแผนที่จะพัฒนาเมตริกต่างๆ ที่สนับสนุนหลังการโหลดที่ยอดเยี่ยม และเราเชื่อว่านี่เป็นวิธีที่ดีที่สุดในการจูงใจ ให้มีคุณภาพสูง SPA ในลักษณะที่ไม่กระทบต่อประสบการณ์การโหลดเริ่มต้น เรามี ได้ส่งเมตริกใหม่ชื่อ Interaction to Next Paint (INP) ซึ่งวัดเวลาในการตอบสนองของการโต้ตอบตลอดอายุการใช้งานหน้าเว็บ และเรากำลังพัฒนาเมตริกอื่นๆ เมตริกหลังโหลดด้วย รวมถึงเมตริกที่วัดการเปลี่ยนเส้นทาง SPA (ดูด้านล่าง)
เราเปลี่ยนเว็บไซต์ของเราจาก MPA เป็น SPA และคะแนนของเราก็ถดถอย นี่เป็นเรื่องปกติใช่ไหม
แล้วแต่กรณี มีสาเหตุหลายประการที่อาจทำให้คะแนนของคุณเปลี่ยนแปลงไปหลังจาก การย้ายข้อมูลสถาปัตยกรรมที่สำคัญ แต่จำนวนการโหลดแคชอุ่นลดลง อาจมีผลต่อการเปลี่ยนแปลงบางอย่าง
วิธีตรวจสอบที่รวดเร็วคือการทดสอบทั้งเวอร์ชัน MPA และ SPA ของ หน้า Landing Page ที่มี Lighthouse หาก Lighthouse คะแนนต่ำกว่าเมตริก Core Web Vitals สำหรับ SPA มีแนวโน้มว่าประสบการณ์การโหลดจะแย่ลงหลังจาก อัปเดต
ฉันควรเปลี่ยนเว็บไซต์ของฉันจาก SPA เป็น MPA เพื่อให้คะแนนใน Core Web Vitals ดีขึ้นไหม
อาจจะไม่ คุณควรเปลี่ยนจาก SPA เป็น MPA ในกรณีที่รู้สึกไม่สบายใจเท่านั้น กับสแต็ก SPA และคุณมีเหตุผลที่จะเชื่อว่า MPA จะให้ ประสบการณ์ของผู้ใช้
เมื่อเวลาผ่านไป เนื่องจากเมตริกของ Core Web Vitals จะปรับปรุงและครอบคลุม ประสบการณ์ท่องเว็บ ทีมงานที่มี SPA ที่สร้างมาอย่างดี พร้อมมอบประสบการณ์ใช้งานที่ยอดเยี่ยม ว่าคะแนน Core Web Vitals จะสะท้อนถึงสิ่งนั้น
หากมีการรายงานคะแนน Core Web Vitals สำหรับหน้า Landing Page ของ SPA เท่านั้น ฉันจะแก้ไขข้อบกพร่องที่เกิดขึ้นใน "หน้าเว็บ" ได้อย่างไร หลังการเปลี่ยนเส้นทาง
เครื่องมือของ Google ที่รายงานข้อมูลในช่องสำหรับเมตริก Core Web Vitals (เช่น Search Console และ PageSpeed Insights) รับข้อมูลจากประสบการณ์ของผู้ใช้ Chrome รายงาน (CrUX) และ CrUX จะรวบรวมข้อมูลตามต้นทางหรือตาม URL ของหน้าเว็บ (กล่าวคือ URL ของหน้าเว็บขณะโหลด)
จากเหตุผลทั้งหมดที่ระบุไว้ข้างต้น CrUX ไม่สามารถรวบรวมข้อมูลตาม เส้นทาง SPA อย่างไรก็ตาม ในฐานะเจ้าของเว็บไซต์ที่คุ้นเคยกับสถาปัตยกรรมของคุณเอง คุณก็สามารถวัดผลได้ด้วยตัวเอง และเครื่องมือวิเคราะห์อีกมากมาย เมื่อมีการเปลี่ยนเส้นทาง SPA และอัปเดตการวัดผล ตามข้อมูลที่ได้รับ
เมื่อวัดเมตริก Web Vitals ด้วยเครื่องมือวิเคราะห์ โปรดตรวจสอบว่าคุณ วัดทั้ง URL เส้นทางปัจจุบันและ URL ของหน้าเดิม การดำเนินการนี้จะ ช่วยให้คุณแก้ไขข้อบกพร่องของปัญหาแต่ละอย่างที่เกิดขึ้นในหน้าเว็บ ตลอดจนรวบรวมตาม URL ของหน้าเดิมเพื่อให้ตรงกับวิธีที่ Google เครื่องมือวัดผลและรายงานเกี่ยวกับเมตริก
ดูรายละเอียดเพิ่มเติมและแนวทางปฏิบัติแนะนำเกี่ยวกับหัวข้อนี้ได้ที่แก้ไขข้อบกพร่องด้านประสิทธิภาพใน
Google จะทำอย่างไรเพื่อให้มั่นใจว่า MPA ไม่มีข้อได้เปรียบอย่างไม่เป็นธรรมเมื่อเทียบกับ SPA
ดังที่กล่าวไว้ข้างต้น ในบางกรณี MPA ที่เพิ่มประสิทธิภาพอย่างเหมาะสมจะสามารถรายงาน คะแนน Web Vitals ที่เปอร์เซ็นไทล์ที่ 75 เนื่องจากมีแนวโน้มว่า มีเปอร์เซ็นต์การเข้าชมหน้าเว็บที่แคชไว้สูงกว่า ในทางกลับกัน การปรับปรุงที่แท้จริงสำหรับ ยังไม่มีการบันทึกประสบการณ์ของผู้ใช้ใน SPA ที่มีการเพิ่มประสิทธิภาพอย่างเหมาะสม ตามเมตริกของ Core Web Vitals
Google ตระหนักดีว่าสิ่งนี้สร้างสิ่งจูงใจที่ไม่สอดคล้องกับความต้องการทั้งหมด กับเป้าหมายของโครงการริเริ่ม Web Vitals และเรากำลังเร่งหาวิธีใช้ เพื่อแก้ไขปัญหานี้ ปัจจุบัน เรากำลังสำรวจโซลูชันที่เป็นไปได้ 2 โซลูชัน โดยโซลูชันหนึ่งระยะสั้น และอีก 1 ระยะยาว
- ประเมินการเข้าชมหน้าแบบข้ามต้นทางและต้นทางเดียวกันแยกกัน
- ออกแบบ API ใหม่ที่ช่วยให้วัด SPA ได้ดีขึ้น
ประเมินการเข้าชมหน้าแบบข้ามต้นทางและหน้าต้นทางเดียวกันแยกกัน
ปัจจุบันเมตริกของ Core Web Vitals รวบรวมการเข้าชมหน้าเว็บทั้งหมดเป็นเมตริกเดียว โดยจะไม่แยกความแตกต่างระหว่างการเข้าชมใหม่กับผู้เข้าชมที่กลับมาหรือ Landing Page หน้าเทียบกับหน้าชำระเงินหรือการรวมประเภทอื่นๆ ที่มีสถานะแคช ก็อาจส่งผลต่อประสิทธิภาพได้
วิธีหนึ่งที่จะทำให้ความแตกต่างระหว่างประสิทธิภาพของ SPA และ MPA เป็นปกติคือ ใช้การถ่วงน้ำหนักที่ต่างกันกับการเข้าชมประเภทต่างๆ เกณฑ์ที่แตกต่างออกไปโดยสิ้นเชิง คำแนะนำ
แม้ว่าเราจะต้องการตอบแทนการติดตั้งแคชที่มีประสิทธิภาพ เราก็ไม่ ต้องการการนำทางภายในเว็บไซต์ที่รวดเร็วเพื่อครอบคลุมหน้า Landing Page ที่ช้า โหลดขึ้นมา และเราไม่ต้องการจูงใจให้เว็บไซต์แบ่งหน้าเว็บยาวๆ ออกเป็น คอลเล็กชันของหน้าเว็บสั้นๆ เพื่อปรับปรุงคะแนนเมตริกเท่านั้น
การประเมินการเข้าชมในหน้าแบบข้ามต้นทางและต้นทางเดียวกันแยกกันช่วยให้เราช่วยได้ ทำให้แน่ใจว่าประสบการณ์ทั้ง 2 ประเภทนั้นสำคัญโดยไม่ต้องให้ประสบการณ์ ความนิยมของประเภทหนึ่งๆ ในเว็บไซต์หนึ่งๆ บิดเบือนการกระจายของ เมตริก
ออกแบบ API ใหม่ที่ช่วยให้วัด SPA ได้ดียิ่งขึ้น
วิธีแก้ไขอีกอย่างหนึ่งที่เรากําลังพัฒนา (ควบคู่ไปกับแนวทางข้างต้น) คือ API ประวัติแอปใหม่ซึ่งจะช่วยทำให้ รูปแบบ SPA ทั้งยังช่วยให้วัดและทำความเข้าใจการใช้งาน SPA ในวงกว้างได้ง่ายขึ้น
App History API ขอแนะนำ
navigate ซึ่ง
มีฟีเจอร์หลัก 2 อย่างสําหรับการวัด SPA โดยเฉพาะ ได้แก่
- ต
userInitiatedซึ่งจะตั้งค่าเป็น "จริง" ก็ต่อเมื่อการนำทางเริ่มต้นขึ้นผ่าน การคลิกลิงก์ การส่งแบบฟอร์ม หรือ UI การย้อนกลับหรือการส่งต่อของเบราว์เซอร์ - ต
transitionWhile()ซึ่งจะให้คำมั่นสัญญาในการอนุญาตให้นักพัฒนาซอฟต์แวร์ส่งสัญญาณแจ้งเมื่อ ที่ผู้ใช้ได้เริ่มดำเนินการเพื่อให้การนำทางเสร็จสมบูรณ์
แฟล็ก userInitiated สามารถใช้เพื่อกำหนดจุดเริ่มต้นทางความหมายสำหรับ
การเปลี่ยนเส้นทาง SPA เป็นการแสดงความตั้งใจของผู้ใช้ที่ชัดเจน transitionWhile()
การแปลงข้อมูลจะช่วยให้เบราว์เซอร์เชื่อมโยงการแสดงผลกับเส้นทางที่เฉพาะเจาะจง
เพื่อที่ว่าเทคโนโลยีนี้จะสามารถระบุ Contentful Paint ที่ใหญ่ที่สุดได้
ที่เกี่ยวข้องกับการเปลี่ยนนั้น
ต่อยอดจากไอเดียที่นำเสนอในส่วนก่อนหน้านี้ ในการรวมเวลาการเปลี่ยนเส้นทาง SPA ไว้ในที่เก็บข้อมูลเดียวกัน การโหลดหน้าต้นทางเดียวกันใน MPA ซึ่งเป็นเรื่องที่น่าตื่นเต้น เนื่องจากจะช่วยให้เว็บไซต์ การย้ายข้อมูลจาก MPA ไปยัง SPA เพื่อเปรียบเทียบประสิทธิภาพที่แท้จริงก่อนและหลัง หลังจากนั้น
แน่นอนว่าต้องมีการวิจัยเพิ่มเติมก่อน จึงจะทราบว่าเราสามารถ จะพิจารณาเรื่องเหล่านี้ หากคุณมีคำแนะนำหรือความคิดเห็นเกี่ยวกับ โปรดส่งอีเมล web-vitals-feedback@googlegroups.com
ความคิดขั้นสุดท้าย
Google มุ่งมั่นที่จะปรับปรุงเมตริก Web Vitals และรับประกันว่า วัดผลและจูงใจให้ได้รับประสบการณ์คุณภาพสูงที่มีความสำคัญต่อ ผู้ใช้ อย่างไรก็ตาม เราทราบดีว่ามีช่องว่างในการวัดผลในปัจจุบัน และไม่ได้ครอบคลุมประสบการณ์ของผู้ใช้ในทุกแง่มุม แต่เรา อย่างเต็มที่เพื่อปิดช่องว่างเหล่านี้
แม้ในปัจจุบันจะมีข้อจำกัดมากมาย แต่เราเชื่อว่าเมตริกที่มีอยู่จะมีประโยชน์ต่อคุณ และมีความสำคัญอย่างยิ่งต่อความสำเร็จและความสำเร็จของเว็บ เว็บไซต์ (ไม่ว่าจะมีสถาปัตยกรรมแบบใด) ไม่เป็นไปตามเกณฑ์ที่แนะนำ เราเชื่อว่ายังมีสิ่งที่ต้องปรับปรุง
เราหวังว่าโพสต์นี้จะทำให้คุณเห็นประเด็นที่มีความซับซ้อนและละเอียดอ่อนนี้ และเช่นเคย หากคุณมีความคิดเห็นเกี่ยวกับเมตริก Web Vitals ในปัจจุบันหรือในอนาคต ส่งอีเมลถึงหน่อย web-vitals-feedback@googlegroups.com