FlowingDev

File HAR, dijelaskan: Perekam kotak hitam browser kamu

Pelajari apa itu file HAR (HTTP Archive), bagaimana file ini merekam setiap request jaringan yang dibuat browser kamu, dan kenapa ini penting banget buat debugging performa web.

Coba tool-nya: Penampil HAR

Dalam satu kalimat

File HAR adalah log berformat JSON dari interaksi browser web dengan sebuah situs, yang menangkap setiap request dan response jaringan secara super detail untuk dianalisis nanti.

Masalah yang diselesaikannya

Bayangin deh: seorang user di belahan dunia lain nge-DM kamu, "Aplikasi lu lemot banget, gak bisa dipake." Kamu coba. Lancar jaya. Mereka bilang rusak. Kamu bilang di komputermu aman-aman aja. Buntu.

Ini adalah drama klasik "katanya-vs-katanya" dalam dunia web development. Sebelum ada tool browser modern, nge-debug masalah jaringan jarak jauh itu mimpi buruk: nebak-nebak, ngubek-ngubek log server, dan minta user non-teknis buat jelasin pesan error yang aneh-aneh. Bahkan dengan munculnya DevTools browser dan tab Network-nya yang keren itu, masalahnya tetap ada: datanya cuma sementara. Kamu nggak bisa dengan mudah "membotolkannya" dan mengirimkannya ke teman kerja. Screenshot grafik waterfall nggak menceritakan keseluruhan cerita.

Masuklah format HTTP Archive, atau HAR. Diciptakan oleh Web Performance Working Group dari W3C, format ini dirancang untuk menjadi format standar yang bisa dibagikan untuk, ya, mengarsipkan transaksi HTTP. Ini ibaratnya versi digital dari menaruh perekam kotak hitam di browser pengguna.

File HAR menyelesaikan masalah "di komputer saya bisa" dengan menangkap keseluruhan percakapan jaringan antara browser dan server saat memuat halaman web tertentu. File ini merekam setiap request untuk gambar, script, font, atau panggilan API. File ini mencatat header yang dikirim, cookie yang dipertukarkan, redirect yang diikuti, dan yang paling penting, timing yang presisi untuk setiap tahap request.

Ini memungkinkan seorang developer di Jakarta melihat persis apa yang dialami oleh pengguna di Singapura, milidetik demi milidetik, tanpa harus menebak-nebak. Ini membuat bug jaringan yang sifatnya sementara dan sulit direproduksi menjadi bisa dianalisis, dan mengubah keluhan samar "lemot" menjadi data yang bisa ditindaklanjuti.

Cara kerjanya di balik kap mesin

Pada dasarnya, file HAR itu bukan sihir. Cuma file JSON gede yang terstruktur aja. Kamu bisa buka satu file di text editor dan lihat semuanya, meskipun viewer khusus akan membuatnya jauh lebih mudah untuk dibaca. Yuk, kita intip isinya.

Struktur Besarnya: Cuma JSON Kok

Sebuah file HAR berisi satu objek JSON level atas dengan satu kunci: log. Semua yang lain ada di dalam objek log ini.

{
  "log": {
    "version": "1.2",
    "creator": { "name": "Chrome", "version": "118.0.0.0" },
    "browser": { "name": "Chrome", "version": "118.0.0.0" },
    "pages": [ /* ... satu atau lebih objek page ... */ ],
    "entries": [ /* ... satu atau lebih objek request/response ... */ ]
  }
}
  • version: Versi spesifikasi HAR, biasanya "1.2".
  • creator / browser: Metadata tentang tool dan browser apa yang menghasilkan file ini. Berguna untuk konteks.
  • pages: Sebuah array yang mendeskripsikan halaman utama atau halaman-halaman yang dimuat. Ini mencakup judul halaman dan timing untuk event tingkat tinggi seperti onLoad dan onContentLoad.
  • entries: Ini dia bintang utamanya. Ini adalah array panjang di mana setiap objek mewakili satu request jaringan dan response yang bersangkutan.

Bintang Utamanya: Array entries

Saat kamu menganalisis file HAR, 99% waktumu akan dihabiskan di dalam entries. Setiap entry adalah berkas lengkap tentang satu sumber daya.

Berikut adalah tampilan sederhana dari satu entry:

{
  "startedDateTime": "2023-10-27T10:30:05.123Z",
  "time": 258.45,
  "request": { /* ... detail dari request ... */ },
  "response": { /* ... detail dari response ... */ },
  "timings": { /* ... rincian performa yang juicy ... */ },
  "pageref": "page_1"
}
  • startedDateTime: Timestamp UTC persis saat request dimulai.
  • time: Total waktu yang berlalu untuk request dalam milidetik, dari awal hingga akhir.
  • request: Sebuah objek yang berisi semua yang dikirim browser ke server.
  • response: Sebuah objek yang berisi semua yang dikirim server kembali.
  • timings: Tambang emas untuk debugging performa. Kita akan bedah ini selanjutnya.
  • pageref: Sebuah ID yang menghubungkan request ini kembali ke salah satu pages di dalam array pages.

