ใช้ DevTools หา “ตัวดูดเวลา” ของเว็บใน 10 นาที ก่อนลงมือแก้โค้ด

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

เป้าหมายของการวิเคราะห์

ก่อนเริ่มตรวจสอบ ควรตั้งเป้าหมายให้ชัดว่าเราต้องการรู้เรื่องใดบ้าง

1. หน้าเว็บช้าเพราะรอโหลดข้อมูลหรือทรัพยากร
2. หน้าเว็บช้าเพราะ JavaScript ทำงานหนักเกินไป
3. หน้าเว็บช้าเพราะขั้นตอน render, layout หรือ paint ใช้เวลามาก
4. เลือกแก้จุดที่ให้ผลกระทบสูงสุดก่อน ตามหลัก 80/20

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

นาทีที่ 1-3: เปิด Network เพื่อดูความจริงของการโหลด

เริ่มจากเปิด Chrome DevTools แล้วไปที่แท็บ Network จากนั้นติ๊ก Disable cache ชั่วคราวเพื่อให้การทดสอบสะท้อนการโหลดจริงมากขึ้น แล้วสั่ง Hard reload หรือกด Ctrl+Shift+R

สิ่งที่ควรดูเป็นอันดับแรกมี 4 อย่าง

1. TTFB สูง หาก Time To First Byte สูงผิดปกติ อาจหมายถึงปัญหาที่เซิร์ฟเวอร์ ระบบแคช หรือ CDN

2. ไฟล์ใหญ่เกินจำเป็น เช่น รูปภาพ ฟอนต์ วิดีโอ หรือ JavaScript bundle ที่มีขนาดมากเกินไป

3. จำนวน request มากเกินไป เว็บไซต์ที่โหลดไฟล์ย่อยจำนวนมาก หรือพึ่งพา third-party และ tracking script มากเกินไป มักทำให้โหลดช้าโดยไม่จำเป็น

4. Waterfall มีช่วงว่างยาว ถ้าเห็นช่วงที่ไม่มีอะไรคืบหน้า อาจมีคอขวดในการโหลด หรือมีบางอย่างบล็อกลำดับการดึงทรัพยากร

ทริคที่ใช้แล้วเห็นผลเร็ว

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

นาทีที่ 4-7: ใช้ Performance หา JavaScript และการเรนเดอร์ที่หนักเกินไป

หลังจากดูฝั่งการโหลดแล้ว ให้ไปที่แท็บ Performance กด Record จากนั้นรีโหลดหน้าเว็บ และหยุดบันทึกเมื่อโหลดเสร็จ

ในรายงานที่ได้ ให้โฟกัสกับ 3 สัญญาณสำคัญ

1. Main thread แถบสีเหลืองยาว มักเป็นสัญญาณว่า JavaScript ใช้เวลานานเกินไป

2. สีม่วงหรือสีเขียวถี่ ๆ บ่งบอกว่ากระบวนการ render, layout หรือ paint หนัก หรือมีการเปลี่ยนแปลง DOM มากเกินจำเป็น

3. Long task งานที่ใช้เวลามากกว่าประมาณ 50 มิลลิวินาที อาจทำให้การเลื่อนหน้ากระตุก ปุ่มตอบสนองช้า หรืออินพุตหน่วง

วิธีดูแบบมืออาชีพ

ให้ซูมไปยังช่วงเวลาที่ผู้ใช้รู้สึกว่าช้า เช่น ตอนคลิกปุ่ม หรือช่วงที่หน้าเว็บเพิ่งแสดงผล แล้วเปิดดู Call tree หรือ Bottom-up เพื่อหา function ที่ใช้เวลามากที่สุด

จุดสำคัญคืออย่าเดาจากชื่อ function เพียงอย่างเดียว แต่ให้ดูค่า Self time เป็นหลัก เพราะค่านี้สะท้อนเวลาที่ function นั้นใช้ทำงานจริงด้วยตัวเอง ไม่ใช่เวลาที่เกิดจากการเรียกงานอื่นต่อ

นาทีที่ 8-10: จับคู่ข้อมูลจาก Network และ Performance

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

ตัวอย่างต้นเหตุที่พบได้บ่อย ได้แก่

1. JavaScript bundle ใหญ่เกินไป แม้จะโหลดเร็ว แต่ขั้นตอน parse และ compile อาจช้ามาก

2. Third-party script ไม่เพียงโหลดช้า แต่ยังอาจบล็อก main thread และทำให้หน้าไม่ตอบสนอง

