Performa Front-End 2021: Pengoptimalan Pengiriman

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.

Pengoptimalan Pengiriman

1. Apakah kita menggunakan defer untuk memuat JavaScript penting secara asinkron?
   Saat pengguna meminta halaman, browser mengambil HTML dan membuat DOM, lalu mengambil CSS dan membuat CSSOM, lalu membuat pohon rendering dengan mencocokkan DOM dan CSSOM. Jika ada JavaScript yang perlu diselesaikan, browser tidak akan mulai merender halaman sampai diselesaikan, sehingga menunda rendering. Sebagai pengembang, kita harus secara eksplisit memberi tahu browser untuk tidak menunggu dan mulai merender halaman. Cara melakukan ini untuk skrip adalah dengan atribut defer dan async dalam HTML.

   Dalam praktiknya, ternyata lebih baik menggunakan defer daripada async . Ah, apa bedanya lagi? Menurut Steve Souders, begitu skrip async tiba, skrip tersebut segera dieksekusi — segera setelah skrip siap. Jika itu terjadi sangat cepat, misalnya ketika skrip berada di cache aleady, itu sebenarnya dapat memblokir parser HTML. Dengan defer , browser tidak menjalankan skrip sampai HTML diuraikan. Jadi, kecuali Anda membutuhkan JavaScript untuk dieksekusi sebelum memulai render, lebih baik menggunakan defer . Selain itu, beberapa file async akan dieksekusi dalam urutan yang tidak deterministik.

   Perlu dicatat bahwa ada beberapa kesalahpahaman tentang async dan defer . Yang terpenting, async tidak berarti bahwa kode akan berjalan setiap kali skrip siap; itu berarti itu akan berjalan setiap kali skrip siap dan semua pekerjaan sinkronisasi sebelumnya selesai. Dalam kata-kata Harry Roberts, "Jika Anda meletakkan skrip async setelah skrip sinkronisasi, skrip async Anda hanya secepat skrip sinkronisasi paling lambat Anda."

   Juga, tidak disarankan untuk menggunakan async dan defer . Peramban modern mendukung keduanya, tetapi setiap kali kedua atribut digunakan, async akan selalu menang.

   Jika Anda ingin mempelajari lebih detail, Milica Mihajlija telah menulis panduan yang sangat mendetail tentang Membangun DOM lebih cepat, membahas detail parsing spekulatif, asinkron, dan penangguhan.

2. Lazy memuat komponen mahal dengan IntersectionObserver dan petunjuk prioritas.
   Secara umum, disarankan untuk memuat lambat semua komponen mahal, seperti JavaScript yang berat, video, iframe, widget, dan kemungkinan gambar. Pemuatan lambat bawaan sudah tersedia untuk gambar dan iframe dengan atribut loading (hanya Chromium). Di bawah tenda, atribut ini menunda pemuatan sumber daya hingga mencapai jarak yang dihitung dari area pandang.

   <!-- Lazy loading for images, iframes, scripts. Probably for images outside of the viewport. --> <img loading="lazy" ... /> <iframe loading="lazy" ... /> <!-- Prompt an early download of an asset. For critical images, eg hero images. --> <img loading="eager" ... /> <iframe loading="eager" ... />

   Ambang batas itu bergantung pada beberapa hal, mulai dari jenis sumber daya gambar yang diambil hingga jenis koneksi yang efektif. Namun eksperimen yang dilakukan menggunakan Chrome di Android menunjukkan bahwa pada 4G, 97,5% gambar paruh bawah yang dimuat lambat dimuat penuh dalam waktu 10 mdtk setelah terlihat, jadi gambar tersebut seharusnya aman.

   Kita juga dapat menggunakan atribut importance ( high atau low ) pada elemen <script> , <img> , atau <link> (hanya Blink). Faktanya, ini adalah cara yang bagus untuk mengurangi prioritas gambar di carousel, serta memprioritaskan ulang skrip. Namun, terkadang kita mungkin memerlukan kontrol yang lebih terperinci.

   <!-- When the browser assigns "High" priority to an image, but we don't actually want that. --> <img src="less-important-image.svg" importance="low" ... /> <!-- We want to initiate an early fetch for a resource, but also deprioritize it. --> <link rel="preload" importance="low" href="/script.js" as="script" />

   Cara paling berperforma untuk melakukan pemuatan lambat yang sedikit lebih canggih adalah dengan menggunakan Intersection Observer API yang menyediakan cara untuk mengamati perubahan secara asinkron di persimpangan elemen target dengan elemen ancestor atau dengan viewport dokumen tingkat atas. Pada dasarnya, Anda perlu membuat objek IntersectionObserver baru, yang menerima fungsi panggilan balik dan serangkaian opsi. Kemudian kita tambahkan target untuk diamati.

   Fungsi callback dijalankan saat target menjadi terlihat atau tidak terlihat, jadi saat memotong area pandang, Anda dapat mulai mengambil beberapa tindakan sebelum elemen terlihat. Faktanya, kami memiliki kontrol granular kapan panggilan balik pengamat harus dipanggil, dengan rootMargin (margin di sekitar root) dan threshold (satu nomor atau larik angka yang menunjukkan berapa persentase visibilitas target yang kami tuju).

   Alejandro Garcia Anglada telah menerbitkan tutorial praktis tentang cara menerapkannya, Rahul Nanwani menulis posting terperinci tentang pemuatan lambat gambar latar depan dan latar belakang, dan Google Fundamentals memberikan tutorial terperinci tentang pemuatan lambat gambar dan video dengan Intersection Observer juga.

   Ingat cerita yang diarahkan seni membaca panjang dengan benda bergerak dan lengket? Anda juga dapat mengimplementasikan scrollytelling dengan Intersection Observer.

   Periksa lagi apa lagi yang bisa Anda muat dengan malas. Bahkan string terjemahan dan emoji yang memuat lambat dapat membantu. Dengan demikian, Mobile Twitter berhasil mencapai eksekusi JavaScript 80% lebih cepat dari jalur internasionalisasi baru.

   Namun, peringatan singkat: perlu dicatat bahwa pemuatan lambat harus menjadi pengecualian daripada aturan. Mungkin tidak masuk akal untuk malas memuat apa pun yang sebenarnya Anda ingin orang lihat dengan cepat, misalnya gambar halaman produk, gambar pahlawan, atau skrip yang diperlukan agar navigasi utama menjadi interaktif.

