Core Web Vitals สำหรับร้านค้าออนไลน์: อธิบาย LCP, INP และ CLS

LCP, INP และ CLS วัดอะไร เกณฑ์ดีและแย่ที่เปอร์เซ็นไทล์ที่ 75 ข้อมูลแล็บต่างจากข้อมูลภาคสนามอย่างไร และวิธีแก้ที่ใช้บ่อยบนร้าน Shopify และ WooCommerce

ทีมบรรณาธิการ FixReportsอ่าน 7 นาที

Core Web Vitals คือเมตริก 3 ตัวของ Google ที่อธิบายประสบการณ์ของผู้เข้าชมจริงบนหน้าเว็บ ได้แก่ Largest Contentful Paint (LCP) สำหรับความเร็วในการโหลด Interaction to Next Paint (INP) สำหรับการตอบสนอง และ Cumulative Layout Shift (CLS) สำหรับความเสถียรของการแสดงผล หน้าเว็บจะผ่านเกณฑ์เมื่อการเข้าชมอย่างน้อย 75% อยู่ในช่วง “ดี” คือ LCP ไม่เกิน 2.5 วินาที INP ไม่เกิน 200 มิลลิวินาที และ CLS ไม่เกิน 0.1 โดยวัดแยกกันระหว่างมือถือกับเดสก์ท็อป สำหรับร้านค้าออนไลน์ คะแนนที่ไม่ผ่านมักมีสาเหตุมาจากภาพแบนเนอร์หลักและภาพสินค้าที่ใหญ่เกินไปหรือถูกตั้งให้โหลดแบบ lazy สคริปต์ของแอปและแท็กติดตาม เว็บฟอนต์ รวมถึงแบนเนอร์หรือวิดเจ็ตรีวิวที่ดันเนื้อหาลงหลังจากหน้าเว็บแสดงขึ้นมาแล้ว

ประเด็นสำคัญ

  • ระดับดี ต้องปรับปรุง และแย่ ตัดสินจากเปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้าเว็บ โดย LCP ถือว่าแย่เมื่อเกิน 4 วินาที INP แย่เมื่อเกิน 500 ms และ CLS แย่เมื่อเกิน 0.25 (web.dev (เปิดในแท็บใหม่))
  • INP เข้ามาแทน First Input Delay (FID) ในฐานะ Core Web Vital ตั้งแต่วันที่ 12 มีนาคม 2024 (web.dev (เปิดในแท็บใหม่))
  • ข้อมูลภาคสนามของ Chrome UX Report เป็นค่าเฉลี่ยแบบต่อเนื่อง 28 วัน และไม่รวม Chrome บน iOS (Chrome for Developers (เปิดในแท็บใหม่))
  • ฟิลเตอร์ image_tag ของ Shopify จะโหลดภาพแบบ eager ใน 3 เซกชันแรกของเทมเพลต และโหลดแบบ lazy ตั้งแต่เซกชันที่ 4 เป็นต้นไป เว้นแต่คุณจะกำหนดค่าเอง (Shopify (เปิดในแท็บใหม่))
  • ตั้งแต่ WordPress 6.3 เป็นต้นมา ระบบหลักจะเพิ่ม fetchpriority="high" ให้ภาพที่ประเมินว่ามีแนวโน้มเป็นองค์ประกอบ LCP มากที่สุด (Make WordPress Core (เปิดในแท็บใหม่))

เกณฑ์ของ Core Web Vitals คืออะไร

หน้าเว็บจะผ่าน Core Web Vitals เมื่อค่าที่เปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้าเว็บอยู่ในช่วงดีครบทั้ง 3 เมตริก

เมตริกสิ่งที่วัดดีต้องปรับปรุงแย่
LCPเวลาจนกว่าภาพ วิดีโอ หรือบล็อกข้อความที่ใหญ่ที่สุดในวิวพอร์ตจะแสดงผลไม่เกิน 2.5 sเกิน 2.5 s ถึง 4.0 sเกิน 4.0 s
INPเวลาตั้งแต่คลิก แตะ หรือกดแป้นพิมพ์ จนเฟรมถัดไปถูกวาดขึ้นไม่เกิน 200 msเกิน 200 ms ถึง 500 msเกิน 500 ms
CLSเนื้อหาที่มองเห็นขยับโดยไม่คาดคิดมากเพียงใดไม่เกิน 0.1เกิน 0.1 ถึง 0.25เกิน 0.25

