ประวัติของ Core Web Vitals

 (addyosmani.com)
14 คะแนน โดย GN⁺ 2025-10-10 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • Core Web Vitals ซึ่งใช้วัดประสิทธิภาพของเว็บไซต์ เริ่มต้นจากความพยายามตั้งแต่ปี 2014 ที่หลายทีมของ Google ร่วมมือกันเพื่อก้าวข้ามข้อจำกัดของโปรเจกต์ AMP และกำหนด ตัวชี้วัดประสิทธิภาพแบบมาตรฐานเปิด ที่ใช้ได้กับทุกเว็บไซต์
  • ในเดือนพฤษภาคม 2020 มีการประกาศอย่างเป็นทางการถึง ตัวชี้วัดหลัก 3 รายการ ได้แก่ LCP สำหรับความเร็วในการโหลด, FID สำหรับความตอบสนองต่อการโต้ตอบ, และ CLS สำหรับความเสถียรด้านภาพ โดยออกแบบให้เป็น ตัวชี้วัดที่วัดได้จากภาคสนาม ซึ่งสะท้อนประสบการณ์ของผู้ใช้จริง
  • ในปี 2021 มีการนำมาใช้เป็นปัจจัยจัดอันดับการค้นหาผ่าน Page Experience update ของ Google Search และยกเลิกข้อกำหนดผูกขาด AMP ใน Top Stories จึงช่วยสร้าง สภาพแวดล้อมการแข่งขันของเว็บแบบเปิด
  • ผ่านการปรับแต่งเบราว์เซอร์ Chrome, การปรับปรุง CMS หลักอย่าง WordPress และความร่วมมือกับ JavaScript framework ต่าง ๆ ทำให้ภายในปี 2023 สามารถ ประหยัดเวลารอสะสมของผู้ใช้ได้มากกว่า 10,000 ปี และในปี 2024 ทำได้ถึง 30,000 ปี
  • ในปี 2024 มีการพัฒนาอย่างต่อเนื่อง เช่น การ แทนที่ FID ด้วย INP และการนำ Soft Navigation API สำหรับ SPA มาใช้ ซึ่งช่วยเสริมการสร้างระบบนิเวศเว็บที่ รวดเร็ว เสถียร และยึดผู้ใช้เป็นศูนย์กลาง

ภูมิหลังและแรงจูงใจ: จาก AMP สู่ตัวชี้วัดของเว็บแบบเปิด

  • Google เน้นย้ำมาหลายปีแล้วว่าความเร็วและประสบการณ์ผู้ใช้คือหลักการสำคัญของเว็บ แต่ก็ยังมีอีกหลายเว็บไซต์ที่มอบ ประสบการณ์ที่ช้า
  • ในปี 2010 Google Search เริ่มใช้ ความเร็วเว็บไซต์เป็นสัญญาณในการจัดอันดับการค้นหา ซึ่งถือเป็นความพยายามระยะแรกในการนำประสิทธิภาพเข้าไปเป็นส่วนหนึ่งของ SEO
  • ราวปี 2015 มีการเปิดตัวโปรเจกต์ AMP (Accelerated Mobile Pages) เพื่อให้หน้าเว็บที่ถูกปรับแต่งสำหรับการโหลดอย่างรวดเร็ว แต่ก็เกิด ปัญหาเรื่องความเปิดกว้างและความยืดหยุ่น เนื่องจากเป็นสภาพแวดล้อมแบบปิดที่ให้บริการผ่าน Google cache
  • ในปี 2018 ผ่าน Speed Update มีการนำความเร็วหน้าเว็บมาใช้กับอันดับการค้นหาบนมือถือ และ Google Ads ก็เพิ่มคะแนนความเร็วของหน้า landing page บนมือถือ เพื่อย้ำว่า ประสบการณ์ที่รวดเร็วนำไปสู่อัตรา conversion ที่ดีกว่า
  • เพื่อก้าวออกจากแนวทางที่ผูกกับ AMP โดยเฉพาะ ทีม Chrome และ Search จึงร่วมมือกันเริ่มกำหนด ตัวชี้วัดประสิทธิภาพของเว็บแบบเปิดที่ใช้ได้กับทุกหน้าโดยไม่ต้องมี framework พิเศษ
    • วิเคราะห์หลายล้านหน้าเพื่อกำหนด มาตรฐานสาธารณะของหน้าเว็บที่รวดเร็วและเป็นมิตรต่อผู้ใช้
    • ตั้งเป้าให้เป็น ตัวชี้วัดที่วัดได้จากภาคสนาม และสะท้อนประสบการณ์ของผู้ใช้จริง
    • ต้องการค้นหาตัวชี้วัดที่มีความสัมพันธ์กับผลลัพธ์อย่างการมีส่วนร่วมของผู้ใช้

