Lighthouse: Mengoptimalkan kecepatan situs

Sasaran tutorial

Tutorial ini mengajarkan cara menggunakan Chrome DevTools untuk menemukan cara membuat situs Anda dimuat lebih cepat.

Baca terus, atau tonton versi video dari tutorial ini:

Prasyarat

Anda harus sudah memiliki pengalaman pengembangan web dasar, sama seperti yang diajarkan dalam kelas Pengantar Pengembangan Web ini.

Anda tidak perlu mengetahui apa pun tentang performa pemuatan.

Pengantar

Ini Tony. Tony sangat terkenal di komunitas kucing. Ia telah membuat situs sehingga penggemarnya dapat mencari tahu makanan favoritnya. Penggemarnya menyukai situs ini, tetapi Tony terus mendengar keluhan bahwa situs tersebut dimuat dengan lambat. Tony telah meminta Anda untuk membantunya mempercepat situs itu.

Langkah 1: Mengaudit situs

Setiap kali Anda berupaya meningkatkan performa pemuatan situs, selalu mulai dengan audit. Audit memiliki dua fungsi penting:

• Alat ini membuat dasar bawaan untuk mengukur perubahan berikutnya.
• Halaman ini memberi Anda tips yang dapat ditindaklanjuti tentang perubahan apa yang akan memberikan dampak terbesar.

Siapkan

Pertama, Anda perlu menyiapkan lingkungan kerja baru untuk situs Tony, sehingga Anda dapat mengubahnya nanti:

1. Me-remix project situs di Glitch. Project baru Anda akan terbuka di tab. Tab ini akan disebut sebagai tab editor.

   

   Nama project tersebut berubah dari tony menjadi nama yang dibuat secara acak. Anda kini memiliki salinan kode yang dapat diedit. Anda akan membuat perubahan pada kode ini nanti.

2. Di bagian bawah tab editor, klik Preview > Preview in a new window. Demo akan terbuka di tab baru. Tab ini akan disebut sebagai tab demo. Mungkin perlu waktu beberapa saat untuk memuat situs.

   

3. Buka DevTools bersamaan dengan demo.

   

Menetapkan dasar pengukuran

Dasar pengukuran adalah data tentang performa situs sebelum Anda melakukan peningkatan performa.

1. Buka panel Lighthouse. Mungkin tersembunyi di balik double_arrow Panel lainnya.

   

2. Cocokkan setelan konfigurasi laporan Lighthouse Anda dengan setelan yang ada di screenshot. Berikut penjelasan tentang berbagai opsi tersebut:

   • check_box Hapus Penyimpanan. Jika kotak centang ini diaktifkan, semua penyimpanan yang terkait dengan halaman tersebut akan dihapus sebelum setiap audit. Tetap aktifkan setelan ini jika Anda ingin mengaudit pengalaman pengunjung pertama kali di situs Anda. Nonaktifkan setelan ini saat Anda menginginkan pengalaman kunjungan berulang.
   • check_box Aktifkan pengambilan sampel JS. Opsi ini dinonaktifkan secara default. Jika diaktifkan, stack panggilan JavaScript yang mendetail akan ditambahkan ke trace performa, tetapi dapat memperlambat pembuatan laporan. Rekaman aktivitas ini tersedia di bagian more_vert menu Alat > Lihat Rekaman Aktivitas yang Tidak Di-throttle setelah laporan Lighthouse dibuat.
   • Simulasi throttling (default) arrow_drop_down. Opsi ini menyimulasikan kondisi umum penjelajahan di perangkat seluler. Lighthouse disebut "disimulasikan" karena Lighthouse tidak benar-benar melakukan throttle selama proses audit. Sebaliknya, hal ini hanya memperkirakan waktu yang diperlukan untuk memuat halaman dalam kondisi seluler. Di sisi lain, setelan DevTools throttling (lanjutan) sebenarnya men-throttle CPU dan jaringan Anda, tanpa kompromi dari proses pengauditan yang lebih lama.
   • Mode > radio_button_checked Navigasi (Default). Mode ini menganalisis pemuatan halaman tunggal, dan itulah yang kita perlukan dalam tutorial ini. Untuk mengetahui informasi selengkapnya, lihat Tiga mode tersebut.
   • Perangkat > radio_button_checked Seluler. Opsi seluler mengubah string agen pengguna dan menyimulasikan area pandang seluler. Opsi {i>desktop<i} cukup menonaktifkan perubahan di perangkat seluler.
   • Kategori > check_box Performa. Dengan satu kategori yang diaktifkan, Lighthouse membuat laporan hanya dengan serangkaian audit yang sesuai. Anda dapat membiarkan kategori lainnya tetap aktif, jika ingin melihat jenis rekomendasi yang diberikannya. Menonaktifkan kategori yang tidak relevan sedikit akan mempercepat proses audit.

