กลับไปหน้าบทความ
#DevTools#Waterfall#Web Performance#Network Tab#การเพิ่มประสิทธิภาพเว็บไซต์

อ่าน Waterfall ใน DevTools เพื่อค้นหาคอขวดของการโหลดเว็บไซต์

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

8 สิงหาคม 2569อ่านประมาณ 2 นาที

แชร์บทความ

อ่าน Waterfall ใน DevTools เพื่อค้นหาคอขวดของการโหลดเว็บไซต์

Waterfall ใน DevTools คือกราฟเส้นเวลาที่แสดงว่าแต่ละ request เริ่มทำงานเมื่อใด ใช้เวลานานเท่าไร และต้องรอขั้นตอนหรือ resource ใดก่อนหน้า กราฟนี้ช่วยให้เราเข้าใจลำดับการโหลดเว็บไซต์ได้ชัดเจนกว่าการดูเฉพาะตัวเลขเวลา เพราะสามารถมองเห็นคอขวดและความสัมพันธ์ระหว่างไฟล์ต่าง ๆ ได้ในภาพเดียว

Waterfall แสดงข้อมูลอะไร

เมื่อเปิด Network Tab ใน DevTools แล้วโหลดหน้าเว็บใหม่ แต่ละ request จะปรากฏเป็นแถวพร้อมแท่งสีที่วางเรียงตามเวลา ตำแหน่งเริ่มต้นของแท่งบอกว่า request เริ่มเมื่อใด ส่วนความยาวของแท่งแสดงเวลาที่ใช้ตั้งแต่เริ่มเชื่อมต่อจนดาวน์โหลดข้อมูลเสร็จ

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

ขั้นตอนสำคัญที่ควรสังเกตมีดังนี้

  • DNS: เวลาที่ใช้ค้นหาหมายเลข IP ของโดเมน หากนานผิดปกติอาจเกี่ยวข้องกับ DNS provider หรือการเรียก resource จากหลายโดเมน
  • Connection: เวลาที่ใช้สร้างการเชื่อมต่อ รวมถึงการเจรจา TLS สำหรับ HTTPS
  • Waiting: เวลาที่รอข้อมูลไบต์แรกจากเซิร์ฟเวอร์ ซึ่งมักสะท้อนความเร็วของ backend, API หรือฐานข้อมูล
  • Download: เวลาที่ใช้รับข้อมูลทั้งหมด หากนานอาจเกิดจากไฟล์ขนาดใหญ่หรือเครือข่ายของผู้ใช้ช้า

วิธีสังเกต request ที่เป็นปัญหา

หากไฟล์หนึ่งเริ่มโหลดช้ากว่า request อื่นมาก ไม่ได้หมายความว่าไฟล์นั้นดาวน์โหลดช้าเสมอไป แต่อาจกำลังรอ resource ก่อนหน้า รอให้ JavaScript สร้าง request หรือถูกเบราว์เซอร์จำกัดจำนวน connection ที่ทำงานพร้อมกัน

ในทางกลับกัน หากแท่งของ request ยาวผิดปกติ ควรเปิดดูรายละเอียดว่าเวลาส่วนใหญ่หมดไปกับขั้นตอนใด ช่วง Waiting ที่ยาวมักเกี่ยวข้องกับเซิร์ฟเวอร์ตอบช้า ขณะที่ช่วง Download ที่ยาวมักสัมพันธ์กับขนาดไฟล์หรือความเร็วของเครือข่าย

จุดที่ควรตรวจสอบเป็นลำดับแรก ได้แก่

  • รูปภาพ hero เริ่มโหลดช้าหรือมีขนาดใหญ่เกินไป
  • CSS สำคัญมาถึงช้า ทำให้เบราว์เซอร์ยังวาดหน้าแรกไม่ได้
  • JavaScript ขนาดใหญ่บล็อกการประมวลผลหรือสร้าง request สำคัญล่าช้า
  • Web font โหลดนานจนข้อความปรากฏช้าหรือเกิดการเปลี่ยนรูปแบบภายหลัง
  • API บางรายการมีช่วง Waiting นานกว่ารายการอื่นอย่างชัดเจน
  • Third-party script แย่ง bandwidth หรือทำงานก่อน resource หลักของหน้าเว็บ