การนิยาม Core Web Vitals: สามเสาหลักของประสบการณ์ผู้ใช้

  • ในเดือนพฤษภาคม 2020 Google ประกาศอย่างเป็นทางการถึง Web Vitals initiative และเปิดตัว Core Web Vitals ที่มุ่งเน้น “แง่มุมหลักของประสบการณ์ผู้ใช้ที่ใช้ได้กับทุกเว็บเพจ”

  • Core Web Vitals ชุดแรกประกอบด้วย ตัวชี้วัดหลัก 3 รายการ

    • Largest Contentful Paint(LCP): ตัวชี้วัดความเร็วในการโหลด ที่วัดช่วงเวลาที่เนื้อหาหลักถูกเรนเดอร์ โดยไม่ได้มองแค่ First Contentful Paint หรือ onload แต่โฟกัสที่จุดที่ผู้ใช้เห็นเนื้อหาที่มีความหมายจริง
    • First Input Delay(FID): ตัวชี้วัดความตอบสนองต่อการโต้ตอบ ที่วัดความหน่วงระหว่างการโต้ตอบครั้งแรกของผู้ใช้กับการตอบสนองของเบราว์เซอร์ เพื่อจับว่าหน้าเว็บตอบสนองทันทีหรือหน่วงเพราะสคริปต์ที่หนักเกินไป
    • Cumulative Layout Shift(CLS): ตัวชี้วัดความเสถียรด้านภาพ ที่วัดว่าระหว่างการโหลด เลย์เอาต์ของหน้าเคลื่อนที่มากแค่ไหน โดยรวมค่าการขยับเลย์เอาต์ที่ไม่คาดคิดเข้าไว้ด้วยกัน และค่า CLS ที่ต่ำหมายถึงประสบการณ์ที่เสถียรและใช้งานสบาย

  • การคัดเลือกตัวชี้วัดดำเนินไปบนพื้นฐานของงานวิจัยและการทดลองอย่างกว้างขวาง

    • Amar Sagoo, Annie Sullivan, Vivek Sekhar และคนอื่น ๆ ค้นพบความสัมพันธ์ระหว่างค่าประสิทธิภาพเชิงวัตถุกับการรับรู้ของผู้ใช้ ผ่าน งานวิจัยด้านปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์
    • เวลาการโหลดควรอยู่ที่ ภายใน 2~3 วินาที, การตอบสนองต่ออินพุตควรอยู่ที่ ภายใน 100ms, และการขยับของเลย์เอาต์ควร ลดให้น้อยที่สุด
    • จากการวิเคราะห์ข้อมูลผู้ใช้จริง มีการกำหนด เป้าหมายค่า threshold ที่ใช้งานได้จริง ได้แก่ LCP ต่ำกว่า 2.5 วินาที, FID ต่ำกว่า 100ms, CLS ต่ำกว่า 0.1 (อิงเปอร์เซ็นไทล์ที่ 75)
    • หน้าเว็บที่ผ่านค่า threshold เหล่านี้มี โอกาสที่ผู้ใช้จะออกจากหน้าเว็บต่ำลง 24%

  • Google พยายามทำให้ตัวชี้วัดเหล่านี้มีความ เป็นมาตรฐานและเปิดกว้าง

    • เผยแพร่ ร่างข้อกำหนดเว็บสเปก ผ่าน WICG และกลุ่มมาตรฐาน web performance
    • ทำให้วัดค่าได้ผ่าน PerformanceObserver API ใน Chrome และเบราว์เซอร์อื่น ๆ
    • ในเดือนพฤษภาคม 2020 เปิดตัว ไลบรารี JavaScript แบบโอเพนซอร์ส web-vitals ที่นักพัฒนาสามารถฝังลงในเว็บไซต์เพื่อวัด LCP, FID และ CLS ของผู้ใช้จริงได้
    • Addy Osmani พัฒนา ส่วนขยาย Core Web Vitals ที่แสดงตัวชี้วัดแบบเรียลไทม์
    • สะท้อนถึงความพยายามอย่างกว้างขวางในการทำให้ทั้งระบบนิเวศเข้าถึงได้และใช้งานได้จริง

Page Experience: Core Web Vitals ในการจัดอันดับของ Google Search

  • ทีม Google Search นำ Core Web Vitals ไปใช้โดยรวดเร็วในฐานะส่วนหนึ่งของ Page Experience update

  • เมื่อวันที่ 28 พฤษภาคม 2020 Google Search Central ประกาศว่าจะนำตัวชี้วัดเหล่านี้เข้าไปในอัลกอริทึมการจัดอันดับ

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

  • ประกาศที่ได้รับความสนใจมากที่สุดคือ การยกเลิกข้อกำหนด AMP ในแครูเซล Top Stories

    • ก่อนหน้านั้น Google News/Top Stories บนมือถือกำหนดให้ใช้ AMP แต่หลังจาก Page Experience update แล้ว หน้าเว็บที่ไม่ใช่ AMP ก็สามารถเข้าร่วมได้ หากผ่าน Core Web Vitals และเกณฑ์อื่น ๆ
    • “AMP ไม่จำเป็นสำหรับ Top Stories บนมือถืออีกต่อไป และเปิดให้ทุกหน้าที่มี page experience ที่ดี”
    • แสดงให้เห็นถึงความเชื่อมั่นของ Google ที่ต้องการสนับสนุนให้ เว็บแบบเปิดพัฒนาได้โดยไม่ต้องไหลเข้าสู่ framework AMP

  • Google ให้การแจ้งเตือนล่วงหน้าแก่ระบบนิเวศอย่างเพียงพอ

    • โดยตระหนักว่าปี 2020 เป็นปีที่ยากลำบากจากการระบาดของ COVID-19 จึงประกาศว่าการเปลี่ยนแปลงด้านอันดับ จะยังไม่ถูกใช้จนกว่าจะถึงปี 2021 พร้อมให้คำเตือนล่วงหน้าอย่างน้อย 6 เดือน
    • ในอัปเดตเดือนพฤศจิกายน 2020 ระบุว่าการเปลี่ยนแปลงอันดับจาก Page Experience จะเริ่มตั้งแต่พฤษภาคม 2021
    • สุดท้าย Page Experience update เริ่ม rollout ในช่วงกลางเดือนมิถุนายน 2021 และใช้งานเต็มรูปแบบภายในปลายเดือนสิงหาคม (สำหรับการค้นหาบนมือถือ)
    • อัปเดตลักษณะเดียวกันสำหรับการค้นหาบนเดสก์ท็อปเกิดขึ้นในช่วงกุมภาพันธ์ถึงมีนาคม 2022

  • เมื่อมีการใช้การอัปเดตแล้ว อัลกอริทึมจัดอันดับของ Google ก็เริ่มใช้ Core Web Vitals เป็นหนึ่งในหลายร้อยสัญญาณ

    • หน้าที่ผ่าน threshold ระดับ “ดี” ในตัวชี้วัด CWV ทั้งสามรายการจะถือว่ามี ประสบการณ์หน้าเว็บที่ดี
    • Google สร้าง รายงาน Page Experience ใน Google Search Console เพื่อให้เจ้าของเว็บไซต์ดูสัดส่วนหน้าที่ผ่านค่า threshold ได้โดยอิงข้อมูลจาก Chrome UX Report
    • ช่วยให้เว็บมาสเตอร์และผู้เชี่ยวชาญ SEO ได้รับฟีดแบ็กโดยตรงว่าเว็บไซต์ของตนทำได้ดีเพียงใดในมุมมองของสัญญาณ page experience

  • Google เคยพิจารณา การแสดง badge ให้กับหน้าที่มี page experience ดีในผลการค้นหา แต่ไม่ได้เพิ่มไอคอน badge แบบถาวร

    • รางวัลหลักมาในรูปของ การขยับอันดับขึ้น มากกว่าจะเป็นป้ายกำกับที่มองเห็นได้ชัด
    • อยู่ช่วงหนึ่ง Google แสดงตัวบ่งชี้ “Page Experience” แบบชั่วคราวใน Search Console และการทดลองบนผลการค้นหา
    • ใจความสำคัญคือ Google กำลังสร้างแรงจูงใจต่อประสิทธิภาพและ UX อย่างเปิดเผย และการทำ Core Web Vitals ให้ดีไม่เพียงช่วยให้ผู้ใช้พึงพอใจ แต่ยังอาจ เพิ่มการมองเห็นของหน้าในผลการค้นหา ได้ด้วย