3. Klik Analisis pemuatan halaman. Setelah 10 hingga 30 detik, panel Lighthouse akan menampilkan laporan performa situs Anda.

   

Menangani error laporan

Jika Anda pernah mengalami error dalam laporan Lighthouse, coba jalankan tab demo dari jendela samaran tanpa tab lain yang terbuka. Tindakan ini akan memastikan Anda menjalankan Chrome dari kondisi bersih. Ekstensi Chrome secara khusus dapat mengganggu proses audit.

Memahami laporan

Angka di bagian atas laporan Anda adalah skor performa keseluruhan untuk situs. Kemudian, saat membuat perubahan pada kode, Anda akan melihat kenaikan angka ini. Skor yang lebih tinggi berarti performa yang lebih baik.

Regresi

Scroll ke bawah ke bagian Metrik, lalu klik Luaskan tampilan. Untuk membaca dokumentasi tentang metrik, klik Pelajari lebih lanjut....

Bagian ini memberikan pengukuran kuantitatif performa situs. Setiap metrik memberikan insight tentang berbagai aspek performa. Misalnya, First Contentful Paint memberi tahu Anda saat konten pertama kali ditampilkan di layar, yang merupakan pencapaian penting dalam persepsi pengguna terhadap pemuatan halaman, sedangkan Time To Interactive menandai titik saat halaman tampak cukup siap untuk menangani interaksi pengguna.

Screenshot

Berikutnya adalah kumpulan screenshot yang menunjukkan tampilan halaman saat dimuat.

Peluang

Berikutnya adalah bagian Peluang yang memberikan tips spesifik tentang cara meningkatkan performa pemuatan halaman tertentu.

Klik peluang untuk mempelajarinya lebih lanjut.

Klik Pelajari lebih lanjut... untuk melihat dokumentasi tentang alasan pentingnya peluang, dan rekomendasi khusus tentang cara memperbaikinya.

Diagnostik

Bagian Diagnostik memberikan informasi lebih lanjut tentang faktor-faktor yang berkontribusi pada waktu pemuatan halaman.

Lulus audit

Bagian Lulus audit menunjukkan tindakan yang dilakukan situs dengan benar. Klik untuk meluaskan bagian tersebut.

Langkah 2: Bereksperimen

Bagian Peluang di laporan Lighthouse memberikan tips tentang cara meningkatkan performa halaman. Di bagian ini, Anda akan menerapkan perubahan yang direkomendasikan pada codebase, yang mengaudit situs setelah setiap perubahan untuk mengukur pengaruhnya terhadap kecepatan situs.

Aktifkan kompresi teks

Laporan Anda menyatakan bahwa mengaktifkan kompresi teks adalah salah satu peluang terbaik untuk meningkatkan performa halaman.

Kompresi teks adalah saat Anda mengurangi atau mengompresi ukuran file teks sebelum mengirimkannya melalui jaringan. Sama seperti bagaimana Anda dapat membuat zip folder sebelum mengirimkannya ke email untuk mengurangi ukurannya.

Sebelum mengaktifkan kompresi, berikut beberapa cara untuk memeriksa secara manual apakah resource teks dikompresi.

Buka panel Jaringan dan centang settings Setelan > check_box Gunakan baris permintaan besar.