3. รูปภาพขนาดใหญ่ แม้ดาวน์โหลดเสร็จแล้ว แต่ขั้นตอน decode และ paint อาจหนักจนทำให้ทั้งหน้ากระตุก

4. ฟอนต์เว็บ อาจทำให้เกิด layout shift, reflow หรือข้อความกระพริบระหว่างรอฟอนต์

5. API ช้า เมื่อข้อมูลมาช้า หน้าอาจต้องรอ และเมื่อข้อมูลมาถึงก็ render หนักทีเดียว

ตัวอย่างอาการและแนวทางแก้แบบไม่เดา

การอ่านผลจาก DevTools จะมีประโยชน์มากขึ้นเมื่อเชื่อมโยงกับแนวทางแก้ที่เหมาะสม

กรณีที่ 1: โหลดเสร็จเร็ว แต่หน้าไม่ตอบสนองอีก 2-3 วินาที

หาก Network ดูเหมือนโหลดเสร็จไว แต่ผู้ใช้ยังคลิกอะไรไม่ค่อยได้ ปัญหามักอยู่ที่ CPU หรือ JavaScript

แนวทางแก้:

• แยก bundle
• ใช้ lazy load
• ลด polyfill ที่ไม่จำเป็น
• ตัด dependency ที่หนักเกินไป

กรณีที่ 2: Waterfall มีแท่ง JavaScript ยาวและเริ่มโหลดตั้งแต่ต้นมาก

แปลว่าสคริปต์บางตัวอาจกำลังบล็อกการแสดงผลของหน้า

แนวทางแก้:

• ใช้ defer หรือ async ให้เหมาะสม
• ลด script ที่วางไว้ใน head
• เลื่อน third-party script ไปโหลดทีหลัง

กรณีที่ 3: หลังข้อมูลมาแล้ว Layout/Paint หนักมาก

นี่มักเกิดจากการเรนเดอร์รายการจำนวนมาก หรือมี DOM หนักเกินไป

แนวทางแก้:

• ใช้ virtualize list
• ลดจำนวน DOM nodes
• batch update
• ใช้ CSS ที่ไม่กระตุ้น layout บ่อยเกินไป

กรณีที่ 4: รูปโหลดปกติ แต่เลื่อนหน้าแล้วกระตุก

ปัญหาอาจไม่ได้อยู่ที่การโหลด แต่เป็นภาระจากการวาดและเอฟเฟกต์บนจอ

แนวทางแก้:

• ใช้รูปขนาดพอดีกับการแสดงผล
• เปลี่ยนเป็น modern format
• ใช้ lazy load
• ลดเอฟเฟกต์หนัก ๆ เช่น box-shadow หรือ filter ที่ซับซ้อน

เช็กลิสต์ก่อนแก้โค้ดสักบรรทัด

ก่อนเริ่มลงมือแก้จริง ควรถามตัวเองให้ครบ 4 ข้อ

1. เจอ request ที่ช้าที่สุด 3 อันดับแรกแล้วหรือยัง
2. เจอ long task สำคัญบน main thread แล้วหรือยัง
3. ระบุได้ชัดหรือไม่ว่าความช้ามาจาก download, CPU หรือ render
4. เลือกจุดเดียวที่มีโอกาสลดเวลาได้มากที่สุดก่อนหรือยัง

ถ้ายังตอบไม่ได้ครบ การเริ่มแก้โค้ดอาจเป็นการใช้แรงผิดที่

ทำไมวิธีนี้จึงคุ้มค่าก่อนเริ่มปรับระบบ

ข้อดีของการใช้ DevTools แบบนี้คือ ช่วยให้ทั้งมือใหม่และคนมีประสบการณ์ทำงานได้แม่นขึ้น

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

สรุป

แท็บ Performance ช่วยบอกว่าเบราว์เซอร์กำลังใช้ทรัพยากรไปกับอะไร เช่น JavaScript, layout หรือ paint ส่วนแท็บ Network ช่วยบอกว่าเว็บกำลังเสียเวลาไปกับการรออะไร เช่น ไฟล์ใหญ่ เซิร์ฟเวอร์ช้า หรือ request จำนวนมาก

เมื่อใช้สองเครื่องมือนี้ร่วมกัน เราจะเห็นทั้งภาพของการ “รอ” และการ “ทำงานหนัก” พร้อมกัน ทำให้ค้นหา “ตัวดูดเวลา” ของเว็บได้อย่างแม่นยำก่อนเริ่มแก้โค้ดจริง และเพิ่มโอกาสที่การปรับปรุงแต่ละครั้งจะเห็นผลชัดเจนที่สุด