เครื่องมือและข้อมูล: Chrome UX Report และการวัดประสิทธิภาพ

  • Google ลงทุนครั้งใหญ่ในเครื่องมือและข้อมูลสำหรับ Web Vitals

  • Chrome UX Report (CrUX) คือหัวใจสำคัญของความพยายามนี้

    • เป็นชุดข้อมูลสาธารณะของตัวชี้วัดประสบการณ์ผู้ใช้จริงที่มีมาตั้งแต่ปี 2017 โดยรวบรวมข้อมูลประสิทธิภาพแบบไม่ระบุตัวตนของเว็บไซต์หลายล้านแห่งจากผู้ใช้ Chrome หลายล้านคน
    • เมื่อเปิดตัว Core Web Vitals ทาง CrUX ก็เริ่มรายงาน LCP, FID, CLS สำหรับ URL ต้นทางทั้งหมดในชุดข้อมูลทันที
    • ทุกคนสามารถคิวรีข้อมูลประสิทธิภาพภาคสนามได้
    • หลังเปิดให้เข้าถึงผ่าน BigQuery ก็เปิดตัวCrUX API และ CrUX Dashboard ทำให้นักพัฒนาและผู้เชี่ยวชาญ SEO ตรวจสอบได้ง่ายว่าเว็บไซต์ของตนเอง (หรือของคู่แข่ง) ทำผลงานด้านตัวชี้วัด CWV ในการใช้งานจริงได้อย่างไร
    • มีการนำCrUX History API มาใช้เพื่อให้ข้อมูลอนุกรมเวลาของตัวชี้วัดเหล่านี้ ช่วยติดตามความคืบหน้าตลอดหลายเดือนได้

  • ฝั่งเครื่องมือสำหรับนักพัฒนาก็มีการผสานรวมอย่างรวดเร็ว

    • ภายในปลายปี 2020 เครื่องมือด้านประสิทธิภาพส่วนใหญ่ของ Google ได้รับการอัปเดตให้เน้น Core Web Vitals
    • Lighthouse (เครื่องมือตรวจสอบโอเพนซอร์สที่ใช้ใน Chrome DevTools และ PageSpeed Insights) ได้ผสานการวิเคราะห์และคะแนนที่เกี่ยวข้องกับ CWV
      • เพิ่มการตรวจสอบอย่างเช่น "Largest Contentful Paint ใช้เวลา X วินาที (เป้าหมาย <2.5 วินาที)" พร้อมข้อเสนอแนะเพื่อการปรับปรุง
    • เพิ่มแผง Core Web Vitals และตัวทำเครื่องหมายบนไทม์ไลน์ในChrome DevTools เพื่อให้ตรวจสอบองค์ประกอบ LCP หรือการเลื่อนเลย์เอาต์ระหว่างการโหลดหน้าได้
    • PageSpeed Insights (PSI) ถูกยกเครื่องใหม่ทั้งหมดให้โฟกัสที่ CWV
      • แสดงข้อมูลภาคสนามของ LCP, FID (ต่อมาคือ INP), CLS จาก CrUX อย่างเด่นชัดด้านบน
    • Google Search Console มีรายงาน Core Web Vitals โดยเฉพาะ ซึ่งจัดกลุ่มหน้าเป็น "ดี", "ต้องปรับปรุง", "แย่" สำหรับแต่ละตัวชี้วัด ทำให้เจ้าของเว็บไซต์ระบุจุดปัญหาได้อย่างแม่นยำ
    • งานด้านเครื่องมือนี้ขับเคลื่อนโดย Elizabeth Sweeny, Paul Irish, Addy Osmani และคนอื่น ๆ

  • ชุมชนนักพัฒนาเว็บก็ตอบรับผ่านเครื่องมือของบุคคลที่สาม

    • ผู้ให้บริการ Real User Monitoring (RUM) ผสาน Core Web Vitals อย่างรวดเร็ว
    • Akamai mPulse, Browser agent ของ New Relic, Dynatrace, Datadog, SpeedCurve และรายอื่น ๆ รองรับ LCP, FID, CLS เป็นตัวชี้วัดระดับหลักทันที
    • Cloudflare ก็เปิดตัวบริการ Browser Insights ที่สามารถแทรกสคริปต์เพื่อเก็บ Web Vitals ได้
    • การมีอยู่ของไลบรารี web-vitals JS ทำให้เครื่องมือวิเคราะห์ทุกตัวเก็บตัวชี้วัดเหล่านี้ได้ง่าย
    • ภายในปี 2021 Core Web Vitals กลายเป็นเรื่องปกติบนแดชบอร์ดของเครื่องมือติดตามประสิทธิภาพเว็บ
    • การเข้าถึงได้อย่างกว้างขวางนี้ช่วยขยายการรับรู้และมอบข้อมูลให้นักพัฒนาผลักดันการปรับปรุงประสิทธิภาพได้

  • ข้อมูลจากChrome User Experience Report ยังสำคัญต่อการติดตามความคืบหน้าของทั้งเว็บ

    • ตลอดปี 2021 และ 2022 สัดส่วนทราฟฟิกที่มี CWV อยู่ในระดับ "ดี" เพิ่มขึ้นอย่างต่อเนื่อง
    • มักมีการรายงานใน Web Almanac ประจำปีของ HTTP Archive หรืออัปเดตบนบล็อกของ Google เอง
    • การมีตัวชี้วัดที่วัดได้และเปิดเผยต่อสาธารณะได้สร้างการแข่งขันเชิงบวกในระดับหนึ่ง
    • เจ้าของเว็บไซต์และผู้ให้บริการแพลตฟอร์มเริ่มอวดผลลัพธ์และพยายามปรับปรุง Core Web Vitals

ผลกระทบและการปรับปรุง: ทำให้เว็บเร็วขึ้นและเสถียรมากขึ้น