Setiap sel Size menunjukkan dua nilai. Nilai teratas adalah ukuran resource yang didownload. Nilai terbawah adalah ukuran resource yang tidak dikompresi. Jika kedua nilai tersebut sama, berarti resource tidak dikompresi saat dikirim melalui jaringan. Dalam contoh ini, nilai atas dan bawah untuk bundle.js adalah 1.4 MB.

Anda juga dapat memeriksa kompresi dengan memeriksa header HTTP resource:

1. Klik bundle.js dan buka tab Header.

   

2. Telusuri bagian Respons Header untuk header content-encoding. Anda tidak akan melihatnya, yang berarti bundle.js tidak dikompresi. Saat resource dikompresi, header ini biasanya ditetapkan ke gzip, deflate, atau br. Lihat Petunjuk untuk penjelasan tentang nilai-nilai ini.

Cukup dengan penjelasannya. Saatnya membuat beberapa perubahan! Aktifkan kompresi teks dengan menambahkan beberapa baris kode:

1. Di tab editor, buka server.js dan tambahkan dua baris berikut (disorot):

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. Pastikan untuk menempatkan app.use(compression()) sebelum app.use(express.static('build')).

   

3. Tunggu hingga Glitch men-deploy build baru situs tersebut. Emoji senang di sudut kiri bawah menunjukkan deployment yang berhasil.

Gunakan alur kerja yang Anda pelajari sebelumnya untuk memeriksa secara manual apakah kompresi berfungsi:

1. Kembali ke tab demo dan muat ulang halaman.

   Kolom Ukuran kini menampilkan dua nilai yang berbeda untuk resource teks seperti bundle.js. Nilai teratas 269 KB untuk bundle.js adalah ukuran file yang dikirim melalui jaringan, dan nilai terbawah 1.4 MB adalah ukuran file yang tidak dikompresi.

   

2. Bagian Header Respons untuk bundle.js kini harus menyertakan header content-encoding: gzip.

   

Jalankan lagi laporan Lighthouse di halaman untuk mengukur dampak kompresi teks terhadap performa pemuatan halaman:

1. Buka panel Lighthouse dan klik Lakukan audit... pada panel tindakan di bagian atas.

   

2. Tetap gunakan setelan yang sama seperti sebelumnya, lalu klik Analisis pemuatan halaman.

   

Hore! Sepertinya ada kemajuan. Skor performa Anda secara keseluruhan seharusnya meningkat, yang berarti situs menjadi lebih cepat.

Kompresi teks di dunia nyata

Sebagian besar server benar-benar memiliki perbaikan sederhana seperti ini untuk mengaktifkan kompresi! Cukup lakukan pencarian tentang cara mengkonfigurasi server apa pun yang Anda gunakan untuk mengompresi teks.

Ubah ukuran gambar

Laporan baru Anda mengatakan bahwa mengubah ukuran gambar dengan benar adalah peluang besar lainnya.

Mengubah ukuran gambar akan membantu mempercepat waktu pemuatan dengan mengurangi ukuran file gambar. Jika pengguna melihat gambar Anda di layar perangkat seluler dengan lebar 500 piksel, sebenarnya tidak ada gunanya mengirim gambar dengan lebar 1500 piksel. Idealnya, Anda akan mengirim gambar dengan lebar maksimum 500 piksel.

1. Di laporan Anda, klik Sesuaikan gambar dengan ukuran yang tepat untuk melihat gambar yang perlu diubah ukurannya. Sepertinya keempat gambar itu lebih besar dari yang diperlukan.

   

2. Kembali ke tab editor, buka src/model.js.

3. Ganti const dir = 'big' dengan const dir = 'small'. Direktori ini berisi salinan gambar yang sama yang telah diubah ukurannya.

4. Audit halaman lagi untuk melihat bagaimana perubahan ini memengaruhi performa pemuatan.

   

Sepertinya perubahan tersebut hanya memiliki pengaruh kecil pada keseluruhan skor performa. Namun, satu hal yang tidak ditampilkan dengan jelas oleh skor adalah jumlah data jaringan yang Anda simpan untuk pengguna. Ukuran total foto lama sekitar 6,1 MB, yang sekarang hanya sekitar 633 kB. Anda dapat memeriksanya di status bar di bagian bawah panel Network.

