ใช้เครื่องมือของ Google เพื่อตรวจสอบ ปรับปรุง และตรวจสอบเว็บไซต์อย่างมีประสิทธิภาพ
เผยแพร่เมื่อ 28 พฤษภาคม 2020
Core Web Vitals คือชุดเมตริกที่ประเมินประสบการณ์ของผู้ใช้ตามเกณฑ์ต่างๆ เช่น ประสิทธิภาพการโหลด การตอบสนองต่ออินพุตของผู้ใช้ และความเสถียรของเลย์เอาต์
คู่มือนี้จะอธิบายเวิร์กโฟลว์ในการปรับปรุง Core Web Vitals สําหรับเว็บไซต์ แต่จุดเริ่มต้นของเวิร์กโฟลว์จะขึ้นอยู่กับว่าคุณกําลังรวบรวมข้อมูลภาคสนามของคุณเองหรือไม่ ระยะเวลาที่ใช้ในการแก้ปัญหาอาจขึ้นอยู่กับเครื่องมือของ Google ที่คุณพบว่ามีประโยชน์ในการวินิจฉัยและแก้ไขปัญหาเกี่ยวกับประสบการณ์ของผู้ใช้
การวัด Core Web Vitals ทำได้ดีที่สุดในสภาพแวดล้อมจริง
Core Web Vitals ออกแบบมาเพื่อวัดประสบการณ์ของผู้ใช้เว็บไซต์โดยเฉพาะ ซึ่งเป็นเมตริกที่เน้นผู้ใช้เป็นหลัก เครื่องมือแบบห้องทดลอง เช่น Lighthouse เป็นเครื่องมือวิเคราะห์เพื่อไฮไลต์ปัญหาด้านประสิทธิภาพที่อาจเกิดขึ้นและแนวทางปฏิบัติแนะนำ เครื่องมือแบบห้องทดลองจะทํางานภายใต้เงื่อนไขที่กําหนดไว้ล่วงหน้าและอาจไม่ได้แสดงการวัด Core Web Vitals ในชีวิตจริงที่ผู้ใช้ได้รับ
ตัวอย่างเช่น Lighthouse เป็นเครื่องมือแบบห้องทดลองที่ทำการทดสอบด้วยการจําลองการจํากัดความเร็วในสภาพแวดล้อมเดสก์ท็อปหรืออุปกรณ์เคลื่อนที่ที่จำลอง แม้ว่าการจําลองเครือข่ายและอุปกรณ์ที่ช้าลงจะมีประโยชน์เมื่อพยายามวินิจฉัยปัญหาด้านประสิทธิภาพ แต่การจําลองดังกล่าวเป็นเพียงส่วนเล็กๆ ของสภาพเครือข่ายและความสามารถของอุปกรณ์ที่หลากหลาย จึงอาจไม่ได้แสดงถึงสิ่งที่ผู้ใช้ในเว็บไซต์ของคุณพบ
โดยทั่วไปแล้ว เครื่องมือที่ใช้ห้องทดลองอย่าง Lighthouse จะ "โหลดหน้าเว็บแบบไม่อุ่นเครื่อง" ในฐานะผู้เข้าชมใหม่ทั้งหมด ระดับนี้มักจะโหลดช้าที่สุด แต่ในชีวิตจริง ผู้เข้าชมอาจมีชิ้นงานบางส่วนที่แคชไว้หากเคยเข้าชมมาก่อน หรือเมื่อเรียกดูเว็บไซต์ ผู้เข้าชมใหม่และเครื่องมือต่างๆ อาจเห็นเว็บไซต์แตกต่างกันด้วยแบนเนอร์คุกกี้หรือเนื้อหาอื่นๆ ที่แสดงต่อผู้เข้าชม
กล่าวโดยย่อคือ แม้ว่าเครื่องมือแบบห้องทดลองจะระบุปัญหาด้านประสิทธิภาพที่อาจเกิดขึ้นและช่วยแก้ไขข้อบกพร่องและปรับปรุงได้ แต่อาจไม่ได้แสดงจํานวนผู้เข้าชมที่พบปัญหาจริงในเว็บไซต์ ใช้ข้อมูลภาคสนามเพื่อวัดประสิทธิภาพในชีวิตจริง และเครื่องมือทดสอบ เช่น Lighthouse เพื่อวินิจฉัยวิธีปรับปรุงประสิทธิภาพ โปรดดูส่วนกรณีที่ควรใช้ Lighthouse ด้วย
Google จะวัด Core Web Vitals ผ่านรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ชุดข้อมูลนี้เป็นชุดข้อมูลสาธารณะที่รวบรวมจากผู้ใช้ Chrome จริง ซึ่งถือเป็นหัวใจสําคัญของเครื่องมือของ Google และของบุคคลที่สามจํานวนมากที่รายงาน Core Web Vitals ของเว็บไซต์
แต่ CrUX มีข้อจํากัด ข้อมูลนี้มักจะบอกได้เมื่อใดที่เกิดปัญหา แต่มักมีข้อมูลไม่เพียงพอที่จะบอกสาเหตุ
รวบรวมข้อมูลภาคสนามของคุณเอง หากเป็นไปได้
ชุดข้อมูลที่ปรับปรุงประสิทธิภาพเว็บไซต์ได้ดีที่สุดคือชุดข้อมูลที่คุณสร้างขึ้น ซึ่งเริ่มต้นด้วยการเก็บรวบรวมข้อมูลภาคสนามจากผู้เข้าชมเว็บไซต์ วิธีการจะขึ้นอยู่กับขนาดขององค์กร และคุณจะต้องจ่ายเงินสำหรับโซลูชันของบุคคลที่สามหรือสร้างโซลูชันของคุณเอง
โซลูชันแบบชําระเงินเกือบจะวัด Core Web Vitals (และเมตริกประสิทธิภาพอื่นๆ) ได้อย่างแน่นอน และมักจะมีเครื่องมือที่หลากหลายสําหรับเจาะลึกข้อมูลที่ได้รับ ในองค์กรขนาดใหญ่ที่มีทรัพยากรจำนวนมาก วิธีนี้อาจเป็นวิธีที่แนะนำ
อย่างไรก็ตาม คุณอาจไม่ได้อยู่ในองค์กรขนาดใหญ่ หรือแม้แต่องค์กรที่มีงบประมาณเพียงพอที่จะซื้อโซลูชันของบุคคลที่สาม ในกรณีเหล่านี้ web-vitals
library ของ Google จะช่วยรวบรวม Web Vitals ทั้งหมด อย่างไรก็ตาม คุณจะเป็นผู้รับผิดชอบต่อวิธีรายงาน จัดเก็บ และวิเคราะห์ข้อมูลดังกล่าว
หากคุณใช้ Google Analytics อยู่แล้ว แต่ยังไม่ได้เริ่มรวบรวมข้อมูลภาคสนามของตนเอง คุณอาจมีโอกาสใช้ไลบรารี web-vitals
เพื่อส่ง Web Vitals ที่รวบรวมในภาคสนามไปยัง Google Analytics และใช้ BigQuery Export ของ GA4 เพื่อรายงานข้อมูล
ทําความเข้าใจเครื่องมือของ Google
ไม่ว่าคุณจะรวบรวมข้อมูลภาคสนามของคุณเองหรือไม่ Google มีเครื่องมือหลายอย่างซึ่งอาจเป็นประโยชน์ในการวิเคราะห์ Core Web Vitals ก่อนสร้างเวิร์กโฟลว์ ภาพรวมระดับสูงของเครื่องมือแต่ละรายการจะช่วยให้คุณเข้าใจว่าเครื่องมือใดอาจเหมาะกับคุณหรือไม่
รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX)
ดังที่ได้กล่าวไว้ก่อนหน้านี้ CrUX คือชุดข้อมูลสาธารณะเกี่ยวกับข้อมูลในช่องที่รวบรวมจากกลุ่มผู้ใช้ Google Chrome จริงจากเว็บไซต์หลายล้านแห่ง ซึ่งประกอบด้วยเมตริก Core Web Vitals และเมตริกอื่นๆ สําหรับเว็บไซต์ที่มีการเข้าชมเพียงพอ
CrUX มีให้บริการเป็นชุดข้อมูล BigQuery รายเดือนที่ระดับต้นทาง หรือเป็น API รายวันที่ระดับ URL หรือต้นทาง ทั้งนี้ขึ้นอยู่กับว่า URL หรือต้นทางมีตัวอย่างมากพอในชุดข้อมูล CrUX หรือไม่ ข้อมูล CrUX มีให้บริการผ่านเครื่องมือ CrUX ต่างๆ สําหรับทั้งการเข้าถึงแบบเป็นโปรแกรมและเครื่องมือภาพสําหรับผู้ใช้
กรณีที่ควรใช้ CrUX
แม้ว่าคุณจะรวบรวมข้อมูลในช่องของคุณเอง CrUX ก็ยังคงมีประโยชน์ แม้ว่า CrUX จะแสดงถึงผู้ใช้ Chrome เพียงบางส่วน แต่การเปรียบเทียบข้อมูลในช่องของเว็บไซต์เพื่อดูว่าข้อมูลนั้นสอดคล้องกับข้อมูล CrUX อย่างไรก็มีประโยชน์ แต่ละวิธีมีทั้งข้อดีและข้อเสีย ซึ่งอาจส่งผลให้ผลลัพธ์แตกต่างกัน หากคุณไม่ได้รวบรวมข้อมูลภาคสนามใดๆ สําหรับเว็บไซต์ CrUX จะมีประโยชน์อย่างยิ่งในการให้ภาพรวมระดับสูง โดยให้เว็บไซต์ของคุณแสดงอยู่ในชุดข้อมูล
คุณสามารถใช้ CrUX โดยตรงหรือใช้เครื่องมืออื่นก็ได้ (รวมถึงเครื่องมือที่กล่าวถึงด้านล่าง) การใช้ชุดข้อมูล CrUX โดยตรงโดยใช้ BigQuery หรือ API มีประโยชน์ในการแสดงข้อมูลที่ไม่ได้แสดงในเครื่องมืออื่นๆ เช่น ข้อมูลระดับประเทศมักไม่พร้อมใช้งานในเครื่องมืออื่นๆ หรือเพื่อดูเมตริกเพิ่มเติมใน CrUX ซึ่งมักไม่แสดงในเครื่องมืออื่นๆ
กรณีที่ไม่ควรใช้ CrUX
CrUX แสดงถึงผู้ใช้ Chrome เท่านั้น และผู้ใช้ Chrome เพียงบางส่วนเท่านั้น โซลูชัน RUM แบบสมบูรณ์อาจรวมประสบการณ์การใช้งานเพิ่มเติมใน Chrome และเบราว์เซอร์อื่นๆ ที่รองรับเมตริก Web Vitals
เว็บไซต์ที่ได้รับการเข้าชมไม่เพียงพอจะไม่แสดงในชุดข้อมูล CrUX ในกรณีนี้ คุณจะต้องรวบรวมข้อมูลภาคสนามของคุณเองเพื่อให้ทราบประสิทธิภาพของเว็บไซต์ในภาคสนาม เนื่องจาก CrUX จะใช้ไม่ได้ หรือคุณอาจต้องใช้ข้อมูลในห้องทดลอง แต่มีข้อจำกัดที่ข้อมูลดังกล่าวอาจไม่ได้เป็นตัวแทนของการใช้งานจริงตามที่อธิบายไว้ก่อนหน้านี้
เนื่องจากข้อมูล CrUX เป็นค่าเฉลี่ยแบบเลื่อนในช่วง 28 วันที่ผ่านมา จึงไม่ใช่เครื่องมือที่เหมาะสมในระหว่างการพัฒนา เนื่องจากจะต้องใช้เวลาพอสมควรเพื่อให้การปรับปรุงแสดงในชุดข้อมูล CrUX
สุดท้าย CrUX ในฐานะชุดข้อมูลสาธารณะมีข้อจํากัดด้านปริมาณข้อมูลที่เผยแพร่ได้และวิธีค้นหาข้อมูลนี้ การบันทึกข้อมูล RUM ของคุณเองช่วยให้คุณรวบรวมรายละเอียดเพิ่มเติมได้ (เช่น องค์ประกอบ LCP) และแบ่งกลุ่มข้อมูลได้มากขึ้นเพื่อระบุปัญหา ผู้ใช้ที่เข้าสู่ระบบได้รับประสบการณ์ Core Web Vitals ดีกว่าหรือแย่กว่าผู้ใช้ที่ออกจากระบบ ผู้ใช้ที่มี LCP ช้ามีองค์ประกอบ LCP ที่เฉพาะเจาะจงหรือไม่ การโต้ตอบใดทําให้ค่า FID และ INP สูง
PageSpeed Insights (PSI)
PSI เป็นเครื่องมือที่รายงานข้อมูลในช่องจาก CrUX และห้องทดลองจาก Lighthouse สําหรับหน้าหนึ่งๆ ดูรายละเอียดเพิ่มเติมได้ในส่วนนั้นๆ
กรณีที่ควรใช้ PSI
PSI เหมาะสําหรับการประเมินประสิทธิภาพ CrUX ที่ระดับหน้าเว็บหรือระดับต้นทางสําหรับทั้งผู้ใช้อุปกรณ์เคลื่อนที่และเดสก์ท็อป เครื่องมือนี้เหมาะสําหรับภาพรวมเบื้องต้นของ Core Web Vitals สําหรับหน้าเว็บหรือเว็บไซต์ รวมถึงให้คุณดูข้อมูล Core Web Vitals ของเว็บไซต์อื่นๆ เช่น เว็บไซต์ของคู่แข่งได้ด้วย
PSI ยังมีข้อมูล Lighthouse ซึ่งให้คําแนะนําที่เป็นประโยชน์ในการปรับปรุง Core Web Vitals หากเมตริกสอดคล้องกัน หากข้อมูลเหล่านี้ไม่สอดคล้องกัน คำแนะนำของ Lighthouse อาจมีความเกี่ยวข้องน้อยลง
เนื่องจาก Lighthouse ทำงานจากเซิร์ฟเวอร์ จึงสร้างเส้นฐานที่สอดคล้องกันมากกว่าการเรียกใช้ Lighthouse จากเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
กรณีที่ไม่ควรใช้ PSI
PSI ใช้ได้กับ URL สาธารณะเท่านั้น จะใช้กับเว็บไซต์สำหรับการพัฒนาที่เข้าถึงไม่ได้แบบสาธารณะไม่ได้
ข้อมูล CrUX จะพร้อมใช้งานก็ต่อเมื่อเว็บไซต์มีคุณสมบัติตรงตามเกณฑ์การมีสิทธิ์บางประการ รวมถึงเกณฑ์ความนิยมของเว็บไซต์ PSI จะมีประโยชน์น้อยลงเมื่อไม่มีข้อมูล CrUX สําหรับหน้าเว็บหรือต้นทาง เนื่องจากจะแสดงได้เฉพาะข้อมูลห้องทดลองของ Lighthouse ในกรณีเหล่านี้
ในทํานองเดียวกัน หากคุณมีข้อมูล CrUX ระดับต้นทางเท่านั้น ไม่ใช่ URL ที่เฉพาะเจาะจงซึ่งทดสอบอยู่ ก็จะจำกัดประโยชน์ของการเชื่อมโยงข้อมูลภาคสนามระดับต้นทางกับการวินิจฉัยระดับห้องทดลอง การมีข้อมูลในช่องระดับต้นทางยังคงเป็นข้อมูลที่มีประโยชน์มากสำหรับใช้เป็นข้อมูลสรุปเกี่ยวกับประสิทธิภาพของเว็บไซต์ และการตรวจสอบ Lighthouse อาจช่วยได้ แต่ควรใช้ความระมัดระวังเป็นพิเศษในกรณีนี้
สุดท้าย เมื่อข้อมูลระดับหน้าเว็บมีอยู่ใน CrUX แต่แตกต่างจากข้อมูลใน Lighthouse Lab คำแนะนำจาก Lighthouse อาจมีประโยชน์อย่างจำกัด กรณีนี้อาจเกิดขึ้นได้กับปัญหา CLS หลังการโหลด และ Core Web Vitals ของการโต้ตอบ (FID และ INP) ซึ่งการตรวจสอบจากห้องทดลองไม่ค่อยมีประโยชน์
Search Console
Search Console จะวัดการเข้าชมและประสิทธิภาพของ Search ในเว็บไซต์ รวมถึง Core Web Vitals ฟีเจอร์นี้พร้อมให้บริการแก่เจ้าของเว็บไซต์ที่ยืนยันการเป็นเจ้าของเว็บไซต์แล้วเท่านั้น
ฟีเจอร์ที่มีประโยชน์ของ Search Console คือการจัดกลุ่มหน้าเว็บที่คล้ายกัน (เช่น หน้าเว็บที่ใช้เทมเพลตเดียวกัน) ไว้ในการประเมินกลุ่มเดียว นอกจากนี้ Search Console ยังมีรายงาน Core Web Vitals โดยอิงตามข้อมูลในช่องจาก CrUX ด้วย
กรณีที่ควรใช้ Search Console
Search Console เหมาะสําหรับทั้งนักพัฒนาซอฟต์แวร์และผู้ที่อยู่ในบทบาทที่ไม่ใช่นักพัฒนาซอฟต์แวร์ในการประเมินทั้งประสิทธิภาพการค้นหาและหน้าเว็บในลักษณะที่เครื่องมืออื่นๆ ของ Google ไม่มี การนําเสนอข้อมูล CrUX และการจัดกลุ่มหน้าเว็บตามความคล้ายคลึงกันจะให้ข้อมูลเชิงลึกใหม่ๆ เกี่ยวกับผลกระทบที่การปรับปรุงประสิทธิภาพมีต่อหน้าเว็บทั้งหมวดหมู่
กรณีที่ไม่ควรใช้ Search Console
Search Console อาจไม่เหมาะกับโปรเจ็กต์ที่ใช้เครื่องมือของบุคคลที่สามที่แบ่งกลุ่มหน้าเว็บตามความคล้ายคลึงกัน หรือหากเว็บไซต์ไม่แสดงในชุดข้อมูล CrUX
การจัดกลุ่มหน้าเว็บอาจทําให้สับสนได้เมื่อหน้าตัวอย่างในกลุ่มมีลักษณะแตกต่างจากกลุ่มอื่นๆ เช่น หากกลุ่มไม่ผ่าน Core Web Vitals บางรายการโดยรวม แต่หน้าตัวอย่างทั้งหมดดูเหมือนจะผ่าน Core Web Vitals รายการเดียวกัน กรณีนี้อาจเกิดขึ้นเมื่อกลุ่มมีหน้าเว็บที่มีจำนวนการเข้าชมน้อยมากหรือหน้าเว็บที่มีการเข้าชมนานๆ ครั้ง ซึ่งอาจโหลดช้ากว่า เนื่องจากมีแนวโน้มที่จะแคชน้อย เมื่อหน้าเหล่านี้มีปริมาณมากพอในรายการส่วนน้อย หน้าเหล่านี้อาจส่งผลต่ออัตราการผ่านโดยรวมของกลุ่ม
ประภาคาร
Lighthouse เป็นเครื่องมือห้องทดลองที่มอบโอกาสที่เฉพาะเจาะจงในการปรับปรุงประสิทธิภาพหน้าเว็บ นอกจากนี้ เส้นทางของผู้ใช้ Lighthouse ยังช่วยให้นักพัฒนาซอฟต์แวร์เขียนสคริปต์เส้นทางการโต้ตอบสำหรับการทดสอบประสิทธิภาพนอกเหนือจากการโหลดหน้าเว็บได้ด้วย
Lighthouse-CI เป็นเครื่องมือที่เกี่ยวข้องซึ่งจะเรียกใช้ Lighthouse ระหว่างการสร้างและติดตั้งใช้งานโปรเจ็กต์เพื่อช่วยในการทดสอบการถดถอยของประสิทธิภาพ โดยจะแสดงรายงาน Lighthouse พร้อมกับคำขอดึงข้อมูล และติดตามเมตริกประสิทธิภาพเมื่อเวลาผ่านไป
กรณีที่ควรใช้ Lighthouse
Lighthouse เหมาะอย่างยิ่งในการค้นหาโอกาสในการปรับปรุงประสิทธิภาพระหว่างการพัฒนาทั้งในสภาพแวดล้อมในเครื่องและในสภาพแวดล้อมการทดสอบ Lighthouse CI ยังมีประโยชน์ในเฟสการสร้างและทำให้ใช้งานได้ในสภาพแวดล้อมการทดสอบและเวอร์ชันที่ใช้งานจริง ซึ่งจำเป็นต้องมีการทดสอบรีเกรชันด้านประสิทธิภาพเพื่อรักษาประสบการณ์ของผู้ใช้ที่ดี
เมื่อใดที่ไม่ควรใช้ Lighthouse
Lighthouse (หรือ Lighthouse CI) ไม่ใช่ข้อมูลทดแทนสำหรับข้อมูลภาคสนาม Lighthouse เป็นเครื่องมือวินิจฉัยหลักที่แสดงปัญหาที่อาจเกิดขึ้นและแนวทางปฏิบัติแนะนำจากการโหลดหน้าเว็บที่กำหนดไว้ล่วงหน้า คำแนะนำที่แสดงอาจไม่ตรงกับประสิทธิภาพที่ผู้ใช้ได้รับเสมอไป
แม้ว่า Lighthouse จะใช้วินิจฉัยเว็บไซต์เวอร์ชันที่ใช้งานจริงผ่านเครื่องมืออย่าง PageSpeed Insights ได้ แต่เราขอแนะนำให้ใช้ Lighthouse ในสภาพแวดล้อมการพัฒนาและการผสานรวมอย่างต่อเนื่องเพื่อแก้ไขปัญหาด้านประสิทธิภาพก่อนที่จะนำไปใช้งานจริง
การตรวจสอบที่ Lighthouse มีให้ยังดูผ่าน "ข้อมูลเชิงลึก" ในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ได้ด้วย ซึ่งจะให้การวิเคราะห์ประสิทธิภาพของหน้าเว็บอย่างละเอียดยิ่งขึ้น
แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome คือชุดเครื่องมือสำหรับการพัฒนาในเบราว์เซอร์ ซึ่งรวมถึงแผงประสิทธิภาพ แผงประสิทธิภาพเป็นเครื่องมือทดสอบที่มี "โหมด" 2 โหมด ได้แก่
เมื่อเปิดแผงประสิทธิภาพเป็นครั้งแรก หน้าจอเมตริกแบบเรียลไทม์จะแสดงเมตริก Core Web Vitals ปัจจุบัน พร้อมความสามารถในการนําเข้าข้อมูลภาคสนามจาก CrUX ซึ่งมีประโยชน์ในฐานะมุมมอง "แบบเรียลไทม์" ของประสิทธิภาพขณะที่คุณโต้ตอบกับหน้าเว็บเพื่อพยายามค้นหาปัญหาด้านประสิทธิภาพ โดยเฉพาะปัญหาหลังการโหลดที่คุณอาจเห็นในเมตริก CLS และ INP
ประการที่ 2 แผงประสิทธิภาพช่วยให้นักพัฒนาซอฟต์แวร์บันทึกโปรไฟล์ (หรือร่องรอย) ของกิจกรรมทั้งหมดในหน้าเว็บระหว่างการโหลดหน้าเว็บหรือระยะเวลาที่บันทึกไว้ มุมมองนี้ให้ข้อมูลเชิงลึกที่ละเอียดเกี่ยวกับทุกสิ่งที่สังเกตเห็นในมิติข้อมูลต่างๆ เช่น กิจกรรมในเครือข่าย การแสดงผล การวางภาพ และการสร้างสคริปต์ รวมถึง Core Web Vitals ของหน้าเว็บ รวมถึงข้อมูลเชิงลึกที่คล้ายกับที่ Lighthouse มีให้
กรณีที่ควรใช้แผงประสิทธิภาพ
นักพัฒนาซอฟต์แวร์ควรใช้แผงประสิทธิภาพเพื่อให้ได้ข้อมูลเชิงลึกที่ละเอียดเกี่ยวกับประสิทธิภาพของหน้าเว็บหนึ่งๆ
มุมมองเมตริกแบบเรียลไทม์ช่วยให้คุณเข้าใจลักษณะประสิทธิภาพปัจจุบันของหน้าเว็บได้อย่างรวดเร็ว และยังสามารถตรวจหาปัญหาที่อาจเกิดขึ้นขณะที่ผู้ใช้โต้ตอบกับหน้าเว็บ
มุมมองการติดตามจะมีประโยชน์อย่างยิ่งในการแก้ไขข้อบกพร่องเกี่ยวกับความรวดเร็วในการตอบสนองที่ส่งผลต่อ INP เมื่อพบการโต้ตอบที่ตอบสนองช้าและเกิดซ้ำได้ แผงประสิทธิภาพจะแสดงข้อมูลมากมายเกี่ยวกับสิ่งที่เกิดขึ้นในเบราว์เซอร์เพื่อช่วยให้คุณเข้าใจปัญหา ตั้งแต่การบล็อกเธรดหลัก ไปจนถึงสแต็กการเรียกใช้ JavaScript และงานการแสดงผล
เมื่อใดที่ไม่ควรใช้แผงประสิทธิภาพ
แผงประสิทธิภาพเป็นเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ซึ่งให้ข้อมูลการทดสอบเป็นหลัก แต่ก็มีบริบทในช่องบางส่วนจาก CrUX ด้วย ข้อมูลนี้ไม่ได้ใช้แทนข้อมูลภาคสนาม
มุมมองการติดตามมีข้อมูลการแก้ไขข้อบกพร่องจำนวนมาก แต่อาจทําให้นักพัฒนาซอฟต์แวร์มือใหม่หรือผู้ที่ไม่ได้เป็นนักพัฒนาซอฟต์แวร์เข้าใจได้ยาก อย่างไรก็ตาม มุมมองเมตริกแบบเรียลไทม์ที่แผงเปิดขึ้นจะแก้ไขปัญหานี้ด้วยอินเทอร์เฟซที่ใช้งานง่ายขึ้นสําหรับผู้ที่ไม่จําเป็นต้องดูรายละเอียดทั้งหมด
เวิร์กโฟลว์ 3 ขั้นตอนเพื่อให้ Core Web Vitals ของเว็บไซต์ทำงานได้อย่างมีประสิทธิภาพ
เมื่อพยายามปรับปรุงประสบการณ์ของผู้ใช้ คุณควรคิดว่ากระบวนการนี้เป็นวงจรที่ดำเนินอย่างต่อเนื่อง วิธีหนึ่งในการปรับปรุง Core Web Vitals และเมตริกประสิทธิภาพอื่นๆ อาจเป็นดังนี้
- ประเมินประสิทธิภาพของเว็บไซต์และระบุจุดเจ็บปวด
- แก้ไขข้อบกพร่องและเพิ่มประสิทธิภาพ
- ตรวจสอบด้วยเครื่องมือการผสานรวมอย่างต่อเนื่องเพื่อตรวจหาและป้องกันความถดถอย