Anatomi sebuah Request dan Response

Objek request dan response adalah cerminan dari apa yang akan kamu lihat di DevTools.

Detail objek request:

  • method: GET, POST, PUT, dll.
  • url: URL lengkap dari sumber daya.
  • headers: Sebuah array dari semua request header, seperti User-Agent, Accept, dan Cookie.
  • queryString: Sebuah array dari parameter query apa pun di URL.
  • postData: Untuk request POST, ini berisi payload, seperti data formulir atau body JSON.

Detail objek response:

  • status: Kode status HTTP (misalnya, 200, 404, 500).
  • statusText: Frasa alasan (misalnya, OK, Not Found).
  • headers: Sebuah array dari semua response header, seperti Content-Type, Cache-Control, dan Set-Cookie.
  • content: Sebuah objek yang mendeskripsikan body response, termasuk size, mimeType, dan seringkali body itu sendiri di properti text (meskipun ini bisa dihilangkan untuk menghemat ruang atau demi keamanan).

Rincian Waterfall Timings

Objek timings adalah yang menjadi sumber tenaga untuk grafik waterfall warna-warni di viewer HAR. Ini memecah total time request menjadi fase-fase penyusunnya. Memahami ini adalah kunci untuk mendiagnosis "mengapa" sebuah request lambat.

Timing Artinya
blocked Waktu yang dihabiskan request untuk menunggu di antrian browser sebelum bisa dimulai. Seringkali karena batas koneksi.
dns Waktu yang dihabiskan untuk pencarian DNS. Nilai yang tinggi mungkin menunjukkan penyedia DNS yang lambat.
connect Waktu yang dibutuhkan untuk membuat koneksi TCP ke server. Termasuk waktu ssl.
ssl (Bagian dari connect) Waktu untuk handshake SSL/TLS. Nilai yang tinggi bisa menunjuk ke masalah konfigurasi server atau jaringan.
send Waktu yang dihabiskan untuk mengirim request HTTP ke server. Biasanya sangat singkat.
wait Time To First Byte (TTFB). Ini yang paling krusial. Waktu yang dihabiskan menunggu server memproses request dan mengirim byte pertama dari response. Waktu wait yang lama hampir selalu merupakan masalah backend.
receive Waktu yang dihabiskan untuk mengunduh body response dari server. Waktu receive yang lama pada file kecil bisa menunjukkan jaringan yang lambat; pada file besar, itu wajar.

Total time untuk sebuah entry adalah jumlah dari timing-timing individual ini (yang non-negatif). Ketika viewer HAR menunjukkan sebuah bar untuk request, secara visual ia menumpuk nilai-nilai timings ini dari ujung ke ujung.

Kisah dari dunia nyata

Kasus Kelambatan Misterius

Seorang PM yang panik mengirim pesan ke tim: "Halaman checkout yang baru super lemot buat klien terbesar kita! Mereka ngancem mau cabut!" Tim dev mencoba alur checkout. Ngebut banget. Klien bersikeras butuh 20 detik untuk konfirmasi pesanan. Alih-alih bolak-balik argumen tanpa hasil, lead dev memandu klien untuk mengekspor file HAR.

Saat membuka file tersebut, masalahnya langsung terlihat jelas. Di dalam entries, request POST ke /api/v1/finalize_order memiliki time total 20.145ms. Melihat objek timings, wait (TTFB) nya lebih dari 20.000ms. Server backend butuh 20 detik untuk merespons. Ternyata klien spesifik ini memiliki riwayat pesanan yang sangat besar, dan query database yang tidak dioptimalkan mengalami timeout, tetapi hanya untuk akun mereka. File HAR memberikan bukti tak terbantahkan yang menunjuk langsung ke proses backend tertentu.

Pelajaran yang bisa diambil: File HAR menangkap kondisi spesifik pengguna (seperti data akun) yang tidak dapat kamu tiru, mengubah misteri menjadi laporan bug yang terarah.

Biang Kerok Bundle yang Gendut

Sebuah situs marketing baru diluncurkan dan bounce rate-nya meroket. Rasanya berat aja. Seorang developer front-end membuka situs itu, membuka DevTools, merekam sesi, dan mengekspor HAR.