การเพิ่มประสิทธิภาพเบราว์เซอร์ Chrome

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

  • ทีมวิศวกรรม Google Chrome ตรวจสอบเบราว์เซอร์อย่างละเอียดเพื่อปรับวิธีที่ Chrome โหลดและเรนเดอร์หน้าเว็บให้เหมาะสมที่สุด

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

  • การจัดลำดับความสำคัญของเนื้อหาสำหรับ LCP

    • มีการเปลี่ยนแปลงให้ Chrome จัดลำดับความสำคัญการโหลดเนื้อหาสำคัญ
    • ระบุภาพแรก ๆ ใน HTML (ซึ่งมักรวมถึงภาพ LCP) และให้ลำดับความสำคัญของเครือข่ายที่สูงกว่า
    • การจัดลำดับความสำคัญให้ภาพ 5 ภาพแรกแบบนี้ช่วยให้บางหน้าปรับปรุง LCP จาก 3.1 วินาทีเป็น 2.5 วินาที
    • มีการนำมาตรฐานเว็บใหม่อย่างแอตทริบิวต์ fetchpriority (กลไก Priority Hints) มาใช้ เพื่อให้นักพัฒนาระบุภาพหรือ iframe ให้มีลำดับความสำคัญสูงสำหรับ LCP ได้

  • Back/Forward Cache (BFCache)

    • ในอดีต Chrome ไม่ได้ทำ BFCache หน้าอย่างเต็มรูปแบบเนื่องจากความซับซ้อนทางเทคนิค แต่ในช่วงไม่กี่ปีที่ผ่านมาได้เปิดใช้ BFCache กับหลายหน้า
    • ภายในปี 2023 สามารถเพิ่มอัตราการใช้งาน BFCache ที่น่าสนใจได้ทั้งบนเดสก์ท็อปและ Android
    • ผู้ใช้ที่กดย้อนกลับมายังหน้าก่อนหน้าจะเห็นหน้าได้ทันที (LCP เป็นศูนย์, input delay เป็นศูนย์ เพราะหน้าไม่ได้ถูก unload)
    • แพลตฟอร์มขนาดใหญ่อย่าง Amazon ได้ประโยชน์จาก BFCache ของ Chrome และรายงานว่า หลังการปรับปรุงของ Chrome (เวอร์ชัน M112) การใช้ back/forward cache เพิ่มขึ้น 22.7%p

  • Prerendering (NoState Prefetch/Prerender2)

    • Chrome เปิดตัว prerenderer ใหม่ (Prerender2) ที่ให้เบราว์เซอร์โหลดและเรนเดอร์หน้าอย่างสมบูรณ์ในเบื้องหลัง แล้วสลับมาแสดงทันทีเมื่อผู้ใช้นำทางไปยังหน้านั้น
    • ในช่วงแรกถูกใช้กับ Google Search (prerender ผลลัพธ์อันดับต้น ๆ) และการคาดเดา URL ที่ผู้ใช้พิมพ์ ซึ่งช่วยลด LCP ได้อย่างมาก
    • Chrome รายงานว่าการ prerender การค้นหาใน omnibox ช่วยให้ค่า LCP มัธยฐานดีขึ้น 500~700ms (ประมาณ 15~25%) สำหรับการนำทางนั้น
    • Chrome กำลังทยอยเปิดใช้สิ่งนี้อย่างระมัดระวัง (เพื่อหลีกเลี่ยงการคาดเดาผิดหรือปัญหาด้านความเป็นส่วนตัว)

  • การเพิ่มประสิทธิภาพเครือข่ายและการจัดตารางงาน

    • ทีม Chrome ระบุและแก้ไขความล่าช้าเล็ก ๆ หลายรูปแบบที่กระทบต่อการตอบสนองต่ออินพุต
    • มีการเพิ่มฟีเจอร์preconnect ตอน pointer down (เมื่อเริ่มแตะ/คลิก ก่อนปล่อย) เพื่อลดเวลาหลายมิลลิวินาทีในการตั้งค่าการเชื่อมต่อสำหรับการนำทางผ่านลิงก์
    • ช่วยให้ LCP เร็วขึ้นโดยเฉลี่ยราว 6~10ms ในการนำทางข้ามต้นทาง
    • ปรับปรุงวิธีที่เธรดหลักของเบราว์เซอร์จัดการงานเมื่อเปิดหลายแท็บ เพื่อลดการแย่งทรัพยากร
    • ด้วยการปรับการจัดตารางงานและการใช้กลไกอย่าง EcoQOS ของ Windows 11 กับแท็บเบื้องหลัง Chrome จึงสามารถ**ปรับปรุง INP ราว 5% และ LCP ราว 2%**ในสถานการณ์ที่มีโหลดหนัก

  • การปรับปรุงเอนจินการเรนเดอร์และ JavaScript

    • การยกเครื่องสถาปัตยกรรม RenderingNG ของ Chrome (เสร็จราวปี 2021) ทำให้การเรนเดอร์มีประสิทธิภาพมากขึ้น
    • การอัปเกรดลำดับความสำคัญการโหลดภาพ (เพื่อไม่ให้ภาพ LCP ถูกบล็อกโดยงานอื่นที่สำคัญน้อยกว่า) และการกำหนดเวลาทำ garbage collection ของ V8 อย่างชาญฉลาดขึ้น (ให้ทำในช่วง idle) ช่วยรับประกันประสบการณ์ที่ลื่นไหลกว่า
    • นักพัฒนา Chrome พบว่าวิธีที่เบราว์เซอร์แบบหลายโปรเซสเข้าถึงคุกกี้ทำให้เกิด jank
      • การเรียก document.cookie ทุกครั้งต้องดึงข้อมูลแบบ synchronous จากอีกโปรเซสหนึ่ง
      • ด้วยการนำการจัดการเวอร์ชันคุกกี้ผ่าน shared memory มาใช้ Chrome จึงเพิ่มประสิทธิภาพการเข้าถึงคุกกี้และลดการกระโดดข้ามโปรเซสที่ซ้ำซ้อนจำนวนมาก
      • ลด input delay ในกรณีที่เว็บไซต์ยิงการอ่านคุกกี้ถี่ ๆ ทุกครั้งที่มีการโต้ตอบ

  • การเพิ่มประสิทธิภาพทั้งหมดของ Chrome เหล่านี้สร้าง ความแตกต่างที่วัดผลได้

    • ภายในสิ้นปี 2023 Google รายงานว่า เวลาโหลดหน้าเฉลี่ยของ Chrome เร็วขึ้น 166ms เมื่อเทียบกับก่อนที่ Core Web Vitals จะมีขึ้น
    • ผลกระทบมหาศาลต่อทั้งเว็บ: เมื่อนำเวลาที่ประหยัดได้มารวมกัน ทีม Chrome คำนวณว่าในปี 2023 เพียงปีเดียว การปรับปรุงความเร็วช่วยประหยัดเวลาสะสมที่ผู้ใช้ต้องรอให้หน้าโหลดได้มากกว่า 10,000 ปี และประหยัดเวลาเพิ่มอีกกว่า 1,200 ปีในการรอให้หน้าเว็บตอบสนองต่ออินพุต
    • สัดส่วนทราฟฟิกที่ผ่านเกณฑ์ CWV ระดับ "ดี" ก็เพิ่มขึ้นอย่างมากเช่นกัน
    • ตอนประกาศครั้งแรก มีเพียงประมาณ 1/3 ของการโหลดหน้าที่ถือว่าดีตามเกณฑ์ CWV แต่ภายในปี 2023 การเข้าชมหน้าเว็บบนเดสก์ท็อปของ Chrome ราว 68% และบนมือถือราว 64% ผ่านค่าเกณฑ์ CWV ทั้งสามตัว