Mengubah ukuran gambar di dunia nyata

Untuk aplikasi kecil, melakukan perubahan ukuran satu kali seperti ini mungkin sudah cukup. Tapi untuk aplikasi besar, ini jelas tidak skalabel. Berikut beberapa strategi untuk mengelola gambar di aplikasi besar:

• Ubah ukuran gambar selama proses build.
• Buat beberapa ukuran setiap gambar selama proses build, lalu gunakan srcset dalam kode Anda. Pada saat runtime, browser akan memilih ukuran yang terbaik untuk perangkat yang menjalankannya. Lihat Gambar berukuran relatif.
• Gunakan CDN gambar yang memungkinkan Anda mengubah ukuran gambar secara dinamis saat Anda memintanya.
• Setidaknya, optimalkan setiap gambar. Hal ini sering kali dapat menghemat biaya yang sangat besar. Pengoptimalan adalah saat Anda menjalankan gambar melalui program khusus yang mengurangi ukuran file gambar. Lihat Pengoptimalan Gambar Penting untuk tips lainnya.

Menghilangkan resource yang memblokir render

Menurut laporan terbaru, menghilangkan resource yang memblokir rendering sekarang menjadi peluang terbesar.

Resource pemblokir render adalah file JavaScript atau CSS eksternal yang harus didownload, diurai, dan dijalankan oleh browser sebelum dapat menampilkan halaman. Tujuannya adalah hanya menjalankan kode CSS dan JavaScript inti yang diperlukan untuk menampilkan halaman dengan benar.

Selanjutnya, tugas pertama adalah menemukan kode yang tidak perlu dieksekusi saat pemuatan halaman.

1. Klik Eliminasi resource yang memblokir render untuk melihat resource yang memblokir: lodash.js dan jquery.js.

   

2. Bergantung pada sistem operasi Anda, tekan tombol berikut untuk membuka Menu Perintah:

   • Di Mac, Command+Shift+P
   • Di Windows, Linux, atau ChromeOS, Control+Shift+P

3. Mulai ketik Coverage, lalu pilih Tampilkan Cakupan.

   

   Tab Cakupan akan terbuka di Panel Samping.

   

4. Klik Muat ulang. Tab Cakupan memberikan ringkasan tentang jumlah kode dalam bundle.js, jquery.js, dan lodash.js yang dijalankan saat halaman dimuat.

   

   Tangkapan layar ini mengatakan bahwa masing-masing sekitar 74% dan 30% dari file jQuery dan Lodash tidak digunakan.

5. Klik baris jquery.js. DevTools akan membuka file di panel Sources. Baris kode dieksekusi jika memiliki bilah hijau di sebelahnya. Bilah merah di samping baris kode berarti kode tidak dieksekusi, dan pasti tidak diperlukan saat pemuatan halaman.

   

6. Scroll kode jQuery sedikit. Beberapa baris yang "dieksekusi" sebenarnya hanyalah komentar. Menjalankan kode ini melalui minifier yang menghapus komentar adalah cara lain untuk mengurangi ukuran file ini.

Singkatnya, saat Anda menangani kode Anda sendiri, tab Cakupan dapat membantu menganalisis kode, baris demi baris, dan hanya mengirimkan kode yang diperlukan untuk pemuatan halaman.

Apakah file jquery.js dan lodash.js memang diperlukan untuk memuat halaman? Tab Request Blocking dapat menunjukkan apa yang terjadi saat resource tidak tersedia.

1. Klik tab Jaringan dan buka Menu Perintah lagi.

2. Mulai ketik blocking, lalu pilih Show Request Blocking. Tab Minta Pemblokiran akan terbuka.

   

