Lighthouse: Mengoptimalkan kecepatan situs

Kayce Basques

Sofia Emelianova

Ringkasan

Gunakan panel Lighthouse untuk menjalankan audit komprehensif terhadap situs Anda. Panel Lighthouse menghasilkan laporan yang memberikan insight tentang hal berikut tentang situs Anda:

• Performa
• Aksesibilitas
• Praktik Terbaik
• SEO

... dan banyak metrik lainnya.

Tutorial berikut membantu Anda memulai Lighthouse di Chrome DevTools.

Untuk mempelajari lebih lanjut cara lain yang dapat dilakukan Lighthouse untuk meningkatkan kualitas situs Anda, lihat dokumen Lighthouse kami.

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:

Video ini dibuat dengan Chrome 68. Sebagian besar hal yang masih berlaku, tetapi beberapa fitur telah diperbarui. Misalnya, Panel Audits sekarang disebut Lighthouse, dan memiliki tampilan yang berbeda, tetapi semua opsi yang sama tetap tersedia.

Prasyarat

Anda harus memiliki pengalaman pengembangan web dasar, mirip dengan yang diajarkan di 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 membangun situs agar penggemarnya dapat mempelajari konten favoritnya makanan tersebut. Para penggemarnya menyukai situs tersebut, tetapi Tony terus mendengar keluhan bahwa situs dimuat dengan lambat. Tony telah meminta Anda untuk membantunya mempercepat situs itu.

Tony si kucing.

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, agar Anda dapat membuat perubahan 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 > Lihat pratinjau di jendela baru. 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.

   

Poin penting: Untuk screenshot lainnya dalam tutorial ini, DevTools ditampilkan di jendela terpisah.

Menetapkan dasar pengukuran

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

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

   Catatan: Panel ini didukung oleh panel yang bernama sama—Lighthouse, sebuah alat otomatis untuk meningkatkan kualitas aplikasi web Anda.

   

2. Cocokkan setelan konfigurasi laporan Lighthouse Anda dengan setelan yang ada di screenshot. Berikut adalah penjelasan mengenai opsi yang berbeda:

   • 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) . Opsi ini menyimulasikan kondisi umum penjelajahan di perangkat seluler. Alat ini disebut "simulasi" karena Lighthouse tidak benar-benar melakukan {i>throttle<i} 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 > 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 > Seluler. Opsi seluler mengubah string agen pengguna dan menyimulasikan area pandang. 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. Hal ini memastikan bahwa Anda menjalankan Chrome dalam keadaan bersih. Ekstensi Chrome secara khusus dapat mengganggu proses audit.

Memahami laporan

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

Metrik

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 pemuatan halaman, sedangkan Waktu Untuk Interaktif 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 pemuatan halaman tertentu ini tingkat tinggi.

Klik peluang untuk mempelajarinya lebih lanjut.

Klik Pelajari lebih lanjut... untuk melihat dokumentasi tentang mengapa peluang itu penting dan spesifik rekomendasi tentang cara memperbaikinya.

Diagnostik

Bagian Diagnostik memberikan informasi lebih lanjut tentang faktor yang berkontribusi terhadap waktu pemuatan.

Lulus audit

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

Langkah 2: Bereksperimen

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

Aktifkan kompresi teks

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

Kompresi teks adalah ketika 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 sumber daya akan dikompresi.

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

Poin penting: Jika Anda tidak melihat kolom Size di tabel permintaan jaringan, klik kanan header tabel dan pilih Size.

Setiap sel Size menunjukkan dua nilai. Nilai teratas adalah ukuran resource yang didownload. Tujuan nilai terbawah adalah ukuran resource yang tidak dikompresi. Jika kedua nilai itu sama, maka sumber daya 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 bahwa bundle.js tidak dikompresi. Saat resource dikompresi, header ini akan biasanya ditetapkan ke gzip, deflate, atau br. Lihat Petunjuk untuk penjelasan mengenai hal ini masing-masing.

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')).

   

   Catatan: Biasanya, Anda harus menginstal paket compression melalui sesuatu seperti npm i -S compression, tetapi langkah ini sudah dilakukan untuk Anda.

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 kembali laporan Lighthouse di halaman untuk mengukur dampak kompresi teks terhadap pemuatan halaman performa:

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 penelusuran tentang untuk 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 Anda melihat gambar Anda pada layar perangkat seluler dengan lebar 500 piksel, benar-benar 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 bahwa skor tidak terlihat dengan jelas adalah berapa banyak data jaringan yang Anda simpan bagi pengguna. Total ukuran foto lama sekitar 6,1 MB, padahal 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, 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 akan mengurangi ukuran file gambar. Lihat Penting Pengoptimalan Gambar untuk tips lainnya.