ขั้นตอนที่ 1: ประเมินประสิทธิภาพของเว็บไซต์และหาโอกาสในการปรับปรุง
วิธีที่ดีที่สุดคือเริ่มต้นด้วยข้อมูลภาคสนามเพื่อประเมินประสิทธิภาพของเว็บไซต์
- ใช้ PageSpeed Insights เพื่อดูเมตริกประสบการณ์การใช้งาน Core Web Vitals โดยรวมในต้นทาง และข้อมูลเฉพาะของ URL แต่ละรายการ
- Search Console มีประโยชน์ในการระบุหน้าเว็บที่ต้องปรับปรุงเมื่อฟีเจอร์การจัดกลุ่มหน้าเว็บทำงานได้ดีกับเว็บไซต์ของคุณ
- หากมีข้อมูล RUM ตัวเลือกนี้มักเป็นตัวเลือกที่ดีที่สุดในการระบุหน้าเว็บหรือกลุ่มการเข้าชมที่มีปัญหา
ไม่ว่าคุณจะวิเคราะห์ข้อมูลภาคสนามที่รวบรวมเองหรือข้อมูล CrUX ขั้นตอนแรกนี้ถือเป็นขั้นตอนสําคัญ หากคุณไม่ได้รวบรวมข้อมูลภาคสนาม ข้อมูล CrUX ก็อาจเพียงพอที่จะใช้เป็นแนวทางได้ ในกรณีที่เว็บไซต์ของคุณแสดงอยู่ในชุดข้อมูล
วิเคราะห์ประสิทธิภาพเว็บไซต์ด้วย PageSpeed Insights

