HAR File Analyzer: อ่าน Network Waterfall ให้เป็นเหมือน Performance Engineer

เมื่อหน้าเว็บโหลดชี้ ๆ ช้า ๆ เบราว์เซอร์รู้คำตอบอยู่แล้ว — หลักฐานทั้งหมดซ่อนอยู่ใน network panel กระจัดกระจายเป็นสิบ ๆ แถว ไฟล์ HAR (HTTP Archive) คือไฟล์ JSON มาตรฐานที่จับภาพกิจกรรมเหล่านั้นทั้งหมด ไม่ว่าจะเป็นทุก request, ช่วงเวลาแต่ละ phase, status code และขนาดของข้อมูล HAR File Analyzer จะแปลงไฟล์ดิบนี้ให้เป็น request waterfall, อันดับ request ที่ช้าที่สุด, สรุปแยกตามกลุ่ม status code และขนาด transfer รวม ภายในไม่กี่วินาที

การเก็บไฟล์ HAR ไม่ต้องติดตั้งอะไรเพิ่ม เปิด DevTools ด้วย F12 สลับไปที่แท็บ Network กด reload หน้าเว็บ รอให้โหลดจบ แล้วคลิกขวาในรายการ request แล้วเลือก "Save all as HAR" ไฟล์เดียวนี้คือเรื่องราวครบถ้วนว่าหน้าเว็บของคุณถูกประกอบขึ้นมาอย่างไร request ต่อ request

จุดที่ทำให้เครื่องมือนี้ต่างจากเครื่องมืออื่นคือตำแหน่งที่การวิเคราะห์เกิดขึ้น นั่นคือในเบราว์เซอร์ของคุณล้วน ๆ ไฟล์ HAR เป็นข้อมูลที่อ่อนไหว เพราะมีทั้ง URL, query string, cookie และบางครั้งคือ token ใน header การใช้ HAR File Analyzer จึงไม่มีการอัปโหลดไปที่เซิร์ฟเวอร์ใด ๆ คุณจึงตรวจสอบ capture จากระบบภายใน, staging environment หรือ flow ที่ต้องล็อกอินได้อย่างปลอดภัย

ทำไมต้องใช้ HAR File Analyzer?

• ไม่ต้องติดตั้งอะไรเลย ไม่มี CLI ให้ลง ไม่มี desktop app ให้โหลด ขอแค่มีเบราว์เซอร์ก็วิเคราะห์ไฟล์ HAR ได้ทันที
• ข้อมูลไม่หลุดออกจากเครื่อง การประมวลผลเป็นแบบ client-side 100% ซึ่งสำคัญมาก เพราะไฟล์ HAR มักมี session cookie, API key และข้อมูลส่วนบุคคลที่ไม่ควรวางลงเซิร์ฟเวอร์ที่ไม่รู้จัก
• ไตรแอจได้ทันที waterfall และอันดับ 5 อันดับ request ที่ช้าที่สุดชี้ไปที่คอขวดให้ก่อนที่คุณจะได้อ่าน JSON แม้แต่บรรทัดเดียว
• เห็นความล้มเหลวได้ในแวบเดียว สรุปแยกตามกลุ่ม status code (2xx, 3xx, 4xx, 5xx) เผยให้เห็น asset ที่พัง, API ที่ fail และเหตุการณ์ฝั่งเซิร์ฟเวอร์ที่ performance score ธรรมดามองไม่เห็น
• รู้น้ำหนักหน้าเว็บ ขนาด transfer รวมบอกได้ว่าหน้าเว็บชี้เพราะ "หนักเกิน" หรือชี้เพราะมีบาง request "ตอบช้า"
• เอาไปอ้างอิงได้ ส่งออกผลวิเคราะห์เป็น CSV หรือ text summary แนบไปกับ bug report หรือ performance ticket เพื่อให้ทุกคนคุยกันบนตัวเลขชุดเดียวกัน

ฟีเจอร์หลัก

รายละเอียดที่น่ารู้อีกเล็กน้อย:

