Lighthouse: Mengoptimalkan kecepatan situs

Kayce Basques

Twitter GitHub Glitch

Sofia Emelianova

GitHub

Sasaran tutorial

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

Lanjutkan membaca, atau tonton versi video tutorial ini:

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

Prasyarat

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

Anda tidak perlu mengetahui apa pun tentang performa pemuatan.

Pengantar

Ini Tony. Tony sangat terkenal dalam komunitas kucing. Dia telah membuat situs sehingga penggemarnya dapat mengetahui makanan favoritnya. Penggemarnya menyukai situs tersebut, tetapi Tony terus mendengar keluhan bahwa situsnya lambat dimuat. Toni meminta Anda untuk membantunya mempercepat situs.

Toni si kucing.

Langkah 1: Audit situs

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

• Hal ini membuat dasar pengukuran agar Anda dapat mengukur perubahan selanjutnya.
• Halaman ini memberi Anda tips yang dapat ditindaklanjuti tentang perubahan yang akan memberikan dampak terbesar.

Penyiapan

Pertama, Anda perlu menyiapkan lingkungan kerja baru untuk situs Tony, sehingga nanti Anda dapat membuat perubahan padanya:

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

   

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

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 di samping demo.

   

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

Menetapkan dasar pengukuran

Dasar pengukuran adalah catatan tentang performa situs sebelum Anda melakukan peningkatan performa apa pun.

1. Buka panel Lighthouse. Panel ini mungkin tersembunyi di balik Panel lainnya.

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

   

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

   • Hapus Penyimpanan. Jika kotak centang ini diaktifkan, semua penyimpanan yang terkait dengan halaman sebelum setiap audit akan dihapus. Tetap aktifkan setelan ini jika Anda ingin mengaudit pengalaman pengunjung kali pertama di situs Anda. Nonaktifkan setelan ini jika Anda ingin mengulangi kunjungan.
   • Simulasi throttling (default) . Opsi ini menyimulasikan kondisi umum penjelajahan di perangkat seluler. Ini disebut "disimulasikan" karena Lighthouse tidak benar-benar men-throttle selama proses audit. Sebaliknya, fitur ini hanya memperkirakan waktu yang diperlukan untuk memuat halaman dalam kondisi seluler. Di sisi lain, setelan throttling DevTools (lanjutan) sebenarnya akan men-throttle CPU dan jaringan Anda, dengan konsekuensi dari proses audit yang lebih lama.
   • Mode > Navigasi (Default). Mode ini menganalisis satu pemuatan halaman dan hal itulah yang kita perlukan dalam tutorial ini. Untuk mengetahui informasi selengkapnya, lihat Tiga mode.
   • Perangkat > Seluler. Opsi seluler mengubah string agen pengguna dan menyimulasikan area pandang seluler. Opsi {i>desktop<i} hanya menonaktifkan perubahan pada ponsel.
   • Kategori > Performa. Satu kategori yang diaktifkan akan membuat Lighthouse membuat laporan hanya dengan rangkaian audit yang sesuai. Anda dapat tetap mengaktifkan kategori lain jika ingin melihat jenis rekomendasi yang diberikan. Menonaktifkan kategori yang tidak relevan akan sedikit mempercepat proses audit.

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

   

Menangani error laporan

Jika Anda pernah mendapatkan error dalam laporan Lighthouse, coba jalankan tab demo dari jendela samaran tanpa membuka tab lain. 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 adalah skor performa keseluruhan untuk situs. Kemudian, saat membuat perubahan pada kode, Anda akan melihat angka ini meningkat. Skor yang lebih tinggi berarti performa yang lebih baik.

Metrik

Scroll ke bawah ke bagian Metrics, lalu klik Expand view. 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 digambar ke layar, yang merupakan tahap penting bagi persepsi pengguna tentang 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 khusus tentang cara meningkatkan performa pemuatan halaman tertentu.

Klik peluang untuk mempelajarinya lebih lanjut.

Klik Learn more... 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 Audit yang lulus menunjukkan performa situs dengan benar. Klik untuk meluaskan bagian ini.

Langkah 2: Eksperimen

Bagian Peluang pada 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 utama untuk meningkatkan performa halaman.

Kompresi teks adalah saat Anda mengurangi atau mengompresi ukuran file teks sebelum mengirimkannya melalui jaringan. Ini seperti bagaimana Anda melakukan zip folder sebelum mengirimkannya melalui email untuk memperkecil ukurannya.

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

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

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

Setiap sel Ukuran 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 Header Respons untuk header content-encoding. Anda tidak akan melihatnya, artinya bundle.js tidak dikompresi. Saat resource dikompresi, header ini biasanya disetel ke gzip, deflate, atau br. Lihat Perintah untuk penjelasan tentang nilai ini.

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

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

   ...
   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. Emoji gembira di pojok kiri bawah menunjukkan keberhasilan deployment.

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

1. Kembali ke tab demo dan muat ulang halaman.

   Kolom Size kini seharusnya menampilkan dua nilai yang berbeda untuk resource teks seperti bundle.js. Nilai atas 269 KB untuk bundle.js adalah ukuran file yang dikirim melalui jaringan, dan nilai bawah 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 performa pemuatan halaman:

1. Buka panel Lighthouse, lalu klik Perform an audit... pada panel tindakan di bagian atas.

   

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

   

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

Kompresi teks di dunia nyata

Sebagian besar server memiliki perbaikan sederhana seperti ini untuk mengaktifkan kompresi. Lakukan pencarian tentang cara mengkonfigurasi server apa pun yang Anda gunakan untuk mengompresi teks.

Mengubah ukuran gambar

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

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

1. Dalam laporan Anda, klik Ukuran gambar yang sesuai untuk mengetahui gambar yang harus diubah ukurannya. Sepertinya keempat gambar tersebut lebih besar dari yang diperlukan.

   