การปรับปรุงในระบบนิเวศเว็บในวงกว้าง

  • การปรับปรุงไม่ได้เกิดขึ้นแค่ฝั่ง Google เท่านั้น แต่ชุมชนนักพัฒนาเว็บในวงกว้าง รวมถึงเฟรมเวิร์กและผู้ให้บริการแพลตฟอร์ม ก็เข้ามาช่วยแก้ปัญหาด้านประสิทธิภาพที่ Core Web Vitals ระบุไว้

  • การปรับแต่งรูปภาพและการโหลดแบบหน่วงเวลา

    • เมื่อรับรู้ว่ารูปภาพมักเป็นคอนเทนต์ที่ใหญ่ที่สุดและเป็นสาเหตุทั่วไปของ LCP เฟรมเวิร์กเว็บและ CMS ต่างก็เริ่มใช้ค่าเริ่มต้นที่ฉลาดขึ้น
    • HTML แบบเนทีฟ loading="lazy" สำหรับรูปภาพนอกหน้าจอได้ถูกทำให้เป็นมาตรฐาน (ด้วยความช่วยเหลือจาก Chrome และผู้มีส่วนร่วมด้านมาตรฐานเว็บอย่าง Yoav Weiss และ Addy Osmani) และถูกนำไปใช้ใน WordPress กับแพลตฟอร์มอื่น ๆ ช่วยลดการโหลดรูปภาพที่ไม่จำเป็นลงอย่างมาก
    • หลังจาก WordPress เปิดใช้การโหลดแบบหน่วงเวลาสำหรับรูปภาพเป็นค่าเริ่มต้นในปี 2020 ก็ได้ปรับปรุงเพิ่มเติมโดยไม่ใช้การโหลดแบบหน่วงเวลากับภาพแบนเนอร์หลักภาพแรก เพื่อไม่ให้ LCP ช้าลง
    • แอตทริบิวต์ใหม่ &lt;img fetchpriority="high"&gt; ถูกเฟรมเวิร์กต่าง ๆ นำไปใช้ได้อย่างรวดเร็วเพื่อแสดงรูปภาพหลักให้โหลดได้เร็วขึ้น

  • WordPress Performance Team

    • WordPress ครองสัดส่วนราว 40% ของเว็บไซต์ทั้งหมด จึงมีอิทธิพลด้านประสิทธิภาพอย่างมหาศาล
    • ในช่วงแรก เว็บไซต์ WordPress มีคะแนน CWV ตามหลัง และรายงานในปี 2021 แสดงให้เห็นว่าเว็บไซต์ WordPress มีอัตราการผ่านต่ำกว่าบางระบบนิเวศอื่น ๆ ซึ่ง เป็นสัญญาณเตือนสำคัญ
    • ชุมชนจึงตอบสนองด้วยการตั้ง Core Performance Team โดยเฉพาะ (มีผู้ร่วมพัฒนาจาก Google และบริษัทอื่น ๆ รวมอยู่ด้วย) เพื่อปรับปรุงความเร็วของ WordPress core อย่างเป็นระบบ
    • งานในรุ่นล่าสุดเริ่มเห็นผลชัดเจน
      • WordPress 6.3 (2023) มีการปรับแต่งจำนวนมากเกี่ยวกับการเรนเดอร์ธีมและการโหลดแอสเซ็ต ส่งผลให้ธีมหลักโหลด เร็วขึ้น 27% สำหรับบล็อกธีม และเร็วขึ้น 18% สำหรับคลาสสิกธีม เมื่อเทียบกับ WordPress 6.2 ตามตัวชี้วัด LCP
      • ในทางปฏิบัติ เว็บไซต์นับล้านเร็วขึ้นเพียงแค่อัปเกรด WordPress
    • ทีม WordPress ยังปรับแต่งการประมวลผลรูปภาพ เพิ่มแคชสำหรับงานบางอย่างที่มีต้นทุนสูง และยกระดับความสำคัญของประสิทธิภาพให้เทียบเท่าฟีเจอร์ใหม่
    • ผลลัพธ์คือสัดส่วนเว็บไซต์ WordPress ที่มีคะแนน CWV ดีเพิ่มขึ้นอย่างมาก (ข้อมูลบางส่วนชี้ว่าสัดส่วนเว็บไซต์ WP ที่ผ่าน CWV ทุกตัว เพิ่มขึ้นมากกว่า 4 เท่า ระหว่างปี 2020 ถึง 2022)

  • Wix และเครื่องมือสร้างเว็บไซต์

    • แพลตฟอร์มเว็บไซต์แบบโฮสต์อื่น ๆ เช่น Wix, Squarespace, และ Duda ก็ใช้ Core Web Vitals เป็นแรงผลักดันในการปรับปรุงประสิทธิภาพเช่นกัน
    • Wix ปรับโครงสร้างพื้นฐานครั้งใหญ่ (แคช, เซิร์ฟเวอร์ที่เร็วขึ้น, และโค้ดฝั่งไคลเอนต์ที่ดีขึ้น) และเพิ่มสัดส่วนเว็บไซต์ Wix ที่ได้คะแนน CWV ดีขึ้นหลายเท่า
    • ในกรณีศึกษา Wix รายงานว่าสามารถเพิ่มสัดส่วนเว็บไซต์ที่มี CWV ระดับ "ดี" จาก 4% เป็นมากกว่า 33% ภายในเวลาประมาณ 1 ปี
    • สิ่งนี้พิสูจน์ว่าการเปลี่ยนวัฒนธรรมของแพลตฟอร์มให้เน้นประสิทธิภาพสามารถสร้างประโยชน์แก่ผู้ใช้จำนวนมหาศาลได้
    • ผู้สร้างเว็บไซต์รายอื่นอย่าง Duda ก็มักโฆษณาว่าเว็บไซต์ลูกค้าส่วนใหญ่ของตนสามารถไปถึง CWV ระดับดีได้ เพราะแพลตฟอร์มได้ ใส่แนวปฏิบัติที่ดีมาให้เป็นค่าเริ่มต้น (เช่น responsive images, การส่งผ่าน CDN, เทมเพลตที่มีประสิทธิภาพ เป็นต้น)
    • แรงกดดันจากการแข่งขันนี้ทำให้แม้เจ้าของเว็บไซต์รายบุคคลจะไม่ใช่ผู้เชี่ยวชาญด้านประสิทธิภาพ แต่แพลตฟอร์มที่ใช้อยู่ก็ผลักดันการปรับปรุงภายในให้เอง

  • JavaScript เฟรมเวิร์ก (Chrome Aurora)

    • ทีม Chrome Aurora เปิดตัวในช่วงกลางปี 2020 ในฐานะหน่วยงานเฉพาะกิจภายใน Chrome เพื่อทำงานร่วมกับ JavaScript เฟรมเวิร์กยอดนิยม
    • สมาชิก Aurora (เช่น Addy Osmani, Kara Erickson, Houssein Djirdeh ฯลฯ) ทำงานใกล้ชิดกับผู้สร้างเฟรมเวิร์กอย่าง React/Next.js, Angular, Nuxt, Gatsby และอื่น ๆ เพื่อ ระบุคอขวดที่พบบ่อยและนำเสนอโซลูชัน
    • ความร่วมมือนี้ทำให้เกิดฟีเจอร์ต่าง ๆ เช่น
      • คอมโพเนนต์ next/script ของ Next.js (โหลดสคริปต์จาก third-party อย่างมีประสิทธิภาพมากขึ้นนอก main thread)
      • directive NgOptimizedImage ที่มีมาใน Angular (ช่วยโหลดรูปภาพแบบหน่วงเวลาอัตโนมัติ และตั้งค่าขนาดกับลำดับความสำคัญอย่างเหมาะสม)
      • โมดูลปรับแต่ง Google Fonts ของ Nuxt
    • ผลกระทบมีนัยสำคัญ: ในปี 2022 คะแนน Core Web Vitals มัธยฐานของเว็บไซต์ที่สร้างด้วยเฟรมเวิร์กเหล่านี้ดีขึ้นอย่างเห็นได้ชัด
      • อัตราการผ่าน CWV ของเว็บไซต์ Next.js จาก 20.4% เป็น 27.3%
      • Angular จาก 7.6% เป็น 13.2%
      • Nuxt จาก 15.8% เป็น 20.2%
    • ตัวอย่างความสำเร็จรายกรณีก็มีมากมาย
      • เว็บไซต์อีคอมเมิร์ซ Land's End ปรับปรุง LCP บนมือถือดีขึ้น 40% (จากการทดสอบในแล็บ) หลังนำการปรับแต่งรูปภาพของ Angular มาใช้
      • CareerKarma ใช้การโหลดสคริปต์แบบปรับปรุงของ Next.js แล้ว ลด LCP ลง 24%

  • ตัวชี้วัดทางธุรกิจจริง

    • ในที่สุดแล้ว Core Web Vitals ที่ดีขึ้นไม่ได้มีไว้เพียงเพื่อทำให้ Google พอใจเท่านั้น แต่ยัง มีความสัมพันธ์กับความพึงพอใจของผู้ใช้จริงและผลลัพธ์ทางธุรกิจ
    • หลายบริษัทแชร์กรณีศึกษาที่เชื่อมโยงการปรับปรุง CWV เข้ากับการมีส่วนร่วมของผู้ใช้
      • เว็บไซต์ข่าว Economic Times ปรับแต่งการประมวลผลสคริปต์เพื่อปรับปรุง INP และทำให้ ยอดดูหน้าเพิ่มขึ้น 42% และอัตราตีกลับลดลง 49%
      • เว็บไซต์จองการเดินทาง RedBus ปรับปรุง INP และพบว่า อัตราคอนเวอร์ชันเพิ่มขึ้น 7%
      • มาร์เก็ตเพลสออนไลน์ของอินเดีย Meesho ลด LCP จาก 6.9 วินาทีเหลือ 2.5 วินาที ทำให้ อัตราตีกลับลดลงราว 17% และอัตราคอนเวอร์ชันเพิ่มขึ้น 3%
    • ตัวอย่างเหล่านี้ตอกย้ำว่าประสิทธิภาพไม่ใช่แค่ตัวชี้วัดทางเทคนิค แต่แปลไปสู่การที่ผู้ใช้ค้างอยู่นานขึ้น อ่านมากขึ้น และซื้อมากขึ้น
    • เรื่องราวความสำเร็จเหล่านี้ยิ่งสร้างแรงจูงใจให้นักพัฒนาและทีมผลิตภัณฑ์ให้ความสำคัญกับ Web Vitals มากขึ้น