เกณฑ์มาจากคู่มือ LCP (เปิดในแท็บใหม่), INP (เปิดในแท็บใหม่) และ CLS (เปิดในแท็บใหม่) ของ web.dev ณ เดือนตุลาคม 2026

การใช้เปอร์เซ็นไทล์ที่ 75 หมายความว่าผลลัพธ์สะท้อนผู้เข้าชมส่วนใหญ่ ไม่ใช่เฉพาะกลุ่มที่เร็วที่สุด และ Google แยกมือถือกับเดสก์ท็อป (เปิดในแท็บใหม่)ออกจากกัน PageSpeed Insights จะให้หน้าเว็บผ่านเมื่อทั้ง 3 เมตริกอยู่ในระดับดี หากมีข้อมูล INP ไม่เพียงพอ จะตัดสินจาก LCP และ CLS เท่านั้น (เอกสาร PageSpeed Insights (เปิดในแท็บใหม่)) Google ระบุว่า Core Web Vitals ที่อยู่ในสถานะเสถียรจะไม่เปลี่ยนแปลงบ่อยกว่าปีละครั้ง

บนร้านค้าออนไลน์ องค์ประกอบ LCP มักเป็นแบนเนอร์หลัก (hero banner) หรือภาพสินค้าหลัก การจัดการรูปภาพจึงสำคัญมาก

ทำไม INP จึงเข้ามาแทน FID ในเดือนมีนาคม 2024

INP เข้ามาแทน FID เพราะ FID วัดเฉพาะการโต้ตอบครั้งแรกและวัดเพียงบางส่วนของความล่าช้า ขณะที่ INP พิจารณาการโต้ตอบตลอดการเข้าชมทั้งหมด

Google ประกาศในเดือนพฤษภาคม 2023 ว่า INP จะกลายเป็น Core Web Vital และการเปลี่ยนแปลงมีผลเมื่อวันที่ 12 มีนาคม 2024 (เปิดในแท็บใหม่) FID รายงานเฉพาะการโต้ตอบครั้งแรก และรายงานเพียงความล่าช้าของอินพุต ไม่รวมเวลาที่ใช้รัน event handler หรือวาดผลลัพธ์ ส่วน INP สังเกตการคลิก การแตะ และการกดแป้นพิมพ์ตลอดการเข้าชม แล้วรายงานครั้งที่ใช้เวลานานที่สุดโดยไม่นับค่าผิดปกติ การเลื่อนหน้าและการวางเมาส์ค้างไม่นับรวม ผู้ใช้ API ของ CrUX และ PageSpeed Insights มีเวลาถึงวันที่ 9 กันยายน 2024 ในการเปลี่ยนมาใช้ (web.dev (เปิดในแท็บใหม่))

การโต้ตอบแต่ละครั้งมี 3 ส่วน ได้แก่ ความล่าช้าของอินพุต (input delay ซึ่งเป็นการรอสคริปต์ที่กำลังทำงาน) ระยะเวลาประมวลผล (processing duration ซึ่งเป็นการรัน handler) และความล่าช้าในการแสดงผล (presentation delay ซึ่งเป็นการวาดเฟรมถัดไป) (web.dev (เปิดในแท็บใหม่))

บนร้านค้าออนไลน์ การโต้ตอบเหล่านี้คือตัวเลือกสินค้า ปุ่มจำนวน ปุ่มเพิ่มลงตะกร้า ลิ้นชักตะกร้า (cart drawer) ตัวกรอง และเมนู หน้าเว็บอาจผ่าน FID ได้ด้วยการแตะครั้งแรกที่รวดเร็ว แต่ยังรู้สึกช้าเมื่อผู้ใช้เปิดตัวกรองในภายหลัง

ข้อมูลแล็บกับข้อมูลภาคสนามต่างกันอย่างไร

ข้อมูลแล็บ (lab data) มาจากการทดสอบครั้งเดียวภายใต้เงื่อนไขที่กำหนดไว้ ส่วนข้อมูลภาคสนาม (field data) เก็บจากผู้เข้าชมจริงในช่วงระยะเวลาหนึ่ง และ Google แนะนำให้ใช้ข้อมูลภาคสนามในการตัดสินใจว่าจะแก้อะไรก่อน (web.dev (เปิดในแท็บใหม่))