PageSpeed Insights จะแสดงข้อมูล CrUX ที่ครอบคลุมข้อมูลประสบการณ์ของผู้ใช้ในช่วง 28 วันที่ผ่านมาที่เปอร์เซ็นต์ไทล์ที่ 75 ซึ่งหมายความว่าหากประสบการณ์ของผู้ใช้ 75% เป็นไปตามเกณฑ์ที่ตั้งไว้สําหรับเมตริกหนึ่งๆ ระบบจะถือว่าประสบการณ์นั้น "ดี"
หากต้องการดูประสิทธิภาพของหน้าเว็บใดหน้าหนึ่งโดยเฉพาะ ให้ใช้หน้านั้น หากต้องการดูภาพรวมของเว็บไซต์เมื่อเริ่มเพิ่มประสิทธิภาพเป็นครั้งแรก คุณอาจต้องเริ่มที่หน้าแรก เนื่องจากหน้าแรกมักเป็นหนึ่งในหน้ายอดนิยมในหลายเว็บไซต์
ในช่วงแรก ให้มุ่งเน้นที่ส่วนประสบการณ์ที่ผู้ใช้จริงได้รับของ PSI คุณจะเห็นข้อมูลในมุมมองได้สูงสุด 4 มุมมอง ได้แก่ อุปกรณ์เคลื่อนที่และเดสก์ท็อปสําหรับ URL ที่ป้อนและต้นทางทั้งหมด เปรียบเทียบข้อมูลเหล่านี้และดูว่าแตกต่างกันอย่างไร โดยทั่วไปแล้ว อุปกรณ์เคลื่อนที่มีประสิทธิภาพต่ำกว่าเดสก์ท็อป เนื่องจากเป็นอุปกรณ์ที่มีทรัพยากรจํากัดมากกว่าและทํางานภายใต้สภาพเครือข่ายที่อาจไม่เสถียร หาก URL และข้อมูลต้นทางแตกต่างกันมาก ให้ลองหาสาเหตุว่าทำไม หน้าแรกมักเป็นหน้าแรกที่เข้าชม (นั่นคือหน้า Landing Page) จึงอาจช้ากว่าหน้าต้นทางเนื่องจากผู้ใช้ต้นทางต้องแบกรับภาระทั้งหมดของแคชเบราว์เซอร์ที่ไม่ได้เตรียมไว้ หน้าเว็บต่อๆ ไปมีแนวโน้มที่จะโหลดเร็วขึ้น เนื่องจากระบบจะแคชชิ้นงานที่แชร์ไว้ ซึ่งจะลดข้อมูลระดับแหล่งที่มาแบบรวม
นอกจากนี้ PSI ยังแสดง Core Web Vitals ทั้ง 3 รายการ (LCP, CLS และ INP) รวมถึงเมตริก TTFB และ FCP ที่ใช้วินิจฉัย Core Web Vitals ใดไม่เป็นไปตามเกณฑ์ และต่ำกว่าเกณฑ์มากน้อยเพียงใด ซึ่งจะช่วยให้คุณทราบว่าควรมุ่งเน้นที่ส่วนใด
ทําความเข้าใจความสัมพันธ์ระหว่างตัวเลขเหล่านี้ โดยเฉพาะ LCP หาก LCP ช้า ดังที่แสดงในตัวอย่างนี้ ให้ดูที่ TTFB และ FCP ซึ่งเป็นทั้งเหตุการณ์สำคัญและเมตริกนั้น ในตัวอย่างนี้ TTFB ของเราคือ 1.8 วินาที ซึ่งจะทำให้การบรรลุเกณฑ์ที่แนะนํา 2.5 วินาทีสําหรับ LCP ที่ดีนั้นเป็นไปได้ยากมาก ข้อมูลนี้บ่งชี้ว่าแบ็กเอนด์ทำงานช้า (ปัญหาเซิร์ฟเวอร์หรือไม่มี CDN) เครือข่ายช้า หรือการเปลี่ยนเส้นทางทำให้ไบต์ HTML แรกล่าช้า ดูข้อมูลเพิ่มเติมได้ที่คู่มือเพิ่มประสิทธิภาพ TTFB FCP จะใช้เวลาอีก 1 วินาที ซึ่งอาจบ่งบอกถึงเครือข่ายที่ช้าลง LCP อยู่หลัง FCP ในตัวอย่างนี้ไม่นาน ซึ่งหมายความว่าทรัพยากร LCP ได้รับการเพิ่มประสิทธิภาพอย่างดีเมื่อหน้าเว็บโหลด นอกจากนี้ CrUX ยังแสดงข้อมูลการวินิจฉัยเพิ่มเติมในประเภททรัพยากรและส่วนย่อย ซึ่งช่วยในการวินิจฉัยปัญหา LCP ด้วย
สําหรับ CLS ให้ดูคะแนน CLS ของ CrUX และ CLS ของ Lighthouse เพื่อดูว่านี่เป็นปัญหา CLS ในการโหลด (ซึ่ง Lighthouse จะตรวจพบและให้คําแนะนํา) หรือปัญหา CLS หลังการโหลดที่ Lighthouse จะไม่ตรวจพบ ดูข้อมูลเพิ่มเติมได้ที่คู่มือ CLS ของ Optimize
ดูการตอบสนองได้ที่คะแนน INP ดูการตรวจสอบ TBT ใน Lighthouse เพื่อดูว่ามีการประมวลผล JavaScript จำนวนมากเกิดขึ้นระหว่างการโหลดหน้าเว็บครั้งแรกหรือไม่ ซึ่งอาจส่งผลต่อ INP INP เป็นเมตริกที่ปรับปรุงได้ยาก ดังนั้นโปรดดูข้อมูลเพิ่มเติมในคู่มือเพิ่มประสิทธิภาพ INP
ระบุหน้าเว็บที่มีประสิทธิภาพต่ำใน Search Console