ผลลัพธ์ของการยกระดับทั้งระบบนิเวศ

  • ความพยายามร่วมกันของทีมเบราว์เซอร์ ผู้สร้างเฟรมเวิร์ก นักพัฒนา CMS และนักพัฒนาเว็บรายบุคคลจำนวนมาก ช่วยยกระดับสภาพของเว็บอย่างชัดเจน
  • ด้วยการกำหนดตัวชี้วัดที่ชัดเจนและนำไปปฏิบัติได้ Core Web Vitals จึงสร้าง เป้าหมายร่วม ที่ทุกฝ่ายสามารถเดินตามได้
  • สิ่งสำคัญคือความสำเร็จนี้เกิดขึ้นโดยไม่ผูกระบบนิเวศไว้กับเทคโนโลยีแบบปิด แต่ทำได้ผ่าน มาตรฐานเปิดและข้อมูลแบบเปิด
  • ณ ปี 2023 มีเว็บไซต์ประมาณ 40% ของทั้งเว็บ (และในสัดส่วนที่สูงกว่ามากสำหรับเว็บไซต์เชิงพาณิชย์ที่ดูแลอย่างดี) ที่ผ่านค่าเกณฑ์ Core Web Vitals ทุกตัวแล้ว ขณะที่ในต้นปี 2020 มีเพียงส่วนน้อยเท่านั้นที่ผ่าน
  • แม้แต่เว็บไซต์ที่ยังผ่านไม่ครบทั้งหมด โดยทั่วไปก็ยังเร็วและลื่นไหลกว่าเมื่อก่อน
  • วัฒนธรรมการตระหนักเรื่องประสิทธิภาพแพร่หลายมากขึ้น: นักพัฒนาจำนวนมากขึ้นเรื่อย ๆ เฝ้าติดตามตัวชี้วัด CWV (จากผลสำรวจพบว่ามีนักพัฒนาประมาณ 51% ที่ติดตามและปรับแต่ง Web Vitals อย่างจริงจัง)
  • Google ระบุว่าแม้จะผลักดันการปรับปรุงความเร็วเหล่านี้ แต่ความพึงพอใจของนักพัฒนาต่อเว็บแพลตฟอร์มยังคงอยู่ในระดับสูง
    • ซึ่งบ่งชี้ว่าแนวทางดังกล่าว ทำได้จริง โดยไม่ได้ผลักนักพัฒนาไปสู่ความสิ้นหวัง
    • ความสมดุลนี้มีความสำคัญมาก เพราะหากเป้าหมาย CWV เป็นไปไม่ได้หรือเครื่องมือไม่เพียงพอ นักพัฒนาอาจต่อต้าน แต่สิ่งที่เกิดขึ้นกลับเป็นการที่ชุมชนร่วมแรงกันทำให้เว็บดีขึ้น

วิวัฒนาการของตัวชี้วัด: INP, Soft Navigation และอื่น ๆ

  • Google ยอมรับตั้งแต่แรกว่า Core Web Vitals จะ พัฒนาเปลี่ยนแปลงไปตามกาลเวลา
  • ชุดตัวชี้วัดทั้งสามในปี 2020 ไม่ได้ตั้งใจให้เป็นสิ่งคงที่หรือสมบูรณ์แบบ
  • แง่มุมอื่นของประสบการณ์ผู้ใช้ เช่น การเลื่อนที่ลื่นไหล หรือ งานที่กินเวลานานในช่วงท้ายของหน้า ยังไม่ได้รับการครอบคลุมในช่วงแรก
  • ทีม Chrome Web Platform ยังคงศึกษาตัวชี้วัดใหม่ ๆ และการปรับปรุงตัวชี้วัดเดิมอย่างต่อเนื่อง

