ดูเว็บไซต์ของคุณโหลดผ่านสายตาของผู้เยี่ยมชมของคุณ
รับแนวคิดที่ดีว่าผู้เยี่ยมชมของคุณกำลังประสบอะไรอยู่บ้างเมื่อพวกเขาเยี่ยมชมเว็บไซต์ของคุณ
สังเกตเห็นว่ามีการโหลดช้าหรือไม่อยู่ในตำแหน่ง? ข้อมูลนี้สามารถช่วยคุณระบุความล่าช้าและปัญหา Conversion ที่สำคัญที่ผู้เยี่ยมชมของคุณประสบ
ภาพหน้าจอแสดงผลการทดสอบประสิทธิภาพเว็บ DebugBear ตุลาคม 2022 แถบฟิล์มไทม์ไลน์แสดงความคืบหน้าในการแสดงผลของเว็บไซต์เมื่อเวลาผ่านไป
ตัวอย่างเช่น หน้านี้เริ่มแสดงผลหลังจาก 0.7 วินาที และรูปภาพหลักแสดงผลหลังจาก 1.3 วินาที
เว็บไซต์แสดงผลอย่างสมบูรณ์ หรือที่เรียกว่า Visually Complete เมื่อวิดเจ็ตการแชทปรากฏขึ้นหลังจาก 3.7 วินาที
ภาพหน้าจอของ DebugBear แสดงความคืบหน้าในการแสดงผลของเว็บไซต์เมื่อเวลาผ่านไป ตุลาคม 2022 ภายในเครื่องมือนี้ คุณยังสามารถชมการบันทึกวิดีโอของกระบวนการเรนเดอร์ได้อีกด้วย
นี่เป็นวิธีที่ยอดเยี่ยมในการแสดงผลกระทบของปัญหาด้านประสิทธิภาพต่อลูกค้าหรือสมาชิกคนอื่นๆ ในทีมของคุณ
ภาพหน้าจอแสดงการบันทึกวิดีโอของเว็บไซต์ที่แสดงผลบางส่วนใน DebugBear ตุลาคม 2022 ทดสอบการเปลี่ยนแปลงความเร็วของไซต์โดยดูสถิติการโหลดที่แท้จริงของคุณ
สมมติว่าคุณได้เพิ่มประสิทธิภาพเว็บไซต์ของคุณแล้ว และต้องการทำความเข้าใจว่าการเปลี่ยนแปลงเหล่านั้นจะส่งผลกระทบหรือไม่
เครื่องมือนี้เรียกใช้ "การทดสอบในห้องปฏิบัติการ" ในสภาพแวดล้อมที่เหมาะสมเพื่อดูว่าคุณกำลังเพิ่มประสิทธิภาพไซต์ของคุณอย่างถูกต้องหรือไม่
เมื่อคุณทดสอบไซต์ของคุณ คุณจะได้รับ "คะแนนห้องปฏิบัติการ" อย่างเป็นทางการ ซึ่งเป็นข้อมูลสรุปของตัวชี้วัดประสิทธิภาพหกตัวที่มาจากคะแนนประสิทธิภาพจากเครื่องมือ Lighthouse ของ Google:
- First Contentful Paint (10% ของคะแนนโดยรวม)
- ดัชนีความเร็ว (10%)
- ระบายสีเนื้อหาที่ใหญ่ที่สุด (25%)
- เวลาในการโต้ตอบ (10%)
- เวลาบล็อกทั้งหมด (30%)
- การเปลี่ยนแปลงเค้าโครงสะสม (15%)
เมื่อใช้ข้อมูลนี้ คุณจะพบว่าการเพิ่มประสิทธิภาพรอบล่าสุดมีประโยชน์เพียงใด และสิ่งที่คุณอาจจำเป็นต้องเปลี่ยนแปลง
ถึงตอนนี้ คุณอาจสงสัยว่าคุณต้องเปลี่ยนอะไร มาเรียนรู้วิธีเพิ่มประสิทธิภาพไซต์ของคุณโดยใช้เมตริกหลักแต่ละรายการของภาพรวมเมตริก
วิธีเพิ่มประสิทธิภาพความเร็วเว็บไซต์
การทดสอบความเร็วเป็นส่วนแรกของเส้นทางการเพิ่มประสิทธิภาพเว็บไซต์ของคุณ
เมื่อคุณมีเมตริกแล้ว คุณจะต้องรู้วิธีตีความเมตริกและวิธีแก้ไข
ในพื้นที่ภาพรวมเมตริกของรายงานความเร็วเว็บไซต์ของคุณ คุณจะเห็นเมตริกหลักที่เราจะเน้นเพื่อช่วยเร่งความเร็วเว็บไซต์:
- First Contentful Paint : สิ่งนี้สามารถเร่งความเร็วได้โดยการซ่อมแซมความเร็วในการสื่อสารของเซิร์ฟเวอร์
- Largest Contentful Paint : สิ่งนี้สามารถเร่งความเร็วได้ด้วยการเพิ่มประสิทธิภาพสื่อและทรัพยากร
นอกจากนี้ คุณสามารถใช้ลำดับชั้นของคำขอเพื่อดูว่าคำขอใช้เวลานานเท่าใดและส่งผลต่อเมตริกเหล่านั้นอย่างไร
วิธีเพิ่มความเร็วให้กับ First Contentful Paint (FCP)
เริ่มต้นด้วยการทำให้เว็บไซต์ของคุณปรากฏแก่ผู้เยี่ยมชมของคุณเร็วขึ้น เราจะจัดการกับ First Contentful Paint ก่อน
สีแรกที่น่าพึงพอใจคืออะไร?
First Contentful Paint จะวัดว่าเนื้อหาของหน้าเริ่มปรากฏครั้งแรกเมื่อใดหลังจากที่ผู้เยี่ยมชมของคุณไปที่หน้านั้น
สิ่งสำคัญคือต้องแสดงเนื้อหาหลักอย่างรวดเร็วเพื่อป้องกันไม่ให้ผู้เยี่ยมชมออกจากเว็บไซต์ของคุณ ยิ่งผู้ใช้ออกจากเว็บไซต์ของคุณเร็วเท่าไหร่ Google ก็ยิ่งเรียนรู้ได้เร็วขึ้นว่าประสบการณ์ใช้งานหน้าเว็บอาจไม่ดี
แต่คุณจะทราบได้อย่างไรว่าอะไรเป็นสาเหตุให้เว็บไซต์ของคุณโหลดช้า
คุณจะค้นพบปัญหาเซิร์ฟเวอร์ที่ทำให้เว็บไซต์ของคุณช้าลงได้อย่างไร ลองหา
ทำไมการลงสีครั้งแรกของฉันจึงใช้เวลานานมาก
FCP ของคุณอาจได้รับผลกระทบจากความเร็วในการเชื่อมต่อเซิร์ฟเวอร์ คำขอของเซิร์ฟเวอร์ ทรัพยากรการบล็อกการแสดงผล และอื่นๆ
ดูเหมือนมาก แต่มีวิธีง่าย ๆ ในการ ดูว่า FCP ของคุณช้าลงคืออะไร – น้ำตกที่ร้องขอ
เครื่องมือที่มีประโยชน์นี้จะแสดงคำขอที่เว็บไซต์ของคุณสร้างขึ้น และเมื่อคำขอแต่ละรายการเริ่มต้นและสิ้นสุด
ตัวอย่างเช่น ในภาพหน้าจอนี้ ขั้นแรกเราเห็นคำขอสำหรับเอกสาร HTML จากนั้นจึงส่งคำขอสองรายการเพื่อโหลดสไตล์ชีตที่อ้างอิงถึงในเอกสาร
ภาพหน้าจอแสดงข้อมูลการดีบักสำหรับเมตริก First Contentful Paint ใน DebugBear ตุลาคม 2022 เหตุใด First Contentful Paint จึงเกิดขึ้นหลังจาก 0.6 วินาที เราสามารถแยกย่อยสิ่งที่เกิดขึ้นบนหน้าเพื่อทำความเข้าใจสิ่งนี้
ทำความเข้าใจกับสิ่งที่เกิดขึ้นก่อนการลงสีครั้งแรกอย่างพึงพอใจ
ก่อนที่เนื้อหาชิ้นแรกจะสามารถโหลดขึ้นบนเว็บเพจของคุณได้ เบราว์เซอร์ของผู้ใช้ต้องเชื่อมต่อกับเซิร์ฟเวอร์ของคุณและเรียกค้นเนื้อหานั้นก่อน
หากกระบวนการนี้ใช้เวลานาน ผู้ใช้ของคุณจะมองเห็นเว็บไซต์ของคุณเป็นเวลานาน
เป้าหมายของคุณคือการเรียนรู้สิ่งที่เกิดขึ้นก่อนที่เว็บไซต์ของคุณจะเริ่มโหลด เพื่อให้คุณสามารถระบุปัญหาและเร่งประสบการณ์ได้
หน้าโหลดส่วนที่ 1: เบราว์เซอร์สร้างการเชื่อมต่อเซิร์ฟเวอร์
ก่อนที่จะขอเว็บไซต์จากเซิร์ฟเวอร์ในขั้นแรก เบราว์เซอร์ของผู้เยี่ยมชมของคุณต้องสร้างการเชื่อมต่อเครือข่ายกับเซิร์ฟเวอร์นั้น
โดยปกติจะใช้เวลาสามขั้นตอน:
- การตรวจสอบระเบียน DNS เพื่อค้นหาที่อยู่ IP ของเซิร์ฟเวอร์ตามชื่อโดเมน
- การสร้างการเชื่อมต่อเซิร์ฟเวอร์ที่เชื่อถือได้ (เรียกว่าการเชื่อมต่อ TCP)
- การสร้างการเชื่อมต่อเซิร์ฟเวอร์ที่ปลอดภัย (เรียกว่าการเชื่อมต่อ SSL)
เบราว์เซอร์ดำเนินการสามขั้นตอนเหล่านี้ทีละรายการ แต่ละขั้นตอนต้องมีการเดินทางไปกลับจากเบราว์เซอร์ของผู้เยี่ยมชมไปยังเซิร์ฟเวอร์ของเว็บไซต์ของคุณ
ในกรณีนี้ จะใช้เวลาประมาณ 251 มิลลิวินาทีในการสร้างการเชื่อมต่อเซิร์ฟเวอร์
ภาพหน้าจอ DebugBear แสดงการเดินทางไปกลับของเครือข่ายที่ใช้ในการสร้างการเชื่อมต่อเซิร์ฟเวอร์ ตุลาคม 2022 หน้าโหลดส่วนที่ 2: เบราว์เซอร์ร้องขอเอกสาร HTML (เวลาสำหรับไบต์แรกเกิดขึ้นที่นี่)
เมื่อสร้างการเชื่อมต่อเซิร์ฟเวอร์แล้ว เบราว์เซอร์ของผู้เยี่ยมชมสามารถขอรหัส HTML ที่มีเนื้อหาของเว็บไซต์ของคุณได้ สิ่งนี้เรียกว่าคำขอ HTTP
ในกรณีนี้ คำขอ HTTP ใช้เวลา 102 มิลลิวินาที ระยะเวลานี้รวมทั้งเวลาที่ใช้ในการเดินทางไปกลับของเครือข่ายและเวลาที่ใช้ในการรอเซิร์ฟเวอร์เพื่อสร้างการตอบกลับ
หลังจาก 251 มิลลิวินาทีในการสร้างการเชื่อมต่อและ 102 มิลลิวินาทีเพื่อส่งคำขอ HTTP ในที่สุดเบราว์เซอร์ของผู้เยี่ยมชมของคุณสามารถเริ่มดาวน์โหลดการตอบกลับ HTML ได้
เหตุการณ์สำคัญนี้เรียกว่า Time to First Byte (TTFB) ในกรณีนี้ จะเกิดขึ้นหลังจากทั้งหมด 353 มิลลิวินาที
หลังจากที่เซิร์ฟเวอร์ตอบกลับพร้อมแล้ว เบราว์เซอร์ของผู้เยี่ยมชมจะใช้เวลาเพิ่มเติมในการดาวน์โหลดโค้ด HTML ในกรณีนี้ การตอบสนองค่อนข้างน้อย และการดาวน์โหลดใช้เวลาเพิ่มอีก 10 มิลลิวินาทีเท่านั้น
ภาพหน้าจอ DebugBear แสดงส่วนประกอบต่างๆ ของคำขอ HTTP ตุลาคม 2022 ส่วนที่โหลดหน้า 3: เว็บไซต์ของคุณโหลดทรัพยากรการบล็อกการแสดงผลเพิ่มเติม
เบราว์เซอร์ไม่แสดงหรือแสดงหน้าทันทีหลังจากโหลดเอกสาร แต่มักจะมีทรัพยากรการบล็อกการแสดงผลเพิ่มเติมแทน
หน้าส่วนใหญ่จะดูแย่หากไม่มีการจัดรูปแบบภาพ ดังนั้นสไตล์ชีต CSS จะถูกโหลดก่อนที่หน้าจะเริ่มแสดงผล
การโหลดสไตล์ชีตเพิ่มเติม 2 รายการในตัวอย่างการทดสอบความเร็วเว็บไซต์นี้ใช้เวลา 137 มิลลิวินาที
โปรดทราบว่าคำขอเหล่านี้ไม่ต้องการการเชื่อมต่อเซิร์ฟเวอร์ใหม่ ไฟล์ CSS ถูกโหลดจากโดเมนเดียวกันกับเมื่อก่อน และสามารถใช้การเชื่อมต่อที่มีอยู่ซ้ำได้
ภาพหน้าจอ DebugBear แสดงทรัพยากรการบล็อกการแสดงผลเพิ่มเติมที่โหลดหลังจากเอกสาร HTML ตุลาคม 2022 หน้าโหลดส่วนที่ 4: เบราว์เซอร์แสดงผลหน้า
สุดท้าย เมื่อโหลดทรัพยากรที่จำเป็นทั้งหมดแล้ว เบราว์เซอร์ของผู้เยี่ยมชมสามารถเริ่มแสดงผลหน้าเว็บได้ อย่างไรก็ตาม การทำงานนี้ยังต้องใช้เวลาดำเนินการพอสมควร ในกรณีนี้คือ 66 มิลลิวินาที สิ่งนี้ถูกระบุโดยตัวทำเครื่องหมายงาน CPU สีส้มในมุมมองน้ำตก
ภาพหน้าจอ DebugBear แสดงขั้นตอนที่นำไปสู่การโหลดเอกสาร HTML ไปจนถึงการแสดงผลหน้าเว็บ ตุลาคม 2022 ตอนนี้เราเข้าใจแล้วว่าทำไม FCP เกิดขึ้นหลังจาก 632 มิลลิวินาที:
- 364 มิลลิวินาทีสำหรับคำขอเอกสาร HTML
- 137 มิลลิวินาทีในการโหลดสไตล์ชีต
- 66 มิลลิวินาทีในการแสดงผลหน้า
- 65 มิลลิวินาทีสำหรับงานประมวลผลอื่นๆ
งานประมวลผลอื่นๆ รวมถึงงานเล็กๆ เช่น การเรียกใช้สคริปต์แบบอินไลน์หรือการแยกวิเคราะห์โค้ด HTML และ CSS เมื่อดาวน์โหลดแล้ว คุณสามารถเห็นกิจกรรมนี้เป็นเส้นสีเทาเล็กๆ ใต้แถบฟิล์มที่แสดงภาพ
วิธีเพิ่มประสิทธิภาพ First Contentful Paint (FCP)
เมื่อคุณเข้าใจสิ่งที่นำไปสู่การแสดงผลเว็บไซต์ของคุณแล้ว คุณสามารถคิดหาวิธีเพิ่มประสิทธิภาพได้
- เซิร์ฟเวอร์สามารถตอบสนองต่อคำขอ HTML ได้เร็วขึ้นหรือไม่
- สามารถโหลดทรัพยากรผ่านการเชื่อมต่อเดียวกันแทนที่จะสร้างใหม่ได้หรือไม่
- มีคำขอที่สามารถลบหรือเปลี่ยนเป็นไม่บล็อกการเรนเดอร์อีกต่อไปหรือไม่
ขณะนี้ส่วนเริ่มต้นของเว็บไซต์ของคุณกำลังโหลดเร็วขึ้น ก็ถึงเวลาให้ความสำคัญกับการทำให้ไซต์เต็มรูปแบบโหลดเร็วขึ้น
วิธีเพิ่มความเร็วของ Contentful Paint (LCP) ที่ใหญ่ที่สุดด้วยคำแนะนำของ DebugBear
มีหลายวิธีในการเร่งความเร็ว LCP ของคุณ
เพื่อให้ง่าย DebugBear ให้ขั้นตอนต่อไปที่ยอดเยี่ยมแก่เราในส่วนคำแนะนำ
มาดูตัวอย่างคำแนะนำบางส่วนและเรียนรู้วิธีเพิ่มความเร็ว LCP ของเว็บไซต์นี้
คำแนะนำ 1: เริ่มต้นคำขอรูปภาพ LCP จากเอกสาร HTML
หากองค์ประกอบเนื้อหาที่ใหญ่ที่สุดในหน้าของคุณคือรูปภาพ แนวทางปฏิบัติที่ดีที่สุดคือต้องแน่ใจว่า URL มีอยู่ในเอกสาร HTML เริ่มต้นโดยตรง ซึ่งจะช่วยให้เริ่มโหลดได้โดยเร็วที่สุด
อย่างไรก็ตาม แนวทางปฏิบัติที่ดีที่สุดนี้ไม่ได้ใช้เสมอไป และบางครั้งอาจใช้เวลานานกว่าที่เบราว์เซอร์จะพบว่าจำเป็นต้องดาวน์โหลดภาพหลัก
ในตัวอย่างด้านล่าง เนื้อหาที่ใหญ่ที่สุด ซึ่งก็คือรูปภาพ จะถูกเพิ่มไปยังหน้าโดยใช้ JavaScript ด้วยเหตุนี้ เบราว์เซอร์จึงต้องดาวน์โหลดและเรียกใช้สคริปต์ขนาด 200 กิโลไบต์ก่อนที่จะค้นพบภาพและเริ่มดาวน์โหลด
ภาพหน้าจอ DebugBear แสดงห่วงโซ่คำขอตามลำดับที่นำไปสู่คำขอรูปภาพ ตุลาคม 2022 วิธีแก้ไข: ขึ้นอยู่กับเว็บไซต์ มีวิธีแก้ไขที่เป็นไปได้สองวิธี
โซลูชันที่ 1: หากคุณใช้ JavaScript เพื่อโหลดรูปภาพขนาดใหญ่แบบ Lazy Loading ให้ปรับขนาดรูปภาพให้เหมาะสมและลบสคริปต์การโหลดแบบ Lazy Loading ออกหรือแทนที่ด้วยแอตทริบิวต์ modern loading=”lazy” ซึ่งไม่ต้องการ JavaScript
โซลูชันที่ 2: ในกรณีอื่นๆ การเรนเดอร์ฝั่งเซิร์ฟเวอร์จะป้องกันไม่ให้ต้องดาวน์โหลดแอป JavaScript ก่อนที่หน้าจะแสดงผลได้ อย่างไรก็ตาม การดำเนินการนี้อาจซับซ้อนในบางครั้ง
คำแนะนำ 2: ตรวจสอบให้แน่ใจว่ารูปภาพ LCP โหลดด้วยลำดับความสำคัญสูง
หลังจากโหลดโค้ด HTML ของหน้าเว็บ เบราว์เซอร์ของผู้เยี่ยมชมอาจพบว่า นอกจากรูปภาพหลักแล้ว อาจต้องโหลดทรัพยากรเพิ่มเติมจำนวนมาก เช่น สไตล์ชีต
เป้าหมายที่นี่คือเพื่อให้แน่ใจว่ารูปภาพหลักที่ใหญ่และใหญ่ของคุณโหลดได้ตรงตามข้อกำหนด Largest Contentful Paint โดย Google
แหล่งข้อมูลอื่นๆ เช่น สคริปต์การวิเคราะห์ของบุคคลที่สาม ไม่สำคัญเท่ากับภาพหลักของคุณ
นอกจากนี้ รูปภาพส่วนใหญ่ที่อ้างอิงใน HTML ของไซต์ของคุณจะอยู่ในครึ่งหน้าล่างเมื่อหน้าได้รับการแสดงผลแล้ว บางส่วนอาจถูกซ่อนไว้อย่างสมบูรณ์ในการนำทางส่วนหัวที่ซ้อนกัน
ด้วยเหตุนี้ เบราว์เซอร์จึงตั้งค่าลำดับความสำคัญของคำขอรูปภาพทั้งหมดเป็นต่ำในขั้นต้น เมื่อแสดงผลหน้าเว็บแล้ว เบราว์เซอร์จะค้นหาว่ารูปภาพใดมีความสำคัญและเปลี่ยนลำดับความสำคัญ คุณสามารถดูตัวอย่างของสิ่งนั้นได้ในภาพหน้าจอด้านล่าง ตามที่ระบุโดยเครื่องหมายดอกจันในคอลัมน์ลำดับความสำคัญ
ภาพหน้าจอ DebugBear แสดงรูปภาพ LCP ที่โหลดโดยมีลำดับความสำคัญเริ่มต้นต่ำ ตุลาคม 2022 น้ำตกแสดงให้เห็นว่าแม้ว่าเบราว์เซอร์จะรู้จักภาพตั้งแต่เนิ่นๆ แต่ก็ไม่ได้เริ่มดาวน์โหลดตามที่แถบสีเทาระบุ
วิธีแก้ไข: ในการแก้ปัญหานี้ คุณสามารถใช้คุณลักษณะเบราว์เซอร์ใหม่ที่เรียกว่าคำใบ้ลำดับความสำคัญ หากคุณเพิ่มแอตทริบิวต์ fetchpriority=”high” ให้กับองค์ประกอบ img เบราว์เซอร์จะเริ่มโหลดรูปภาพตั้งแต่เริ่มต้น
คำแนะนำ 3: อย่าซ่อนเนื้อหาของหน้าโดยใช้ CSS
บางครั้งคุณอาจดูคำขอ Waterfall และทรัพยากรการบล็อกการแสดงผลทั้งหมดโหลดแล้ว แต่ยังคงไม่มีเนื้อหาของหน้าปรากฏขึ้น เกิดอะไรขึ้น?
เครื่องมือทดสอบ A/B มักจะซ่อนเนื้อหาของหน้าจนกว่าจะมีการใช้รูปแบบการทดสอบกับองค์ประกอบเนื้อหาบนหน้า ในกรณีดังกล่าว เบราว์เซอร์ได้แสดงหน้าแต่เนื้อหาทั้งหมดมีความโปร่งใส
คุณจะทำอย่างไรหากคุณไม่สามารถลบเครื่องมือทดสอบ A/B ได้
วิธีแก้ไข: ตรวจสอบว่าคุณสามารถกำหนดค่าเครื่องมือให้ซ่อนเฉพาะเนื้อหาที่ได้รับผลกระทบจากการทดสอบ A/B ได้หรือไม่ อีกวิธีหนึ่ง คุณสามารถตรวจสอบว่ามีวิธีทำให้เครื่องมือทดสอบ A/B โหลดเร็วขึ้นหรือไม่
ภาพหน้าจอของ DebugBear แสดงแถบฟิล์มสำหรับเรนเดอร์ที่เนื้อหาถูกซ่อนโดยเครื่องมือทดสอบ A/B ตุลาคม 2022 ตรวจสอบความเร็วไซต์ของคุณด้วย DebugBear
ต้องการทดสอบเว็บไซต์ของคุณอย่างต่อเนื่องหรือไม่? ลองใช้เครื่องมือตรวจสอบแบบชำระเงินของเราพร้อมทดลองใช้ฟรี 14 วัน
ด้วยวิธีนี้ คุณจะสามารถตรวจสอบได้ว่าการเพิ่มประสิทธิภาพการทำงานของคุณทำงานอยู่หรือไม่ และรับการแจ้งเตือนถึงการถดถอยของประสิทธิภาพในไซต์ของคุณ
ภาพหน้าจอแสดงแนวโน้มความเร็วไซต์สำหรับเว็บไซต์ใน DebugBear ตุลาคม 2022 
ภาพหน้าจอแสดงข้อมูล Core Web Vitals ใน DebugBear ตุลาคม 2022