แม้ว่า PSI จะมีประโยชน์เมื่อคุณมี URL ที่เฉพาะเจาะจงที่ต้องการทดสอบหรือทั้งเว็บไซต์ แต่ Search Console ก็สามารถช่วยคุณมุ่งเน้นไปที่หน้าเว็บบางประเภทได้ วิธีนี้มีประโยชน์อย่างยิ่งหากหน้าเว็บหลายหน้าใช้ธีมหรือเทคโนโลยีเดียวกัน และ Search Console ระบุธีมหรือเทคโนโลยีเหล่านี้ได้
รายงาน Core Web Vitals ใน Search Console แสดงภาพรวมของประสิทธิภาพเว็บไซต์ แต่คุณยังคงเจาะลึกหน้าเว็บที่เฉพาะเจาะจงซึ่งต้องดำเนินการได้ นอกจากนี้ คุณยังทําสิ่งต่อไปนี้ได้ด้วย Search Console
- ระบุกลุ่มหน้าเว็บแต่ละกลุ่มที่ต้องปรับปรุงและกลุ่มที่มอบประสบการณ์การใช้งานที่ดีแก่ผู้ใช้
- ดูข้อมูลแบบละเอียดเกี่ยวกับประสิทธิภาพตาม URL ซึ่งจัดกลุ่มตามสถานะ เมตริก และกลุ่มหน้าเว็บที่คล้ายกัน (เช่น หน้ารายละเอียดผลิตภัณฑ์ในเว็บไซต์อีคอมเมิร์ซ)
- รับรายงานแบบละเอียดที่จัดกลุ่ม URL ไว้ในหมวดหมู่คุณภาพของประสบการณ์ของผู้ใช้แต่ละหมวดหมู่สําหรับทั้งอุปกรณ์เคลื่อนที่และเดสก์ท็อป
เมื่อคุณมีหน้าเว็บที่เฉพาะเจาะจงที่จะดูแล้ว คุณสามารถใช้ PSI ตามที่อธิบายไว้ก่อนหน้านี้เพื่อรวบรวมความเข้าใจเพิ่มเติมเกี่ยวกับปัญหาของหน้าเว็บเหล่านั้น
ขั้นตอนที่ 2: แก้ไขข้อบกพร่องและเพิ่มประสิทธิภาพ
ในขั้นตอนที่ 1 คุณควรระบุหน้าเว็บที่ต้องปรับปรุงประสิทธิภาพ รวมถึงเมตริก Core Web Vitals ที่ต้องการปรับปรุง คุณสามารถใช้เครื่องมือของ Google เพื่อรับข้อมูลเพิ่มเติมเพื่อทำความเข้าใจสาเหตุของปัญหา
- ดูการตรวจสอบ Lighthouse เพื่อรับคำแนะนำระดับสูงสำหรับหน้าเว็บ
- ใช้มุมมองเมตริกแบบเรียลไทม์ของแผงประสิทธิภาพเพื่อวิเคราะห์ Core Web Vitals แบบเรียลไทม์
- ใช้การติดตามของแผงประสิทธิภาพเพื่อแก้ไขข้อบกพร่องด้านประสิทธิภาพและทดสอบการเปลี่ยนแปลงโค้ด
ดูคําแนะนําโดยละเอียดได้ที่คู่มือต่อไปนี้
ค้นพบโอกาสด้วย Lighthouse
PageSpeed Insights จะเรียกใช้ Lighthouse ให้คุณ นอกจากนี้ คุณยังเรียกใช้ Lighthouse จากเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ได้ด้วย ซึ่งมีประโยชน์ในการยืนยันการแก้ไขในเครื่อง แต่แผงประสิทธิภาพ (จะกล่าวถึงในลำดับถัดไป) เป็นเครื่องมือที่ครอบคลุมมากขึ้นในการระบุและแก้ไขปัญหาด้านประสิทธิภาพในเครื่อง
ประเด็นสำคัญคือต้องตรวจสอบว่าการตรวจสอบ Lighthouse แสดงปัญหาที่คุณพยายามแก้ไข (เช่น LCP ที่ช้าหรือปัญหา CLS) เมื่อใช้งาน Lighthouse ทันทีหลังติดตั้งใช้งาน เครื่องมือจะประเมินเฉพาะประสบการณ์ของผู้ใช้ระหว่างการโหลดหน้าเว็บ เนื่องจากเป็นเครื่องมือทดสอบ จึงจะไม่รวม INP ไว้ด้วยและจะใช้ TBT แทน
เมื่อเมตริก Lighthouse ระบุปัญหาที่คล้ายกับปัญหาที่คุณพยายามแก้ไข ข้อมูลอันมากมายในการตรวจสอบจะช่วยระบุปัญหาและแนะนำวิธีแก้ปัญหาได้
คุณสามารถกรองการตรวจสอบให้แสดงเฉพาะ Core Web Vitals ที่คุณสนใจเพื่อมุ่งเน้นการแก้ไขปัญหาที่เกี่ยวข้องกับเมตริกที่เฉพาะเจาะจงได้ โดยทำดังนี้