ข้อมูลแล็บข้อมูลภาคสนาม
แหล่งข้อมูลการโหลดหน้าเว็บจำลองหนึ่งครั้ง (Lighthouse, Chrome DevTools, ส่วนข้อมูลแล็บของ PageSpeed Insights)ผู้เข้าชมจริงที่ใช้ Chrome (Chrome UX Report) หรือระบบติดตามผู้ใช้จริง (RUM) ของคุณเอง
เงื่อนไขอุปกรณ์และเครือข่ายคงที่ การทดสอบมือถือค่าเริ่มต้นของ Lighthouse (เปิดในแท็บใหม่) ใช้โปรไฟล์ “Slow 4G” (round trip 150 ms ดาวน์โหลด 1.6 Mbps) และลดความเร็ว CPU ลง 4 เท่าอุปกรณ์ เครือข่าย และตำแหน่งที่ตั้งตามที่ผู้เข้าชมของคุณใช้จริง
INPไม่ได้วัดจากการโหลดหน้าเว็บธรรมดา Total Blocking Time (TBT) ใช้เป็นตัวแทนคร่าว ๆ ได้วัดจากการโต้ตอบจริง
เหมาะสำหรับการดีบักและตรวจสอบการเปลี่ยนแปลงก่อนเผยแพร่การรู้ว่าผู้เข้าชมได้รับประสบการณ์อย่างไรจริง ๆ

TBT รวมเวลาส่วนที่เกิน 50 ms ของแต่ละงานบนเธรดหลัก (main thread) web.dev แนะนำให้ต่ำกว่า 200 ms บนฮาร์ดแวร์มือถือระดับทั่วไป แต่ระบุว่า TBT ใช้แทน INP ไม่ได้ (web.dev (เปิดในแท็บใหม่))

รายละเอียด 3 ข้อของ Chrome UX Report (CrUX) ที่สำคัญต่อร้านค้า

  • เป็นค่าเฉลี่ยแบบต่อเนื่อง 28 วัน (เปิดในแท็บใหม่) ที่อัปเดตทุกวัน
  • ครอบคลุม Chrome บนเดสก์ท็อปและ Android สำหรับผู้ใช้ที่เข้าเงื่อนไขการรายงานของ Chrome โดยไม่รวม Chrome บน iOS ร้านที่ลูกค้าส่วนใหญ่ใช้ iPhone จึงเห็นข้อมูลภาคสนามจากผู้ชมเพียงบางส่วน (methodology (เปิดในแท็บใหม่))
  • หน้าเว็บและ origin จะปรากฏก็ต่อเมื่อค้นพบได้แบบสาธารณะและมีผู้เข้าชมมากพอ ร้านที่มีทราฟฟิกน้อยจึงอาจมีเพียงข้อมูลระดับ origin หรือไม่มีข้อมูลเลย

แดชบอร์ดประสิทธิภาพเว็บ (เปิดในแท็บใหม่)ของ Shopify ก็รายงาน LCP, INP และ CLS จากผู้ใช้จริงที่เปอร์เซ็นไทล์ที่ 75 เช่นกัน แต่ใช้ช่วง 30 วันแทน 28 วัน จึงอาจเห็นตัวเลขต่างจาก CrUX อยู่บ้าง

อะไรทำให้ LCP บนหน้าร้านค้าช้า

LCP บนร้านค้ามักช้าเพราะภาพหลักมีขนาดใหญ่เกินไป ถูกค้นพบช้า หรือถูกหน่วงโดยตั้งใจด้วย lazy loading หรือแอนิเมชัน

  • ใช้ lazy loading กับภาพ LCP web.dev ระบุว่าไม่ควรทำเช่นนี้เลย (web.dev (เปิดในแท็บใหม่)) การวิเคราะห์หน้าเว็บ WordPress พบว่า LCP ที่เปอร์เซ็นไทล์ที่ 75 ช้าลงบนเว็บไซต์ที่ใช้ lazy loading แบบเนทีฟ และการเลิกใช้ lazy loading กับภาพในส่วนบนของหน้าก็ทำให้ปัญหานั้นหายไป (web.dev (เปิดในแท็บใหม่))
  • ภาพถูกค้นพบช้า แบนเนอร์หลักที่ตั้งเป็น background-image ใน CSS หรือถูกแทรกโดยสคริปต์สไลเดอร์ จะไม่อยู่ใน HTML ที่เบราว์เซอร์สแกนเป็นอันดับแรก Shopify แนะนำว่าไม่ควรใช้พื้นหลัง CSS กับเนื้อหาแบนเนอร์หลัก และไม่ควรใช้เอฟเฟกต์ fade-in กับภาพ LCP (Shopify (เปิดในแท็บใหม่))
  • ลำดับความสำคัญต่ำ ภาพจะโหลดด้วยลำดับความสำคัญต่ำจนกว่าการจัดเลย์เอาต์จะเสร็จ Shopify จึงแนะนำให้ใส่ fetchpriority="high" ให้ภาพ LCP (Shopify (เปิดในแท็บใหม่)) web.dev ระบุว่าการตั้งค่านี้กับภาพมากกว่าหนึ่งหรือสองภาพจะลดประโยชน์ของมันลง (web.dev (เปิดในแท็บใหม่))
  • CSS และสคริปต์ที่บล็อกการแสดงผล สไตล์ชีตขนาดใหญ่และสคริปต์แบบ synchronous ใน <head> จะหน่วงการแสดงผล แม้ภาพจะโหลดมาถึงแล้วก็ตาม (web.dev (เปิดในแท็บใหม่))
  • ขนาดไฟล์และฟอนต์ ใช้ฟอร์แมตสมัยใหม่ srcset และ sizes และ CDN สำหรับเว็บฟอนต์ ให้ใช้ค่า font-display อื่นที่ไม่ใช่ auto หรือ block
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

