เครื่องมือฟรี: ประสิทธิภาพ

ทดสอบความเร็วเว็บไซต์

เราโหลดหน้าเว็บของคุณแบบโทรศัพท์ระดับกลางบนเครือข่าย 4G ที่ช้า วัดว่าเนื้อหาหลักปรากฏเร็วแค่ไหนและหน้าเว็บกระตุกเลื่อนมากเพียงใด แล้วแสดงสิ่งที่ทำให้หน้าเว็บหนัก หาก Google มีข้อมูลจากผู้ใช้จริงสำหรับเว็บไซต์ของคุณ คุณจะเห็นข้อมูลนั้นด้วย

ฟรี โดยปกติเสร็จภายในไม่ถึง 1 นาที

สิ่งที่เครื่องมือนี้ตรวจ

  • โทรศัพท์บน 4G ที่ช้า

    หน้าเว็บจะโหลดใน Chromium ในฐานะโทรศัพท์ระดับเดียวกับ Moto G Power (412 × 823) ที่มี latency 150 ms ความเร็วดาวน์โหลดประมาณ 1.6 Mbps อัปโหลด 750 Kbps และ CPU ที่ช้าลง 4× นี่คือโปรไฟล์ที่ Lighthouse ใช้ทดสอบบนมือถือ

  • Largest Contentful Paint

    เวลาที่รูปภาพหรือบล็อกข้อความที่ใหญ่ที่สุดในหน้าจอแรกเรนเดอร์เสร็จ และองค์ประกอบนั้นคืออะไร

  • Cumulative Layout Shift

    เนื้อหาที่มองเห็นเลื่อนตำแหน่งโดยไม่คาดคิดมากเพียงใดระหว่างที่หน้าโหลด

  • Total Blocking Time

    สคริปต์ทำให้เบราว์เซอร์ยุ่งจนตอบสนองต่อการแตะไม่ได้นานเท่าไร โดยรวมส่วนที่เกิน 50 ms ของงานที่ใช้เวลานาน (long task) แต่ละงานเข้าด้วยกัน ค่านี้ใช้ในแล็บแทน Interaction to Next Paint

  • สิ่งที่หน้าเว็บดาวน์โหลด

    จำนวนไบต์และคำขอทั้งหมด แยกเป็นรูปภาพ สคริปต์ CSS และฟอนต์ พร้อมสัดส่วนที่มาจากบุคคลที่สาม

  • รูปภาพที่หนักและไฟล์ที่บล็อกการแสดงผล

    รูปภาพที่ใหญ่เกิน 150 KB หรือกว้างกว่าพื้นที่ที่แสดงมาก และไฟล์ CSS และสคริปต์ที่ทำให้การแสดงผลครั้งแรกล่าช้า

  • ข้อมูลผู้ใช้จริงจาก Chrome

    Chrome UX Report ของ Google สำหรับ origin ของคุณบนโทรศัพท์ที่เปอร์เซ็นไทล์ที่ 75 ได้แก่ LCP, INP และ CLS เมื่อ Google มีปริมาณการเข้าชมเว็บไซต์มากพอ

สิ่งที่ตรวจไม่ได้

  • ให้ตัวเลขเดิมทุกครั้งที่ทดสอบ ผลในแล็บเปลี่ยนไปตามเครือข่าย ภาระของเซิร์ฟเวอร์ และสคริปต์ของบุคคลที่สาม จึงควรเปรียบเทียบแนวโน้มแทนการดูผลครั้งเดียว
  • ให้ผลตรงกับ PageSpeed Insights ทุกประการ ทั้งสองใช้โปรไฟล์โทรศัพท์ที่คล้ายกัน แต่ทำงานบนเครื่องและเครือข่ายต่างกัน
  • วัด INP ในแล็บ INP ต้องอาศัยการโต้ตอบจริง การทดสอบในแล็บจึงแสดง TBT และข้อมูลภาคสนามจะแสดง INP เมื่อมี
  • แสดงข้อมูลภาคสนามของทุกเว็บไซต์ Chrome UX Report ครอบคลุม 28 วันล่าสุด และเฉพาะ origin ที่มีการเข้าชมจาก Chrome มากพอ
  • ทดสอบมากกว่าหนึ่งหน้าที่คุณกรอก รายงานประสิทธิภาพแบบชำระเงินทดสอบหน้าสำคัญ 3 หน้า และจัดลำดับสาเหตุพร้อมวิธีแก้

