คำตอบสำหรับคําถามที่พบบ่อยเกี่ยวกับ SPA, Core Web Vitals และแผนของ Google ในการแก้ปัญหาข้อจํากัดการวัดผลในปัจจุบัน
นับตั้งแต่เปิดตัวโครงการริเริ่ม 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 ที่ผู้ใช้ไปยังซึ่งเริ่มการโหลดหน้าเว็บ
เมตริก 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 ในแง่ตรรกะ และในกรณีเช่นนี้ การใช้เมตริก Core Web Vitals ที่มีอยู่ก็น่าจะเหมาะ
อย่างไรก็ตาม หากไม่มีวิธีการหาค่าประมาณที่แน่ชัดในการระบุการเปลี่ยนแปลงเส้นทาง "จริง" จากการเปลี่ยนแปลง URL อื่นๆ ทั้งหมด รวมถึงสัญญาณที่ชัดเจนซึ่งระบุจุดเริ่มต้นและจุดสิ้นสุดของการเปลี่ยนเส้นทางดังกล่าว การรายงานเมตริก Core Web Vitals ในกรณีเหล่านี้จะทำให้ข้อมูลมีความซับซ้อนและทำให้ข้อมูลนั้นมีประโยชน์น้อยลงหรือไม่แสดงถึงประสบการณ์การใช้งานจริงของผู้ใช้บนเว็บไซต์
SPA มีประสิทธิภาพดีใน Core Web Vitals ได้ยากกว่า MPA ไหม
สถาปัตยกรรม SPA ไม่ได้มีข้อจำกัดที่ทําให้หน้าใน SPA โหลดช้ากว่าหน้าใน MPA และไม่ได้ทําให้หน้าใน SPA ได้คะแนนไม่ดีเท่าหน้าใน MPA ในเมตริก Core Web Vitals ทั้งหมด
อย่างไรก็ตาม MPA ที่เพิ่มประสิทธิภาพอย่างเหมาะสมมีข้อได้เปรียบบางอย่างในการช่วยให้เป็นไปตามเกณฑ์ของ Core Web Vitals ซึ่งปัจจุบัน SPA ยังไม่สามารถทำได้ สาเหตุคือเมื่อใช้สถาปัตยกรรม MPA ระบบจะโหลด "หน้า" แต่ละหน้าเป็นการไปยังส่วนต่างๆ ของหน้าเว็บแบบเต็ม (แทนที่จะดึงข้อมูลเนื้อหาแบบไดนามิกและแทรกลงในหน้าที่มีอยู่) ซึ่งหมายความว่าผู้ใช้ที่เข้าชม MPA มีแนวโน้มที่จะโหลดหน้าเว็บมากกว่า 1 หน้าจากเว็บไซต์ ซึ่งหมายความว่าเปอร์เซ็นต์ที่สูงขึ้นของการกระจายการโหลดหน้าเว็บทั้งหมดสําหรับ MPA จะเกี่ยวข้องกับการแคชทรัพยากรย่อยบางส่วนหรือทั้งหมด
แน่นอนว่า MPA จะต้องมีคุณสมบัติบางอย่างจึงจะมีประสิทธิภาพดีกว่า SPA ในเมตริก Core Web Vitals
- MPA ต้องมีการแคชทรัพยากรย่อยที่เพิ่มประสิทธิภาพเพื่อให้การโหลดหน้าเว็บจากแหล่งที่มาเดียวกันเร็วกว่าการโหลดหน้าเว็บจากแหล่งที่มาต่างๆ ที่เปอร์เซ็นต์ไทล์ 75
- ผู้ใช้ที่เข้าชม MPA ต้องเข้าชมหน้าเว็บหลายหน้าเพื่อให้เว็บไซต์ได้รับประโยชน์จากการแคชซึ่งส่งผลให้หน้าเว็บโหลดเร็วขึ้น
เนื่องจากการประเมิน Core Web Vitals พิจารณาเปอร์เซ็นไทล์ที่ 75 ของการเข้าชมหน้าเว็บ การมีการเข้าชมหน้าเว็บที่มีประสิทธิภาพมากขึ้นในชุดข้อมูลจะเพิ่มความเป็นไปได้ที่การเข้าชมในเปอร์เซ็นไทล์ที่ 75 ของการแจกแจงจะอยู่ในเกณฑ์ที่แนะนำ
โปรดทราบว่าสิ่งสําคัญที่ควรพิจารณาเมื่อเปรียบเทียบคะแนน Core Web Vitals คือวิธีรวบรวมข้อมูล ซึ่งก็คือชุดข้อมูลในการแจกแจงรวมหน้าเว็บทั้งหมดจากเว็บไซต์หรือต้นทางของคุณ หรือเป็นการโหลดหน้าเว็บสําหรับ URL หน้าเว็บหนึ่งๆ เท่านั้น
เมื่อรวบรวมคะแนนของหน้าเว็บทั้งหมดในต้นทาง หน้าเว็บที่รวดเร็วแต่ละหน้าจะช่วยปรับปรุงเปอร์เซ็นไทล์ 75 ของต้นทางโดยรวมได้ อย่างไรก็ตาม เมื่อรวบรวมข้อมูลตามหน้าเว็บแต่ละหน้า คะแนนของหน้าหนึ่งจะไม่ส่งผลต่อคะแนนของหน้าถัดไป กล่าวคือ เมื่อรวบรวมคะแนนของ MPA ตามหน้าเว็บ การโหลดแคชที่รวดเร็วซึ่งพบในหน้าชำระเงินจะไม่ปรับปรุงคะแนนของการโหลดครั้งแรกที่ช้าซึ่งพบในหน้า Landing Page ของเว็บไซต์
คุณสามารถตรวจสอบคะแนนของเว็บไซต์สำหรับวิธีการรวบรวมข้อมูลต่างๆ ได้โดยใช้ PageSpeed Insights หรือ Chrome User Experience Report 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 อาจมีประสิทธิภาพดีกว่าในเมตริก Core Web Vitals ที่เปอร์เซ็นต์ไทล์ 75 เมื่อเทียบกับเว็บไซต์เวอร์ชัน SPA เดียวกัน แต่เวอร์ชัน SPA ก็ควรพยายามให้เป็นไปตามเกณฑ์ "ดี" หากเวอร์ชัน SPA ไม่เป็นไปตามเกณฑ์ "ดี" สําหรับผู้ใช้ส่วนใหญ่ ประสบการณ์การโหลดครั้งแรกอาจยังถือว่าไม่ดี แม้ว่าประสบการณ์การนําทางในหน้าเว็บในภายหลังจะยอดเยี่ยมก็ตาม
ในอนาคตเราวางแผนที่จะพัฒนาเมตริกที่ส่งเสริมประสบการณ์การใช้งานที่ยอดเยี่ยมหลังการโหลด และเราเชื่อว่านี่เป็นเส้นทางที่ดีที่สุดในการจูงใจให้ SPA มีคุณภาพสูงในลักษณะที่ไม่กระทบประสบการณ์การโหลดครั้งแรก เราได้เปิดตัวเมตริกใหม่ชื่อ Interaction to Next Paint (INP) แล้ว ซึ่งจะวัดเวลาในการตอบสนองของการโต้ตอบตลอดอายุหน้าเว็บ และเรากําลังทํางานอย่างหนักกับเมตริกอื่นๆ หลังการโหลดด้วย รวมถึงเมตริกที่วัดการเปลี่ยนเส้นทาง SPA (ดูด้านล่าง)
เราเปลี่ยนเว็บไซต์จาก MPA เป็น SPA แล้วคะแนนก็ลดลง นี่เป็นปกติไหม
แล้วแต่กรณี คะแนนอาจเปลี่ยนแปลงได้หลายสาเหตุหลังจากการย้ายข้อมูลสถาปัตยกรรมครั้งใหญ่ แต่จำนวนการโหลดแคชที่อุ่นขึ้นที่ลดลงอาจเป็นสาเหตุของการเปลี่ยนแปลงบางส่วน
วิธีตรวจสอบอย่างรวดเร็วคือทดสอบหน้า Landing Page เวอร์ชัน MPA และ SPA ด้วย 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 รายการ ดังนี้
- ประเมินการเข้าชมหน้าเว็บจากต้นทางเดียวกันและข้ามต้นทางแยกกัน
- ออกแบบ API ใหม่ที่ช่วยให้วัด SPA ได้ดีขึ้น
ประเมินการเข้าชมหน้าเว็บจากต้นทางอื่นและจากต้นทางเดียวกันแยกกัน
ปัจจุบันเมตริก Core Web Vitals จะรวบรวมการเข้าชมหน้าเว็บทั้งหมดไว้ในที่เก็บข้อมูลเดียว โดยจะไม่แยกความแตกต่างระหว่างการเข้าชมใหม่กับการเข้าชมซ้ำ หรือหน้า Landing Page กับหน้าชำระเงิน หรือประเภทการรวมข้อมูลอื่นๆ ที่สถานะแคชอาจส่งผลต่อประสิทธิภาพ
วิธีหนึ่งในการทำให้ความแตกต่างระหว่างประสิทธิภาพของ SPA กับ MPA เป็นมาตรฐานคือใช้น้ำหนักที่แตกต่างกันกับการเข้าชมแต่ละประเภท ซึ่งอาจใช้คําแนะนําเกี่ยวกับเกณฑ์ที่แตกต่างกันโดยสิ้นเชิง
แม้ว่าเราจะต้องการตอบแทนการใช้งานแคชที่มีประสิทธิภาพอย่างแน่นอน แต่เราก็ไม่ต้องการให้การไปยังส่วนต่างๆ ภายในเว็บไซต์ที่รวดเร็วบดบังการโหลดหน้าที่เชื่อมโยงไปถึงที่ช้า นอกจากนี้ เรายังไม่ต้องการกระตุ้นให้เว็บไซต์แบ่งหน้าเว็บยาวๆ ออกเป็นกลุ่มหน้าเว็บที่สั้นลงเพื่อปรับปรุงคะแนนเมตริก
การประเมินการเข้าชมหน้าเว็บจากแหล่งที่มาหลายแห่งและแหล่งที่มาเดียวกันแยกกันจะช่วยให้เรามั่นใจได้ว่าประสบการณ์การใช้งานทั้ง 2 ประเภทมีความสำคัญโดยไม่ปล่อยให้ความนิยมแบบสัมพัทธ์ของประเภทใดประเภทหนึ่งในเว็บไซต์หนึ่งบิดเบือนการแจกแจงเมตริกใดเมตริกหนึ่ง
ออกแบบ API ใหม่ที่ทําให้การวัด SPA ดีขึ้น
โซลูชันอีกอย่างหนึ่งที่เรากําลังพัฒนาอยู่ (ควบคู่ไปกับโซลูชันข้างต้น) คือ App History API ใหม่ ซึ่งจะช่วยทำให้รูปแบบ SPA ในปัจจุบันเป็นมาตรฐานเดียวกัน และช่วยให้วัดผลและทำความเข้าใจการใช้งาน SPA ได้ในวงกว้างได้ง่ายขึ้น
App History API เปิดตัวเหตุการณ์ navigate ใหม่ ซึ่งมีฟีเจอร์หลัก 2 รายการสําหรับการวัด SPA โดยเฉพาะ ดังนี้
- FLAG
userInitiatedซึ่งจะตั้งค่าเป็น "จริง" ก็ต่อเมื่อการนําทางเริ่มต้นผ่านการคลิกลิงก์ การส่งแบบฟอร์ม หรือ UI ของเบราว์เซอร์สำหรับย้อนกลับหรือไปข้างหน้าเท่านั้น - วิธีการ
transitionWhile()ซึ่งใช้สัญญาที่ให้นักพัฒนาแอปส่งสัญญาณเมื่องานเริ่มต้นเพื่อนำทางเสร็จสมบูรณ์
ใช้ Flag userInitiated เพื่อระบุจุดเริ่มต้นเชิงความหมายสำหรับการเปลี่ยนเส้นทาง SPA ซึ่งบ่งบอกถึงเจตนาของผู้ใช้อย่างชัดเจน transitionWhile()การแก้ไขสัญญาจะช่วยให้เบราว์เซอร์เชื่อมโยง Paint กับการเปลี่ยนเส้นทางที่เฉพาะเจาะจงได้ เช่น เพื่อให้สามารถระบุ Largest Contentful Paint ที่เกี่ยวข้องกับการเปลี่ยนเส้นทางนั้น
จากแนวคิดที่นำเสนอในส่วนก่อนหน้านี้ เราอาจรวมเวลาการเปลี่ยนเส้นทาง SPA ไว้ในกลุ่มเดียวกันกับการโหลดหน้าเว็บต้นทางเดียวกันใน MPA ได้ นี่เป็นข่าวที่น่าตื่นเต้นเนื่องจากจะช่วยให้เว็บไซต์ที่ย้ายข้อมูลจาก MPA ไปยัง SPA สามารถเปรียบเทียบประสิทธิภาพก่อนและหลังได้
แน่นอนว่าเราต้องทำการวิจัยเพิ่มเติมก่อนจึงจะทราบว่าเราจะทำการตัดสินเหล่านี้ได้อย่างแม่นยำหรือไม่ หากมีคำแนะนำหรือความคิดเห็นเกี่ยวกับข้อเสนอเหล่านี้ โปรดส่งอีเมลมาที่ web-vitals-feedback@googlegroups.com
สรุปความคิด
Google มุ่งมั่นอย่างยิ่งที่จะปรับปรุงเมตริก Web Vitals และตรวจสอบว่าเมตริกเหล่านี้วัดผลและกระตุ้นให้เกิดประสบการณ์การใช้งานที่มีคุณภาพสูงซึ่งสำคัญต่อผู้ใช้ อย่างไรก็ตาม เราทราบดีว่าปัจจุบันยังมีช่องว่างในการวัดผล ปัจจุบันเมตริกเหล่านี้ยังไม่ครอบคลุมทุกแง่มุมของประสบการณ์ของผู้ใช้ แต่เรากําลังพยายามอย่างเต็มที่เพื่อปิดช่องโหว่เหล่านี้
แม้จะมีข้อจํากัดในปัจจุบัน แต่เราเชื่อว่าเมตริกที่มีอยู่จะบันทึกข้อมูลในขอบเขตที่สําคัญต่อประสิทธิภาพและความสําเร็จของเว็บ และเราเชื่อว่ายังมีช่องว่างในการปรับปรุงเมื่อเว็บไซต์ (ไม่ว่าสถาปัตยกรรมจะเป็นอย่างไร) ไม่เป็นไปตามเกณฑ์ที่แนะนํา
เราหวังว่าโพสต์นี้จะช่วยอธิบายหัวข้อที่ซับซ้อนและละเอียดอ่อนนี้ และเช่นเคย หากมีความคิดเห็นเกี่ยวกับเมตริก Web Vitals ปัจจุบันหรืออนาคต โปรดส่งอีเมลไปที่ web-vitals-feedback@googlegroups.com