Interaction to Next Paint(INP)

  • ช่องว่างที่ชัดเจนของ CWV เดิมคือ การโต้ตอบที่เกินกว่าการคลิกครั้งแรก
  • FID วัดเฉพาะความหน่วงของอินพุต ครั้งแรก เท่านั้น ซึ่งสำคัญต่อความประทับใจแรก แต่หน้าเว็บอาจยังไม่ตอบสนองต่อการโต้ตอบอื่น ๆ ของผู้ใช้ในภายหลังได้
  • เพื่อแก้ปัญหานี้ Googler อย่าง Annie Sullivan และ Michal Mocny จึงเสนอ INP
    • พิจารณาการโต้ตอบของผู้ใช้ ทั้งหมด บนหน้า (หรืออย่างน้อยก็จำนวนมาก) แล้วรายงานความหน่วงในลักษณะกรณีเลวร้าย หรือเปอร์เซ็นไทล์ที่ 98
    • ตั้งคำถามว่า "เมื่อผู้ใช้โต้ตอบกับหน้าในช่วงเวลาใดก็ตาม ต้องใช้เวลานานเท่าไรจนกว่าเฟรมถัดไปจะถูกวาดขึ้นเพื่อตอบสนอง" และใช้สิ่งนี้เพื่อ จับความหน่วงของการประมวลผลอีเวนต์และการเรนเดอร์
  • INP ถูกทยอยนำมาใช้เป็นตัวชี้วัดภาคสนามแบบทดลองในปี 2022 และถูกรวบรวมไว้ใน CrUX
  • ภายในต้นปี 2023 Google พบว่า INP คาดการณ์ปัญหาการตอบสนองโดยรวมได้ดีกว่า FID
  • ดังนั้นจึงประกาศว่า ในเดือนมีนาคม 2024 INP จะมาแทนที่ FID ในฐานะ Core Web Vital
    • มีการสื่อสารการเปลี่ยนแปลงนี้ให้นักพัฒนาทราบล่วงหน้าอย่างเพียงพอ
    • เครื่องมืออย่าง Lighthouse และ PageSpeed Insights เริ่มแสดงค่า INP (พร้อมระบุว่า "กำลังจะเป็น CWV เร็ว ๆ นี้")
    • Web.dev ให้คำแนะนำเรื่องการปรับปรุง INP ซึ่งมักลงเอยที่แนวปฏิบัติด้านประสิทธิภาพทั่วไป เช่น แยกงานยาว ๆ ใช้เว็บเวิร์กเกอร์กับงานคำนวณหนัก เป็นต้น
  • การเปลี่ยนจาก FID ไปเป็น INP ตอกย้ำปรัชญาของทีม CWV ที่ปรับปรุงตัวชี้วัดซ้ำ ๆ เพื่อให้ครอบคลุมสิ่งที่สำคัญกว่าได้ดีขึ้น
    • ในกรณีนี้ไม่ใช่แค่การโหลดหน้า แต่คือ การรับประกันการตอบสนองที่สม่ำเสมอตลอดทั้งการเยี่ยมชมของผู้ใช้

ความลื่นไหลและแอนิเมชัน

  • อีกแง่มุมหนึ่งที่ทีม Chrome ศึกษาคือ ความลื่นไหลด้านภาพ เช่น อัตราเฟรมของแอนิเมชันและอาการสกอลล์กระตุก
  • แม้จะยังไม่เป็นตัวชี้วัด CWV อย่างเป็นทางการ แต่ก็มีงานที่ดำเนินอยู่ในด้านนี้
  • ทีม Chrome มีตัวชี้วัด Smoothness ให้กับเครื่องมือ RUM (และบางครั้งรายงานใน CrUX ว่าเป็น "Jankiness") เพื่อใช้วัดสิ่งอย่างแอนิเมชันที่กระตุก
  • มีการเพิ่ม heuristic ในเบราว์เซอร์เพื่อลด jank
    • ตัวอย่างเช่น ปรับวิธีซิงก์ touch event กับเฟรมของจอแสดงผล จนทำให้ความลื่นไหลของการเลื่อนใน Chrome บน Android ดีขึ้นเป็นสองเท่า (อธิบายรายละเอียดไว้ในโพสต์ Fast and Curious เดือนสิงหาคม 2023)
  • ในอนาคตเราอาจได้เห็น Web Vital ด้าน smoothness อย่างเป็นทางการ หรือ INP อาจถูกขยายให้ครอบคลุมความหน่วงของแอนิเมชันบางประเภท
  • ประเด็นสำคัญคือ Google รับรู้ถึงแง่มุมเหล่านี้และกำลังทดลองอย่างจริงจัง