1. Muat gambar secara bertahap.
   Anda bahkan dapat melakukan pemuatan lambat ke tingkat berikutnya dengan menambahkan pemuatan gambar progresif ke halaman Anda. Sama halnya dengan Facebook, Pinterest, Medium, dan Wolt, Anda dapat memuat gambar berkualitas rendah atau bahkan buram terlebih dahulu, lalu saat halaman terus dimuat, gantilah dengan versi kualitas penuh dengan menggunakan teknik BlurHash atau LQIP (Low Quality Image Placeholder) teknik.

   Pendapat berbeda jika teknik ini meningkatkan pengalaman pengguna atau tidak, tetapi itu pasti meningkatkan waktu untuk First Contentful Paint. Kami bahkan dapat mengotomatiskannya dengan menggunakan SQIP yang membuat versi gambar berkualitas rendah sebagai placeholder SVG, atau Gradient Image Placeholder dengan gradien linier CSS.

   Placeholder ini dapat disematkan di dalam HTML karena secara alami terkompresi dengan baik dengan metode kompresi teks. Dalam artikelnya, Dean Hume telah menjelaskan bagaimana teknik ini dapat diimplementasikan menggunakan Intersection Observer.

   mundur? Jika browser tidak mendukung pengamat persimpangan, kita masih bisa malas memuat polyfill atau segera memuat gambar. Dan bahkan ada perpustakaan untuk itu.

   Ingin menjadi lebih mewah? Anda dapat melacak gambar Anda dan menggunakan bentuk dan tepi primitif untuk membuat placeholder SVG yang ringan, memuatnya terlebih dahulu, lalu bertransisi dari gambar vektor placeholder ke gambar bitmap (dimuat).



2. Apakah Anda menunda rendering dengan content-visibility ?
   Untuk tata letak yang kompleks dengan banyak blok konten, gambar, dan video, decoding data dan rendering piksel mungkin merupakan operasi yang cukup mahal — terutama pada perangkat kelas bawah. Dengan content-visibility: auto , kita dapat meminta browser untuk melewati tata letak anak-anak saat wadah berada di luar viewport.

   Misalnya, Anda mungkin melewatkan rendering footer dan bagian akhir pada pemuatan awal:

   footer { content-visibility: auto; contain-intrinsic-size: 1000px; /* 1000px is an estimated height for sections that are not rendered yet. */ }

   Perhatikan bahwa visibilitas konten: otomatis; berperilaku seperti overflow: hidden; , tetapi Anda dapat memperbaikinya dengan menerapkan padding-left dan padding-right sebagai ganti default margin-left: auto; , margin-right: auto; dan lebar yang dinyatakan. Padding pada dasarnya memungkinkan elemen meluap ke kotak konten dan masuk ke kotak padding tanpa meninggalkan model kotak secara keseluruhan dan terpotong.

   Juga, perlu diingat bahwa Anda mungkin memperkenalkan beberapa CLS saat konten baru akhirnya dirender, jadi sebaiknya gunakan contain-intrinsic-size pengganti yang tepat ( terima kasih, Una! ).

   Thijs Terluin memiliki lebih banyak detail tentang kedua properti dan bagaimana contain-intrinsic-size konten dihitung oleh browser, Malte Ubl menunjukkan bagaimana Anda dapat menghitungnya dan penjelasan video singkat oleh Jake dan Surma menjelaskan cara kerjanya.

   Dan jika Anda perlu sedikit lebih terperinci, dengan CSS Containment, Anda dapat secara manual melewati pekerjaan tata letak, gaya, dan pengecatan untuk turunan simpul DOM jika Anda hanya memerlukan ukuran, perataan, atau gaya yang dihitung pada elemen lain — atau elemen tersebut saat ini di luar kanvas.

1. Apakah Anda menunda decoding dengan decoding="async" ?
   Terkadang konten muncul di luar layar, namun kami ingin memastikan bahwa konten tersedia saat pelanggan membutuhkannya — idealnya, tidak memblokir apa pun di jalur kritis, tetapi mendekode dan merender secara asinkron. Kita dapat menggunakan decoding="async" untuk memberikan izin kepada browser untuk memecahkan kode gambar dari utas utama, menghindari dampak pengguna dari waktu CPU yang digunakan untuk memecahkan kode gambar (melalui Malte Ubl):
   
   

   <img decoding="async" … />

   Atau, untuk gambar di luar layar, kita dapat menampilkan placeholder terlebih dahulu, dan ketika gambar berada di dalam viewport, menggunakan IntersectionObserver, memicu panggilan jaringan agar gambar diunduh di latar belakang. Selain itu, kita dapat menunda render hingga decode dengan img.decode() atau mengunduh gambar jika Image Decode API tidak tersedia.

   Saat merender gambar, kita dapat menggunakan animasi fade-in, misalnya. Katie Hempenius dan Addy Osmani berbagi lebih banyak wawasan dalam pembicaraan mereka Speed ​​at Scale: Web Performance Tips and Tricks from the Trenches.

