Performa Front-End 2021: Menetapkan Tujuan Realistis

Panduan ini telah didukung dengan baik oleh teman-teman kami di LogRocket, layanan yang menggabungkan pemantauan kinerja frontend , pemutaran ulang sesi, dan analisis produk untuk membantu Anda membangun pengalaman pelanggan yang lebih baik. LogRocket melacak metrik utama, termasuk. DOM selesai, waktu untuk byte pertama, penundaan input pertama, CPU klien dan penggunaan memori. Dapatkan uji coba gratis LogRocket hari ini.

Daftar isi

1. Persiapan: Perencanaan Dan Metrik
2. Menetapkan Tujuan yang Realistis
3. Mendefinisikan Lingkungan
4. Pengoptimalan Aset
5. Membangun Optimasi
6. Pengoptimalan Pengiriman
7. Jaringan, HTTP/2, HTTP/3
8. Pengujian Dan Pemantauan
9. Kemenangan Cepat
10. Semuanya dalam satu halaman
11. Unduh Daftar Periksa (PDF, Halaman Apple, MS Word)
12. Berlangganan buletin email kami agar tidak ketinggalan panduan berikutnya.

Menetapkan Tujuan yang Realistis

1. Waktu respons 100 milidetik, 60 fps.
   Agar interaksi terasa mulus, antarmuka memiliki 100 ms untuk merespons masukan pengguna. Lebih lama dari itu, dan pengguna menganggap aplikasi itu lamban. RAIL, model kinerja yang berpusat pada pengguna memberi Anda target yang sehat : Untuk memungkinkan respons <100 milidetik, halaman harus mengembalikan kontrol ke utas utama paling lambat setelah setiap <50 milidetik. Perkiraan Latensi Input memberi tahu kita jika kita mencapai ambang itu, dan idealnya, itu harus di bawah 50 md. Untuk titik-titik bertekanan tinggi seperti animasi, yang terbaik adalah tidak melakukan hal lain di mana Anda bisa dan minimum absolut di mana Anda tidak bisa.

   

   Selain itu, setiap bingkai animasi harus diselesaikan dalam waktu kurang dari 16 milidetik, sehingga mencapai 60 bingkai per detik (1 detik 60 = 16,6 milidetik) — sebaiknya di bawah 10 milidetik. Karena browser membutuhkan waktu untuk melukis bingkai baru ke layar, kode Anda harus selesai dieksekusi sebelum mencapai tanda 16,6 milidetik. Kami mulai berdiskusi tentang 120fps (misalnya layar iPad Pro berjalan pada 120Hz) dan Surma telah membahas beberapa solusi kinerja rendering untuk 120fps, tapi itu mungkin bukan target yang kami lihat dulu .

   Jadilah pesimis dalam ekspektasi kinerja, tetapi optimis dalam desain antarmuka dan gunakan waktu idle dengan bijak (periksa idle, idle-sampai-mendesak dan react-idle). Jelas, target ini berlaku untuk kinerja waktu proses, bukan kinerja pemuatan.