Di viewer HAR, mereka mengurutkan entri berdasarkan ukuran. Di paling atas ada main.acb123.js dengan ukuran raksasa 5.2 MB. Waterfall menunjukkan bahwa ini adalah sumber daya yang memblokir render; tidak ada yang muncul di halaman sampai raksasa ini selesai diunduh. Waktu receive-nya saja beberapa detik, bahkan dengan koneksi cepat. Lebih parah lagi, melihat header response untuk entri ini, mereka melihat server tidak mengirim header Content-Encoding: gzip, meskipun browser mengirim Accept-Encoding: gzip di header request. Bundle JavaScript itu tidak dikompres.

Pelajaran yang bisa diambil: File HAR membuatnya sangat mudah untuk menemukan biang keladi performa seperti aset berukuran besar dan kesalahan konfigurasi server yang membunuh waktu muat halamanmu.

Looping Redirect Tanpa Henti

Seorang pengguna mengeluh tidak bisa login. Mereka memasukkan kredensial, mengklik "Log In," dan langsung dilempar kembali ke halaman login tanpa error. Ini adalah looping klasik. Tim support meminta pengguna untuk memberikan file HAR dari upaya login tersebut.

Daftar entries di HAR menceritakan sebuah kisah yang jelas:

  1. POST /login berhasil dan mendapatkan 302 Redirect ke /dashboard. Response-nya menyertakan header Set-Cookie dengan token sesi.
  2. Browser mengikuti redirect dan membuat request GET /dashboard.
  3. Server merespons GET /dashboard dengan 302 Redirect kembali ke /login.

Kenapa? Dev memeriksa entri request GET /dashboard. Header Cookie-nya tidak menyertakan token sesi. Kemudian mereka memeriksa response dari POST /login awal. Header Set-Cookie-nya adalah session_id=...; Secure; HttpOnly. Flag Secure berarti browser hanya akan mengirim cookie melalui HTTPS. Pengguna berada di lingkungan http://staging.example.com. Browser dengan benar menolak mengirim cookie yang aman melalui koneksi yang tidak aman, sehingga server tidak pernah melihat mereka sebagai sudah login.

Pelajaran yang bisa diambil: File HAR memberimu pemutaran ulang yang sempurna, frame-demi-frame, dari redirect HTTP dan pertukaran header, memungkinkan untuk men-debug alur otentikasi kompleks yang gagal secara diam-diam.

Kesalahan dan jebakan umum

  • Lupa mencentang "Preserve log". Jika bug kamu melibatkan perpindahan dari halaman A ke halaman B, kamu harus mengaktifkan opsi "Preserve log" (atau yang setara) di DevTools. Jika tidak, log akan dihapus saat navigasi, dan file HAR kamu hanya akan berisi request untuk halaman B.
  • Membagikan data sensitif. File HAR adalah perekam tanpa pandang bulu. Mereka akan menangkap kunci API, token sesi di cookie, dan informasi identitas pribadi (PII) di dalam body POST. Selalu bersihkan (sanitize) file HAR sebelum membagikannya di bug tracker publik atau forum.
  • Salah menafsirkan waktu blocked. Waktu blocked yang tinggi tidak selalu berarti jaringan sedang padat. Browser memiliki batas berapa banyak koneksi paralel yang akan dibuka ke satu domain (biasanya 6). Jika kamu menembakkan 20 request gambar sekaligus, 14 di antaranya akan berada dalam status blocked, menunggu salah satu dari 6 yang pertama selesai.
  • Mengabaikan status cache. Jika kamu menguji performa pemuatan pertama kali, kamu perlu merekam dengan cache browser dinonaktifkan. Jika tidak, kamu akan melihat banyak response 304 Not Modified atau request yang selesai dalam waktu kurang dari satu milidetik, yang tidak mencerminkan pengalaman pengguna baru.

Kenapa ini wajib masuk radarmu

Kamu harus berpikir untuk menggunakan file HAR setiap kali komunikasi jaringan menjadi tersangka potensial.

  • Ketika pengguna melaporkan masalah performa yang tidak bisa kamu reproduksi.
  • Ketika kamu perlu mengoptimalkan halaman yang lambat dan ingin mengidentifikasi bottleneck terbesar.
  • Ketika kamu sedang men-debug alur API multi-langkah, seperti login OAuth atau proses pembayaran, dan perlu melihat urutan kejadian yang persis.
  • Ketika kamu perlu mengajukan laporan bug ke layanan pihak ketiga (seperti CDN atau penyedia API) dan ingin memberi mereka bukti masalah yang tak terbantahkan. File HAR adalah bahasa universal untuk masalah jaringan.

Gali lebih dalam

Teori beres. Saatnya praktik — 100% di browser kamu.

Coba tool-nya: Penampil HAR