Chrome DevTools คือกล่องเครื่องมืออเนกประสงค์ที่มาพร้อมกับเบราว์เซอร์เพื่อช่วยตอบคำถามว่า "เว็บพังที่ตรงไหน?" แทนที่เราจะใช้วิธีเดาสุ่มหรือแก้ไขโค้ดเรื่อยเปื่อย เราสามารถมองลึกไปถึงโครงสร้าง DOM, กฎสไตล์ CSS, ข้อผิดพลาดของสคริปต์, ปฏิกิริยาของระบบ API, และขีดจำกัดความเร็วของแอปพลิเคชันได้โดยตรงจากเบราว์เซอร์
บทความนี้จะนำเสนอขั้นตอนการดีบั๊กตั้งแต่ระดับพื้นฐานไปจนถึงระดับสูงที่นักพัฒนาฟรอนต์เอนด์ระดับพรีเมียมควรรู้ เพื่อให้คุณวิเคราะห์และแก้ปัญหาหน้าจอพังได้อย่างเป็นระบบ
ขั้นตอนที่ 1: เปิด DevTools และดู Console ก่อน
เมื่อพบอาการผิดปกติใดๆ เช่น ปุ่มกดไม่ตอบสนอง หรือเนื้อหาโหลดค้าง ขั้นตอนแรกสุดคือการกดปุ่ม F12 (หรือคลิกขวาที่ใดก็ได้บนหน้าเว็บแล้วเลือก Inspect) แล้วเปลี่ยนแท็บไปที่ Console หากมีข้อผิดพลาดร้ายแรงเกิดขึ้นใน JavaScript ระบบจะแสดงตัวอักษรสีแดงแจ้งเตือนทันที
Cannot read properties of undefined (reading '...'): เกิดจากโค้ดพยายามเข้าถึงค่าตัวแปรที่เป็นค่าว่างหรือไม่ได้นิยามไว้Failed to fetch: ปัญหาทางด้านเครือข่าย หรือเบราว์เซอร์ไม่สามารถเข้าถึงเซิร์ฟเวอร์ปลายทางได้404 Not Found: ไฟล์รูปภาพ หรือ Assets หรือ API endpoint ที่ระบุไม่มีอยู่จริงCORS policy: คำขอฝั่งไคลเอนต์ถูกบล็อก เนื่องจากเซิร์ฟเวอร์ปลายทางไม่ได้ประกาศรับรอง Origin ของเว็บเราUncaught SyntaxError: ไวยากรณ์ในโค้ดเขียนผิดพลาด เช่น ลืมปิดวงเล็บหรือเครื่องหมายปีกกา
ขั้นตอนที่ 2: ใช้ Elements ตรวจ Layout
หากหน้าเว็บมีอาการ "หน้าแตก" หรือระยะขอบเยื้องไม่ตรงตามต้องการ ให้ไปที่แท็บ Elements เพื่อตรวจสอบโครงสร้าง HTML และกฎ CSS ที่มีผลจริงกับแท็กนั้นๆ
- กดสัญลักษณ์ลูกศรซ้ายบนของ DevTools (เครื่องมือ Inspect Element) แล้วจิ้มไปยังกล่องที่พัง
- ด้านขวามือในส่วนของ Styles จะแสดงกฎสไตล์ CSS ที่สอดคล้อง ตรวจดูว่ามีกฎไหนโดนขีดทับหรือไม่ (ซึ่งแปลว่าถูกทับซ้อนด้วยกฎที่มีสิทธิ์สูงกว่า)
- ตรวจเช็คค่าคุณสมบัติสำคัญที่เป็นหัวใจของ Layout:
position,width,height,overflow, และระบบจัดตำแหน่งอย่าง Flexbox หรือ CSS Grid
ขั้นตอนที่ 3: ใช้ Network ตรวจ API และ Asset
หากเว็บโหลดรูปภาพไม่สำเร็จ หรือการดึงข้อมูลตารางผิดพลาด ให้เปิดแท็บ Network แล้วรีโหลดหน้าเว็บเพื่อดูคำร้องขอทรัพยากรทุกตัวที่เว็บสั่งซื้อเข้ามา
| Status Code / Error | คำอธิบายและการแก้ไขเบื้องต้น |
|---|---|
| 200 OK | ข้อมูลโหลดผ่านปกติ แต่อาจแสดงผลไม่ถูกเพราะสะกดชื่อตัวแปรรับค่าผิดในโค้ด |
| 304 Not Modified | ไฟล์ถูกดึงมาจากแคชของเบราว์เซอร์ ทำงานได้รวดเร็วและปกติ |
| 404 Not Found | ใส่ Path ไฟล์ผิด ลืมอิมพอร์ต หรือลืมดันไฟล์ assets ขึ้นระบบคลาวด์ |
| 500 Internal Server Error | เซิร์ฟเวอร์ฝั่ง API เกิดการขัดข้อง ต้องเช็ค log ฝั่งหลังบ้าน |
| CORS Error | เซิร์ฟเวอร์ API ปฏิเสธข้ามโดเมน ต้องตั้งค่า CORS Headers ให้ตอบรับโดเมนเว็บเรา |
ขั้นตอนที่ 4: Debug JavaScript ด้วย Sources
แทนที่จะเขียนคำสั่ง console.log() ฝังไว้ทั่วหน้าเว็บแล้วต้องคอยลบออกภายหลัง การใช้แท็บ Sources เพื่อวางจุดหยุดทำงาน (Breakpoints) จะช่วยให้นักพัฒนาเห็นสภาวะของตัวแปรและลำดับการทำงานทีละบรรทัดได้อย่างยืดหยุ่น:
- จำลองการทำงานที่เป็นปัญหา (Reproduce Bug)
- เปิดโค้ดในแท็บ Sources และคลิกตรงหมายเลขบรรทัดที่ต้องการวาง Breakpoint
- รันกิจกรรมเดิมบนเว็บ ระบบจะหยุดประมวลผลทันทีเมื่อชนบรรทัดดังกล่าว
- ตรวจสอบค่าตัวแปรในส่วนของ Scope หรือพิมพ์สอบถามค่าในหน้า Console ได้สดๆ
- ใช้ปุ่ม Step over และ Step into เพื่อควบคุมลำดับการรันทีละสเต็ป
ขั้นตอนที่ 5: ตรวจ Responsive Mode
เพื่อให้มั่นใจว่าเว็บตอบสนองได้สวยงามไร้รอยต่อในจอโทรศัพท์ ให้กดไอคอนรูปมือถือและแท็บเล็ตบริเวณมุมซ้ายบนของ DevTools เพื่อจำลองขนาดหน้าจอ:
- ทดสอบสเกลความกว้างขนาดต่างๆ: 360px, 390px (สากลสำหรับมือถือ), 768px (แท็บเล็ต) และแบบ responsive ยืดหยุ่น
- ตรวจดูว่าแผงนำทาง (Navbar) ล้น, รูปไม่ย่อขนาดตามอัตราส่วน หรือตัวอักษรตกขอบหน้าจอหรือไม่
ขั้นตอนที่ 6: ใช้ Lighthouse เป็น Checklist รอบสุดท้าย
แท็บ Lighthouse ช่วยสร้างรายงานออดิตเพื่อชี้แนะข้อบกพร่องทั้งในด้านความเร็ว (Performance), ประสิทธิภาพ SEO, การเขียนโค้ดตามมาตรฐานสากล (Best Practices), และการเข้าถึงระบบที่เอื้อต่อผู้พิการ (Accessibility) เพียงคลิกปุ่ม Analyze page load ระบบจะรายงานข้อเสียที่ควรแก้ไขเป็นสเต็ปชัดเจน
Debug Checklist ที่ควรนำไปใช้ในทุกโปรเจกต์
- Console Check: ล้าง JavaScript crash และ runtime warning ทั้งหมดให้สะอาด
- Elements Check: ตรวจว่าโครงสร้างสอดคล้อง ไม่มีการล้นของเนื้อหาจากการเขียนขนาดคงที่ (Fixed sizing)
- Network Check: ตรวจดูเวลาตอบรับ (Latency) และสถานะสถานะ HTTP status ของทุก Asset
- Sources Check: ทำความเข้าใจขั้นตอนและดักเงื่อนไขค่าตัวแปรที่เป็น Null เสมอ
- Application Check: ล้าง Local Storage, Session หรือ Cookies ทุกครั้งเมื่อแก้ไขสคริปต์สลับเวอร์ชันแคช
- Responsive Check: ไม่เขียน CSS ห้ามย่อรูป ต้องมี
max-width: 100%เสมอ - Lighthouse Audit: ปรับความเร็วโหลดให้ผ่านเกณฑ์ระดับ 90+ คะแนน
เมื่อใช้กระบวนการด้านบนนี้เป็นประจำ คุณจะเริ่มแก้ปัญหาได้ทันใจและเข้าใจทิศทางการประมวลผลของเบราว์เซอร์อย่างถ่องแท้ครับ! 💻🚀
Chrome DevTools is a suite of web developer tools built directly into the Google Chrome browser. It enables you to inspect the rendered HTML (DOM), debug CSS layouts, monitor network activity, troubleshoot JavaScript code, and audit accessibility and performance.
This step-by-step guide will walk you through the essential debugging workflows that every frontend developer should master to solve layout breaks and script errors efficiently.
Step 1: Open DevTools and Audit the Console
When a feature doesn't work or an API call fails, press F12 (or right-click anywhere and select Inspect) and switch to the Console tab. Red warnings highlight fatal JavaScript crashes.
Cannot read properties of undefined: Attempting to read properties of an uninitialized variable.Failed to fetch: Network-level blockages or offline servers.404 Not Found: Incorrect asset paths or missing file resources.CORS policy: API server rejects cross-origin requests from your frontend origin.Uncaught SyntaxError: Syntax syntax errors like missing brackets or semicolons.
Step 2: Inspect CSS & Layout in Elements Tab
If your design looks broken, use the Inspect cursor in the top-left of DevTools and hover over the elements in the page:
- Select the target tag to inspect its HTML node on the left and applied CSS rules on the right.
- Examine crossed-out CSS properties to see if they are overridden by more specific declarations.
- Check key layout-breaking properties:
position,display,width, and flex container settings.
Step 3: Track APIs & Media Assets in Network Tab
The Network tab logs every HTTP request made by the browser. Refresh your page with the tab open to track network status:
| Status Code / Error | Description & Resolution |
|---|---|
| 200 OK | Successful load. If data doesn't render, check your frontend object parsing keys. |
| 304 Not Modified | Loaded efficiently from browser memory cache. |
| 404 Not Found | Asset or endpoint missing. Check your directory mapping or paths. |
| 500 Internal Error | Backend API failure. Check backend server logs. |
| CORS Blocked | Missing Cross-Origin Resource Sharing headers on your API server. |
Step 4: Stop console.log — Use Sources Breakpoints
Instead of scattering temporary print logs across your code, use Sources Breakpoints to pause JavaScript execution and inspect active states:
- Locate your script files in the Sources file tree.
- Click the line number where you want to pause execution to set a breakpoint.
- Trigger the web event (e.g. click the button). The browser will freeze exactly on your breakpoint line.
- Examine active variables in the Scope tab.
- Step line-by-line using the Step Over button to observe logical forks.
Step 5: Test Mobile Viewports in Device Mode
Enable Device Mode (the mobile icon next to the Inspector cursor) to test your website's responsiveness across standard mobile breakpoints:
- Simulate common viewport dimensions such as 360px, 390px, or 768px.
- Detect issues like horizontal scrolling, un-wrapped text, or squished buttons on smaller screens.
Step 6: Run Audits with Lighthouse
The Lighthouse tool automates auditing for Page Load Performance, Search Engine Optimization (SEO), Accessibility, and Best Practices. Run a scan to get detailed tips on optimization.
Universal Web Debugging Checklist
- Console: Clear out all red exceptions and yellow warning flags.
- Elements: Check layouts and prevent element overflows.
- Network: Ensure all files return a 200 or 304 code.
- Sources: Leverage breakpoints to trace complex states.
- Application: Clear storage/cookies regularly during development.
- Responsive: Use relative percentage sizing and
max-width: 100%for media. - Lighthouse: Aim for 90+ green scores in performance and SEO.
ความคิดเห็น (2) Responses (2)
ปกติใช้แต่ console.log พอได้รู้เทคนิค Breakpoint ในแท็บ Sources ช่วยให้ประหยัดเวลาไล่โค้ดได้เยอะเลยค่ะ I used to only use console.log. Setting breakpoints in Sources saves so much debugging time!
ตารางสรุป HTTP status code อธิบายเข้าใจง่ายมากครับ ติดเรื่อง CORS มานาน อ่านหน้านี้แล้วเคลียร์เลย The status code table is very clear. Finally resolved my CORS confusion!