สถาปัตยกรรม SPA ส่งผลต่อ Core Web Vitals อย่างไร

คำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับ SPA, Core Web Vitals และแผนการของ Google ในการแก้ไขข้อจำกัดในการวัดผลในปัจจุบัน

Philip Walton

Yoav Weiss

นับตั้งแต่เปิดตัวโครงการริเริ่ม Web Vitals เป็นครั้งแรกในเดือนพฤษภาคม 2020 ทีม Chrome ก็ได้รับคำถามและความคิดเห็นดีๆ มากมายเกี่ยวกับโปรแกรม

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

คำถามเหล่านี้ตอบยากเนื่องจากปัญหาค่อนข้างแตกต่างกัน ดังนั้นในโพสต์นี้ เราจะพยายามตอบคำถามที่พบบ่อยที่สุดโดยให้รายละเอียดและบริบทให้มากที่สุด

ก่อนที่จะเข้าดูรายละเอียดเฉพาะ ควรบอกว่า Google ไม่มีความชอบเป็นพิเศษเกี่ยวกับสถาปัตยกรรมหรือเทคโนโลยีที่ใช้ในการสร้างเว็บไซต์ เราเชื่อว่า SPA และแอปพลิเคชันที่มีหลายหน้าเว็บ (MPA) สามารถมอบประสบการณ์ที่มีคุณภาพสูงให้แก่ผู้ใช้ และความตั้งใจของเราที่มีต่อโครงการริเริ่ม Web Vitals คือการนำเสนอเมตริกที่วัดประสบการณ์การใช้งานโดยไม่เกี่ยวข้องกับเทคโนโลยี แม้ว่าในปัจจุบันจะเป็นไปไม่ได้ในทุกกรณี (เนื่องจากข้อจำกัดในแพลตฟอร์มเว็บ) แต่เราก็กำลังดำเนินการอย่างเต็มที่เพื่อปิดช่องว่างเหล่านั้น

หมายเหตุ: ข้อมูลอัปเดต (กุมภาพันธ์ 2023): เว็บไซต์ได้ทดลองใช้แล้ว ดูรายละเอียดเพิ่มเติมในโพสต์การทดสอบการวัดการนำทางแบบนุ่มนวล

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

เมตริก Core Web Vitals รวมการเปลี่ยนเส้นทาง SPA หรือไม่

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

เมตริก Core Web Vitals จะจัดการกับการเปลี่ยนเส้นทาง SPA เหมือนกับการโหลดหน้าเว็บแบบดั้งเดิมได้ไหม

ขออภัย ยังไม่ใช่

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

• SPA บางรายจะอัปเดต URL เฉพาะเวลาที่โหลดเนื้อหา "แบบเต็มหน้า" ใหม่เท่านั้น ในขณะที่เว็บไซต์อื่นๆ อัปเดต URL สำหรับการเปลี่ยนแปลงเนื้อหาเล็กๆ น้อยๆ หรือแม้กระทั่งการเปลี่ยนแปลงสถานะ UI
• SPA บางรายอัปเดต URL โดยใช้ History API ในขณะที่บางรายใช้การเปลี่ยนแปลงแฮชเพื่อรองรับเบราว์เซอร์รุ่นเก่า (และบางตัวไม่อัปเดต URL เลย)
• โดย SPA บางรายการจะโหลดเนื้อหาแล้วอัปเดต URL ขณะที่บางรายการจะอัปเดต URL ก่อนที่จะโหลดเนื้อหา
• SPA บางรายการจะโหลดเนื้อหาพร้อมกันทั้งหมดพร้อมกันในงาน JavaScript งานเดียว ขณะที่รายการอื่นๆ จะเปลี่ยนเนื้อหาแบบไม่พร้อมกันในหลายๆ งาน (โดยไม่มีเหตุการณ์สิ้นสุดการเปลี่ยนที่ชัดเจน)
• SPA บางรายจะโหลดเนื้อหาจากเครือข่ายเสมอ ขณะที่รายอื่นๆ จะโหลดเนื้อหาทั้งหมดล่วงหน้าเพื่อให้การเปลี่ยนแปลงเส้นทางโหลดจากหน่วยความจำได้ทันที

ความแตกต่างเหล่านี้ทำให้การกำหนดและการระบุสิ่งที่ประกอบขึ้นเป็นการเปลี่ยนแปลงเส้นทาง SPA หรือแม้กระทั่ง SPA เองนั้นเป็นเรื่องยากมากที่จะทำในวงกว้าง

ในบางกรณี การเปลี่ยนเส้นทาง SPA จะเหมือนกับการโหลดหน้าเว็บของ MPA อย่างสมเหตุสมผล และในกรณีเช่นนี้ การเปลี่ยนเส้นทาง SPA จะดีมากหากใช้เมตริก Core Web Vitals ที่มีอยู่

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

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

คุณตรวจสอบคะแนนของเว็บไซต์สำหรับวิธีการรวบรวมแบบต่างๆ ได้โดยใช้ PageSpeed Insights หรือ API รายงานประสบการณ์ของผู้ใช้ Chrome ซึ่งจะรายงานคะแนนของทั้ง 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 อาจมีประสิทธิภาพดีกว่าในเมตริก Core Web Vitals ที่เปอร์เซ็นไทล์ที่ 75 เมื่อเทียบกับเวอร์ชัน SPA ของเว็บไซต์เดียวกัน แต่เวอร์ชัน SPA ควรพยายามทำให้ได้ตามเกณฑ์ "ดี" หากเวอร์ชัน SPA ไม่เป็นไปตามเกณฑ์ "ดี" สำหรับผู้ใช้ส่วนใหญ่ ประสบการณ์การโหลดช่วงแรกก็อาจยังไม่ถือว่าดี แม้ว่าประสบการณ์การนำทางในหน้าเว็บที่ตามมาจะยอดเยี่ยมก็ตาม

