Profilkan perjalanan pelanggan sebelum mengubah kode
Pilih satu rute dan interaksi penting, seperti membuka navigasi, memfilter hasil, atau mengirimkan formulir. Rekam di panel Performance Chrome DevTools dalam kondisi browser yang bersih. Ulangi tindakan tersebut dan ambil rekaman pada satu pengujian dengan CPU dibatasi serta satu pengujian di mesin pengembangan; jejak desktop dapat menyembunyikan pekerjaan yang mengganggu pada ponsel berkinerja lebih rendah.
Gunakan trace untuk menguji hipotesis sempit, bukan untuk menyalahkan komponen dari laporan bundel. Di Main flame chart, bar yang lebih lebar memakan waktu lebih lama dan bar bertumpuk menunjukkan call stack. Segitiga merah pada sebuah Task menunjukkan potensi long task; pilih itu dan ikuti tautan kode penginisiasi. Simpan trace sebelum-dan-sesudah untuk melihat perubahan yang berarti.
Rekam tepat sebelum aksi dan hentikan setelah hasil yang terlihat tercapai.
Pertahankan rute, status akun, dan urutan aksi konsisten.
Tugaskan setiap biaya teratas ke tim atau vendor yang dapat mengubahnya.
Baca trace sebagai antrean pekerjaan
Long task adalah ambang penyelidikan, bukan diagnosis lengkap. Spesifikasi W3C Long Tasks melaporkan tugas yang berlangsung 50 milidetik atau lebih. Lihat di bawah tugas untuk evaluasi JavaScript, event handler, perhitungan gaya, layout, atau paint. Call stack menunjukkan titik awal; linimasa menunjukkan apakah masalah berasal dari kode, rendering, atau frame pihak ketiga.
Prioritaskan biaya yang berulang selama interaksi bernilai. Handler pendek masih bisa terasa lambat jika memicu layout atau menunggu di belakang pekerjaan sebelumnya. Trace adalah pengukuran laboratorium, jadi konfirmasi perbaikan pada perangkat representatif dan, bila tersedia, dengan telemetri lapangan yang menjaga privasi.
Parsing saat startup memerlukan solusi berbeda dari handler setelah ketukan.
Temukan pola berulang ketika gaya ditulis lalu layout dibaca sebelum melakukan refaktor.
Lampirkan trace, skenario, dan biaya teratas ke item pekerjaan.
Kirim lebih sedikit kode pada saat yang tepat
Buat inventaris skrip berdasarkan rute dan tujuan. Hapus paket yang tidak terpakai, duplikat, eksperimen yang dihentikan, dan kode untuk fitur yang berakhir. Kemudian pisahkan fitur spesifik-rute atau yang jarang dipakai sehingga dimuat ketika diperlukan bukan di jalur awal. Pemecahan dinamis dapat mengurangi pekerjaan startup, tetapi dapat menciptakan jeda terlihat saat pengguna membutuhkan fitur segera.
Tanyakan apakah sebuah komponen membutuhkan framework sisi-klien penuh, apakah sebuah utilitas menggandakan kemampuan yang sudah ada, dan apakah HTML statis plus peningkatan kecil akan bekerja. Uji keadaan fallback modul yang ditunda. Halaman harus menunda kemampuan opsional secara anggun daripada menampilkan kontrol yang mati.
Dokumentasikan skrip mana yang diizinkan pada sebuah rute dan mengapa.
Pertimbangkan ini untuk editor opsional, peta, pemutar, atau tampilan pelaporan.
Uji autentikasi, aksesibilitas, pembayaran, dan penyelesaian formulir; minta tinjauan berkualifikasi ketika kontrol terpengaruh.
Pecah pekerjaan agar browser bisa merespons
Memberi nama fungsi kecil tidak membuatnya menjadi tugas browser terpisah ketika dijalankan secara sinkron. Untuk loop panjang, batch pekerjaan, perbarui status yang terlihat pengguna segera, lalu beri kesempatan (yield) sebelum melanjutkan. Itu memungkinkan browser memproses input dan rendering antar-batch.
Pada browser yang mendukungnya, scheduler.yield() mengembalikan kontrol kepada main thread lalu melanjutkan pekerjaan; lakukan deteksi fitur ini dan gunakan fallback untuk browser yang tidak mendukungnya. Jangan memberi kesempatan setelah setiap operasi kecil: ada overhead dan waktu penyelesaian dapat bertambah. Pilih batas berdasarkan pengukuran, pertahankan kemampuan pembatalan, dan cegah hasil usang menggantikan status yang lebih baru.
Tampilkan tanda terima atau progres sebelum tindak lanjut yang tidak terlihat.
Beri kesempatan sebelum pekerjaan terukur menjadi panjang, bukan sekali per item.
Panduan web.dev saat ini tidak merekomendasikan strategi baru berbasis isInputPending().
Pindahkan komputasi, bukan antarmuka, ke worker
Web Worker menjalankan skrip di thread latar yang terpisah dari thread eksekusi utama. Ini cocok untuk parsing mahal, transformasi data, pengindeksan pencarian, dan komputasi lain yang tidak memerlukan akses langsung ke antarmuka. Kirim input yang terdefinisi, kembalikan hasil yang terdefinisi, dan pertahankan rendering serta perubahan status terlihat di main thread.
Worker tidak selalu cocok. Worker tidak dapat memanipulasi DOM secara langsung atau menggunakan Window, dan komunikasi pesan biasanya menyalin data. Pembuatan worker, pemindahan data, dan koordinasi kesalahan dapat mengalahkan manfaat untuk perhitungan kecil. Ukur keseluruhan interaksi, hentikan worker yang tidak diperlukan, dan rancang fallback jika pekerjaan worker gagal.
Mulai dengan perhitungan yang input dan outputnya bisa diserialisasi dan diuji.
Buang hasil yang dibuat untuk filter, rute, atau aksi yang lebih lama.
Sampaikan progres bermakna melalui antarmuka normal.
Kelola JavaScript pihak ketiga sebagai dependensi produksi
Analitik, periklanan, eksperimen, embed sosial, pemutar video, dan widget dukungan dapat menambah permintaan, evaluasi JavaScript, iframe, dan dependensi. Skrip vendor mungkin diperlukan, tetapi berada di luar kontrol langsung tim aplikasi dan dapat memengaruhi kinerja, privasi, keamanan, dan kontinuitas. Inventarisasikan tujuannya, rute, kondisi pemuatan, pihak yang menyetujui, persyaratan persetujuan, dan pemilik penghapusan.
Di mana kondisi dan kontrak memungkinkan, bandingkan halaman representatif dengan dan tanpa satu origin pihak ketiga. Alat performa dapat mengekspos evaluasi mahal, payload, dan atribusi long-task. Pertahankan integrasi ringan atau ditunda hanya ketika nilai yang terdokumentasi membenarkan biaya yang terukur. Konfirmasikan konten inti dan pekerjaan transaksi utama ketika dependensi opsional lambat atau tidak ada.
Muat tag hanya pada rute dan kondisi yang membutuhkannya.
Sertakan perubahan tag-manager dalam tinjauan kinerja, privasi, keamanan, dan rollback.
Dokumentasikan dan uji cara menonaktifkan integrasi nonkritis.
Jadikan responsivitas sebagai pengaman rilis
Jadikan trace yang menunjukkan perbaikan sebagai pemeriksaan regresi kecil untuk perjalanan penting. Definisikan interaksi yang dicakup, batas perangkat atau CPU, respons yang diharapkan, dan reviewer. Padukan ini dengan tinjauan inventaris bundel dan pihak ketiga agar paket atau tag baru tidak diam-diam memperkenalkan kembali pekerjaan main thread.
Status Is UP menggunakan bukti ini untuk optimisasi proaktif dan remediasi aman, bukan untuk menggantikan pemantauan ketersediaan langsung. Sebelum perubahan berisiko tinggi, siapkan rollback dan verifikasi alur kritis setelah rilis. Hasil bervariasi menurut perangkat, jaringan, browser, konten, dan status akun; anggap ambang sebagai batas pengaman, bukan jaminan.
Minta trace sebelum-dan-sesudah untuk navigasi bersama, checkout, pencarian, atau bundel besar.
Ketahui feature flag, pengaturan tag, atau versi deployment yang mengembalikan perilaku yang diketahui baik.
Profil ulang setelah rilis besar, perubahan vendor, atau pergeseran campuran perangkat.