PageSpeed Insights คืออะไร อ่านคะแนนอย่างไร และต้องได้กี่คะแนนถึงพอ

PageSpeed Insights คือเครื่องมือฟรีของ Google ที่รายงานความเร็วของหน้าเว็บสองแบบในหน้าเดียว คือข้อมูลจากผู้ใช้จริงในช่วง 28 วันล่าสุด และผลทดสอบจำลองจาก Lighthouse พร้อมคะแนน 0 ถึง 100 ตัวเลขที่ควรดูก่อนคือผลประเมิน Core Web Vitals ด้านบนสุดของรายงาน เพราะส่วนนั้นมาจากผู้ใช้จริง ส่วนคะแนนวงกลมสีเขียว ส้ม แดง เป็นผลจากการโหลดหน้าเว็บหนึ่งครั้งในสภาพแวดล้อมจำลอง

บทความนี้อธิบายวิธีอ่านรายงานทีละส่วน ความต่างของข้อมูลสองชุด จุดที่ต้องแก้เมื่อ LCP, INP หรือ CLS ไม่ผ่าน และคำตอบของคำถามที่เจ้าของเว็บถามบ่อยที่สุดว่าต้องได้กี่คะแนนถึงพอ

PageSpeed Insights คืออะไร และรายงานมีอะไรบ้าง

เมื่อวาง URL แล้วกดวิเคราะห์ PageSpeed Insights จะแสดงผลแยกแท็บมือถือกับเดสก์ท็อป แต่ละแท็บมีสองส่วนหลัก

• ส่วนบน "Discover what your real users are experiencing" เป็นข้อมูลภาคสนาม (field data) จาก Chrome User Experience Report หรือ CrUX แสดงค่า LCP, INP, CLS, FCP และ TTFB ซึ่ง Google ระบุว่ายังเป็นตัวชี้วัดเชิงทดลอง พร้อมผลสรุปว่าหน้านี้ผ่านหรือไม่ผ่านการประเมิน Core Web Vitals
• ส่วนล่าง "Diagnose performance issues" เป็นข้อมูลห้องทดลอง (lab data) จาก Lighthouse มีคะแนน 4 หมวด คือ Performance, Accessibility, Best Practices และ SEO ตามด้วยรายการสิ่งที่ควรแก้ เช่น รูปภาพที่ใหญ่เกิน JavaScript ที่ไม่ได้ใช้ หรือทรัพยากรที่บล็อกการแสดงผล

คะแนนหมวด SEO ในรายงานนี้เป็นการตรวจพื้นฐานทางเทคนิคของหน้าเดียว เช่น มี title หรือไม่ ลิงก์อ่านได้หรือไม่ ไม่ได้บอกว่าหน้านั้นจะติดอันดับดีแค่ไหน จึงไม่ควรใช้แทนการตรวจเว็บทั้งระบบ

อ่านคะแนน PageSpeed Insights อย่างไร

คะแนน Performance แบ่งเป็นสามช่วง 90 ถึง 100 เป็นสีเขียว 50 ถึง 89 เป็นสีส้ม และ 0 ถึง 49 เป็นสีแดง ตัวเลขนี้เป็นค่าถ่วงน้ำหนักของตัวชี้วัดห้องทดลอง 5 ตัว และแปลงเป็นจำนวนวินาทีไม่ได้ ตั้งแต่ Lighthouse เวอร์ชัน 10 น้ำหนักเป็นดังนี้

• Total Blocking Time (TBT) น้ำหนัก 30%
• Largest Contentful Paint (LCP) น้ำหนัก 25%
• Cumulative Layout Shift (CLS) น้ำหนัก 25%
• First Contentful Paint (FCP) น้ำหนัก 10%
• Speed Index น้ำหนัก 10%