ในอนาคตเราวางแผนที่จะพัฒนาเมตริกที่จะช่วยส่งเสริมประสบการณ์หลังการโหลดที่ยอดเยี่ยม และเราเชื่อว่านี่เป็นเส้นทางที่ดีที่สุดในการจูงใจให้ SPA คุณภาพสูงในลักษณะที่ไม่กระทบต่อประสบการณ์การโหลดครั้งแรก เราได้แสดงเมตริกใหม่ที่ชื่อ Interaction to Next Paint (INP) ที่วัดเวลาในการตอบสนองของการโต้ตอบตลอดทั้งวงจรของหน้าเว็บ และกำลังดำเนินการอย่างเต็มที่กับเมตริกอื่นๆ หลังการโหลด รวมถึงเมตริกที่วัดการเปลี่ยนเส้นทาง SPA (ดูด้านล่าง)

เราเปลี่ยนเว็บไซต์ของเราจาก MPA เป็น SPA และคะแนนของเราก็ถดถอยลง นี่เป็นเรื่องปกติใช่ไหม

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

วิธีตรวจสอบที่รวดเร็วคือการทดสอบทั้งเวอร์ชัน MPA และ SPA ของหน้า Landing Page หน้าใดหน้าหนึ่งด้วย Lighthouse หากคะแนนของ Lighthouse ในเมตริก Core Web Vitals สำหรับเวอร์ชัน SPA ต่ำกว่าคะแนน แสดงว่าประสบการณ์การโหลดแย่ลงหลังการอัปเดต

ฉันควรเปลี่ยนเว็บไซต์จาก SPA เป็น MPA เพื่อให้คะแนนใน Core Web Vitals ดีขึ้นไหม

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

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

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

1. ประเมินการเข้าชมหน้าเว็บแบบข้ามต้นทางและหน้าเว็บเดียวกันแยกกัน
2. ออกแบบ API ใหม่ที่ช่วยให้การวัด SPA ดีขึ้น

ประเมินการเข้าชมหน้าเว็บแบบข้ามต้นทางและหน้าเว็บเดียวกันแยกกัน

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

วิธีหนึ่งในการทําให้ความแตกต่างระหว่างประสิทธิภาพของ SPA และ MPA เป็นมาตรฐานก็คือการใช้การถ่วงน้ำหนักที่ต่างกันกับการเข้าชมประเภทต่างๆ ซึ่งอาจจะมีคําแนะนําเกี่ยวกับเกณฑ์ที่แตกต่างกันโดยสิ้นเชิง

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

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

ออกแบบ API ใหม่ที่ช่วยให้การวัด SPA ดีขึ้น

อีกโซลูชันหนึ่งที่กําลังพัฒนาอยู่ (เช่นเดียวกับข้างต้น) คือ App History API ใหม่ซึ่งจะช่วยทําให้รูปแบบ SPA ปัจจุบันเป็นมาตรฐาน รวมถึงทำให้วัดผลและทำความเข้าใจการใช้งาน SPA ในวงกว้างได้ง่ายขึ้น

App History API เปิดตัวเหตุการณ์ navigate ใหม่ ซึ่งมีฟีเจอร์หลัก 2 อย่างสำหรับการวัด SPA โดยเฉพาะ ดังนี้

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

แฟล็ก userInitiated สามารถใช้กำหนดจุดเริ่มต้นเชิงความหมายสำหรับการเปลี่ยนเส้นทาง SPA ได้ ซึ่งบ่งบอกถึงความตั้งใจของผู้ใช้ที่ชัดเจน การแปลงโดยใช้สัญญา transitionWhile() จะช่วยให้เบราว์เซอร์เชื่อมโยงสีกับการเปลี่ยนเส้นทางที่เฉพาะเจาะจงได้ ซึ่งจะทำให้สามารถระบุ Contentful Paint ที่เกี่ยวข้องกับการเปลี่ยนดังกล่าวได้มากที่สุด

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

หมายเหตุ: ข้อมูลอัปเดต (กุมภาพันธ์ 2023): ดูโพสต์การทดสอบด้วยการวัดการนำทางแบบนุ่มนวลเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับ API "การไปยังส่วนต่างๆ แบบนุ่มนวล" ใหม่ที่มีจุดมุ่งหมายเพื่อช่วยให้การวัดผล Core Web Vitals ที่ดีขึ้นสำหรับ SPA

แน่นอนว่าต้องมีการวิจัยมากกว่านี้ก่อนที่เราจะทราบว่าเราสามารถพิจารณาเรื่องนี้ได้อย่างแม่นยำหรือไม่ หากคุณมีคำแนะนำหรือความคิดเห็นเกี่ยวกับข้อเสนอเหล่านี้ โปรดส่งอีเมลไปที่ [e-mail]

ความคิดขั้นสุดท้าย

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

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

เราหวังว่าโพสต์นี้จะทำให้คุณเข้าใจหัวข้อที่ซับซ้อนและแตกต่างกันเพียงเล็กน้อยได้ และเช่นเคย หากคุณมีความคิดเห็นเกี่ยวกับเมตริก Web Vitals ในปัจจุบันหรืออนาคต โปรดส่งอีเมลไปที่ [e-mail]