อะไรทำให้ INP บนหน้าร้านค้าช้า

INP ที่ช้าบนร้านค้ามักหมายถึงมี JavaScript บนเธรดหลักมากเกินไป ซึ่งส่วนใหญ่มาจากแอป แท็กติดตาม และฟีเจอร์ของธีม การแตะแต่ละครั้งจึงต้องรอ

หากผู้ซื้อแตะ “เพิ่มลงตะกร้า” ขณะที่สคริปต์รีวิว แชต และ analytics ยังทำงานอยู่ การแตะนั้นจะต้องรอ ตัวเลือกสินค้าที่เรนเดอร์ฟอร์มสินค้าใหม่ทั้งหมดจะเพิ่มระยะเวลาประมวลผล ส่วนเมกะเมนูขนาดใหญ่และกริดคอลเลกชันที่มีตัวอย่างสี (swatch) จำนวนมากจะเพิ่มความล่าช้าในการแสดงผล

web.dev แนะนำให้แบ่งงานที่ใช้เวลานานออกเป็นส่วนย่อยและคืนการทำงานให้เธรดหลัก (yield) อัปเดตหน้าจอก่อนแล้วค่อยเลื่อนงานที่เหลือออกไป และทำให้ DOM มีขนาดเล็กลง (web.dev (เปิดในแท็บใหม่)) Shopify เพิ่มขั้นตอนเฉพาะสำหรับร้านค้า ได้แก่ ตรวจสอบแอป พิกเซล และสคริปต์ของธีมทุกตัว เลื่อนการโหลดสิ่งที่ไม่จำเป็นออกไป โหลดฟีเจอร์เมื่อมีการโต้ตอบ และปิดสคริปต์ป้องกันการกระพริบ (anti-flicker) ของการทดสอบ A/B เมื่อไม่มีการทดสอบอยู่ (Shopify (เปิดในแท็บใหม่))

อะไรทำให้เลย์เอาต์ขยับบนหน้าสินค้าและหน้าคอลเลกชัน

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

web.dev ระบุสาเหตุที่พบบ่อยว่าเป็นสื่อที่ไม่ทราบขนาด เนื้อหาที่ถูกเพิ่มเหนือเนื้อหาเดิม วิดเจ็ตของบุคคลภายนอกที่ปรับขนาดตัวเอง และเว็บฟอนต์ที่มีขนาดต่างจากฟอนต์สำรอง (web.dev (เปิดในแท็บใหม่)) บนร้านค้า นั่นหมายถึงแถบส่งฟรีที่ถูกแทรกไว้ด้านบน ดาวรีวิวที่โหลดหลังชื่อสินค้า ข้อความผ่อนชำระใต้ราคา และคารูเซลสินค้าแนะนำ Shopify ระบุว่าเนื้อหาป๊อปอัปก็ทำให้เกิดการขยับได้เช่นกัน (Shopify (เปิดในแท็บใหม่))

