จับคอขวดเว็บด้วย Chrome DevTools ให้โหลดไวขึ้นใน 10 นาที

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

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

1) วัดก่อนแก้ด้วย Lighthouse

ขั้นตอนแรกที่ควรทำเสมอคือการวัดผลก่อนลงมือแก้ เพราะถ้าไม่วัด เราจะไม่รู้ว่าปัญหาหนักอยู่ตรงไหน และหลังแก้แล้วดีขึ้นจริงหรือไม่

วิธีใช้งานแบบเร็ว:

• เปิด Chrome DevTools
• ไปที่แท็บ Lighthouse
• เลือก Mobile และ Performance
• กด Run

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

หัวข้อที่มักเจอบ่อยและควรโฟกัสก่อน ได้แก่:

• Render-blocking resources: มีไฟล์ที่ขวางการแสดงผลหน้าเว็บ
• Reduce unused JavaScript: มี JavaScript ที่โหลดมาเกินความจำเป็น
• Properly size images: ใช้รูปภาพขนาดใหญ่เกินจริงเมื่อเทียบกับพื้นที่แสดงผล

หากเริ่มจาก 3 จุดนี้ก่อน มักเห็นผลลัพธ์ได้ค่อนข้างเร็ว

2) จับคอขวดจริงด้วยแท็บ Performance

เมื่อรู้แนวโน้มจาก Lighthouse แล้ว ขั้นต่อไปคือการหาต้นเหตุจริงว่าเว็บเสียเวลาอยู่ตรงไหน

วิธีใช้งาน:

• เปิดแท็บ Performance
• กด Record
• รีโหลดหน้าเว็บ
• กดหยุดการบันทึก

หลังจากนั้นให้ดูกราฟหลัก 3 ส่วนสำคัญ:

• Main / CPU: ถ้าพุ่งสูงมาก มักแปลว่า JavaScript หนัก
• Frames: หากมีอาการแดงหรือตก แปลว่าหน้าเว็บกระตุกระหว่าง render
• Network: ถ้าแถบยาวผิดปกติ อาจกำลังรอไฟล์หรือรอการตอบสนองจากเซิร์ฟเวอร์

อีกจุดที่ควรดูอย่างมากคือ Largest Contentful Paint (LCP) เพราะเป็นตัวชี้วัดว่าคอนเทนต์หลักของหน้าปรากฏช้าเพียงใด

แนวทางอ่านแบบทำงานจริง:

• ถ้า LCP ติดที่รูปใหญ่ แปลว่าควรแก้เรื่องรูปภาพ
• ถ้า LCP ติดที่ฟอนต์ แปลว่าควรปรับการโหลดฟอนต์
• ถ้า LCP ติดที่ JavaScript แปลว่าควรลดหรือเลื่อนการโหลดสคริปต์

วิธีนี้ช่วยให้การแก้ปัญหาแม่นขึ้น เพราะเห็นต้นเหตุจริง ไม่ต้องคาดเดา

3) แก้ไวให้เห็นผลด้วย Network และ Coverage

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

3.1 จัดการรูปภาพในแท็บ Network

รูปภาพเป็นหนึ่งในสาเหตุยอดนิยมที่ทำให้หน้าเว็บช้า และมักแก้ได้เร็วที่สุด

วิธีใช้งาน:

• เปิดแท็บ Network
• ติ๊ก Disable cache
• รีโหลดหน้าเว็บ
• เรียงข้อมูลตาม Size

สัญญาณที่ควรระวัง:

• ใช้ไฟล์ .png ขนาดใหญ่กับภาพถ่าย
• ใช้รูปความกว้าง 3000px แต่แสดงจริงเพียง 400px
• โหลดรูป hero หนักทั้งที่ไม่ได้อยู่ในจอแรก

แนวทางแก้แบบเห็นผลเร็ว:

• เปลี่ยนรูปเป็น WebP หรือ AVIF
• ใส่ width และ height ให้ครบเพื่อลด layout shift
• ใช้ responsive images ผ่าน srcset
• ใส่ loading="lazy" ให้รูปที่อยู่นอกจอแรก

ตัวอย่าง:

