Lihat Situs Anda Memuat Melalui Mata Pengunjung Anda
Dapatkan ide bagus tentang apa yang sebenarnya dialami pengunjung Anda ketika mereka mengunjungi situs web Anda.
Perhatikan ada yang dimuat dengan lambat atau tidak pada tempatnya? Ini dapat membantu Anda mengidentifikasi kelambatan penting dan masalah konversi yang dialami pengunjung Anda.
Tangkapan layar yang menunjukkan hasil uji kinerja web DebugBear, Oktober 2022 Garis film garis waktu menunjukkan kemajuan rendering situs web dari waktu ke waktu.
Misalnya, halaman ini mulai dirender setelah 0,7 detik, dan gambar utama dirender setelah 1,3 detik.
Situs web sepenuhnya dirender, juga dikenal sebagai Visually Complete, ketika widget obrolan ditampilkan setelah 3,7 detik.
Tangkapan layar DebugBear yang menunjukkan kemajuan rendering situs web dari waktu ke waktu, Oktober 2022 Di dalam alat, Anda juga dapat menonton rekaman video dari proses rendering.
Ini adalah cara yang bagus untuk menunjukkan dampak masalah kinerja kepada klien atau anggota tim Anda lainnya.
Tangkapan layar yang menunjukkan rekaman video dari situs web yang dirender sebagian di DebugBear, Oktober 2022 Uji Perubahan Kecepatan Situs Dengan Melihat Statistik Pemuatan Sejati Anda
Katakanlah Anda telah mengoptimalkan situs web Anda, dan Anda ingin memahami apakah perubahan itu akan berdampak.
Alat ini menjalankan "uji lab" di lingkungan yang optimal untuk mengetahui apakah Anda mengoptimalkan situs dengan benar.
Saat Anda menguji situs Anda, Anda akan mendapatkan "Skor Lab" resmi, yang merupakan ringkasan dari enam metrik kinerja yang berasal dari Skor kinerja dari alat Lighthouse Google:
- Cat Contentful Pertama (10% dari skor keseluruhan).
- Indeks Kecepatan (10%).
- Cat Contentful Terbesar (25%).
- Waktu untuk Interaktif (10%).
- Total Waktu Pemblokiran (30%).
- Pergeseran Tata Letak Kumulatif (15%).
Dengan menggunakan data ini, Anda akan menemukan betapa bermanfaatnya putaran terakhir pengoptimalan Anda dan apa yang mungkin perlu Anda ubah.
Sekarang, Anda mungkin bertanya-tanya apa yang perlu Anda ubah. Mari pelajari cara mengoptimalkan situs Anda menggunakan setiap metrik utama dari Ikhtisar Metrik.
Cara Mengoptimalkan Kecepatan Situs Web
Menjalankan tes kecepatan adalah bagian pertama dari perjalanan pengoptimalan situs web Anda.
Setelah Anda memiliki metrik, Anda harus tahu cara menafsirkannya dan apa yang harus dilakukan untuk memperbaikinya.
Di area Ikhtisar Metrik pada laporan kecepatan situs web Anda, Anda akan melihat metrik utama yang akan kami fokuskan untuk membantu mempercepat situs Anda:
- First Contentful Paint : Ini dapat dipercepat dengan memperbaiki kecepatan komunikasi server.
- Cat Contentful Terbesar : Ini dapat dipercepat dengan mengoptimalkan media dan sumber daya.
Selain itu, Anda dapat menggunakan air terjun permintaan untuk melihat berapa lama waktu yang dibutuhkan dan bagaimana pengaruhnya terhadap metrik tersebut.
Cara Mempercepat First Contentful Paint (FCP)
Mari kita mulai dengan membuat situs web Anda muncul lebih cepat untuk pengunjung Anda; kita akan menangani First Contentful Paint terlebih dahulu.
Apa itu First Contentful Paint?
First Contentful Paint mengukur seberapa cepat konten halaman pertama kali mulai muncul setelah pengunjung Anda menavigasi ke halaman itu.
Sangat penting bahwa konten utama Anda muncul dengan cepat agar pengunjung Anda tidak meninggalkan situs web Anda. Semakin cepat pengguna meninggalkan situs Anda, semakin cepat Google mengetahui bahwa pengalaman halaman mungkin buruk.
Tetapi bagaimana Anda tahu persis apa yang menyebabkan situs web Anda dimuat dengan lambat?
Bagaimana Anda menemukan masalah server mana yang memperlambat situs web Anda? Mari kita cari tahu.
Mengapa Cat Contentful Pertama Saya Butuh Waktu Lama?
FCP Anda mungkin terpengaruh oleh kecepatan koneksi server, permintaan server, sumber daya yang memblokir render, dan banyak lagi.
Kedengarannya seperti banyak, tetapi ada cara mudah untuk melihat dengan tepat apa yang memperlambat FCP Anda – request waterfall.
Alat yang berguna ini menunjukkan permintaan apa yang dibuat oleh situs web Anda dan kapan setiap permintaan dimulai dan selesai.
Misalnya, dalam tangkapan layar ini, pertama-tama kita melihat permintaan untuk dokumen HTML dan kemudian dua permintaan untuk memuat lembar gaya yang direferensikan dalam dokumen.
Tangkapan layar yang menampilkan data debug untuk metrik Cat Contentful Pertama di DebugBear, Oktober 2022 Mengapa Cat Contentful Pertama terjadi setelah 0,6 detik? Kami dapat memecah apa yang terjadi pada halaman untuk memahami hal ini.
Memahami Apa yang Terjadi Sebelum Cat Contentful Pertama
Sebelum konten pertama dapat dimuat di halaman web Anda, browser pengguna Anda harus terlebih dahulu terhubung ke server Anda dan mengambil konten tersebut.
Jika proses ini memakan waktu lama, maka dibutuhkan waktu lama bagi pengguna Anda untuk melihat situs web Anda.
Tujuan Anda adalah mempelajari apa yang terjadi sebelum situs web Anda mulai dimuat sehingga Anda dapat menemukan masalah dan mempercepat pengalaman.
Page Load Bagian 1: Browser Membuat Koneksi Server
Sebelum meminta situs web dari server terlebih dahulu, browser pengunjung Anda perlu membuat koneksi jaringan ke server tersebut.
Ini biasanya membutuhkan tiga langkah:
- Memeriksa catatan DNS untuk mencari alamat IP server berdasarkan nama domain.
- Membangun koneksi server yang andal (dikenal sebagai koneksi TCP).
- Membangun koneksi server yang aman (dikenal sebagai koneksi SSL).
Ketiga langkah ini dilakukan oleh browser, satu demi satu. Setiap langkah memerlukan perjalanan pulang pergi dari browser pengunjung Anda ke server situs web Anda.
Dalam hal ini, dibutuhkan sekitar 251 milidetik untuk membuat koneksi server.
Tangkapan layar DebugBear yang menunjukkan perjalanan pulang pergi jaringan yang digunakan untuk membuat koneksi server, Oktober 2022 Page Load Bagian 2: Browser Meminta Dokumen HTML (Waktu Untuk Byte Pertama Terjadi Di Sini)
Setelah koneksi server dibuat, browser pengunjung Anda dapat meminta kode HTML yang berisi konten situs web Anda. Ini disebut permintaan HTTP.
Dalam hal ini, permintaan HTTP membutuhkan waktu 102 milidetik. Durasi ini mencakup waktu yang dihabiskan untuk perjalanan pulang pergi jaringan dan waktu yang dihabiskan untuk menunggu server menghasilkan respons.
Setelah 251 milidetik untuk membuat koneksi dan 102 milidetik untuk membuat permintaan HTTP, browser pengunjung Anda akhirnya dapat mulai mengunduh respons HTML.
Tonggak sejarah ini disebut Time to First Byte (TTFB). Dalam hal ini, itu terjadi setelah total 353 milidetik.
Setelah respons server siap, browser pengunjung Anda menghabiskan beberapa waktu tambahan untuk mengunduh kode HTML. Dalam hal ini, responsnya cukup kecil dan unduhan hanya membutuhkan tambahan 10 milidetik.
Tangkapan layar DebugBear yang menunjukkan berbagai komponen permintaan HTTP, Oktober 2022 Pemuatan Halaman Bagian 3: Situs Web Anda Memuat Sumber Daya Pemblokiran Render Tambahan
Browser tidak merender, atau menampilkan, halaman segera setelah memuat dokumen. Sebagai gantinya, biasanya ada sumber daya pemblokiran render tambahan.
Sebagian besar halaman akan terlihat buruk tanpa gaya visual apa pun, jadi lembar gaya CSS dimuat sebelum halaman mulai dirender.
Memuat 2 lembar gaya tambahan dalam contoh uji kecepatan situs web ini membutuhkan waktu 137 milidetik.
Perhatikan bahwa permintaan ini tidak memerlukan koneksi server baru. File CSS dimuat dari domain yang sama seperti sebelumnya dan dapat menggunakan kembali koneksi yang ada.
Tangkapan layar DebugBear yang menunjukkan sumber daya pemblokiran render tambahan sedang dimuat setelah dokumen HTML, Oktober 2022 Page Load Bagian 4: Browser Membuat Halaman
Terakhir, setelah semua sumber daya yang diperlukan telah dimuat, browser pengunjung Anda dapat mulai merender halaman. Namun, melakukan pekerjaan ini juga membutuhkan beberapa waktu pemrosesan – dalam hal ini, 66 milidetik. Ini ditunjukkan oleh penanda tugas CPU oranye di tampilan air terjun.
Tangkapan layar DebugBear yang menunjukkan langkah-langkah mulai dari memuat dokumen HTML hingga merender halaman web, Oktober 2022 Kami sekarang mengerti mengapa FCP terjadi setelah 632 milidetik:
- 364 milidetik untuk permintaan Dokumen HTML.
- 137 milidetik untuk memuat stylesheet.
- 66 milidetik untuk merender halaman.
- 65 milidetik untuk pekerjaan pemrosesan lainnya.
Pekerjaan pemrosesan lainnya mencakup pekerjaan kecil seperti menjalankan skrip sebaris atau menguraikan kode HTML dan CSS setelah diunduh. Anda dapat melihat aktivitas ini sebagai garis abu-abu kecil tepat di bawah strip film rendering.
Cara Mengoptimalkan First Contentful Paint (FCP)
Sekarang setelah Anda memahami apa yang menyebabkan situs web Anda dirender, Anda dapat memikirkan cara mengoptimalkannya.
- Bisakah server merespons permintaan HTML lebih cepat?
- Bisakah sumber daya dimuat melalui koneksi yang sama alih-alih membuat yang baru?
- Apakah ada permintaan yang dapat dihapus atau diubah agar tidak lagi memblokir rendering?
Sekarang bagian awal situs web Anda dimuat lebih cepat, saatnya untuk fokus membuat situs penuh dimuat lebih cepat.
Bagaimana Mempercepat Cat Contentful Terbesar (LCP) Dengan Rekomendasi DebugBear
Ada banyak cara untuk mempercepat LCP Anda.
Untuk mempermudah, DebugBear memberi kami langkah-langkah hebat berikutnya di bagian Rekomendasi mereka.
Mari kita lihat beberapa contoh rekomendasi dan pelajari cara mempercepat LCP situs web ini.
Rekomendasi 1: Memulai Permintaan Gambar LCP Dari Dokumen HTML
Jika elemen konten terbesar di halaman Anda adalah gambar, praktik terbaiknya adalah memastikan bahwa URL langsung dimuat dalam dokumen HTML awal. Ini akan membantunya mulai memuat sesegera mungkin.
Namun, praktik terbaik ini tidak selalu digunakan, dan terkadang dibutuhkan waktu lama sebelum browser menemukan bahwa ia perlu mengunduh gambar utama.
Pada contoh di bawah, konten terbesar, yaitu gambar, ditambahkan ke halaman menggunakan JavaScript. Akibatnya, browser perlu mengunduh dan menjalankan skrip 200 kilobyte sebelum menemukan gambar dan mulai mengunduhnya.
Tangkapan layar DebugBear menunjukkan rantai permintaan berurutan yang mengarah ke permintaan gambar, Oktober 2022 Cara Memperbaiki: Tergantung pada situs webnya, ada dua kemungkinan solusi.
Solusi 1: Jika Anda menggunakan JavaScript untuk malas memuat gambar besar, optimalkan ukuran gambar dan hapus skrip pemuatan lambat atau ganti dengan atribut modern loading=”lazy”, yang tidak memerlukan JavaScript.
Solusi 2: Dalam kasus lain, rendering sisi server akan mencegah keharusan mengunduh aplikasi JavaScript sebelum halaman dapat dirender. Namun, ini terkadang rumit untuk diterapkan.
Rekomendasi 2: Pastikan Gambar LCP Dimuat Dengan Prioritas Tinggi
Setelah memuat kode HTML laman, peramban pengunjung Anda mungkin menemukan bahwa, selain gambar utama Anda, sejumlah besar sumber daya tambahan seperti lembar gaya mungkin perlu dimuat.
Tujuannya di sini adalah untuk memastikan bahwa gambar utama Anda yang lebih besar dimuat untuk memenuhi persyaratan Cat Konten Terbesar oleh Google.
Sumber daya lain, seperti skrip analitik pihak ketiga, tidak sepenting gambar utama Anda.
Selain itu, sebagian besar gambar yang dirujuk dalam HTML situs Anda akan berada di paro bawah setelah laman dirender. Beberapa mungkin disembunyikan sepenuhnya di navigasi header bersarang.
Karena itu, browser awalnya menetapkan prioritas semua permintaan gambar ke Rendah. Setelah halaman dirender, browser mengetahui gambar mana yang penting dan mengubah prioritas. Anda dapat melihat contohnya pada tangkapan layar di bawah, seperti yang ditunjukkan oleh tanda bintang di kolom prioritas.
Tangkapan layar DebugBear yang menunjukkan gambar LCP sedang dimuat dengan prioritas awal rendah, Oktober 2022 Air terjun menunjukkan bahwa sementara browser mengetahui tentang gambar sejak awal, itu tidak mulai mengunduhnya, seperti yang ditunjukkan oleh bilah abu-abu.
Cara Memperbaiki: Untuk mengatasi ini, Anda dapat menggunakan fitur browser baru yang disebut petunjuk prioritas. Jika Anda menambahkan atribut fetchpriority="high" ke elemen img, browser akan mulai memuat gambar sejak awal.
Rekomendasi 3: Jangan Sembunyikan Konten Halaman Menggunakan CSS
Terkadang Anda mungkin melihat air terjun permintaan dan semua sumber daya pemblokiran render telah dimuat tetapi tetap saja, tidak ada konten halaman yang muncul. Apa yang sedang terjadi?
Alat pengujian A/B sering kali menyembunyikan konten halaman hingga variasi pengujian diterapkan ke elemen konten di halaman. Dalam kasus tersebut, browser telah merender halaman tetapi semua konten transparan.
Apa yang dapat Anda lakukan jika Anda tidak dapat menghapus alat pengujian A/B?
Cara Memperbaiki: Periksa apakah Anda dapat mengonfigurasi alat untuk hanya menyembunyikan konten yang terpengaruh oleh pengujian A/B. Atau, Anda dapat memeriksa apakah ada cara untuk membuat alat pengujian A/B memuat lebih cepat.
Tangkapan layar DebugBear yang menampilkan strip film rendering tempat konten disembunyikan oleh alat pengujian A/B, Oktober 2022 Pantau Kecepatan Situs Anda Dengan DebugBear
Ingin terus menguji situs web Anda? Coba alat pemantauan berbayar kami dengan uji coba gratis selama 14 hari.
Dengan begitu, Anda dapat memeriksa apakah pengoptimalan kinerja Anda berfungsi dan mendapatkan peringatan tentang regresi kinerja apa pun di situs Anda.
Tangkapan layar yang menunjukkan tren kecepatan situs untuk situs web di DebugBear, Oktober 2022 
Tangkapan layar yang menunjukkan data Data Web Inti di DebugBear, Oktober 2022