Menghilangkan resource yang memblokir render

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

Sumber daya pemblokir render adalah file JavaScript atau CSS eksternal yang harus diunduh browser, mengurai, dan mengeksekusi sebelum dapat menampilkan halaman. Tujuannya adalah untuk hanya menjalankan CSS dan JavaScript inti kode yang diperlukan untuk menampilkan halaman dengan benar.

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

1. Klik Hilangkan aset yang memblokir render untuk melihat aset 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 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. Sebuah baris kode dieksekusi jika terdapat bilah hijau di sebelahnya. Bilah merah di sebelah baris kode berarti kode tidak dieksekusi, dan benar-benar tidak diperlukan pada saat pemuatan halaman.

   

6. Scroll kode jQuery sedikit. Beberapa baris yang "dijalankan" sebenarnya hanya 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 Minta Pemblokiran dapat menunjukkan apa yang terjadi saat sumber daya 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, lalu tekan Enter untuk mengonfirmasi.

   

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

   

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

Secara umum, tab Pemblokiran Permintaan berguna untuk menyimulasikan perilaku halaman Anda saat resource 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 dapat mempercepat pemuatan halaman dengan hanya mengirimkan kode penting selama pemuatan halaman, lalu pemuatan lambat segala hal lainnya.

• Kecil kemungkinan Anda akan menemukan skrip yang dapat langsung dihapus, tetapi Anda akan sering menemukannya banyak skrip yang tidak perlu diminta selama pemuatan halaman, tetapi 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 sebagai 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 bagian Diagnostik. Sepertinya bottleneck terbesar adalah terlalu banyak thread utama aktivitas Anda.

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

Catatan: Bagian ini memberikan pengantar yang cukup singkat tentang panel Performa. Lihat Referensi fitur performa untuk mempelajari lebih lanjut cara menggunakannya untuk menganalisis halaman performa.

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

1. Buka Performa > Ambil Setelan dan 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 Muat ulang. DevTools memuat ulang halaman, lalu menghasilkan visualisasi yang harus dilakukan untuk memuat halaman. Visualisasi ini akan disebut sebagai rekaman aktivitas.

   

Rekaman aktivitas menampilkan aktivitas secara kronologis, dari kiri ke kanan. Diagram FPS, CPU, dan NET di memberikan gambaran umum tentang {i>frame per detik<i}, 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 menunjukkan log kronologis dari 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 sebuah {i>framework<i}, sebagian besar aktivitas atas disebabkan oleh kerangka kerja, yang biasanya di luar kendali 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...

   Catatan: Meskipun panggilan yang dilakukan framework biasanya berada di luar kendali Anda, terkadang Anda mungkin membuat struktur aplikasi sedemikian rupa sehingga menyebabkan framework berjalan secara tidak efisien. Restrukturisasi aplikasi Anda untuk menggunakan framework secara efisien bisa menjadi cara untuk melakukan lebih sedikit pekerjaan thread utama. Hal ini memerlukan pemahaman mendalam tentang cara kerja framework Anda, dan jenis perubahan yang dapat Anda buat dalam kode Anda sendiri agar dapat menggunakan framework secara lebih efisien.

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 Anda miliki saat ini dipilih. 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 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.

Berhasil: Tapi sepertinya perubahan terakhir yang menyebabkan lonjakan performa yang signifikan.

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 perlu.

Jika Anda lebih memilih pendekatan yang terasa seperti console.log(), User Timing API memungkinkan Anda secara bebas menandai fase tertentu dari siklus hidup aplikasi Anda, untuk melacak berapa lama masing-masing fase fase-fase yang diperlukan.

Ringkasan

• Setiap kali Anda berupaya mengoptimalkan performa pemuatan situs, selalu mulai dengan audit. Audit menetapkan dasar, dan memberi Anda tips tentang cara menjadi lebih baik.
• Buat satu perubahan dalam satu waktu, dan audit laman setelah setiap perubahan untuk melihat bagaimana perubahan terisolasi itu memengaruhi kinerja.

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 teknis IT. 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.