Performance Engineering Aplikasi Web: Budget Performa, Profiling, Load Testing, dan Core Web Vitals

Halaman terasa cepat di laptop pengembang, tetapi lambat di ponsel pengguna. Kuliah ini mengganti perasaan itu dengan budget performa yang diperiksa otomatis. Materi ini bagian dari mata kuliah Pengembangan Aplikasi Web dan melanjutkan Bab 2 sampai Bab 4, yang sudah menyiapkan baseline, perbaikan query, dan cache. Budget performa menetapkan kapan aplikasi dianggap cukup cepat, dan gate otomatis menolak setiap perubahan kode yang melanggarnya. Bila ada batas yang terlampaui, profiling menunjukkan bagian termahal, lalu pengukuran ulang di bawah beban memperlihatkan apakah angkanya sudah turun. Semua angka diukur pada aplikasi katalog buku (Python dan PostgreSQL 16) dengan 50.000 baris data. Yang dibahas: Tiga batas dalam budget performa: latency persentil 95 per alamat (rata-rata menyembunyikan pengalaman terburuk), response size setelah compress, dan ambang Core Web Vitals (LCP, INP, CLS) budget.json diperlakukan seperti kode, dan gate-budget.py keluar dengan status 1 bila satu batas saja terlampaui, sehingga Continuous Integration memblokir merge Angka lab menjadi gate sebelum merge, sedangkan angka lapangan dari kunjungan nyata dinilai pada persentil 75 Pengukur Core Web Vitals di halaman (web-vitals.ts) yang memakai PerformanceObserver dan mengirim laporan dengan navigator.sendBeacon saat halaman ditinggalkan Profiling dengan cProfile menunjukkan katalog penuh sibuk mengolah 50.000 baris, sementara agregat buku terlaris menghabiskan 99 persen waktunya menunggu basis data, sehingga keduanya butuh perbaikan yang berbeda Klien menunggu 43,06 ms untuk kerja server yang hanya sekitar 0,58 ms, akibat algoritma Nagle yang bertemu delayed ACK. Dengan TCP_NODELAY, persentil 50 menjadi 74 kali lebih cepat tanpa mengubah logika aplikasi Dengan gzip, response katalog penuh menyusut 15 kali, tetapi masih 34 kali di atas budget 8 KiB karena jumlah barisnya tetap Menekan ukuran JavaScript dengan tree shaking, code splitting, dan lazy loading Gambar dan font: ukuran sesuai tampilan, WebP dan AVIF, loading lazy (kecuali gambar LCP, yang memakai fetchpriority high), width dan height untuk mencegah CLS, serta font-display swap Streaming server-side rendering dengan chunked transfer encoding membuat byte pertama tiba dalam kurang dari 1 ms, sedangkan waktu totalnya tidak berubah Katalog berhalaman dengan batas ukuran yang ditegakkan di server berjalan 238 kali lebih cepat pada persentil 50 daripada katalog penuh Load testing closed loop dari 1 sampai 32 worker menemukan titik jenuh di sekitar 13 permintaan per detik, dan hukum Little dipakai untuk memeriksa silang angkanya Katalog penuh menyapu shared buffers PostgreSQL, jadi gate memakai warmup 30 permintaan, jeda 3 detik, dan mengukur alamat terberat paling akhir Empat latihan: menegakkan budget, memprofil dua alamat yang lambat, mencari titik jenuh, dan mengumpulkan Core Web Vitals dari browser Latihan membutuhkan Docker dengan Compose v2, Python 3, dan Node.js. Arahkan load generator hanya ke aplikasi milik sendiri. Bila diarahkan ke sistem orang lain tanpa izin tertulis, bebannya tidak bisa dibedakan dari serangan banjir permintaan. #PerformanceEngineering #CoreWebVitals #LoadTesting #WebPerformance #Profiling #PerformanceBudget #PengembanganAplikasiWeb #PostgreSQL #Python