2. Apakah Anda membuat dan menyajikan CSS penting?
   Untuk memastikan bahwa browser mulai merender halaman Anda secepat mungkin, sudah menjadi praktik umum untuk mengumpulkan semua CSS yang diperlukan untuk mulai merender bagian halaman pertama yang terlihat (dikenal sebagai "CSS kritis" atau "CSS paruh atas" ") dan sertakan sebaris di <head> halaman, sehingga mengurangi perjalanan pulang pergi. Karena terbatasnya ukuran paket yang dipertukarkan selama fase slow start, anggaran Anda untuk CSS penting adalah sekitar 14 KB.

   Jika Anda melampaui itu, browser akan membutuhkan bolak-balik tambahan untuk mengambil lebih banyak gaya. CriticalCSS dan Critical memungkinkan Anda untuk menampilkan CSS penting untuk setiap template yang Anda gunakan. Dalam pengalaman kami, tidak ada sistem otomatis yang lebih baik daripada pengumpulan manual CSS penting untuk setiap template, dan memang itulah pendekatan yang telah kami pindahkan baru-baru ini.

   Anda kemudian dapat memasukkan CSS kritis dan memuat sisanya dengan plugin critters Webpack. Jika memungkinkan, pertimbangkan untuk menggunakan pendekatan inlining bersyarat yang digunakan oleh Filament Group, atau ubah kode inline menjadi aset statis dengan cepat.

   Jika saat ini Anda memuat CSS lengkap Anda secara asinkron dengan pustaka seperti loadCSS, itu tidak terlalu diperlukan. Dengan media="print" , Anda dapat mengelabui browser agar mengambil CSS secara asinkron tetapi menerapkan ke lingkungan layar setelah dimuat. ( terima kasih, Scott! )

   <!-- Via Scott Jehl. https://www.filamentgroup.com/lab/load-css-simpler/ --> <!-- Load CSS asynchronously, with low priority --> <link rel="stylesheet" href="full.css" media="print" onload="this.media='all'" />

   Saat mengumpulkan semua CSS penting untuk setiap template, biasanya menjelajahi area "paro atas" saja. Namun, untuk tata letak yang kompleks, mungkin ide yang baik untuk menyertakan dasar tata letak juga untuk menghindari perhitungan ulang besar-besaran dan biaya pengecatan ulang, akibatnya merugikan skor Data Vital Web Inti Anda.

   Bagaimana jika pengguna mendapatkan URL yang tertaut langsung ke tengah halaman tetapi CSS belum diunduh? Dalam hal ini, telah menjadi umum untuk menyembunyikan konten yang tidak penting, misalnya dengan opacity: 0; dalam CSS sebaris dan opacity: 1 dalam file CSS lengkap, dan tampilkan saat CSS tersedia. Ini memiliki kelemahan utama , karena pengguna dengan koneksi lambat mungkin tidak akan pernah bisa membaca konten halaman. Itulah mengapa lebih baik untuk selalu menjaga konten tetap terlihat, meskipun mungkin tidak ditata dengan benar.

   Menempatkan CSS penting (dan aset penting lainnya) dalam file terpisah di domain root memiliki manfaat, kadang-kadang bahkan lebih dari inlining, karena caching. Chrome secara spekulatif membuka koneksi HTTP kedua ke domain root saat meminta halaman, yang menghilangkan kebutuhan akan koneksi TCP untuk mengambil CSS ini. Itu berarti Anda dapat membuat satu set file -CSS kritis (mis . critical-homepage.css , critical-product-page.css, dll.) dan menyajikannya dari root Anda, tanpa harus membuat inline. ( terima kasih, Filipus! )

   Sebuah kata peringatan: dengan HTTP/2, CSS penting dapat disimpan dalam file CSS terpisah dan dikirimkan melalui server push tanpa membengkakkan HTML. Tangkapannya adalah bahwa mendorong server merepotkan dengan banyak gotcha dan kondisi balapan di seluruh browser. Itu tidak pernah didukung secara konsisten dan memiliki beberapa masalah caching (lihat slide 114 dan seterusnya dari presentasi Hooman Beheshti).

   Efeknya, pada kenyataannya, bisa menjadi negatif dan membuat buffer jaringan membengkak, mencegah pengiriman bingkai asli dalam dokumen. Jadi tidak terlalu mengejutkan bahwa untuk saat ini, Chrome berencana untuk menghapus dukungan untuk Server Push.

3. Bereksperimenlah dengan mengelompokkan kembali aturan CSS Anda.
   Kami telah terbiasa dengan CSS penting, tetapi ada beberapa pengoptimalan yang dapat melampaui itu. Harry Roberts melakukan penelitian yang luar biasa dengan hasil yang cukup mengejutkan. Misalnya, mungkin ide yang baik untuk membagi file CSS utama menjadi kueri media individualnya. Dengan begitu, browser akan mengambil CSS penting dengan prioritas tinggi, dan semua hal lain dengan prioritas rendah — sepenuhnya keluar dari jalur kritis.

   Juga, hindari menempatkan <link rel="stylesheet" /> sebelum async snippet. Jika skrip tidak bergantung pada stylesheet, pertimbangkan untuk menempatkan skrip pemblokiran di atas gaya pemblokiran. Jika ya, pisahkan JavaScript itu menjadi dua dan muat di kedua sisi CSS Anda.

   Scott Jehl memecahkan masalah menarik lainnya dengan men-cache file CSS sebaris dengan pekerja layanan, masalah umum yang biasa terjadi jika Anda menggunakan CSS kritis. Pada dasarnya, kami menambahkan atribut ID ke elemen style sehingga mudah ditemukan menggunakan JavaScript, kemudian sebagian kecil JavaScript menemukan CSS itu dan menggunakan Cache API untuk menyimpannya di cache browser lokal (dengan tipe konten text/css ) untuk digunakan pada halaman berikutnya. Untuk menghindari inlining pada halaman berikutnya dan sebagai gantinya mereferensikan aset yang di-cache secara eksternal, kami kemudian menyetel cookie pada kunjungan pertama ke sebuah situs. Voila!

   Perlu dicatat bahwa gaya dinamis juga bisa mahal, tetapi biasanya hanya jika Anda mengandalkan ratusan komponen yang dirender secara bersamaan. Jadi, jika Anda menggunakan CSS-in-JS, pastikan pustaka CSS-in-JS Anda mengoptimalkan eksekusi saat CSS Anda tidak memiliki ketergantungan pada tema atau props, dan jangan terlalu banyak membuat komponen bergaya . Aggelos Arvanitakis membagikan lebih banyak wawasan tentang biaya kinerja CSS-in-JS.

4. Apakah Anda mengalirkan tanggapan?
   Sering dilupakan dan diabaikan, stream menyediakan antarmuka untuk membaca atau menulis potongan data yang tidak sinkron, hanya sebagian yang mungkin tersedia di memori pada waktu tertentu. Pada dasarnya, mereka mengizinkan halaman yang membuat permintaan asli untuk mulai bekerja dengan respons segera setelah potongan data pertama tersedia, dan menggunakan parser yang dioptimalkan untuk streaming untuk menampilkan konten secara progresif.

   Kami dapat membuat satu aliran dari berbagai sumber. Misalnya, alih-alih menyajikan shell UI kosong dan membiarkan JavaScript mengisinya, Anda dapat membiarkan service worker membuat aliran di mana shell berasal dari cache, tetapi bodynya berasal dari jaringan. Seperti yang dicatat Jeff Posnick, jika aplikasi web Anda diberdayakan oleh CMS yang server-render HTML dengan menggabungkan sebagian template, model tersebut diterjemahkan secara langsung menjadi menggunakan respons streaming, dengan logika template yang direplikasi di service worker, bukan di server Anda. Artikel The Year of Web Streams karya Jake Archibald menyoroti bagaimana tepatnya Anda dapat membangunnya. Peningkatan kinerja cukup terlihat.

   Satu keuntungan penting dari streaming seluruh respons HTML adalah bahwa HTML yang dirender selama permintaan navigasi awal dapat memanfaatkan sepenuhnya pengurai HTML streaming browser. Potongan HTML yang dimasukkan ke dalam dokumen setelah halaman dimuat (seperti yang biasa terjadi pada konten yang diisi melalui JavaScript) tidak dapat memanfaatkan pengoptimalan ini.

   Dukungan peramban? Masih sampai di sana dengan dukungan parsial di Chrome, Firefox, Safari dan Edge yang mendukung API dan Service Worker yang didukung di semua browser modern. Dan jika Anda merasa ingin bertualang lagi, Anda dapat memeriksa implementasi eksperimental permintaan streaming, yang memungkinkan Anda untuk mulai mengirim permintaan sambil tetap membuat badan. Tersedia di Chrome 85.

1. Pertimbangkan untuk membuat komponen Anda sadar akan koneksi.
   Data bisa mahal dan dengan muatan yang terus bertambah, kami harus menghormati pengguna yang memilih untuk memilih penghematan data saat mengakses situs atau aplikasi kami. Header permintaan petunjuk klien Simpan-Data memungkinkan kami untuk menyesuaikan aplikasi dan muatan untuk pengguna dengan kendala biaya dan kinerja.

   Bahkan, Anda dapat menulis ulang permintaan untuk gambar DPI tinggi ke gambar DPI rendah, menghapus font web, efek paralaks mewah, thumbnail pratinjau dan gulir tak terbatas, mematikan pemutaran otomatis video, mendorong server, mengurangi jumlah item yang ditampilkan dan menurunkan kualitas gambar, atau bahkan mengubah cara Anda memberikan markup. Tim Vereecke telah menerbitkan artikel yang sangat rinci tentang strategi penghindaran data yang menampilkan banyak opsi untuk menyimpan data.

   Siapa yang menggunakan save-data , Anda mungkin bertanya-tanya? 18% pengguna Chrome Android global mengaktifkan Mode Ringan (dengan Save-Data aktif), dan jumlahnya kemungkinan akan lebih tinggi. Menurut penelitian Simon Hearne, tingkat keikutsertaan tertinggi pada perangkat yang lebih murah, tetapi ada banyak outlier. Misalnya: pengguna di Kanada memiliki tingkat keikutsertaan lebih dari 34% (dibandingkan dengan ~7% di AS) dan pengguna di flagship Samsung terbaru memiliki tingkat keikutsertaan hampir 18% secara global.

   Dengan mengaktifkan mode Save-Data , Chrome Seluler akan memberikan pengalaman yang dioptimalkan, yaitu pengalaman web yang diproksi dengan skrip yang ditangguhkan , font-display: swap , dan pemuatan lambat yang dipaksakan. Lebih masuk akal untuk membangun pengalaman Anda sendiri daripada mengandalkan browser untuk melakukan pengoptimalan ini.

   Header saat ini hanya didukung di Chromium, di Chrome versi Android, atau melalui ekstensi Penghemat Data di perangkat desktop. Terakhir, Anda juga dapat menggunakan API Informasi Jaringan untuk mengirimkan modul JavaScript yang mahal, gambar dan video beresolusi tinggi berdasarkan jenis jaringan. API Informasi Jaringan dan khususnya navigator.connection.effectiveType menggunakan nilai RTT , downlink , effectiveType (dan beberapa lainnya) untuk memberikan representasi koneksi dan data yang dapat ditangani pengguna.

   Dalam konteks ini, Max Bock berbicara tentang komponen connection-aware dan Addy Osmani berbicara tentang penyajian modul adaptif. Misalnya, dengan React, kita bisa menulis komponen yang dirender secara berbeda untuk tipe koneksi yang berbeda. Seperti yang disarankan Max, komponen <Media /> dalam artikel berita mungkin menampilkan:

   • Offline : alt dengan teks alternatif,
   • 2G / mode save-data : gambar beresolusi rendah,
   • 3G pada layar non-Retina: gambar resolusi menengah,
   • 3G pada layar Retina: gambar Retina beresolusi tinggi,
   • 4G : video HD.

   Dean Hume menyediakan implementasi praktis dari logika serupa menggunakan service worker. Untuk video, kami dapat menampilkan poster video secara default, lalu menampilkan ikon "Putar" serta cangkang pemutar video, meta-data video, dll. pada koneksi yang lebih baik. Sebagai cadangan untuk browser yang tidak mendukung, kita dapat mendengarkan acara canplaythrough dan menggunakan Promise.race() untuk menghentikan waktu pemuatan sumber jika acara canplaythrough tidak diaktifkan dalam 2 detik.

   Jika Anda ingin menyelam lebih dalam, berikut adalah beberapa sumber untuk memulai:

   
   • Addy Osmani menunjukkan cara mengimplementasikan penyajian adaptif di React.
   • React Adaptive Loading Hooks & Utilities menyediakan cuplikan kode untuk React,
   • Netanel Basel mengeksplorasi Komponen Connection-Aware di Angular,
   • Theodore Vorilas membagikan bagaimana Melayani Komponen Adaptif Menggunakan API Informasi Jaringan di Vue bekerja.
   • Umar Hansa menunjukkan cara selektif mengunduh/mengeksekusi JavaScript yang mahal.
2. Pertimbangkan untuk membuat perangkat Anda sadar memori.
   Koneksi jaringan memberi kita hanya satu perspektif pada konteks pengguna sekalipun. Lebih jauh, Anda juga dapat menyesuaikan sumber daya secara dinamis berdasarkan memori perangkat yang tersedia, dengan Device Memory API. navigator.deviceMemory mengembalikan berapa banyak RAM yang dimiliki perangkat dalam gigabyte, dibulatkan ke bawah ke pangkat dua terdekat. API juga menampilkan Header Petunjuk Klien, Device-Memory , yang melaporkan nilai yang sama.

   Bonus : Umar Hansa menunjukkan cara menunda skrip mahal dengan impor dinamis untuk mengubah pengalaman berdasarkan memori perangkat, konektivitas jaringan, dan konkurensi perangkat keras.

1. Panaskan koneksi untuk mempercepat pengiriman.
   Gunakan petunjuk sumber daya untuk menghemat waktu pada dns-prefetch (yang melakukan pencarian DNS di latar belakang), preconnect (yang meminta browser untuk memulai koneksi handshake (DNS, TCP, TLS) di latar belakang), prefetch (yang meminta browser untuk meminta sumber daya) dan preload (yang antara lain mengambil sumber daya tanpa menjalankannya). Didukung dengan baik di browser modern, dengan dukungan segera hadir di Firefox.

   Ingat prerender ? Petunjuk sumber daya yang digunakan untuk meminta browser membuat seluruh halaman di latar belakang untuk navigasi berikutnya. Masalah implementasi cukup bermasalah, mulai dari jejak memori yang besar dan penggunaan bandwidth hingga beberapa klik analitik terdaftar dan tayangan iklan.

   Tidak mengherankan, itu sudah usang, tetapi tim Chrome telah membawanya kembali sebagai mekanisme NoState Prefetch. Faktanya, Chrome memperlakukan petunjuk prerender sebagai Prefetch NoState, jadi kami masih dapat menggunakannya hari ini. Seperti yang dijelaskan Katie Hempenius dalam artikel itu, "seperti pra-perenderan, NoState Prefetch mengambil sumber daya terlebih dahulu ; tetapi tidak seperti pra-perenderan, itu tidak mengeksekusi JavaScript atau merender bagian mana pun dari halaman sebelumnya."

   NoState Prefetch hanya menggunakan ~45MiB memori dan subsumber daya yang diambil akan diambil dengan IDLE Net Priority. Sejak Chrome 69, NoState Prefetch menambahkan header Tujuan: Prefetch ke semua permintaan agar dapat dibedakan dari penjelajahan normal.

   Juga, perhatikan alternatif dan portal pra-perenderan, upaya baru menuju pra-perenderan yang sadar privasi, yang akan memberikan preview sisipan konten untuk navigasi yang mulus.

   Menggunakan petunjuk sumber daya mungkin adalah cara termudah untuk meningkatkan kinerja , dan itu memang bekerja dengan baik. Kapan harus menggunakan apa? Seperti yang telah dijelaskan oleh Addy Osmani, masuk akal untuk memuat sumber daya yang kami tahu kemungkinan besar akan digunakan pada halaman saat ini dan untuk navigasi di masa mendatang melintasi beberapa batas navigasi, misalnya bundel Webpack yang diperlukan untuk halaman yang belum dikunjungi pengguna.

   Artikel Addy tentang "Memuat Prioritas di Chrome" menunjukkan bagaimana tepatnya Chrome menafsirkan petunjuk sumber daya, jadi setelah Anda memutuskan aset mana yang penting untuk rendering, Anda dapat menetapkan prioritas tinggi untuk mereka. Untuk melihat bagaimana permintaan Anda diprioritaskan, Anda dapat mengaktifkan kolom "prioritas" di tabel permintaan jaringan Chrome DevTools (serta Safari).

   Sebagian besar waktu hari ini, kami akan menggunakan setidaknya preconnect dan dns-prefetch , dan kami akan berhati-hati dengan menggunakan prefetch , preload dan prerender . Perhatikan bahwa bahkan dengan preconnect dan dns-prefetch , browser memiliki batasan jumlah host yang akan dicari/dihubungkan secara paralel, jadi merupakan taruhan yang aman untuk memesannya berdasarkan prioritas ( terima kasih Philip Tellis! ).

   Karena font biasanya merupakan aset penting pada sebuah halaman, terkadang ada baiknya meminta browser untuk mendownload font penting dengan preload . Namun, periksa kembali apakah itu benar-benar membantu kinerja karena ada teka-teki prioritas saat memuat font sebelumnya: karena preload dianggap sangat penting, pramuat dapat melampaui sumber daya yang lebih penting seperti CSS penting. ( terima kasih, Barry! )

   <!-- Loading two rendering-critical fonts, but not all their weights. --> <!-- crossorigin="anonymous" is required due to CORS. Without it, preloaded fonts will be ignored. https://github.com/w3c/preload/issues/32 via https://twitter.com/iamakulov/status/1275790151642423303 --> <link rel="preload" as="font" href="Elena-Regular.woff2" type="font/woff2" crossorigin="anonymous" media="only screen and (min-width: 48rem)" /> <link rel="preload" as="font" href="Mija-Bold.woff2" type="font/woff2" crossorigin="anonymous" media="only screen and (min-width: 48rem)" />
   <!-- Loading two rendering-critical fonts, but not all their weights. --> <!-- crossorigin="anonymous" is required due to CORS. Without it, preloaded fonts will be ignored. https://github.com/w3c/preload/issues/32 via https://twitter.com/iamakulov/status/1275790151642423303 --> <link rel="preload" as="font" href="Elena-Regular.woff2" type="font/woff2" crossorigin="anonymous" media="only screen and (min-width: 48rem)" /> <link rel="preload" as="font" href="Mija-Bold.woff2" type="font/woff2" crossorigin="anonymous" media="only screen and (min-width: 48rem)" />

   Karena <link rel="preload"> menerima atribut media , Anda dapat memilih untuk mengunduh sumber daya secara selektif berdasarkan aturan kueri @media , seperti yang ditunjukkan di atas.

   Selanjutnya, kita dapat menggunakan atribut imagesrcset dan imagesizes untuk memuat gambar pahlawan yang terlambat ditemukan lebih cepat, atau gambar apa pun yang dimuat melalui JavaScript, misalnya poster film:

   <!-- Addy Osmani. https://addyosmani.com/blog/preload-hero-images/ --> <link rel="preload" as="image" href="poster.jpg" image image>
   <!-- Addy Osmani. https://addyosmani.com/blog/preload-hero-images/ --> <link rel="preload" as="image" href="poster.jpg" image image>

   Kami juga dapat melakukan pramuat JSON sebagai fetch , sehingga ditemukan sebelum JavaScript memintanya:

   <!-- Addy Osmani. https://addyosmani.com/blog/preload-hero-images/ --> <link rel="preload" as="fetch" href="foo.com/api/movies.json" crossorigin>

   Kami juga dapat memuat JavaScript secara dinamis, efektif untuk eksekusi skrip yang lambat.

   /* Adding a preload hint to the head */ var preload = document.createElement("link"); link.href = "myscript.js"; link.rel = "preload"; link.as = "script"; document.head.appendChild(link); /* Injecting a script when we want it to execute */ var script = document.createElement("script"); script.src = "myscript.js"; document.body.appendChild(script);

   Beberapa hal yang perlu diingat: preload bagus untuk memindahkan waktu pengunduhan awal aset lebih dekat ke permintaan awal, tetapi aset yang dimuat sebelumnya mendarat di cache memori yang terkait dengan halaman yang membuat permintaan. preload baik dengan cache HTTP: permintaan jaringan tidak pernah dikirim jika item sudah ada di cache HTTP.

   Oleh karena itu, ini berguna untuk sumber daya yang terlambat ditemukan, gambar pahlawan yang dimuat melalui background-image , menyisipkan CSS penting (atau JavaScript) dan memuat sisa CSS (atau JavaScript) sebelumnya.

   

   Tag preload dapat memulai pramuat hanya setelah browser menerima HTML dari server dan pengurai lookahead telah menemukan tag preload . Pramuat melalui header HTTP bisa menjadi sedikit lebih cepat karena kita tidak perlu menunggu browser untuk mengurai HTML untuk memulai permintaan (meskipun masih diperdebatkan).

   Petunjuk Awal akan membantu lebih jauh, memungkinkan pramuat untuk memulai bahkan sebelum header respons untuk HTML dikirim (pada peta jalan di Chromium, Firefox). Plus, Petunjuk Prioritas akan membantu kami menunjukkan prioritas pemuatan untuk skrip.

   Hati -hati: jika Anda menggunakan preload , as yang harus ditentukan atau tidak ada yang dimuat, ditambah font yang dimuat sebelumnya tanpa atribut crossorigin akan mengambil ganda. Jika Anda menggunakan prefetch , waspadalah terhadap masalah header Age di Firefox.

1. Gunakan pekerja layanan untuk caching dan cadangan jaringan.
   Tidak ada pengoptimalan kinerja melalui jaringan yang bisa lebih cepat daripada cache yang disimpan secara lokal di mesin pengguna (meskipun ada pengecualian). Jika situs web Anda berjalan melalui HTTPS, kami dapat menyimpan aset statis di cache pekerja layanan dan menyimpan fallback offline (atau bahkan halaman offline) dan mengambilnya dari mesin pengguna, daripada pergi ke jaringan.

   Seperti yang disarankan oleh Phil Walton, dengan pekerja layanan, kami dapat mengirim muatan HTML yang lebih kecil dengan menghasilkan respons kami secara terprogram. Service worker dapat meminta data minimal yang dibutuhkan dari server (misalnya sebagian konten HTML, file penurunan harga, data JSON, dll.), dan kemudian secara terprogram dapat mengubah data tersebut menjadi dokumen HTML lengkap. Jadi, setelah pengguna mengunjungi situs dan pekerja layanan dipasang, pengguna tidak akan pernah meminta laman HTML lengkap lagi. Dampak kinerja bisa sangat mengesankan.

   Dukungan peramban? Pekerja layanan didukung secara luas dan cadangannya adalah jaringan. Apakah itu membantu meningkatkan kinerja ? Oh ya, memang. Dan itu menjadi lebih baik, misalnya dengan Background Fetch yang memungkinkan upload/download latar belakang melalui service worker juga.

   Ada sejumlah kasus penggunaan untuk pekerja layanan. Misalnya, Anda dapat menerapkan fitur "Simpan untuk offline", menangani gambar yang rusak, memperkenalkan perpesanan antar tab, atau memberikan strategi cache yang berbeda berdasarkan jenis permintaan. Secara umum, strategi umum yang andal adalah menyimpan shell aplikasi di cache service worker bersama dengan beberapa halaman penting, seperti halaman offline, halaman depan, dan apa pun yang mungkin penting dalam kasus Anda.

   Ada beberapa gotcha yang perlu diingat. Dengan adanya service worker, kita perlu mewaspadai permintaan jangkauan di Safari (jika Anda menggunakan Workbox untuk service worker, ia memiliki modul permintaan jangkauan). Jika Anda pernah menemukan DOMException: Quota exceeded. kesalahan di konsol browser, lalu lihat artikel Gerardo Ketika 7KB sama dengan 7MB.

   Seperti yang ditulis Gerardo, “Jika Anda sedang membangun aplikasi web progresif dan mengalami penyimpanan cache yang membengkak saat pekerja layanan Anda menyimpan cache aset statis yang disajikan dari CDN, pastikan header respons CORS yang tepat ada untuk sumber daya lintas-asal, Anda tidak men-cache respons buram dengan service worker Anda secara tidak sengaja, Anda mengikutsertakan aset gambar lintas asal ke mode crossorigin dengan menambahkan atribut lintas asal ke tag <img> .”

   Ada banyak sumber daya yang bagus untuk memulai dengan pekerja layanan:

   • Service Worker Mindset, yang membantu Anda memahami cara kerja service worker di balik layar dan hal-hal yang perlu dipahami saat membangunnya.
   • Chris Ferdinandi menyediakan serangkaian artikel hebat tentang service worker, menjelaskan cara membuat aplikasi offline dan mencakup berbagai skenario, mulai dari menyimpan halaman yang baru dilihat secara offline hingga menyetel tanggal kedaluwarsa untuk item di cache service worker.

   • Kesalahan Service Worker dan Praktik Terbaik, dengan beberapa tips tentang cakupan, menunda pendaftaran service worker dan caching service worker.
   • Seri hebat oleh Ire Aderinokun tentang "Offline First" dengan Service Worker, dengan strategi untuk mem-cache shell aplikasi.
   • Service Worker: Pengantar dengan tips praktis tentang cara menggunakan service worker untuk pengalaman offline yang kaya, sinkronisasi latar belakang berkala, dan pemberitahuan push.
   • Itu selalu layak mengacu pada Buku Masak Offline Jake Archibald yang bagus dengan sejumlah resep tentang cara memanggang pekerja layanan Anda sendiri.
   • Workbox adalah kumpulan pustaka pekerja layanan yang dibuat khusus untuk membangun aplikasi web progresif.
2. Apakah Anda menjalankan pekerja server di CDN/Edge, misalnya untuk pengujian A/B?
   Pada titik ini, kami cukup terbiasa menjalankan service worker di klien, tetapi dengan CDN yang mengimplementasikannya di server, kami juga dapat menggunakannya untuk mengubah kinerja di edge.

   Misalnya, dalam pengujian A/B, ketika HTML perlu memvariasikan kontennya untuk pengguna yang berbeda, kita dapat menggunakan Service Worker di server CDN untuk menangani logikanya. Kami juga dapat melakukan streaming penulisan ulang HTML untuk mempercepat situs yang menggunakan Google Font.

1. Optimalkan kinerja rendering.
   Setiap kali aplikasi lamban, itu langsung terlihat. Jadi, kami perlu memastikan bahwa tidak ada jeda saat menggulir halaman atau saat elemen dianimasikan, dan Anda secara konsisten mencapai 60 frame per detik. Jika itu tidak memungkinkan, maka setidaknya membuat frame per detik konsisten lebih baik daripada rentang campuran 60 hingga 15. Gunakan will-change CSS untuk memberi tahu browser tentang elemen dan properti mana yang akan berubah.

   Kapan pun Anda mengalaminya, debug pengecatan ulang yang tidak perlu di DevTools:

   • Ukur kinerja rendering runtime. Periksa beberapa tip berguna tentang cara memahaminya.
   • Untuk memulai, lihat kursus Udacity gratis Paul Lewis tentang pengoptimalan rendering browser dan artikel Georgy Marchuk tentang pengecatan Browser dan pertimbangan untuk kinerja web.
   • Aktifkan Paint Flashing di "Alat lainnya → Rendering → Paint Flashing" di Firefox DevTools.
   • Di React DevTools, centang "Soroti pembaruan" dan aktifkan "Rekam mengapa setiap komponen dirender",
   • Anda juga dapat menggunakan Why Did You Render, jadi saat komponen dirender ulang, flash akan memberi tahu Anda tentang perubahan tersebut.

   Apakah Anda menggunakan tata letak Masonry? Perlu diingat bahwa mungkin dapat membangun tata letak Masonry dengan grid CSS saja, segera.

   Jika Anda ingin menyelami topik lebih dalam, Nolan Lawson telah berbagi trik untuk mengukur kinerja tata letak secara akurat dalam artikelnya, dan Jason Miller juga menyarankan teknik alternatif. Kami juga memiliki artikel kecil oleh Sergey Chikuyonok tentang cara mendapatkan animasi GPU dengan benar.

   

   Catatan : perubahan pada lapisan komposisi GPU adalah yang paling murah, jadi jika Anda bisa lolos dengan hanya memicu komposisi melalui opacity dan transform , Anda akan berada di jalur yang benar. Anna Migas juga telah memberikan banyak saran praktis dalam ceramahnya tentang Debugging UI Rendering Performance. Dan untuk memahami cara men-debug kinerja cat di DevTools, lihat video audit Kinerja Cat Umar.

2. Sudahkah Anda mengoptimalkan kinerja yang dirasakan?
   Meskipun urutan bagaimana komponen muncul di halaman, dan strategi bagaimana kami menyajikan aset ke browser penting, kami juga tidak boleh meremehkan peran kinerja yang dirasakan. Konsep ini berkaitan dengan aspek psikologis menunggu, pada dasarnya membuat pelanggan sibuk atau terlibat saat sesuatu yang lain sedang terjadi. Di situlah manajemen persepsi, awal preemptive, penyelesaian awal dan manajemen toleransi berperan.

   Apa artinya itu semua? Saat memuat aset, kami dapat mencoba untuk selalu selangkah lebih maju dari pelanggan, sehingga pengalaman terasa cepat sementara ada banyak hal yang terjadi di latar belakang. Untuk membuat pelanggan tetap terlibat, kami dapat menguji layar kerangka (demo implementasi) alih-alih memuat indikator, menambahkan transisi/animasi, dan pada dasarnya menipu UX ketika tidak ada lagi yang perlu dioptimalkan.

   Dalam studi kasus mereka tentang Seni Kerangka UI, Kumar McMillan berbagi beberapa ide dan teknik tentang cara mensimulasikan daftar dinamis, teks, dan layar akhir, serta bagaimana mempertimbangkan pemikiran kerangka dengan React.

   Namun berhati-hatilah: layar kerangka harus diuji sebelum digunakan karena beberapa pengujian menunjukkan bahwa layar kerangka dapat melakukan yang terburuk menurut semua metrik.

3. Apakah Anda mencegah pergeseran tata letak dan pengecatan ulang?
   Di ranah kinerja yang dirasakan, mungkin salah satu pengalaman yang lebih mengganggu adalah perubahan tata letak , atau reflows , yang disebabkan oleh gambar dan video yang diskalakan ulang, font web, iklan yang disuntikkan, atau skrip yang terlambat ditemukan yang mengisi komponen dengan konten sebenarnya. Akibatnya, pelanggan mungkin mulai membaca artikel hanya untuk terganggu oleh lompatan tata letak di atas area baca. Pengalamannya sering kali tiba-tiba dan cukup membingungkan: dan itu mungkin kasus pemuatan prioritas yang perlu dipertimbangkan kembali.

   Komunitas telah mengembangkan beberapa teknik dan solusi untuk menghindari reflows. Secara umum, sebaiknya hindari menyisipkan konten baru di atas konten yang sudah ada , kecuali jika hal itu terjadi sebagai respons terhadap interaksi pengguna. Selalu atur atribut lebar dan tinggi pada gambar, jadi browser modern mengalokasikan kotak dan memesan ruang secara default (Firefox, Chrome).

   Untuk gambar atau video, kita dapat menggunakan placeholder SVG untuk memesan kotak tampilan di mana media akan muncul. Itu berarti bahwa area tersebut akan dicadangkan dengan benar ketika Anda juga perlu mempertahankan rasio aspeknya. Kami juga dapat menggunakan placeholder, atau gambar cadangan untuk iklan dan konten dinamis, serta slot tata letak yang telah dialokasikan sebelumnya.

   Daripada memuat gambar dengan lambat dengan skrip eksternal, pertimbangkan untuk menggunakan pemuatan lambat asli, atau pemuatan lambat hibrida saat kami memuat skrip eksternal hanya jika pemuatan lambat asli tidak didukung.

   Seperti disebutkan di atas, selalu kelompokkan pengecatan ulang font web dan transisi dari semua font fallback ke semua font web sekaligus — pastikan bahwa peralihan itu tidak terlalu mendadak, dengan menyesuaikan tinggi garis dan jarak antara font dengan font-style-matcher .

   Untuk mengganti metrik font untuk font fallback guna meniru font web, kita dapat menggunakan deskriptor @font-face untuk mengganti metrik font (demo, diaktifkan di Chrome 87). (Perhatikan bahwa penyesuaian rumit dengan tumpukan font yang rumit.)

   Untuk CSS yang lebih baru, kami dapat memastikan bahwa CSS yang sangat penting dalam tata letak digariskan di header setiap template. Lebih jauh dari itu: untuk halaman yang panjang, ketika bilah gulir vertikal ditambahkan, itu menggeser konten utama 16px ke kiri. Untuk menampilkan scrollbar lebih awal, kita dapat menambahkan overflow-y: scroll pada html untuk menerapkan scrollbar pada first paint. Yang terakhir membantu karena bilah gulir dapat menyebabkan pergeseran tata letak yang tidak sepele karena konten paruh atas mengalir kembali ketika lebar berubah. Seharusnya sebagian besar terjadi pada platform dengan scrollbar non-overlay seperti Windows. Tetapi: break position: sticky karena elemen-elemen itu tidak akan pernah keluar dari wadah.

   Jika Anda berurusan dengan tajuk yang menjadi tetap atau menempel di bagian atas halaman saat menggulir, sisakan ruang untuk tajuk saat menjadi pine, misalnya dengan elemen placeholder atau margin-top pada konten. Pengecualian harus berupa spanduk izin cookie yang seharusnya tidak berdampak pada CLS, tetapi terkadang berdampak: itu tergantung pada penerapannya. Ada beberapa strategi dan takeaways yang menarik di utas Twitter ini.

   Untuk komponen tab yang mungkin menyertakan berbagai jumlah teks, Anda dapat mencegah pergeseran tata letak dengan tumpukan kisi CSS. Dengan menempatkan konten setiap tab di area kisi yang sama, dan menyembunyikan salah satunya pada satu waktu, kami dapat memastikan bahwa wadah selalu mengambil ketinggian elemen yang lebih besar, sehingga tidak ada perubahan tata letak yang akan terjadi.

   Ah, dan tentu saja, pengguliran tak terbatas dan "Muat lebih banyak" dapat menyebabkan pergeseran tata letak juga jika ada konten di bawah daftar (misalnya footer). Untuk meningkatkan CLS, sediakan ruang yang cukup untuk konten yang akan dimuat sebelum pengguna menggulir ke bagian halaman tersebut, hapus footer atau elemen DOM apa pun di bagian bawah halaman yang mungkin terdorong ke bawah oleh pemuatan konten. Selain itu, prefetch data dan gambar untuk konten paruh bawah sehingga pada saat pengguna menggulir sejauh itu, itu sudah ada di sana. Anda dapat menggunakan perpustakaan virtualisasi daftar seperti jendela reaksi untuk mengoptimalkan daftar panjang juga ( terima kasih, Addy Osmani! ).

   Untuk memastikan bahwa dampak reflow terkendali, ukur stabilitas tata letak dengan Layout Instability API. Dengannya, Anda dapat menghitung skor Pergeseran Tata Letak Kumulatif ( CLS ) dan memasukkannya sebagai persyaratan dalam pengujian Anda, jadi setiap kali regresi muncul, Anda dapat melacak dan memperbaikinya.

   Untuk menghitung skor pergeseran tata letak, browser melihat ukuran area pandang dan pergerakan elemen yang tidak stabil di area pandang antara dua bingkai yang dirender. Idealnya, skor akan mendekati 0 . Ada panduan hebat oleh Milica Mihajlija dan Philip Walton tentang apa itu CLS dan bagaimana mengukurnya. Ini adalah titik awal yang baik untuk mengukur dan mempertahankan kinerja yang dirasakan dan menghindari gangguan, terutama untuk tugas-tugas bisnis yang penting.

   Kiat cepat : untuk mengetahui apa yang menyebabkan perubahan tata letak di DevTools, Anda dapat menjelajahi perubahan tata letak di bawah "Pengalaman" di Panel Kinerja.

   Bonus : jika Anda ingin mengurangi reflows dan repaints, periksa panduan Charis Theodoulou untuk Meminimalkan DOM Reflow/Layout Thrashing dan daftar Paul Irish tentang Apa yang memaksa layout / reflow serta CSSTriggers.com, tabel referensi tentang properti CSS yang memicu layout, paint dan pengomposisian.

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.