ทำไมจึงสำคัญ

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

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

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

วิธีอ่านผลลัพธ์

Largest Contentful Paint (LCP)
ดีเมื่อต่ำกว่า 2.5 s และแย่เมื่อเกิน 4 s หากองค์ประกอบ LCP เป็นรูปภาพ ขนาดและลำดับความสำคัญในการโหลดของรูปสำคัญที่สุด หากเป็นข้อความ ให้ดูเว็บฟอนต์และ CSS ที่บล็อกการแสดงผล
Cumulative Layout Shift (CLS)
ดีเมื่อต่ำกว่า 0.1 และแย่เมื่อเกิน 0.25 เป็นคะแนนที่ไม่มีหน่วย ซึ่งรวมว่าพื้นที่บนหน้าจอเลื่อนไปมากเพียงใดและไกลแค่ไหน
Total Blocking Time (TBT)
ดีเมื่อต่ำกว่า 200 ms และแย่เมื่อเกิน 600 ms TBT ที่สูงบ่งชี้ว่าผู้ใช้จริงจะได้รับการตอบสนองต่อการแตะที่ช้า
ไบต์และคำขอ
ไม่มีขีดจำกัดอย่างเป็นทางการ ให้ดูว่าประเภทใดมีสัดส่วนมากที่สุด รูปภาพมักเป็นส่วนที่ใหญ่ที่สุด และสัดส่วนจากบุคคลที่สามที่สูงบ่งชี้ถึงแอป แท็ก และวิดเจ็ต
รูปภาพที่หนัก
รูปภาพแต่ละรูปที่ใหญ่เกิน 150 KB หรือดาวน์โหลดมาในขนาดที่กว้างกว่าที่แสดงมาก พร้อมขนาดไฟล์และขนาดภาพ
ไฟล์ที่บล็อกการแสดงผล
CSS และสคริปต์แบบ synchronous ที่เบราว์เซอร์ต้องดาวน์โหลดก่อนจึงจะแสดงอะไรได้
ข้อมูลภาคสนาม (เปอร์เซ็นไทล์ที่ 75)
ผู้ใช้ Chrome จริงบนโทรศัพท์ในช่วง 28 วันล่าสุด เปอร์เซ็นไทล์ที่ 75 หมายความว่าการโหลดหน้า 3 ใน 4 ครั้งเร็วอย่างน้อยเท่านี้ INP ดีเมื่อต่ำกว่า 200 ms และแย่เมื่อเกิน 500 ms
ไม่มีข้อมูลภาคสนาม
Google มีการเข้าชมจาก Chrome สำหรับ origin ของคุณไม่มากพอ ซึ่งไม่ได้บอกอะไรเกี่ยวกับความเร็วของคุณ ให้ใช้ผลจากการทดสอบในแล็บแทน

