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

คำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับ SPA, Core Web Vitals และวิธีที่ Core Web Vitals จัดการกับสิ่งเหล่านี้

Philip Walton

Yoav Weiss

Barry Pollard

เผยแพร่เมื่อวันที่ 14 กันยายน 2021 อัปเดตล่าสุดเมื่อวันที่ 11 สิงหาคม 2026

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

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

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

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

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

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

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

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

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

Chrome 151 ได้เปิดตัว API ใหม่ที่ช่วยให้วัด Core Web Vitals ในการเปลี่ยนเส้นทางของ SPA ได้ ณ เวลาที่เขียนบทความนี้ (สิงหาคม 2026) ไลบรารีการวัดผล เช่น web-vitals, โซลูชัน RUM และเครื่องมือต่างๆ เช่น เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพิ่งเริ่มใช้ API เหล่านี้ Chrome ยังไม่ได้เผยแพร่กรอบเวลาในการผสานรวม API เหล่านี้เข้ากับรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) นอกจากนี้ กลไกการแสดงผลของเบราว์เซอร์อื่นๆ ยังไม่รองรับ API ใหม่เหล่านี้ ดังนั้นจึงวัด Core Web Vitals ได้เฉพาะการโหลดหน้าเว็บแบบเต็มสำหรับเบราว์เซอร์เหล่านั้น

เหตุใดปัญหานี้จึงแก้ไขได้ยาก

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

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

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

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

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

งานการนำทางแบบยืดหยุ่นได้มอบโซลูชันสำหรับปัญหานี้ด้วย API ประสิทธิภาพใหม่ 2 รายการ

• PerformanceSoftNavigation ซึ่งวัดเวลาที่การโต้ตอบของผู้ใช้นำไปสู่การแสดงผลและการเปลี่ยนแปลง URL การรวมกันของ 3 สิ่งนี้จะให้คำจำกัดความมาตรฐานของการ "นำทางแบบยืดหยุ่น" ไม่ว่าเฟรมเวิร์กที่ใช้จะเป็นอะไรและไม่ว่าจะมีข้อแตกต่างบางอย่างที่กล่าวถึงก่อนหน้านี้ ซึ่งจะช่วยให้แยกไทม์ไลน์ประสิทธิภาพออกเป็นการ "นำทาง" ที่แยกกันได้ ทำให้วัด CLS และ INP สำหรับการนำทางแต่ละครั้งได้
• InteractionContentfulPaint ซึ่งวัด "Contentful Paint" หลังจากการโต้ตอบ ทำให้วัด FCP และ LCP สำหรับการนำทางแบบยืดหยุ่นเหล่านี้ได้

การรวมกันของ API ทั้ง 2 รายการนี้ช่วยให้วัด Core Web Vitals ได้ทั้งการโหลดหน้าเว็บแบบเต็มและการนำทางแบบยืดหยุ่น

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

ไม่ การนำทางประเภทเหล่านี้ยังคงมีความแตกต่างกันหลายอย่าง ซึ่งอาจส่งผลให้เมตริก Core Web Vitals แตกต่างกัน

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

ในทางทฤษฎี ความแตกต่างหลักคือการนำทางแบบยืดหยุ่นอาจเร็วกว่ามาก แต่ก็มีความแตกต่างอื่นๆ ที่ละเอียดกว่า

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

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

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

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

SPA ทำได้ยากกว่า MPA ในการทำคะแนนได้ดีใน Core Web Vitals ใช่ไหม

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

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

แน่นอนว่า MPA จะทำคะแนนได้ดีกว่าในเมตริก Core Web Vitals เมื่อเทียบกับ SPA ได้ก็ต่อเมื่อเป็นไปตามเงื่อนไขต่อไปนี้

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

เนื่องจากการประเมิน Core Web Vitals พิจารณาการเข้าชมหน้าเว็บที่เปอร์เซ็นไทล์ที่ 75 การมีการเข้าชมหน้าเว็บจำนวนมากขึ้นที่ทำได้ดีในชุดข้อมูลจะเพิ่มโอกาสที่การเข้าชมที่เปอร์เซ็นไทล์ที่ 75 ของการกระจายจะอยู่ในเกณฑ์ที่แนะนำ

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

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

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

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

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

หากสถาปัตยกรรม SPA ปรับปรุงประสบการณ์ของผู้ใช้ การปรับปรุงนั้นก็ควรแสดงในเมตริกด้วยใช่ไหม

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

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

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

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

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

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

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

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

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

เราเชื่อว่างานการนำทางแบบยืดหยุ่นได้แก้ไขปัญหาการวัดผลแล้ว ดังนั้นการย้ายข้อมูลด้วยเหตุผลนั้นเพียงอย่างเดียวจึงไม่สมเหตุสมผล

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

หากระบบรายงานคะแนน Core Web Vitals สำหรับหน้าแรกของ SPA เท่านั้น ฉันจะแก้ไขข้อบกพร่องที่เกิดขึ้นใน "หน้าเว็บ" หลังจากการเปลี่ยนเส้นทางได้อย่างไร

เครื่องมือของ Google ที่รายงานข้อมูลภาคสนามสำหรับเมตริก Core Web Vitals (เช่น Search Console และ PageSpeed Insights) จะรับข้อมูลจากรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) และ CrUX จะรวมข้อมูลตามต้นทางหรือตาม URL ของหน้าเว็บ (นั่นคือ URL ของหน้าเว็บ ณ เวลาที่ใช้ในการโหลด)

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

ดูรายละเอียดเพิ่มเติมและแนวทางปฏิบัติแนะนำเกี่ยวกับเรื่องนี้ได้ที่การวัดการนำทางแบบยืดหยุ่น

Google ทำอะไรบ้างเพื่อให้แน่ใจว่า MPA จะไม่ได้รับข้อได้เปรียบที่ไม่ยุติธรรมเมื่อเทียบกับ SPA

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

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

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

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

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

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

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

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

นอกจากนี้ เรายังเชื่อว่า API ใหม่เหล่านี้ (โดยเฉพาะ InteractionContentfulPaint) มีประโยชน์และการใช้งานที่เป็นไปได้อื่นๆ นอกเหนือจากการวัด Core Web Vitals สำหรับการนำทางแบบยืดหยุ่น เราตื่นเต้นมากที่จะพัฒนา API เหล่านี้ต่อไปในตอนนี้ที่ได้แก้ไขเหตุผลหลักในการเปิดตัว API เหล่านี้แล้ว

เราหวังว่าโพสต์นี้จะช่วยให้คุณเข้าใจหัวข้อที่ซับซ้อนและละเอียดอ่อนนี้มากขึ้น และเช่นเคย หากมีความคิดเห็นเกี่ยวกับเมตริก Web Vitals ปัจจุบันหรือในอนาคต โปรดส่งอีเมลไปที่ web-vitals-feedback@googlegroups.com