สําหรับ INP ให้ใช้การตรวจสอบ TBT เพื่อระบุปัญหาที่อาจส่งผลต่อเมตริกเหล่านั้น แต่โปรดทราบว่า Lighthouse จะวินิจฉัยได้เพียงเล็กน้อยหากไม่มีอินเทอร์แอกชัน
วิเคราะห์แบบเรียลไทม์ด้วยหน้าจอเมตริกแบบเรียลไทม์ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
หน้าจอเมตริกแบบเรียลไทม์ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ในแผงประสิทธิภาพจะแสดง Core Web Vitals แบบเรียลไทม์ขณะโหลดหน้าเว็บ และขณะเรียกดูหน้าเว็บ ด้วยเหตุนี้ จึงสามารถบันทึก INP รวมถึงการเปลี่ยนแปลงเลย์เอาต์ที่เกิดขึ้นหลังการโหลด นอกจากนี้ คุณยังดูข้อมูลโดยละเอียดเพิ่มเติมเกี่ยวกับเมตริกแต่ละรายการได้ด้วย โดยทำดังนี้

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

ข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพจะอยู่ในแผงด้านข้างข้อมูลเชิงลึก ซึ่งจะแสดงเมตริก Core Web Vitals พร้อมกับค่าในฟิลด์ของเมตริกเหล่านั้นด้วย (หากมี)
แทร็กการขยับของเลย์เอาต์จะไฮไลต์การขยับของเลย์เอาต์ และการคลิกแทร็กเหล่านี้จะให้รายละเอียดเพิ่มเติมเกี่ยวกับองค์ประกอบที่ขยับสำหรับการแก้ไขข้อบกพร่อง CLS
ช่วงเวลาสําคัญ เช่น LCP จะแสดงในช่วงเวลาที่ด้านล่างของการติดตาม คลิกลิงก์เหล่านี้เพื่อดูรายละเอียดเพิ่มเติม
งานที่มีระยะเวลานาน (ซึ่งอาจทำให้เกิดปัญหา INP) จะไฮไลต์ด้วยรูปสามเหลี่ยมสีแดงในแผนภูมิเปลวไฟด้วย
ฟีเจอร์เหล่านี้ รวมถึงข้อมูลในส่วนอื่นๆ ของแผงประสิทธิภาพจะช่วยคุณพิจารณาว่าการแก้ไขส่งผลต่อ Core Web Vitals ของหน้าเว็บหรือไม่
แก้ไขข้อบกพร่อง Core Web Vitals ในพื้นที่ทำงาน
เครื่องมือห้องทดลองอาจระบุสาเหตุของปัญหา Core Web Vitals ทั้งหมดที่ส่งผลกระทบต่อผู้ใช้ไม่ได้เสมอไป ด้วยเหตุนี้ การเก็บรวบรวมข้อมูลภาคสนามของคุณเองจึงมีความสำคัญอย่างยิ่ง เนื่องจากจะพิจารณาปัจจัยที่ข้อมูลในห้องทดลองไม่สามารถพิจารณาได้
ดูข้อมูลเพิ่มเติมที่แก้ไขข้อบกพร่องด้านประสิทธิภาพในสนาม
ขั้นตอนที่ 3: ตรวจสอบการเปลี่ยนแปลง