น้ำหนักชุดนี้บอกลำดับความสำคัญได้ชัด TBT, LCP และ CLS รวมกันคิดเป็น 80% ของคะแนน ถ้าหน้าเว็บมี JavaScript หนักจน TBT สูง การบีบอัดรูปเพิ่มอีกรอบจะขยับคะแนนได้น้อยมาก ส่วนรายการคำแนะนำด้านล่างไม่ได้ถูกนับเป็นคะแนนโดยตรง การแก้รายการเหล่านั้นจะมีผลก็ต่อเมื่อทำให้ค่าตัวชี้วัดทั้ง 5 ตัวดีขึ้น

อีกเรื่องที่ควรรู้คือคะแนนเปลี่ยนได้ทุกครั้งที่กดทดสอบ แม้หน้าเว็บไม่ได้แก้อะไรเลย สาเหตุมีทั้งสภาพเครือข่ายของเครื่องทดสอบ โฆษณาหรือ A/B test ที่แสดงต่างกันในแต่ละรอบ และสคริปต์ภายนอกที่ตอบช้าเร็วไม่เท่ากัน วิธีอ่านที่ปลอดภัยคือทดสอบหลายรอบแล้วดูค่ากลาง

ผลประเมิน Core Web Vitals ผ่านหรือไม่ผ่านดูจากอะไร

PageSpeed Insights ใช้ค่าเปอร์เซ็นไทล์ที่ 75 ของผู้ใช้จริง หมายความว่าการเข้าชมอย่างน้อย 75% ต้องได้ค่าในเกณฑ์ "ดี" หน้าเว็บจะผ่านเมื่อ LCP, INP และ CLS อยู่ในเกณฑ์ดีครบทั้งสามตัว ถ้า INP มีข้อมูลไม่พอ ระบบจะดูเฉพาะ LCP กับ CLS แต่ถ้า LCP หรือ CLS ตัวใดตัวหนึ่งไม่มีข้อมูล หน้านั้นจะประเมินไม่ได้

ข้อมูล field (CrUX) กับ lab (Lighthouse) ต่างกันอย่างไร

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

จุดต่างที่มีผลกับการตีความมีดังนี้

• INP วัดในห้องทดลองไม่ได้ เพราะต้องมีคนกดหรือแตะหน้าเว็บจริง Lighthouse จึงใช้ TBT เป็นตัวแทน ซึ่งวัดแค่ช่วงโหลดหน้า หน้าที่ TBT ดีจึงยังมี INP แย่ได้ ถ้าปัญหาเกิดตอนผู้ใช้เปิดเมนูหรือกดตัวกรองสินค้าหลังหน้าโหลดเสร็จ
• CLS ในห้องทดลองนับเฉพาะช่วงโหลดและส่วนที่เห็นบนจอแรก ส่วน CLS ภาคสนามนับตลอดอายุของหน้า รวมการเลื่อนที่เกิดหลังผู้ใช้สกรอลล์ลงไป
• LCP ภาคสนามได้ประโยชน์จากแคช ผู้ใช้ที่กลับมาซ้ำมีไฟล์อยู่ในเครื่องแล้ว ขณะที่การทดสอบห้องทดลองเริ่มจากแคชว่างทุกครั้ง องค์ประกอบที่ถูกนับเป็น LCP ก็ต่างกันได้ตามขนาดจอและเนื้อหาที่แต่ละคนเห็น
• ข้อมูล field ช้ากว่า เพราะเป็นข้อมูลย้อนหลัง 28 วันที่อัปเดตทุกวัน แก้เว็บวันนี้ ตัวเลขภาคสนามจะค่อย ๆ ขยับตามในสัปดาห์ถัด ๆ ไป ส่วน lab เห็นผลทันทีที่ทดสอบใหม่

แนวทางของ Google คือใช้ข้อมูล field จัดลำดับว่าควรแก้อะไรก่อน เพราะสะท้อนสิ่งที่ผู้ใช้เจอจริง แล้วใช้ข้อมูล lab หาสาเหตุและทดสอบว่าการแก้ได้ผลหรือไม่

ถ้าไม่มีข้อมูลผู้ใช้จริงแสดงขึ้นมา