2. FID < 100 md, LCP < 2.5 d, TTI < 5 d pada 3G, Anggaran ukuran file penting < 170KB (gzip).
   Meskipun mungkin sangat sulit untuk dicapai, tujuan akhir yang baik adalah Waktu untuk Interaktif di bawah 5 detik, dan untuk kunjungan berulang, bidik di bawah 2 detik (hanya dapat dicapai dengan pekerja layanan). Bertujuan untuk Cat Isi Terbesar di bawah 2,5 detik dan meminimalkan Waktu Pemblokiran Total dan Pergeseran Tata Letak Kumulatif . Penundaan Input Pertama yang dapat diterima adalah di bawah 100 md–70 md. Seperti disebutkan di atas, kami mempertimbangkan baseline sebagai ponsel Android seharga $200 (misalnya Moto G4) pada jaringan 3G yang lambat, diemulasi pada 400ms RTT dan kecepatan transfer 400kbps.

   Kami memiliki dua kendala utama yang secara efektif membentuk target yang masuk akal untuk pengiriman konten yang cepat di web. Di satu sisi, kami memiliki kendala pengiriman jaringan karena TCP Mulai Lambat. 14KB pertama dari HTML — 10 paket TCP, masing-masing 1460 byte, menghasilkan sekitar 14,25 KB, meskipun tidak diartikan secara harfiah — adalah bagian muatan yang paling penting, dan satu-satunya bagian dari anggaran yang dapat dikirimkan dalam perjalanan pulang pergi pertama ( hanya itu yang Anda dapatkan dalam 1 detik pada 400ms RTT karena waktu bangun seluler).

   

   ( Catatan : karena TCP umumnya kurang memanfaatkan koneksi jaringan dalam jumlah yang signifikan, Google telah mengembangkan TCP Bottleneck Bandwidth dan RRT ( BBR ), sebuah algoritma kontrol aliran TCP yang dikendalikan penundaan TCP. Dirancang untuk web modern, ia merespons kemacetan yang sebenarnya, daripada kehilangan paket seperti TCP, ini jauh lebih cepat, dengan throughput yang lebih tinggi dan latensi yang lebih rendah — dan algoritme bekerja secara berbeda. ( terima kasih, Victor, Barry! )

   Di sisi lain, kami memiliki kendala perangkat keras pada memori dan CPU karena penguraian JavaScript dan waktu eksekusi (kami akan membicarakannya secara rinci nanti). Untuk mencapai tujuan yang dinyatakan dalam paragraf pertama, kita harus mempertimbangkan anggaran ukuran file penting untuk JavaScript. Pendapat bervariasi tentang berapa anggaran yang seharusnya (dan itu sangat tergantung pada sifat proyek Anda), tetapi anggaran 170KB JavaScript yang sudah di-gzip akan membutuhkan waktu hingga 1 detik untuk diurai dan dikompilasi pada ponsel kelas menengah. Dengan asumsi bahwa 170KB berkembang menjadi 3x ukuran itu ketika didekompresi (0,7MB), itu sudah bisa menjadi lonceng kematian dari pengalaman pengguna yang "layak" di Moto G4/G5 Plus.

   

   Dalam kasus situs web Wikipedia, pada tahun 2020, secara global, eksekusi kode menjadi 19% lebih cepat untuk pengguna Wikipedia. Jadi, jika metrik kinerja web Anda dari tahun ke tahun tetap stabil, itu biasanya merupakan tanda peringatan karena Anda sebenarnya mengalami kemunduran saat lingkungan terus membaik (detail dalam posting blog oleh Gilles Dubuc).

   Jika Anda ingin menargetkan pasar yang sedang berkembang seperti Asia Tenggara, Afrika, atau India, Anda harus melihat serangkaian kendala yang sangat berbeda. Addy Osmani mencakup kendala ponsel berfitur utama, seperti sedikit biaya rendah, perangkat berkualitas tinggi, tidak tersedianya jaringan berkualitas tinggi dan data seluler yang mahal — bersama dengan anggaran PRPL-30 dan pedoman pengembangan untuk lingkungan ini.

   

   

   Faktanya, Alex Russell dari Google merekomendasikan untuk membidik 130-170KB gzip sebagai batas atas yang masuk akal. Dalam skenario dunia nyata, sebagian besar produk bahkan tidak mendekati: ukuran bundel rata-rata saat ini adalah sekitar 452KB, yang naik 53,6% dibandingkan dengan awal 2015. Pada perangkat seluler kelas menengah, yang menyumbang 12-20 detik untuk Time -Untuk-Interaktif .

   

   Kami juga bisa melampaui anggaran ukuran bundel. Misalnya, kita dapat menetapkan anggaran kinerja berdasarkan aktivitas thread utama browser, yaitu waktu melukis sebelum memulai render, atau melacak CPU hog front-end. Alat seperti Calibre, SpeedCurve, dan Bundlesize dapat membantu Anda mengendalikan anggaran, dan dapat diintegrasikan ke dalam proses pembuatan Anda.

   Terakhir, anggaran kinerja mungkin tidak boleh berupa nilai tetap . Tergantung pada koneksi jaringan, anggaran kinerja harus beradaptasi, tetapi muatan pada koneksi yang lebih lambat jauh lebih "mahal", terlepas dari bagaimana mereka digunakan.

   Catatan : Mungkin terdengar aneh untuk menetapkan anggaran yang begitu kaku pada saat HTTP/2 yang meluas, 5G dan HTTP/3 yang akan datang, ponsel yang berkembang pesat, dan SPA yang berkembang pesat. Namun, mereka terdengar masuk akal ketika kita berurusan dengan sifat jaringan dan perangkat keras yang tidak dapat diprediksi, termasuk segala sesuatu mulai dari jaringan yang padat hingga infrastruktur yang berkembang perlahan, hingga batas data, browser proxy, mode hemat data, dan biaya roaming yang licik.

Daftar isi

1. Persiapan: Perencanaan Dan Metrik
2. Menetapkan Tujuan yang Realistis
3. Mendefinisikan Lingkungan
4. Pengoptimalan Aset
5. Membangun Optimasi
6. Pengoptimalan Pengiriman
7. Jaringan, HTTP/2, HTTP/3
8. Pengujian Dan Pemantauan
9. Kemenangan Cepat
10. Semuanya dalam satu halaman
11. Unduh Daftar Periksa (PDF, Halaman Apple, MS Word)
12. Berlangganan buletin email kami agar tidak ketinggalan panduan berikutnya.