การขยับที่เกิดภายใน 500 ms หลังผู้ใช้ป้อนข้อมูลจะไม่นับ แต่การขยับระหว่างการเลื่อนหน้านับรวมด้วย และเครื่องมือแล็บมักตรวจไม่พบ (web.dev (เปิดในแท็บใหม่)) ให้กำหนด width และ height หรือ aspect-ratio ใน CSS ให้รูปภาพ จองพื้นที่ไว้สำหรับวิดเจ็ต แสดงแบนเนอร์แบบซ้อนทับ ลดการขยับจากการสลับฟอนต์ด้วย size-adjust และทำแอนิเมชันด้วย transform แทน top หรือ left

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

ปรับปรุง Core Web Vitals บน Shopify อย่างไร

บน Shopify ผลลัพธ์ส่วนใหญ่มาจากการโหลดภาพแรกแบบ eager พร้อมลำดับความสำคัญสูง การลดสคริปต์ของแอป และการตรวจผลในรายงานประสิทธิภาพเว็บของหน้าผู้ดูแล

ตรวจข้อมูลในหน้าผู้ดูแลร้าน

สรุปข้อมูลจะแสดงอยู่ในหน้า Online Store > Themes และรายงาน LCP, INP และ CLS ฉบับเต็มอยู่ใน Analytics > Reports ข้อมูลอาจล่าช้าได้สูงสุด 36 ชั่วโมง และต้องปิดโหมดส่วนตัว (private mode) ของร้านก่อน (Shopify Help Center (เปิดในแท็บใหม่))

ควบคุมการโหลดภาพใน Liquid

ฟิลเตอร์ image_tag จะโหลดภาพแบบ lazy ในเซกชันที่อยู่ด้านล่างของหน้า เว้นแต่คุณจะตั้งค่า preload (ข้อมูลอ้างอิง image_tag (เปิดในแท็บใหม่)) โดยโหลดแบบ eager สำหรับเซกชันที่ 1 ถึง 3 และแบบ lazy ตั้งแต่เซกชันที่ 4 เนื่องจาก section.index มีค่าเป็น nil ในเครื่องมือแก้ไขธีม ให้ตรวจเงื่อนไขด้วย > 3 แทน <= 3

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

ในกริดสินค้า Shopify แนะนำให้โหลดแบบ eager เฉพาะการ์ดสินค้าไม่กี่ใบแรก (เช่น forloop.index <= 4) (Shopify (เปิดในแท็บใหม่)) ใช้ preload: true อย่างประหยัด เพราะ Shopify แนะนำให้ preload เฉพาะทรัพยากรที่ถูกค้นพบช้าเพียงหนึ่งหรือสองรายการ

ลบสิ่งที่แอปทิ้งไว้

ปิด app embed ที่ไม่ได้ใช้ใน Online Store > Edit theme > App embeds (Shopify Help Center (เปิดในแท็บใหม่)) การถอนการติดตั้งแอปจะลบ app block ของแอปนั้นออก แต่แอปที่แก้ไขไฟล์ธีมโดยตรงอาจทิ้ง “โค้ดผี” (ghost code) ไว้ ซึ่ง Shopify ระบุว่าอาจก่อปัญหาด้านคุณภาพและประสิทธิภาพ (Shopify (เปิดในแท็บใหม่)) Shopify ยังระบุว่า script tag จะหยุดทำงานในวันที่ 1 มีนาคม 2027 สำหรับฟอนต์ Shopify แนะนำให้ใช้ CDN ของ Shopify เองหรือฟอนต์ของระบบ แทนบริการฟอนต์ภายนอก (Shopify (เปิดในแท็บใหม่))

ปรับปรุง Core Web Vitals บน WooCommerce อย่างไร

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

  • คงการจัดการภาพของระบบหลักไว้ ตั้งแต่ WordPress 6.3 (เปิดตัววันที่ 8 สิงหาคม 2023) ระบบหลักจะเพิ่ม fetchpriority="high" ให้ภาพที่น่าจะเป็น LCP (ขนาดอย่างน้อย 50,000 ตารางพิกเซลตามค่าเริ่มต้น) และไม่ใช้ lazy loading กับภาพในเนื้อหา 3 ภาพแรก (Make WordPress Core (เปิดในแท็บใหม่)) หากปลั๊กอินเพิ่มประสิทธิภาพเพิ่ม lazy loading ของตัวเองเข้ามา ให้ตรวจว่าได้ยกเว้นแบนเนอร์หลักและภาพสินค้าหลักไว้
  • แคชหน้าเว็บ แต่ไม่แคชตะกร้า คู่มือของ WooCommerce แนะนำให้ใช้การแคชหน้าเว็บที่เซิร์ฟเวอร์หรือผ่านปลั๊กอิน และใช้ CDN โดยไม่แคชหน้าตะกร้าและหน้าชำระเงิน (เอกสารสำหรับนักพัฒนา WooCommerce (เปิดในแท็บใหม่))
  • ตรวจ cart fragments ตั้งแต่ WooCommerce 7.8 สคริปต์ cart fragments จะโหลดเฉพาะหน้าที่มีวิดเจ็ต Cart แต่บางธีมฝังวิดเจ็ตนั้นไว้ในโค้ดโดยตรง ส่วนบล็อก Mini-Cart ไม่ได้ใช้ cart fragments (บล็อกนักพัฒนา WooCommerce (เปิดในแท็บใหม่))
  • หาปลั๊กอินที่หนัก WooCommerce แนะนำให้ใช้ Query Monitor เพื่อหาปลั๊กอินที่ช้า และเลื่อนการโหลด JavaScript ที่ไม่สำคัญออกไป