2. Kembali di 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 pengaruh perubahan ini terhadap performa pemuatan.

   

Sepertinya perubahan tersebut hanya berdampak kecil pada skor performa secara keseluruhan. Namun, ada satu hal yang tidak ditampilkan dengan jelas oleh skor ini adalah jumlah data jaringan yang disimpan pengguna. Ukuran total foto lama sekitar 6,1 MB, sedangkan sekarang hanya sekitar 633 kB. Anda dapat memeriksanya di status bar di bagian bawah panel Jaringan.

Mengubah ukuran gambar di dunia nyata

Untuk aplikasi kecil, mengubah ukuran satu kali seperti ini mungkin cukup baik. Namun, untuk aplikasi besar, hal ini jelas tidak terukur. Berikut beberapa strategi untuk mengelola gambar di aplikasi besar:

• Mengubah ukuran gambar selama proses build.
• Buat beberapa ukuran untuk setiap gambar selama proses build, lalu gunakan srcset dalam kode Anda. Saat runtime, browser akan memilih ukuran 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 menghasilkan penghematan yang sangat besar. Pengoptimalan adalah saat Anda menjalankan gambar melalui program khusus yang mengurangi ukuran file gambar. Lihat Pengoptimalan Gambar Penting untuk tips lainnya.

Hilangkan resource yang memblokir render

Laporan terbaru Anda menyatakan bahwa menghilangkan resource yang memblokir perenderan kini menjadi peluang terbesar.

Resource yang memblokir rendering adalah file JavaScript atau CSS eksternal yang harus didownload, diurai, dan dieksekusi 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 dijalankan saat pemuatan halaman.

1. Klik Eliminate rendering-blocking resource untuk melihat resource yang memblokir: lodash.js dan jquery.js.

   

2. Bergantung pada sistem operasi Anda, tekan perintah berikut untuk membuka Menu Command:

   • 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 banyaknya kode di bundle.js, jquery.js, dan lodash.js yang dieksekusi saat halaman dimuat.

   

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

5. Klik baris jquery.js. DevTools akan membuka file di panel Sources. Satu baris kode dieksekusi jika ada batang hijau di sampingnya. Batang merah di samping baris kode berarti kode tersebut tidak dijalankan, dan tentunya tidak diperlukan saat halaman dimuat.

   

6. Scroll sedikit kode jQuery. 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 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 diperlukan untuk memuat halaman? Tab Request Blocking dapat menunjukkan apa yang terjadi jika resource tidak tersedia.

1. Klik tab Network dan buka Command Menu lagi.

2. Mulai ketik blocking, lalu pilih Show Request Blocking. Tab Request Blocking 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, yang berarti 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 di 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 halaman lagi dari panel Lighthouse. Skor keseluruhan Anda seharusnya sudah 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 menjalankan pemuatan lambat untuk hal lainnya.

• Anda mungkin tidak akan menemukan skrip yang dapat langsung dihapus, tetapi Anda akan sering menemukan bahwa banyak skrip tidak perlu diminta selama pemuatan halaman, dan sebagai gantinya dapat diminta secara asinkron. Lihat Menggunakan asinkron atau tangguhkan.
• 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 tugas 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.

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

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

1. Buka Performance > Capture Settings dan setel Network ke Slow 3G dan CPU ke 6x pelambatan.

   

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

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

   

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

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

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

1. Klik bagian Waktu untuk meluaskannya.

   

   Ada banyak pengukuran Waktu Pengguna dari React, sepertinya aplikasi Toni menggunakan mode pengembangan React. Beralih ke mode produksi React mungkin akan menghasilkan beberapa peningkatan performa yang mudah.

2. Klik Waktu 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 menggunakan framework, sebagian besar aktivitas atas disebabkan oleh framework, yang biasanya di luar kendali Anda. Aktivitas yang disebabkan oleh aplikasi Anda biasanya ada di bagian bawah.

   

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

   Catatan: Meskipun panggilan yang dilakukan framework biasanya di luar kendali Anda, terkadang Anda dapat membuat struktur aplikasi sedemikian rupa sehingga menyebabkan framework berjalan secara tidak efisien. Merestrukturisasi 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, dan jenis perubahan yang dapat dibuat dalam kode Anda sendiri agar dapat menggunakan framework dengan lebih efisien.

5. Buka tab Bottom-Up di bagian bawah. Tab ini mengelompokkan aktivitas yang memerlukan waktu paling lama. 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 secara langsung dalam setiap aktivitas. Dalam hal ini, sekitar 82% waktu thread utama dihabiskan di 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 kembali halaman tersebut.

   

Kurangi aktivitas JavaScript dengan menghapus panggilan ke mineBitcoin:

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

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

Berhasil: Namun, sepertinya perubahan terakhir menyebabkan lonjakan performa yang besar.

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 memilih pendekatan yang lebih terasa seperti console.log(), User Timing API memungkinkan Anda me-markup fase tertentu dari siklus proses aplikasi secara sembarang untuk melacak waktu yang diperlukan oleh setiap fase tersebut.

Ringkasan

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

Langkah berikutnya

Jalankan audit di situs Anda sendiri. Jika Anda memerlukan bantuan untuk menafsirkan laporan atau menemukan cara untuk meningkatkan kinerja 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 Chromium Bugs.
• Diskusikan fitur dan perubahan di Mailing List. Jangan gunakan milis untuk pertanyaan dukungan. Sebagai gantinya, gunakan Stack Overflow.
• Dapatkan bantuan umum tentang cara menggunakan DevTools di Stack Overflow. Untuk mengajukan permintaan bug, selalu gunakan Bug Chromium.
• Kirimkan tweet kepada kami di @ChromeDevTools.