• มีทางเข้าสองทาง ลากไฟล์ .har มาวาง หรือจะ paste JSON ของ HAR ตรง ๆ ก็ได้ เหมาะกับกรณีที่เพื่อนร่วมงานส่งข้อความมาแทนไฟล์
• อ่านได้แม้ capture ใหญ่ capture ขนาดใหญ่จะถูกสรุปให้ waterfall ยังอ่านง่าย ส่วนตัวเลขรวมคำนวณจากทุก entry ไม่ใช่แค่แถวที่แสดง
• มี method, host และ URL กำกับ ทุกแถวยังแสดง HTTP method และ URL เต็ม ทำให้แยก tracking pixel ออกจาก checkout call ได้

วิธีการใช้งาน

1. เก็บไฟล์ HAR ใน Chrome, Edge หรือ Firefox: เปิด DevTools ไปที่แท็บ Network เปิด "Disable cache" ตามต้องการ กด reload หน้าเว็บ รอให้นิ่ง แล้วคลิกขวาที่รายการ request เลือก "Save all as HAR"
2. เปิดตัว analyzer เข้าไปที่ HAR File Analyzer แล้วลากไฟล์ .har ไปวางบนช่องอัปโหลด หรือ copy JSON มา paste ลงช่อง input
3. อ่านภาพรวมก่อน ดูจำนวน request ทั้งหมด, สรุปแยกกลุ่ม status code และขนาด transfer รวม เพื่อจับรูปร่างของ capture ภายใน 5 วินาที
4. สแกน waterfall มองหาแท่งที่ยาวและช่องว่างที่นาน อันดับ request ที่ช้าที่สุดด้านล่างจะบอกได้ทันทีว่า entry ไหนควรได้รับความสนใจ
5. ส่งออกแล้วลงมือแก้ ดาวน์โหลด CSV หรือ copy text summary ใส่ issue tracker แล้วแก้ตามที่ข้อมูลชี้ — ไม่ว่าจะเป็น endpoint ที่ช้า, asset ที่ใหญ่เกิน หรือ request ที่พัง

อ่าน Waterfall ให้เป็นเหมือน Performance Engineer

กายวิภาคของ waterfall แท่งแต่ละแท่งใน waterfall คือ request หนึ่งรายการที่ถูกแยกเป็น phase ต่าง ๆ ได้แก่ queueing (เบราว์เซอร์หน่วงไว้), DNS (แก้ hostname), TLS (เจรจาการเข้ารหัส), TTFB (รอ byte แรกจากเซิร์ฟเวอร์) และ download (รับ body) ข้อมูล phase เหล่านี้อยู่ใน timings object ของ HAR ดังนั้นแท่งเดียวก็บอกได้ว่าเวลาหายไปที่ไหน ไม่ใช่แค่ว่าเสียเวลาไป

TTFB ยาว กับ download ยาว ต่างกันอย่างไร สองปัญหานี้ต้องแก้คนละทาง TTFB ยาวหมายถึงเซิร์ฟเวอร์หรือเครือข่ายใช้เวลาก่อนจะส่งอะไรกลับมาเลย ให้สืบดู backend query, ประสิทธิภาพ origin, cold start หรือ redirect ส่วน download ยาวหมายถึงเซิร์ฟเวอร์ตอบไวแต่ payload ใหญ่หรือ bandwidth ช้า ให้ไปดู compression, น้ำหนักรูป และการ cache ผ่าน CDN แทน

วินิจฉัยจากกลุ่ม status code ถ้า 4xx พุ่งสูงผิดปกติ แปลว่ามักมี reference พัง เช่น asset ที่ 404 เพราะหายไปจาก build, 401/403 จาก session หมดอายุหรือสิทธิ์ไม่พอ หรือ 429 จาก rate limit ส่วน 5xx ที่โผล่มาเป็นกลุ่มชี้ไปที่เหตุการณ์ฝั่งเซิร์ฟเวอร์ตอนที่เก็บ capture และถ้า 3xx เยอะ แปลว่ามี redirect chain ซึ่งแต่ละ hop เพิ่ม round trip เต็ม ๆ ก่อนเนื้อหาจริงจะเริ่มโหลด