CrUX เก็บข้อมูลเฉพาะหน้าที่เปิดสาธารณะและมีผู้เข้าชมมากพอ โดย Google ไม่เปิดเผยจำนวนขั้นต่ำ ถ้าหน้านั้นข้อมูลไม่พอ PageSpeed Insights จะสลับไปแสดงข้อมูลระดับ origin ซึ่งรวมทุกหน้าของโดเมนแทน ให้สังเกตปุ่มสลับ "This URL" กับ "Origin" ในรายงานว่ากำลังดูข้อมูลชุดไหน ถ้าทั้งโดเมนยังข้อมูลไม่พอ ส่วนบนจะว่าง และเหลือเฉพาะผล Lighthouse ให้ใช้อ้างอิง

LCP INP CLS แต่ละตัวแก้ที่ไหน

ตารางนี้สรุปเกณฑ์ที่ Google กำหนดสำหรับ Core Web Vitals ทั้งสามตัว และจุดในเว็บที่มักเป็นต้นเหตุ

LCP: เริ่มจากหาว่าองค์ประกอบไหนคือ LCP

ในส่วน Lighthouse จะมีรายการที่ระบุว่าองค์ประกอบใดถูกนับเป็น Largest Contentful Paint ส่วนใหญ่เป็นรูปแบนเนอร์หรือหัวข้อใหญ่ของหน้า เมื่อรู้แล้วให้ไล่ตรวจตามลำดับนี้

• เวลาตอบของเซิร์ฟเวอร์ (TTFB) ถ้าเซิร์ฟเวอร์ตอบช้า ทุกอย่างที่ตามมาก็ช้าหมด จุดแก้อยู่ที่โฮสติ้ง แคชฝั่งเซิร์ฟเวอร์ และ CDN
• รูป LCP ต้องไม่ถูกตั้ง lazy-load ควรอยู่ใน HTML ตั้งแต่แรกเพื่อให้เบราว์เซอร์เจอเร็ว และใส่ fetchpriority="high" ได้เพื่อบอกลำดับความสำคัญ
• ขนาดไฟล์รูป ใช้รูปที่มีขนาดพอดีกับพื้นที่แสดงผล และใช้ฟอร์แมตสมัยใหม่อย่าง WebP หรือ AVIF
• CSS และ JavaScript ใน head ที่บล็อกการแสดงผล ย้ายสิ่งที่ไม่จำเป็นต่อจอแรกไปโหลดทีหลัง

INP: ลดงานของ main thread

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

CLS: จองพื้นที่ไว้ก่อนเนื้อหาจะมา

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

ทำไมคะแนนมือถือต่ำกว่าเดสก์ท็อป

คะแนนมือถือต่ำกว่าเพราะเงื่อนไขทดสอบหนักกว่า และไม่ได้แปลว่าเว็บเวอร์ชันมือถือทำมาแย่กว่า Google อธิบายว่า Lighthouse ทดสอบแท็บมือถือด้วยการจำลองโทรศัพท์ระดับกลางบนเครือข่ายมือถือ ส่วนแท็บเดสก์ท็อปจำลองคอมพิวเตอร์ที่ต่ออินเทอร์เน็ตแบบสาย หน้าเว็บเดียวกัน โค้ดเดียวกัน จึงได้คะแนนต่างกันมาก

ผลกระทบชัดที่สุดอยู่ที่ JavaScript เพราะซีพียูของโทรศัพท์ระดับกลางประมวลผลสคริปต์ช้ากว่าคอมพิวเตอร์มาก TBT จึงพุ่งขึ้น และ TBT มีน้ำหนักมากที่สุดในคะแนน เว็บที่ใช้ธีมสำเร็จรูปพร้อมปลั๊กอินจำนวนมาก หรือเว็บที่เรนเดอร์ทุกอย่างด้วย JavaScript ฝั่งเบราว์เซอร์ จะเห็นช่องว่างระหว่างสองแท็บกว้างเป็นพิเศษ

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

คะแนนต่ำส่งผลต่อ SEO จริงไหม