Dependency chain ทำให้เว็บช้าได้อย่างไร

เมื่อ request หลายรายการเรียงต่อกันเป็นลูกโซ่ แสดงว่า resource ถัดไปยังเริ่มไม่ได้จนกว่ารายการก่อนหน้าจะโหลดหรือประมวลผลเสร็จ ปัญหานี้เรียกว่า dependency chain และอาจทำให้เนื้อหาสำคัญปรากฏช้ากว่าที่ควร แม้แต่ละไฟล์จะไม่ได้ใช้เวลาดาวน์โหลดมากนัก

ตัวอย่างเช่น เบราว์เซอร์ต้องโหลด HTML ก่อนจึงจะค้นพบไฟล์ CSS และอาจต้องอ่าน CSS ต่อจึงจะพบ URL ของ font หากแต่ละขั้นตอนเริ่มต่อกันตามลำดับ เวลาเล็กน้อยในแต่ละ request จะสะสมจนผู้ใช้ต้องรอหน้าเว็บนานขึ้น

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

แนวทางแก้ปัญหาจากข้อมูลใน Waterfall

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

แนวทางที่ใช้ได้ในสถานการณ์ต่าง ๆ มีดังนี้

  1. ใช้ preload กับรูปภาพ hero, font หรือ resource สำคัญที่เบราว์เซอร์ค้นพบช้า
  2. ใช้ preconnect เมื่อต้องเชื่อมต่อโดเมนภายนอกที่จำเป็นตั้งแต่ช่วงต้น
  3. ลดขนาดรูปภาพ เลือกรูปแบบไฟล์ที่เหมาะสม และส่งขนาดให้พอดีกับพื้นที่แสดงผล
  4. ลดหรือแบ่ง JavaScript bundle เพื่อไม่ให้ผู้ใช้ดาวน์โหลดโค้ดที่ยังไม่จำเป็น
  5. เลื่อน third-party script และ resource ที่ไม่สำคัญไปโหลดภายหลัง
  6. ปรับปรุง API, query ฐานข้อมูล หรือระบบ cache เมื่อช่วง Waiting ของเซิร์ฟเวอร์ยาว
  7. ลด dependency chain เพื่อให้ request สำคัญเริ่มทำงานได้เร็วขึ้น

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

วิธีเริ่มต้นสำหรับมือใหม่

เริ่มจากโหลดหน้าเว็บใหม่โดยเปิด Network Tab ไว้ แล้วเรียง request ตาม Waterfall เพื่อดูว่าไฟล์ใดเริ่มก่อนหรือหลัง จากนั้นเลือกตรวจ request แรก ๆ ไฟล์ที่ใช้เวลารวมมากที่สุด และ resource สำคัญที่ผู้ใช้ต้องเห็นทันที

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

สรุป

Waterfall คือแผนที่เวลาของการโหลดเว็บไซต์ที่ช่วยให้เห็นว่าแต่ละ request เริ่มเมื่อใด รออะไร และเสียเวลาในขั้นตอนไหน เมื่ออ่านกราฟนี้ได้ เราจะแยกได้ว่าเว็บช้าเพราะ asset มากเกินไป เซิร์ฟเวอร์ตอบช้า ไฟล์มีขนาดใหญ่ หรือเกิด dependency chain ที่ไม่จำเป็น

ข้อมูลจาก Waterfall ทำให้เลือกวิธีแก้ได้แม่นยำขึ้น ไม่ว่าจะเป็นการ preload หรือ preconnect resource สำคัญ ลดขนาดไฟล์ ปรับปรุง API หรือเลื่อน script ที่ไม่จำเป็นออกไป เป้าหมายไม่ใช่ทำให้ทุก request เร็วที่สุด แต่คือทำให้สิ่งสำคัญต่อผู้ใช้โหลดได้เร็วและเป็นลำดับที่เหมาะสม