จุดร้อนเรื่องขนาดข้อมูลและการ cache ลองจัดเรียงตามน้ำหนักในใจ ถ้ามีรูปหรือ bundle ไม่กี่ตัวกิน total transfer size เกือบหมด นั่นคือจุดที่ compression, ฟอร์แมตรุ่นใหม่ หรือ lazy loading จะคุ้มค่าที่สุด และถ้า asset ใหญ่ตัวเดิมถูกดาวน์โหลดใหม่ทุกครั้งที่เปิดหน้า cache header ของมันอาจหายไป — การแก้ที่เซิร์ฟเวอร์จุดเดียวช่วยทุก visitor ได้

ตัวอย่างจริงสั้น ๆ นึกภาพหน้าเว็บที่ชี้แบบคลาสสิก ไฟล์ HTML มาถึงใน 300 ms — ผ่าน bundle app.js หลักใช้ 900 ms เพราะหนัก 1.8 MB แบบไม่ compress จากนั้นหน้าเว็บเรียก POST /api/reports ที่ค้างใน TTFB นาน 2.6 วินาทีแล้วตอบ 500: endpoint นี้คือคอขวด และมันพังซะด้วย สคริปต์ tracking ถูกดึงช้าแล้วโดน ad blocker จน 404 ส่วน /api/search ที่ 404 เผยว่า endpoint ถูกถอดไปแล้วแต่โค้ดยังเรียกอยู่ waterfall เดียว เจอทั้ง 4 ประเด็น — ไม่ต้องเดาเลยสักนิด

กรณีการใช้งานจริง

ตั๋วซัพพอร์ต: ขอไฟล์ HAR จากผู้ใช้

ประโยคว่า "เว็บชี้" แก้ไม่ได้เลย แต่ไฟล์ HAR แก้ได้ ขอให้ผู้ใช้เจอปัญหาซ้ำหนึ่งครั้งโดยเปิดแท็บ Network ค้างไว้แล้วส่ง capture มา คำร้องเรียนคลุมเครือจะกลายเป็นข้อมูลชัดเจน — request, timing และความล้มเหลวจริงจากเครือข่ายและเครื่องของเขาเอง เพราะ analyzer ทำงานฝั่ง client ผู้ใช้ยังมั่นใจได้ว่า capture ของเขาอยู่บนเครื่องตัวเองก่อนแชร์ด้วย

ดีบักสคริปต์ Third-Party

แท็ก analytics, chat widget และสคริปต์โฆษณาขึ้นชื่อว่าลากหน้าเว็บให้ชี้ เก็บ HAR แบบปกติหนึ่งชุด แล้วอีกชุดตอน block host ของ third-party ไว้ อันดับ request ที่ช้าที่สุดจะเรียกชื่อตัวปัญหาพร้อม timing จริง — เป็นหลักฐานที่ส่งให้ vendor ได้ แทนที่จะส่งความรู้สึกไปให้เขาเดา

เปรียบเทียบก่อนและหลังปรับปรุง

ก่อนเริ่ม optimize เก็บ HAR เป็น baseline ไว้ หลัง bundle ใหม่, compress รูป หรือเพิ่ม CDN เสร็จ เก็บอีกชุดในเงื่อนไขเดิม เทียบ total transfer size, จำนวน 4xx/5xx และ request ที่ช้าที่สุดเคียงกัน ตัวเลขจากสอง capture เทียบกันชนะความเห็นใด ๆ ว่าการเปลี่ยนแปลงช่วยจริงหรือไม่

รายงาน Latency ของ API

Product manager และทีม backend ไม่ค่อยอยากดู network dump ดิบ ๆ สิ่งที่ทำให้งานปรับปรุง performance ได้ priority คือ summary ของ endpoint ที่ช้าที่สุด จัดกลุ่มตาม host และ duration export ออกจาก analyzer แล้ว paste ลง ticket ได้เลย

แนวปฏิบัติที่ดี