ส่งผล แต่ไม่ใช่ผ่านคะแนน 0 ถึง 100 Google ระบุในเอกสารของตัวเองว่าระบบจัดอันดับใช้ Core Web Vitals ซึ่งก็คือค่า LCP, INP และ CLS จากผู้ใช้จริง ส่วนคะแนน Performance เป็นผลทดสอบห้องทดลองของ Lighthouse ที่มีไว้ให้นักพัฒนาใช้หาปัญหา

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

นอกจากเรื่องอันดับ หน้าที่โหลดช้าและกดแล้วไม่ตอบสนองทำให้คนปิดหน้าก่อนอ่านหรือก่อนสั่งซื้อ ไม่ว่าจะมาจาก Google โฆษณา หรือลิงก์ใน LINE การแก้ความเร็วจึงได้ผลกับทุกช่องทาง ถ้ากำลังวางแผนงาน SEO ทั้งระบบ ให้นับ Core Web Vitals เป็นหนึ่งในงานเทคนิคร่วมกับการเก็บข้อมูล การทำดัชนี และโครงสร้างเว็บ

ต้องได้กี่คะแนนถึงพอ

เป้าหมายที่ใช้งานได้จริงคือผ่านการประเมิน Core Web Vitals บนมือถือ ไม่ใช่ได้ 100 คะแนน เอกสารของ Google เองระบุว่าการไล่ตามคะแนนเต็มเพื่อเหตุผลด้าน SEO อาจไม่ใช่การใช้เวลาที่คุ้มที่สุด

ลำดับการตั้งเป้าที่สมเหตุสมผลมีดังนี้

1. ทำให้ LCP, INP และ CLS จากผู้ใช้จริงอยู่ในเกณฑ์ดีครบทั้งสามตัว นี่คือเส้นที่ Google ใช้ตัดว่าผ่านหรือไม่ผ่าน
2. ถ้ายังไม่มีข้อมูลผู้ใช้จริง ให้ใช้คะแนน Lighthouse มือถือเป็นตัวแทน คะแนนช่วงสีเขียว (90 ขึ้นไป) เป็นสัญญาณที่ดี แต่หน้าที่ได้ช่วงสีส้มก็ผ่าน Core Web Vitals ได้ ถ้าผู้ใช้จริงมีอุปกรณ์และเครือข่ายที่ดีกว่าเงื่อนไขจำลอง
3. เมื่อผ่านแล้ว ให้เปลี่ยนจากการไล่คะแนนเป็นการเฝ้าระวัง ตรวจซ้ำทุกครั้งที่เพิ่มปลั๊กอิน แท็กการตลาด หรือเปลี่ยนดีไซน์

ตัวอย่างสมมติเพื่อให้เห็นภาพ หน้าสินค้าหน้าหนึ่งได้คะแนน Lighthouse มือถือ 62 แต่ข้อมูลผู้ใช้จริงแสดง LCP 2.1 วินาที INP 160 มิลลิวินาที และ CLS 0.05 หน้านี้ผ่าน Core Web Vitals แล้ว งานที่เหลือคือปรับปรุงเพื่อผู้ใช้ที่เครื่องช้า และไม่มีข้อไหนเร่งด่วนในแง่ SEO กลับกัน ถ้าหน้าได้ 91 คะแนนแต่ INP ของผู้ใช้จริงอยู่ที่ 380 มิลลิวินาที หน้านี้ยังไม่ผ่าน และต้องไปหาว่าการกดปุ่มไหนที่ช้า

ขั้นตอนใช้ PageSpeed Insights ให้ได้ข้อสรุปที่ลงมือทำได้

การทดสอบหน้าแรกหน้าเดียวแล้วสรุปทั้งเว็บเป็นความผิดพลาดที่พบบ่อย เพราะหน้าแรกมักเป็นหน้าที่ถูกดูแลดีที่สุด ขั้นตอนที่ให้ภาพครบกว่ามีดังนี้