วิธีแก้ปัญหาที่พบบ่อยที่สุด

  • รูปภาพ LCP ที่โหลดช้า

    ส่งรูปภาพหลักในขนาดที่แสดงจริงโดยใช้ srcset ในรูปแบบ WebP หรือ AVIF อย่าใช้ lazy-load กับรูปนี้ เพิ่ม fetchpriority="high" และใส่ไว้ใน HTML เป็นองค์ประกอบ img แทนการโหลดจากสคริปต์หรือภาพพื้นหลังใน CSS

  • เนื้อหาที่เลื่อนขณะโหลด

    กำหนดแอตทริบิวต์ width และ height หรือ aspect-ratio ใน CSS ให้รูปภาพ วิดีโอ และเนื้อหาที่ฝังไว้ จองพื้นที่สำหรับแบนเนอร์ ประกาศคุกกี้ และโฆษณา หรือแสดงเป็นโอเวอร์เลย์ที่ไม่ดันเนื้อหาลง สำหรับเว็บฟอนต์ ให้ใช้ font-display: optional หรือฟอนต์สำรองที่ปรับขนาดให้ใกล้เคียงกัน

  • Total Blocking Time สูง

    เริ่มจากลบแอป แท็ก และปลั๊กอินที่ไม่ได้ใช้แล้ว เพราะสคริปต์ของสิ่งเหล่านี้มักยังค้างอยู่แม้เลิกใช้ไปแล้ว โหลดแชต รีวิว และเครื่องมือวิเคราะห์ด้วย defer หรือหลังจากหน้าโต้ตอบได้แล้ว ใน Shopify ให้ตรวจ Online Store › Themes › Customize › App embeds

  • CSS และสคริปต์ที่บล็อกการแสดงผล

    เพิ่ม defer ให้สคริปต์ที่ไม่จำเป็นต้องทำงานก่อนการแสดงผลครั้งแรก ใส่ CSS จำนวนเล็กน้อยที่หน้าจอแรกต้องใช้แบบ inline และนำสไตล์ชีตของฟีเจอร์ที่หน้านั้นไม่ได้ใช้ออก

  • รูปภาพที่หนักเกินไป

    ปรับขนาดรูปภาพก่อนอัปโหลด (กว้างประมาณ 2000 px ก็เพียงพอสำหรับแบนเนอร์เต็มความกว้าง) และบีบอัดไฟล์ Shopify และ WordPress ส่งรูปเวอร์ชันที่เล็กกว่าได้อัตโนมัติเมื่อธีมร้องขอ จึงควรตรวจว่าธีมของคุณใช้ขนาดรูปภาพแบบ responsive

คำถามเกี่ยวกับเครื่องมือนี้

ทำไมผลลัพธ์จึงต่างจาก PageSpeed Insights?

การทดสอบในแล็บขึ้นอยู่กับเครื่อง เครือข่าย และช่วงเวลา PageSpeed Insights รัน Lighthouse บนเซิร์ฟเวอร์ของ Google และจำลองการเชื่อมต่อที่ช้า ส่วนเราจำกัดความเร็ว (throttling) ในเบราว์เซอร์จริง ผลจึงควรอยู่ในช่วงใกล้เคียงกัน ไม่ใช่ตัวเลขเดียวกัน

LCP ที่ดีคือเท่าไร?

2.5 วินาทีหรือน้อยกว่าสำหรับการโหลดหน้าอย่างน้อย 75% ตามข้อมูลของ web.dev หากเกิน 4 วินาทีถือว่าแย่

ทำไมจึงไม่มีข้อมูลจากผู้ใช้จริงสำหรับเว็บไซต์ของฉัน?

Chrome UX Report รวมเฉพาะ origin ที่ค้นพบได้แบบสาธารณะ และมีการเข้าชมมากพอจากผู้ใช้ Chrome ที่แชร์สถิติการใช้งาน เว็บไซต์ขนาดเล็กจำนวนมากไปไม่ถึงระดับนั้น แต่การทดสอบในแล็บยังแสดงสิ่งที่ต้องแก้ได้

ทำไมจึงทดสอบบนโทรศัพท์ที่ช้าแทนเดสก์ท็อป?

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

First Input Delay หายไปไหน?

Interaction to Next Paint (INP) เข้ามาแทนที่ First Input Delay ในฐานะ Core Web Vital เมื่อเดือนมีนาคม 2024 โดย INP พิจารณาความล่าช้าของการโต้ตอบตลอดการเข้าชม ไม่ใช่เฉพาะการโต้ตอบครั้งแรก

แหล่งอ้างอิง

เครื่องมือที่เกี่ยวข้อง

รายงานประสิทธิภาพ ($55 ชำระครั้งเดียว) เริ่มจากการสแกนฟรีแบบเต็ม แล้วเพิ่มจำนวนหน้า สิ่งที่ต้องเปลี่ยนสำหรับทุกปัญหาที่พบ ไฟล์ PDF และการทดสอบซ้ำเพื่อยืนยันการแก้ไข

เกี่ยวกับรายงานประสิทธิภาพ