• ลบ header และ cookie ที่อ่อนไหวก่อนแชร์ ไฟล์ HAR อาจมี Authorization header, ค่า Set-Cookie และ token ต่าง ๆ ควรแก้ไข (redact) ด้วย text editor ก่อนส่ง capture ให้คนนอกทีม
• เก็บ capture บน profile ที่สะอาด ใช้หน้าต่าง incognito พร้อมเปิด "Disable cache" เพื่อไม่ให้ extension หรือ cache เก่าบิดเบือน timing
• จดเงื่อนไขเครือข่ายไว้ด้วย บันทึกว่าตอนนั้น throttle อยู่หรือเปล่า ใช้ VPN หรือเน็ตมือถือ — capture ที่เก็บบนไฟเบอร์เร็ว ๆ จะหน้าตาต่างจากของผู้ใช้จริงมาก
• เทียบให้เหมือนกันทุกอย่าง หน้าเดิม, สถานะ cache เดิม, เครือข่ายแบบเดิม สำหรับ capture ก่อน-หลัง ไม่อย่างนั้นผลเทียบก็เป็นแค่ noise
• เก็บ capture ให้กระชับ ฟิลเตอร์ network log ให้เหลือแค่โดเมนที่สนใจ เพื่อให้ไฟล์ HAR เล็กและ waterfall อ่านง่าย
• เก็บสองรอบเมื่อเรื่องสำคัญ capture หนึ่งชุดคือ sample สองชุดที่ผลสอดคล้องกันคือหลักฐาน — ถ้า request เดียวกันช้าทั้งสองรอบ นั่นคือ finding จริง

คราวหน้าที่ใครบอกว่า "เว็บมันชี้" อย่าเพิ่งเดา เปิด DevTools เซฟ HAR แล้วหย่อนลง HAR File Analyzer ได้คำตอบภายในไม่กี่วินาทีว่าปัญหาคือเซิร์ฟเวอร์ช้า, หน้าเว็บหนัก หรือ request พัง — และ waterfall จะช่วยอธิบายให้ทั้งทีมเห็นภาพเดียวกันด้วย

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• HAR to cURL Converter — แปลง request จาก capture เป็นคำสั่ง cURL พร้อมรันได้ทันที
• JSON Formatter — จัดรูปแบบและอ่าน JSON ดิบของ HAR เมื่อต้องการรายละเอียดระดับ entry
• URL Parser — แยกส่วน query string ยาว ๆ ที่มักซ่อนอยู่ใน URL ของ capture

ขอให้ทุก waterfall จบลงด้วยแท่งสีเขียวและการวิเคราะห์ที่ราบรื่น

คำถามที่พบบ่อย

ถ: ไฟล์ HAR ของฉันถูกอัปโหลดไปที่เซิร์ฟเวอร์หรือเปล่า?

ตอบ: ไม่ HAR File Analyzer ประมวลผลและแสดงผล capture ทั้งหมดในเบราว์เซอร์ของคุณ ไฟล์ทั้งหมด รวมถึง cookie หรือ token ที่อยู่ข้างใน ไม่เคยออกจากเครื่องของคุณ

ถ: ไฟล์ HAR คืออะไรกันแน่?

ตอบ: HAR ย่อมาจาก HTTP Archive เป็นไฟล์ JSON ที่บันทึกทุก network request ที่หน้าเว็บเรียก ทั้ง timing, status code, header และขนาด เบราว์เซอร์หลักทุกตัว export ออกมาได้จากแท็บ Network ของ DevTools

ถ: เก็บไฟล์ HAR ยังไง?

ตอบ: เปิด DevTools (F12) ไปที่แท็บ Network กด reload หน้าเว็บแล้วรอจนโหลดจบ จากนั้นคลิกขวาในรายการ request แล้วเลือก "Save all as HAR" ไฟล์ .har ที่ได้พร้อมนำไปวิเคราะห์ทันที

ถ: 4xx กับ 5xx เหมือนกันหรือเปล่า?

ตอบ: ไม่เหมือน 4xx หมายถึงฝั่ง client ส่งคำขอที่ผิด — asset หาย, session หมดอายุ หรือ resource ถูก block ส่วน 5xx หมายถึงเซิร์ฟเวอร์ประมวลผลคำขอที่ถูกต้องไม่สำเร็จ การแยกตามกลุ่ม status code ช่วยให้รู้ว่าต้องไปสืบฝั่งไหน

ถ: capture ที่มี request เป็นพัน ๆ รายการ ใช้ได้ไหม?

ตอบ: ได้ ตัวเลขสรุปครอบคลุมทุก entry ในไฟล์ ส่วน waterfall จะแสดงเฉพาะแถวที่เกี่ยวข้องที่สุด เพื่อให้กราฟยังอ่านง่ายแม้ capture จะใหญ่มาก