1. เลือกหน้าตัวแทนของแต่ละเทมเพลต เช่น หน้าแรก หน้าหมวดสินค้า หน้าสินค้า หน้าบทความ และหน้าฟอร์มติดต่อ ปัญหาความเร็วมักอยู่ที่เทมเพลต แก้ที่เทมเพลตหนึ่งครั้งจึงได้ผลกับทุกหน้าที่ใช้เทมเพลตนั้น
2. ทดสอบแท็บมือถือก่อน จดผลประเมิน Core Web Vitals และค่าตัวชี้วัดที่ไม่ผ่าน
3. เลื่อนลงไปที่ส่วน Lighthouse ใช้ตัวกรอง "Show audits relevant to" เลือกเฉพาะตัวชี้วัดที่มีปัญหา จะเหลือรายการที่ต้องแก้สั้นลงมาก
4. แก้ทีละเรื่อง ทดสอบซ้ำหลายรอบ แล้วเทียบค่าตัวชี้วัดควบคู่กับคะแนนรวม
5. ติดตามข้อมูลผู้ใช้จริงต่อในรายงาน Core Web Vitals ของ Google Search Console ซึ่งจัดกลุ่ม URL ที่มีปัญหาแบบเดียวกันไว้ด้วยกัน

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

สิ่งที่ต้องระวังเป็นพิเศษสำหรับเว็บไซต์ในตลาดไทย

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

ทราฟฟิกจากแอป ลิงก์ที่เปิดจากแอปแชตและโซเชียลมักเปิดในเบราว์เซอร์ที่ฝังอยู่ในแอป CrUX ไม่นับข้อมูลจากแอป Android ที่ใช้ WebView และไม่นับ Chrome บน iOS เว็บที่ลูกค้าส่วนใหญ่มาจากช่องทางเหล่านี้หรือใช้ iPhone จึงอาจเห็นข้อมูลผู้ใช้จริงใน PageSpeed Insights ไม่ตรงกับฐานลูกค้าทั้งหมด ควรอ่านควบคู่กับข้อมูลใน Analytics ของตัวเอง

แท็กการตลาดสะสม เว็บธุรกิจมักติดตั้งพิกเซลโฆษณาหลายแพลตฟอร์ม ปุ่มแชต และป๊อปอัปโปรโมชัน สคริปต์เหล่านี้กระทบ INP และ TBT โดยตรง การทบทวนว่าแท็กไหนยังใช้อยู่ควรเป็นงานประจำ

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

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

PageSpeed Insights ใช้ฟรีหรือไม่

ใช้ฟรีและไม่ต้องเข้าสู่ระบบ เพียงเปิด pagespeed.web.dev วาง URL ที่ต้องการตรวจแล้วกดวิเคราะห์ ตรวจได้ทุกหน้าเว็บที่เปิดสาธารณะ รวมถึงเว็บของคู่แข่ง แต่ข้อมูลผู้ใช้จริงจะแสดงเฉพาะหน้าที่มีผู้เข้าชมมากพอในชุดข้อมูล CrUX

ทำไมทดสอบสองครั้งได้คะแนนไม่เท่ากัน

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

แก้เว็บแล้ว ทำไมข้อมูลผู้ใช้จริงยังไม่เปลี่ยน

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

คะแนน 100 จำเป็นต่อการติดอันดับ Google หรือไม่

ไม่จำเป็น Google ใช้ค่า Core Web Vitals จากผู้ใช้จริงในระบบจัดอันดับ ไม่ได้ใช้คะแนน 0 ถึง 100 ของ Lighthouse และระบุเองว่าผลที่ดีไม่ได้รับประกันอันดับบนสุด เป้าหมายที่คุ้มกว่าคือทำให้ LCP, INP และ CLS ผ่านเกณฑ์ดีบนมือถือ

ควรดูแท็บมือถือหรือเดสก์ท็อปก่อน

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

PageSpeed Insights ให้คำตอบได้เร็วว่าหน้าเว็บช้าตรงไหน ส่วนการตัดสินว่าควรแก้อะไรก่อนและแก้แล้วคุ้มหรือไม่ ต้องดูทั้งเว็บประกอบกัน หากต้องการให้ทีมเทคนิคตรวจความเร็วร่วมกับปัญหาการเก็บข้อมูลและการทำดัชนีในรอบเดียว ดูขอบเขตงานได้ที่หน้า บริการ SEO Audit ของ Relevant Audience