เมื่อแก้ไขปัญหาแล้ว คุณต้องตรวจสอบว่าปัญหาได้รับการแก้ไขแล้วและปัญหาใหม่จะไม่รบกวน Core Web Vitals ซึ่งต้องมีการตรวจสอบปัญหาด้านประสิทธิภาพเป็นส่วนหนึ่งของเวิร์กโฟลว์ของนักพัฒนาซอฟต์แวร์เพื่อป้องกันไม่ให้ปัญหาด้านประสิทธิภาพเผยแพร่ไปยังเวอร์ชันที่ใช้งานจริง และตรวจสอบข้อมูลภาคสนามเป็นประจำเพื่อให้แน่ใจว่าเป็นเช่นนั้น
ตรวจสอบคําขอประสิทธิภาพในสภาพแวดล้อมการรวมอย่างต่อเนื่อง (CI)
Lighthouse-CI ช่วยให้คุณเรียกใช้การตรวจสอบ Lighthouse กับโค้ดที่คอมมิตโดยอัตโนมัติเพื่อป้องกันไม่ให้โค้ดมีประสิทธิภาพลดลง ซึ่งสามารถตรวจสอบเวลาในการดำเนินการ (ซึ่งอาจแตกต่างกันไป) หรือเพียงแค่การตรวจสอบประสิทธิภาพ เพื่อเป็นเครื่องมือตรวจสอบโค้ดเพื่อหลีกเลี่ยงแนวทางปฏิบัติที่ไม่ถูกต้อง
ดูแนวโน้มเกี่ยวกับประสิทธิภาพของเว็บไซต์ด้วยข้อมูลภาคสนาม
แม้ว่าคุณควรพยายามตรวจหาและแก้ไขปัญหาด้านประสิทธิภาพทั้งหมดก่อนที่จะนำไปใช้งานจริง แต่การตรวจสอบข้อมูลภาคสนามโดยใช้ RUM ก็เป็นสิ่งจําเป็นเพื่อค้นหาปัญหาที่อาจเกิดขึ้น มีผลิตภัณฑ์ RUM เชิงพาณิชย์จํานวนมากที่จะช่วยแก้ปัญหานี้ได้ ไลบรารี JavaScript ของ web-vitals
สามารถทําการเก็บรวบรวมข้อมูลในช่องของเว็บไซต์ให้ทำงานอัตโนมัติได้ และอาจใช้ข้อมูลนี้เพื่อขับเคลื่อนแดชบอร์ดและการแจ้งเตือนที่กําหนดเอง
สําหรับเว็บไซต์ที่ไม่มีโซลูชัน RUM คุณสามารถใช้เครื่องมือ CrUX ต่างๆ เป็นการวิเคราะห์แนวโน้มพื้นฐานของข้อมูลภาคสนาม
บทสรุป
การสร้างประสบการณ์การใช้งานที่รวดเร็วและน่าพึงพอใจต้องอาศัยแนวคิดที่เน้นประสิทธิภาพเป็นอันดับแรกและใช้เวิร์กโฟลว์เพื่อให้มั่นใจว่างานจะเสร็จสมบูรณ์ การมีเครื่องมือและกระบวนการที่เหมาะสมในการตรวจสอบ แก้ไขข้อบกพร่อง และตรวจสอบจะช่วยให้คุณสร้างประสบการณ์การใช้งานที่ยอดเยี่ยมและอยู่ในเกณฑ์ที่กำหนดไว้สำหรับ Core Web Vitals ที่ดีได้