Soft Navigation(SPA)

  • ข้อจำกัดอย่างหนึ่งของนิยาม CWV ในช่วงแรกคือการมุ่งเน้นที่ การโหลดหน้าแบบเต็ม (หรือที่เรียกว่า hard navigation)
  • แต่ Single-Page Application (SPA) สมัยใหม่มักโหลดเพียงครั้งเดียว จากนั้นอัปเดตคอนเทนต์และเส้นทางแบบไดนามิกโดยไม่รีโหลดทั้งหน้า
  • soft navigation เหล่านี้ (เมื่อคลิกลิงก์แล้วคอนเทนต์เปลี่ยนผ่าน JavaScript โดยไม่เกิดการนำทางของเบราว์เซอร์แบบเต็ม) เดิมทีไม่ถูกจับในการวัด LCP หรือ CLS
    • จากมุมมองของเบราว์เซอร์ มันยังคงเป็นหน้าเดิมอยู่ ดังนั้นการอัปเดต DOM ขนาดใหญ่จึงไม่ทำให้เกิด LCP ใหม่
  • นี่หมายความว่าสำหรับ SPA นักพัฒนาต้องพึ่งการวัดแบบกำหนดเองเพื่อประเมิน "การเปลี่ยนหน้า" ภายในแอป และข้อมูล CrUX (ภาคสนาม) ก็ยังมองไม่เห็นการนำทางต่อเนื่องเหล่านั้นด้วยเช่นกัน (บันทึกเฉพาะ CWV ของการโหลดหน้าเริ่มต้น)
  • เพื่อแก้ไขเรื่องนี้ Chrome จึงเสนอ Soft Navigation API
    • Yoav Weiss ได้รับเครดิตทั้งหมดสำหรับงานนี้
    • กลางปี 2023 Chrome เริ่มทดลองตรวจจับการนำทางของ SPA ด้วย heuristic
    • ภายในกลางปี 2025 มีการเปิด origin trial สำหรับ Soft Navigations API
  • ตามที่วิศวกร Chrome อย่าง Barry Pollard และ Michal Mocny อธิบาย soft navigation คือ "JavaScript ดักจับการนำทาง (เช่น ผ่าน History API หรือ framework router) และอัปเดตคอนเทนต์ของหน้าปัจจุบันพร้อมอัปเดต URL ผ่าน history.pushState โดยไม่รีโหลดทั้งหน้า"
  • API ใหม่นี้ทำให้เบราว์เซอร์ (และนักพัฒนา) สามารถทำเครื่องหมายอีเวนต์เหล่านี้ และปฏิบัติต่อมันเสมือนเป็น การดูหน้าใหม่
  • ที่สำคัญ มันทำให้สามารถ วัด Core Web Vitals บน SPA สำหรับการเปลี่ยนเส้นทางแบบ soft ได้ ราวกับว่าเป็นการโหลดหน้า
  • เมื่อใช้ API นี้ ตัวชี้วัดอย่าง LCP สามารถรีเซ็ตได้บน soft navigation และจับคอนเทนต์ที่ใหญ่ที่สุดของวิวใหม่ได้ (โดยใช้แนวคิดของรายการ "interaction-to-next-paint" ใน Performance Timeline)
  • เช่นเดียวกัน CLS สามารถแยกตามการนำทางได้ และ INP สามารถผูกกับวิวปัจจุบันได้
  • นี่คือ ความก้าวหน้าครั้งใหญ่ ในการนำ CWV เข้าสู่โลกของแอปที่ใช้ client-side routing ซึ่งแพร่หลายมาก
  • ณ ช่วงปลายปี 2025 Soft Nav API ยังอยู่ในช่วงทดลอง และนักพัฒนาสามารถ opt-in พร้อมส่งข้อเสนอแนะได้
  • เมื่อเวลาผ่านไป คาดว่า Chrome จะรองรับตัวชี้วัด soft nav อย่างเต็มรูปแบบ และข้อมูลภาคสนาม (CrUX) ก็จะรวมสิ่งนี้เข้าไปด้วย
  • วิวัฒนาการนี้ยอมรับว่า เส้นทางการใช้งานของผู้ใช้ประกอบด้วยหลายขั้นตอน ไม่ได้มีเพียงการโหลดหน้า landing page เท่านั้น และเว็บแพลตฟอร์มควรสามารถวัดและปรับแต่งทั้งเส้นทางได้

การพัฒนาในอนาคต

  • Google ส่งสัญญาณว่าจะ ปรับปรุงตัวชี้วัดต่อไปทุกปี
  • เราอาจได้เห็นการปรับเปลี่ยนอย่าง เกณฑ์ใหม่
    • ตัวอย่างเช่น หากเว็บโดยรวมเร็วขึ้นอย่างทั่วถึง เป้าหมาย LCP ระดับ "ดี" ในอนาคตอาจเข้มงวดกว่า 2.5 วินาที
    • หรืออาจมีตัวชี้วัดใหม่ทั้งหมด หากปรากฏช่องว่างที่ชัดเจน
  • การเพิ่มเติมทั้งหมดจะผ่านกระบวนการแบบเปิดเผยต่อสาธารณะ (การนิยามมาตรฐานประสิทธิภาพเว็บ การหารือกับผู้พัฒนาเบราว์เซอร์รายอื่น ฯลฯ) เหมือนกรณีของ INP
  • Google ยังมีแผนผนวกรวมสัญญาณประสบการณ์หน้าเพิ่มเติมเมื่อเวลาผ่านไป
    • ตัวอย่างเช่น การทดลองด้านความเป็นส่วนตัวและความปลอดภัย เช่น การแสดงป้าย "หน้าเร็ว" ผ่าน Chrome หากเว็บไซต์ใช้แนวปฏิบัติที่ดี
  • อย่างไรก็ตาม ในบริบทของอันดับ Search นั้น Google ได้ทำให้สารที่สื่อออกมาง่ายขึ้นในช่วงหลัง
    • ภายในปี 2023 มีการระบุว่าจะไม่มีตัวเร่งอันดับ "ประสบการณ์หน้า" แบบชัดเจนที่แยกออกจากสัญญาณรายตัวอีกต่อไป
    • โดยพื้นฐานแล้วคือการผนวกรวมปัจจัยด้านประสบการณ์หน้าเข้าในอัลกอริทึมการจัดอันดับหลักอย่างแนบเนียนมากขึ้น
    • แต่จากมุมมองของเจ้าของเว็บไซต์แล้ว ไม่มีอะไรเปลี่ยนแปลง
    • หน้าเว็บที่เร็ว ตอบสนองดี และเสถียร ยังเป็นสิ่งสำคัญพื้นฐานต่อทั้งความพึงพอใจของผู้ใช้และ SEO ที่ดี

สรุป

  • ประวัติของ Core Web Vitals คือ เรื่องราวของเว็บแพลตฟอร์มที่พัฒนาตัวเองเพื่อตอบรับความท้าทาย
    • เริ่มจากแนวคิดที่ว่า คุณภาพของประสบการณ์ผู้ใช้ควรสามารถวัดได้และควรได้รับการให้คุณค่า ก่อนจะขยายเป็นขบวนการวงกว้างที่แตะทั้งตัวชี้วัด เบราว์เซอร์ อันดับการค้นหา เครื่องมือ เฟรมเวิร์ก และแพลตฟอร์มโฮสติ้ง
    • ภายในเวลาเพียงไม่กี่ปี ก็ผลักดันให้เกิดการปรับปรุงครั้งสำคัญทั่วทั้งวงการประสิทธิภาพเว็บ
    • การเดินทางนี้ยังไม่สิ้นสุด: นวัตกรรมในอนาคตอย่างการวัด soft navigation สำหรับ SPA และการปรับปรุงตัวชี้วัดอย่างต่อเนื่อง แสดงให้เห็นว่าคำมั่นของอุตสาหกรรมต่อประสบการณ์เว็บที่รวดเร็วและน่าใช้งานยังคงแข็งแกร่ง
  • Core Web Vitals ไม่ได้เป็นเพียงชุดตัวชี้วัด แต่ได้พิสูจน์แล้วว่าเป็น ตัวเร่งให้เกิดเว็บที่ดีต่อสุขภาพ เร็วกว่าเดิม และยึดผู้ใช้เป็นศูนย์กลางมากขึ้น
    • เป็นมรดกที่สร้างขึ้นจากความร่วมมือของผู้คนจำนวนมาก และเป็นมรดกที่จะเป็นประโยชน์ต่อทุกคนที่ใช้งานเว็บ

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น