หากเลย์เอาต์ของคุณแสดงภาพมากกว่า 3 ภาพในส่วนบนของหน้า (above the fold) คุณปรับเกณฑ์ของ WordPress ให้สูงขึ้นได้

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

ต้องใช้เวลานานแค่ไหนกว่าผลการแก้ไขจะปรากฏ

การทดสอบแล็บจะแสดงผลของการแก้ไขได้ทันที แต่ข้อมูลภาคสนามต้องใช้เวลาราว 4 สัปดาห์จึงจะสะท้อนผลได้เต็มที่ เพราะ CrUX เฉลี่ยข้อมูลย้อนหลัง 28 วัน

ทดสอบแล็บหลายรอบทั้งก่อนและหลังการเปลี่ยนแปลง เพราะผลแต่ละรอบไม่เท่ากัน จากนั้นติดตามตัวเลขภาคสนามใน PageSpeed Insights รายงาน Core Web Vitals ของ Search Console หรือรายงานของ Shopify การสแกนฟรีให้ผลเบื้องต้นในเวลาประมาณหนึ่งนาที ส่วนรายงานประสิทธิภาพจะทดสอบแล็บบนมือถือแบบจำกัดความเร็ว (slow 4G, CPU 4 เท่า) และเพิ่มข้อมูลภาคสนามจาก Chrome UX Report รวมถึง INP เมื่อ Google มีข้อมูลของร้านคุณมากพอ

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

Core Web Vitals มีผลต่ออันดับบน Google หรือไม่

Google ระบุว่าระบบจัดอันดับของ Google ใช้ Core Web Vitals แต่คะแนนที่ดีไม่ได้รับประกันอันดับต้น ๆ และ Google ยังคงแสดงเนื้อหาที่เกี่ยวข้องที่สุด แม้ประสบการณ์การใช้งานหน้าเว็บจะไม่ดีก็ตาม (Google Search Central (เปิดในแท็บใหม่))

ทำไม PageSpeed Insights จึงไม่แสดงข้อมูลภาคสนามของร้าน

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

ต้องได้คะแนน Lighthouse 90 ขึ้นไปจึงจะผ่านหรือไม่

ไม่จำเป็น คะแนนประสิทธิภาพของ Lighthouse เป็นผลจากแล็บ ขณะที่การประเมิน Core Web Vitals ใช้ข้อมูลภาคสนามที่เปอร์เซ็นไทล์ที่ 75 หน้าเว็บจึงอาจผ่านได้แม้คะแนน Lighthouse ปานกลาง และอาจไม่ผ่านแม้คะแนนสูง

ควรใช้ lazy loading กับภาพสินค้าทั้งหมดหรือไม่

ไม่ควร ให้ใช้ lazy loading กับภาพที่อยู่ถัดจากหน้าจอแรกลงไป แต่โหลดแบนเนอร์หลักและภาพสินค้าหลักแบบ eager โดยใส่ fetchpriority="high" ให้ภาพใดภาพหนึ่ง

ทำไมผลบนมือถือจึงแย่กว่าบนเดสก์ท็อป

Google วัดผลมือถือและเดสก์ท็อปแยกกัน และโทรศัพท์มีหน่วยประมวลผลและเครือข่ายที่ช้ากว่า การทดสอบมือถือของ Lighthouse จำลองสภาพนั้นด้วยโปรไฟล์ Slow 4G และลดความเร็ว CPU ลง 4 เท่า

แหล่งที่มา

คู่มือทั้งหมด