<img src="hero.avif" width="1200" height="600" fetchpriority="high">
<img src="photo.webp" loading="lazy" decoding="async" width="800" height="600">

3.2 ไล่ไฟล์ที่ไม่จำเป็นด้วย Coverage

อีกปัญหาที่ทำให้เว็บช้าแบบเงียบ ๆ คือการโหลด JavaScript หรือ CSS มาเยอะ แต่ใช้งานจริงน้อยมาก

วิธีเปิด Coverage:

• กด Ctrl+Shift+P
• พิมพ์ Show Coverage
• กด Start instrumenting coverage
• รีโหลดหน้าเว็บ

จากนั้นระบบจะแสดงเปอร์เซ็นต์ Unused ของแต่ละไฟล์ หากไฟล์ไหน unused สูงมาก ก็มีแนวโน้มเป็นตัวการที่ทำให้หน้าเว็บหนักโดยไม่จำเป็น

แนวทางแก้เบื้องต้น:

• แยก bundle หรือทำ code splitting
• ลบไลบรารีที่ไม่ได้ใช้
• ย้ายสคริปต์ที่ไม่จำเป็นไปไว้ท้ายหน้า
• ใส่ defer ให้สคริปต์ที่ไม่ต้องบล็อกการ render

ตัวอย่าง:

<script src="app.js" defer></script>

4) ทดสอบความช้าแบบโลกจริงด้วย Throttling

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

ดังนั้นควรลองจำลองสภาพแวดล้อมที่ช้าลงด้วย:

• Network throttling เลือก Fast 3G หรือ Slow 4G
• CPU throttling ตั้งเป็น 4x
• จากนั้นรีโหลดหน้าเว็บอีกครั้ง

ถ้าภายใต้เงื่อนไขที่ถูกบีบแล้ว หน้าเว็บยังพอใช้งานได้ดี แสดงว่า UX ของเว็บนั้นแข็งแรงพอสำหรับผู้ใช้ส่วนใหญ่

5) สูตรทำงาน 10 นาทีแบบเช็กลิสต์

หากต้องการลำดับการทำงานแบบเร็วและใช้ได้จริง สามารถทำตามนี้ได้เลย

• นาที 1-2: เปิด Lighthouse แล้วดูว่าหัวข้อไหนประหยัดเวลาได้มากที่สุด
• นาที 3-6: เปิด Performance เพื่อดูว่า LCP ไปติดที่อะไร
• นาที 7-9: เปิด Network แล้วจัดการรูป ฟอนต์ หรือไฟล์ใหญ่ที่โหลดหนัก
• นาที 10: เปิด Coverage เพื่อตรวจ unused JS/CSS และเลื่อนโหลดด้วย defer หรือ lazy

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

โบนัสทริคเล็กที่มักถูกมองข้าม

แม้จะเป็นรายละเอียดเล็กน้อย แต่หลายครั้งกลับช่วยเรื่องความเร็วได้มาก

• หากฟอนต์โหลดช้า ให้ใช้ font-display: swap
• หากมี third-party เยอะ ให้เปิด Network แล้วดูว่าโดเมนไหนใช้เวลาในขั้นตอน TLS หรือ TTFB สูง
• หาก TTFB สูงผิดปกติ การแก้ฝั่ง backend หรือระบบแคชมักคุ้มค่ามากกว่าการปรับ frontend อย่างเดียว

สรุป

การเร่งความเร็วเว็บไม่จำเป็นต้องเริ่มจากการแก้โค้ดครั้งใหญ่เสมอไป แค่ใช้ Chrome DevTools ให้เป็น เราก็สามารถมองเห็นคอขวดหลักของหน้าเว็บได้ภายในเวลาไม่กี่นาที

ลำดับที่ควรจำให้ขึ้นใจคือ วัดก่อนด้วย Lighthouse, หาต้นเหตุจริงด้วย Performance, และ แก้จุดคุ้มค่าด้วย Network กับ Coverage เมื่อทำซ้ำหลายรอบ คุณจะเริ่มอ่านกราฟได้คล่องขึ้น และตัดสินใจแก้ปัญหาได้ไวแบบมืออาชีพ

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