3. Klik Tambahkan Pola, ketik /libs/* di kotak teks, dan tekan Enter untuk mengonfirmasi.

   

4. Muat ulang halaman. Permintaan jQuery dan Lodash berwarna merah, artinya permintaan tersebut diblokir. Halaman masih dimuat dan bersifat interaktif, sehingga sepertinya resource ini tidak diperlukan sama sekali.

   

5. Klik Hapus semua pola untuk menghapus pola pemblokiran /libs/*.

Secara umum, tab Request Blocking berguna untuk menyimulasikan perilaku halaman Anda saat resource tertentu tidak tersedia.

Sekarang, hapus referensi ke file ini dari kode dan audit halaman lagi:

1. Kembali ke tab editor, buka template.html.

2. Hapus tag <script> yang sesuai:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. Tunggu hingga situs dibangun ulang dan di-deploy ulang.

4. Audit kembali halaman dari panel Lighthouse. Skor keseluruhan Anda seharusnya meningkat lagi.

   

Mengoptimalkan Jalur Rendering Penting di dunia nyata

Jalur Rendering Penting mengacu pada kode yang Anda perlukan untuk memuat halaman. Secara umum, Anda dapat mempercepat pemuatan halaman dengan hanya mengirimkan kode penting selama pemuatan halaman, lalu memuat lambat untuk lainnya.

• Anda kemungkinan tidak akan menemukan skrip yang dapat langsung dihapus, tetapi sering kali Anda akan menemukan bahwa banyak skrip yang tidak perlu diminta selama pemuatan halaman, dan justru dapat diminta secara asinkron. Lihat Menggunakan asinkron atau tunda.
• Jika Anda menggunakan framework, periksa apakah framework tersebut memiliki mode produksi. Mode ini dapat menggunakan fitur seperti tree shaking untuk menghilangkan kode tidak perlu yang memblokir render penting.

Melakukan lebih sedikit pekerjaan thread utama

Laporan terbaru Anda menunjukkan beberapa potensi penghematan kecil di bagian Peluang, tetapi jika Anda men-scroll ke bawah ke bagian Diagnostik, sepertinya bottleneck terbesar adalah terlalu banyak aktivitas thread utama.

Thread utama adalah tempat browser melakukan sebagian besar pekerjaan yang diperlukan untuk menampilkan halaman, seperti mengurai dan mengeksekusi HTML, CSS, dan JavaScript.

Tujuannya adalah menggunakan panel Performance untuk menganalisis pekerjaan yang dilakukan thread utama saat halaman dimuat, dan menemukan cara untuk menunda atau menghapus pekerjaan yang tidak perlu.

1. Buka Performa > Setelan Tangkapan, lalu tetapkan Jaringan ke 3G lambat dan CPU ke 6x lebih lambat.

   

   Perangkat seluler biasanya memiliki lebih banyak batasan hardware dibandingkan laptop atau desktop, sehingga setelan ini memungkinkan Anda mengalami pemuatan halaman seolah-olah Anda menggunakan perangkat yang tidak terlalu canggih.

2. Klik Muat ulang. DevTools memuat ulang halaman, lalu menghasilkan visualisasi yang harus dilakukan untuk memuat halaman. Visualisasi ini akan disebut sebagai trace.

   

Rekaman aktivitas menampilkan aktivitas secara kronologis, dari kiri ke kanan. Diagram FPS, CPU, dan NET di bagian atas memberi Anda ringkasan frame per detik, aktivitas CPU, dan aktivitas jaringan.

Dinding berwarna kuning yang Anda lihat di bagian Overview berarti CPU benar-benar sibuk dengan aktivitas pembuatan skrip. Ini adalah petunjuk bahwa Anda mungkin dapat mempercepat pemuatan halaman dengan melakukan lebih sedikit pekerjaan JavaScript.

Selidiki rekaman aktivitas untuk menemukan cara melakukan lebih sedikit pekerjaan JavaScript:

1. Klik bagian Timings untuk meluaskannya.

   

   Ada banyak pengukuran User Timing dari React, sepertinya aplikasi Tony menggunakan mode pengembangan React. Peralihan ke mode produksi React mungkin akan menghasilkan beberapa performa yang mudah.

2. Klik Timings lagi untuk menciutkan bagian tersebut.

3. Jelajahi bagian Utama. Bagian ini menampilkan log kronologis aktivitas thread utama, dari kiri ke kanan. Sumbu y (atas ke bawah) menunjukkan alasan terjadinya peristiwa.

   

   Dalam contoh ini, peristiwa Evaluate Script menyebabkan fungsi (anonymous) dieksekusi, yang menyebabkan __webpack__require__ dieksekusi, yang menyebabkan ./src/index.jsx dieksekusi, dan seterusnya.

4. Scroll ke bawah ke bagian Utama. Saat Anda menggunakan framework, sebagian besar aktivitas atas disebabkan oleh framework, yang biasanya di luar kontrol Anda. Aktivitas yang disebabkan oleh aplikasi Anda biasanya berada di bagian bawah.

   

   Di aplikasi ini, sepertinya fungsi bernama App menyebabkan banyak panggilan ke fungsi mineBitcoin. Sepertinya Tony menggunakan perangkat para penggemarnya untuk menambang mata uang kripto...

5. Buka tab Bottom-Up di bagian bawah. Tab ini menguraikan aktivitas yang paling banyak menghabiskan waktu. Jika Anda tidak melihat apa pun di bagian Bottom-Up, klik label untuk bagian Utama.

   

   Bagian Bottom-Up hanya menampilkan informasi untuk aktivitas, atau grup aktivitas apa pun yang saat ini Anda pilih. Misalnya, jika Anda mengklik salah satu aktivitas mineBitcoin, bagian Bottom-Up hanya akan menampilkan informasi untuk satu aktivitas tersebut.

   Kolom Waktu Mandiri menampilkan jumlah waktu yang dihabiskan langsung di setiap aktivitas. Dalam hal ini, sekitar 82% waktu thread utama dihabiskan untuk fungsi mineBitcoin.

Waktunya untuk melihat apakah menggunakan mode produksi dan mengurangi aktivitas JavaScript akan mempercepat pemuatan halaman. Mulai dengan mode produksi:

1. Di tab editor, buka webpack.config.js.
2. Ubah "mode":"development" menjadi "mode":"production".
3. Tunggu hingga build baru di-deploy.

4. Audit halaman lagi.

   

Kurangi aktivitas JavaScript dengan menghapus panggilan ke mineBitcoin:

1. Di tab editor, buka src/App.jsx.
2. Jadikan panggilan this.mineBitcoin(1500) di constructor sebagai komentar.
3. Tunggu hingga build baru di-deploy.
4. Audit halaman lagi.

Seperti biasa, masih ada hal-hal yang perlu dilakukan, misalnya, kurangi metrik Largest Contentful Paint dan Pergeseran Tata Letak Kumulatif.

Melakukan lebih sedikit pekerjaan thread utama di dunia nyata

Secara umum, panel Performa adalah cara paling umum untuk memahami aktivitas yang dilakukan situs Anda saat dimuat, dan menemukan cara untuk menghapus aktivitas yang tidak diperlukan.

Jika Anda lebih menyukai pendekatan yang terasa seperti console.log(), User Timing API memungkinkan Anda menandai fase tertentu dari siklus proses aplikasi secara acak untuk melacak berapa lama waktu yang dibutuhkan masing-masing fase tersebut.

Ringkasan

• Setiap kali Anda berupaya mengoptimalkan performa pemuatan situs, selalu mulai dengan audit. Audit ini menetapkan dasar pengukuran, dan memberi Anda tips tentang cara meningkatkan.
• Buat satu perubahan dalam satu waktu, dan audit halaman setelah setiap perubahan untuk melihat bagaimana perubahan terpisah tersebut memengaruhi performa.

Langkah berikutnya

Jalankan audit di situs Anda sendiri. Jika Anda memerlukan bantuan dalam menafsirkan laporan atau menemukan cara untuk meningkatkan performa pemuatan, lihat semua cara untuk mendapatkan bantuan dari komunitas DevTools:

• Laporkan bug pada dokumen ini di repositori developer.chrome.com.
• Laporkan bug di DevTools di Bug Chromium.
• Diskusikan fitur dan perubahan di Milis. Jangan gunakan milis untuk pertanyaan dukungan. Sebagai gantinya, gunakan Stack Overflow.
• Dapatkan bantuan umum mengenai cara menggunakan DevTools di Stack Overflow. Untuk mengajukan permintaan bug, selalu gunakan Bug Chromium.
• Tweet kami di @ChromeDevTools.