Konsep lanjutan untuk mengukur kecepatan halaman pada tahun 2020

Diterbitkan: 2020-04-09

Untuk memahami apa yang memengaruhi kecepatan halaman pada tahun 2020, pertama-tama kita perlu memahami bagaimana browser merender halaman web. Jika Anda tidak terbiasa dengan kecepatan halaman dan konsep teknologi web seperti DOM, CSSOM, pohon rendering, biaya reflow, dan jenis DOM, Anda mungkin ingin memulai dengan membaca artikel yang ditautkan di atas.

Ketika situs web dan browser web menjadi lebih kompleks, kecepatan halaman menjadi lebih dari sekadar seberapa besar halaman atau seberapa cepat server dapat merespons. Dalam artikel ini, kita akan melihat beberapa metrik baru dan yang muncul untuk kecepatan halaman pada tahun 2020 dan seterusnya: jumlah dan ukuran permintaan sumber daya, jalur rendering penting, LCP, CLS, dan total waktu pemblokiran.

Artikel ini adalah yang kedua dari empat artikel tentang kecepatan halaman. Anda dapat menemukan artikel pertama di sini: Bagaimana cara browser membuat halaman web?

Mengelola pesanan, ukuran, dan jumlah permintaan sumber daya

Setiap langkah proses rendering membutuhkan waktu. Cara untuk menemukan di mana situs web Anda lambat, dan cara mempercepatnya, melibatkan melihat bagaimana browser menangani sumber daya selama proses rendering halaman.

Ini berarti bahwa urutan, jumlah, dan ukuran permintaan memainkan peran utama dalam mengukur kecepatan halaman saat ini.

Kontribusi terpenting dari urutan sumber daya dan pengoptimalan petunjuk pemuatan sumber daya adalah mengurangi TTI (Waktu untuk Interaktif) melalui Cat Konten Terbesar. Dengan pengoptimalan urutan sumber daya, Anda dapat mengunggah file dengan jumlah dan ukuran yang sama dalam waktu yang lebih singkat dan mengirimkannya ke pengguna dan mesin telusur.

Apa itu Jalur Rendering Kritis?

Jalur rendering penting mencakup semua sumber daya yang akan membuat bagian halaman web paro atas.

Halaman web Anda mungkin lebih lambat dari halaman web pesaing Anda karena ukuran pemuatan total halaman Anda. Tapi inilah triknya: bahkan jika departemen bisnis lain tidak mengizinkan Anda memperbaiki ukuran pemuatan halaman, Anda tetap dapat menyajikan konten Anda lebih cepat daripada pesaing Anda dengan mengoptimalkan jalur rendering penting.

Cara mengoptimalkan jalur rendering penting

Ini adalah simulator korelasi kecepatan halaman dan tingkat konversi yang dibuat oleh Sergey Chernyshev. Anda mungkin menemukan jawaban atas pertanyaan tentang apa yang akan terjadi jika halaman web saya dimuat 0,5 detik lebih cepat bagi pengguna dan menunjukkannya kepada tim pengembang Anda untuk menentukan bahwa setiap milidetik dapat meningkatkan konversi.

Untuk mengoptimalkan jalur rendering penting, Anda perlu menentukan sumber daya mana yang Anda perlukan untuk membuat bagian paruh atas. Setelah itu, ada beberapa pertanyaan kecil yang akan ditanyakan:

  1. Sumber daya mana yang mencegah sumber penting diunduh oleh browser?
  2. Bisakah ukuran dan jumlah sumber kritis dikurangi?
  3. Dapatkah sumber-sumber kritis digarisbawahi?
  4. Bisakah sumber jalur rendering penting disatukan untuk membatasi proses pencarian DNS?

Kita akan melihat sebuah contoh. Kami juga akan memberikan beberapa rekomendasi untuk mempercepat CSS, JS dan HTML.

Berikut adalah contoh bagian penting dari halaman web Amazon. Dengan DevTools, Anda dapat melihat elemen <div> terpenting di bagian penting halaman bersama dengan kode CSS yang diperlukan. Dengan cara ini, Anda dapat membuat blok kode CSS sebaris sebelum membuat sumber daya pemblokiran mengganggu browser. Anda mungkin juga melihat tumpukan kode yang tidak digunakan di bagian bawah. Amazon selalu menggunakan pola sumber daya CSS/JS yang sama untuk kategori yang berbeda, meskipun tidak dioptimalkan.

Selain kecepatan, ada juga masalah lain di sini. Dengan ukuran layar ponsel yang berbeda, bagian penting dari halaman web bervariasi dari model ke model. Beberapa layar tidak menunjukkan harga, beberapa di antaranya tidak menampilkan informasi stok. Ini adalah kesalahan desain yang penting, tetapi juga membuat pengoptimalan jalur rendering kritis menjadi lebih sulit. Ini juga membagi nilai PageRank jika ada tautan di area ini dan mengurangi kemungkinan konversi.

Anda dapat menggunakan Puppeteer (Mesin Perayapan Googlebot) untuk memeriksa jenis masalah ini dan mengambil tangkapan layar otomatis untuk setiap model ponsel cerdas/tablet dan memeriksa desain bagian penting dari laman web. Jean-Francois Lagarde memiliki perpustakaan Dalang yang bagus untuk tugas ini yang mungkin ingin Anda periksa.

Berikut adalah tangkapan layar cepat untuk konfigurasi perangkat di tangkapan layar otomatis Dalang untuk setiap alat viewport perangkat.

Apa Cat Contentful Terbesar?

Largest Contentful Paint (LCP) adalah area terbesar di halaman web dalam hal byte dan ukuran. Di setiap halaman web, ada banyak elemen "div" dan semuanya mengandung komponen halaman yang berbeda. Dan komponen ini memiliki nilai pemuatan halaman yang berbeda.

Menurut Google, Cat Konten Terbesar sebagian besar dipengaruhi oleh elemen terpenting halaman. Untuk memberi Anda gambaran tentang pentingnya LCP, Google telah memutuskan untuk menambahkan metrik baru ini ke laporan Lighthouse di masa mendatang.

Ini juga berarti bahwa kita akan semakin sering mendengar tentang LCP, karena akan digunakan bersama dengan Metrik Pengguna Nyata (RUM) dan akan menjadi metrik utama, terutama yang berkaitan dengan jalur rendering penting.

Berikut adalah contoh Cat Contentful Terbesar dari Lendio. Seperti yang Anda lihat, DevTools menampilkan LCP pada halaman bersama dengan data tentang jenis, ukuran, dan waktu muatnya. Konten Cat Konten Terbesar Anda harus selalu menyertakan tujuan dan nilai halaman, bersama dengan fungsionalitas paling penting atau CTA–dan, yang terpenting, itu juga harus dimuat terlebih dahulu!

Dalam contoh ini, itu hanya teks. Menggabungkannya dengan alat fungsional akan lebih baik daripada hanya teks/gambar LCP.

LCP hanya mempertimbangkan jenis sumber daya tertentu. Alasan utamanya adalah untuk menjaga agar pengukuran LCP tetap sederhana pada awalnya. Di bawah ini adalah "Script Instance" yang dicap untuk membuat daftar entri LCP. Mempelajari potongan kode ini akan mengajari Anda apa dan bagaimana Google Developers memperhatikan saat memuat halaman.

[Terbuka=Jendela]
antarmuka LargestContentfulPaint : PerformanceEntry {
atribut readonly DOMHighResTimeStamp renderTime;
atribut readonly DOMHighResTimeStamp loadTime;
atribut readonly ukuran panjang yang tidak ditandatangani;
atribut readonly id DOMString;
atribut readonly url DOMString;
Elemen atribut readonly? elemen;
[Default] objek keJSON();
};

Apa yang Anda lihat dalam daftar ini adalah skala yang diperlukan untuk perbandingan item kandidat yang masuk ke daftar entri LCP. Di bawah ini, saya akan menunjukkan metodologi untuk memilih kandidat LCP ("teks badan besar" dan "gambar besar").

Memahami prinsip dan proses untuk mendefinisikan LCP Anda

Prinsip-prinsip untuk menentukan LCP sangat penting:

  • Saat halaman dimuat, LCP dapat berubah dalam hitungan detik. Terkadang, bahkan jika komponen halaman tetap cukup lama sebagai LCP di layar, bahkan elemen halaman yang lebih besar yang dimuat di belakang tidak mengubah status sebelumnya.
  • Terkadang, elemen paruh atas (di bagian penting halaman web) dipilih sebagai LCP, bukan item yang lebih besar di paruh bawah (bagian tidak penting dari halaman web).
  • Elemen<div> yang lebih besar tidak dapat dipilih sebagai LCP jika komponennya terbelah di layar. Sebagai gantinya, elemen <div> blok akan dipilih sebagai LCP. Di bawah ini Anda akan melihat contoh yang menggambarkan hal ini.

Dalam contoh ini, kita melihat bahwa komponen terbesar adalah <div> yang mencakup empat gambar berbeda. Namun, tidak satu pun dari gambar individual ini yang lebih besar dari Logo Oncrawl dan teks yang disertakan dengannya dalam elemen <div> yang sama. Karena keduanya berada di bagian penting halaman web, elemen kedua adalah LCP.

Saat menghitung waktu LCP dan serta menentukan sudut pandang Google Developers, Anda juga harus fokus pada desain "peracikan". Jika elemen <div> tidak memiliki perasaan/tampilan desain gabungan dan terpadu, itu mungkin tidak akan dipilih sebagai LCP.

Meskipun dipilih, Google Chrome mungkin berpikir bahwa ini bukan LCP yang sehat dengan kode baru yang akan ditambahkan ke API LCP di masa mendatang. Untuk alasan yang berkaitan dengan UX dan untuk pemahaman yang lebih baik tentang kecepatan halaman, Google akan terus meningkatkan persepsinya sendiri menggunakan metode ini.

Apa itu Pergeseran Tata Letak dan Pergeseran Tata Letak Kumulatif?

Pergeseran tata letak adalah gagasan bahwa, saat halaman sedang diunduh oleh browser, elemen halaman mengubah posisinya dengan cara yang dapat mengganggu pengguna.

Saat halaman sedang diunduh, setiap bagian halaman akan terlihat satu per satu dalam urutan tertentu. Ini normal. Tetapi jika bagian-bagian ini mengubah posisi awalnya karena bagian-bagian berikutnya, ini adalah pergeseran tata letak.

Pergeseran Tata Letak Kumulatif (CLS) adalah jumlah dari semua peristiwa pergeseran tata letak.

Pengalaman Pengguna Chrome juga memiliki bagian tentang skor CLS. Tapi ini bukan hanya tentang UX. Pergeseran tata letak dapat berbahaya bagi pasien epilepsi fotosensitif. Sebagai “perusahaan kesehatan”, Google juga harus memberikan nilai bagi kesehatan pengguna; mereka mencoba mengurangi "tekanan web" di mana pun mereka bisa.

“Saya yakin Google sudah menjadi perusahaan kesehatan. Sudah menjadi DNA perusahaan sejak awal”
David Feinberg – Kepala Kesehatan Google

Berikut adalah contoh pergeseran tata letak yang sederhana dan menentukan dari salah satu situs yang sama yang telah kita lihat sebelumnya dalam seri ini. Ini adalah situs web berita utama dari Turki dan ini adalah halaman utama mereka…

Anda dapat membaca lebih lanjut tentang Pergeseran Tata Letak, Kedipan, Flash dan Variasi Warna yang berbahaya bagi kesehatan dari Pengembang Moz.

Bagaimana menemukan pergeseran tata letak kumulatif di situs web Anda

Untuk melihat pergeseran tata letak bagian halaman web Anda, Anda dapat menggunakan Google Chrome DevTools atau Anda dapat menggunakan Layout Instability API untuk menskalakan proses untuk semua halaman web Anda.

Pergeseran Tata Letak Kumulatif, atau jumlah semua peristiwa pergeseran tata letak, merupakan kriteria penting baik kecepatan halaman maupun UX pada tahun 2020 dan seterusnya. Jika bagian paruh atas halaman web bergeser saat memuat, Anda juga perlu mengoptimalkannya saat mengoptimalkan kecepatan.

Di bawah ini, Anda akan menemukan Rumus Pergeseran Tata Letak, juga contoh Kode API Ketidakstabilan Tata Letak untuk memberi Anda perspektif tentang kontribusi CLS dan metode untuk menghitung Skor Pergeseran Tata Letak Anda.

Rumus Pergeseran Tata Letak di bawah ini:
skor pergeseran tata letak = fraksi dampak * fraksi jarak

Skor Pergeseran Tata Letak dihitung dengan dua istilah baru yang bermanfaat, Pecahan Dampak dan Pecahan Jarak:

  • Fraksi dampak adalah persentase layar yang terpengaruh oleh pergeseran. Anda tahu bahwa CLS Anda akan tinggi jika elemen halaman, yang mencakup 50% area pandang di perangkat seluler, membuat pergeseran tata letak, karena memindahkannya akan berdampak, minimal, lebih dari 50% layar.
  • Fraksi jarak diukur dengan seberapa jauh elemen yang bergeser menjauh dari titik aslinya ke arah di mana ia bergeser selama pergeseran. Jika jarak antara posisi pertama dan terakhir berlebihan, fraksi Jarak juga akan berlebihan.

Ini akan memudahkan Anda untuk memperkirakan Skor CLS Anda dan memberi tahu tim TI dan UX Anda.

Di atas, Anda dapat melihat cuplikan Kode API CLS dan di bawah, GIF yang menunjukkan cara menghitung Pergeseran Tata Letak Kumulatif.

Di situs berita Turki yang sama yang telah kami lihat, CLS kami adalah 0,47. Mengingat itu dihitung antara 0 dan 1, ini adalah skor yang sangat buruk.
Anda dapat menghitung CLS Anda dengan Sistem Metrik Kustom Lanjutan Webpagetest.org. Anda harus menggunakan kode CLS API hingga "Mengirim Bagian Info". Setelah itu Anda perlu mengubah URL Anda dari root/results/ menjadi root/custom_metrics.php?test={Same Result Number}.

Berapa Waktu Pemblokiran Total?

Anda dapat mengunduh bagian paruh atas halaman web Anda dengan cepat tanpa perubahan tata letak, tetapi jika tidak menanggapi input pengguna, Google Algorithms mengklaim Anda memiliki masalah UX dan kecepatan halaman lain. Total Blocking Time adalah waktu yang hilang pada tahap ini.

Seperti Pergeseran Tata Letak Kumulatif dan Cat Konten Terbesar, Waktu Pemblokiran Total adalah kecepatan halaman dan metrik UX baru untuk tahun 2020 dan seterusnya.

Yang diperhitungkan dalam Total Blocking Time (TBT) adalah setiap peristiwa pemuatan antara First Paint (FP) dan Time to Interactive (TTI) yang memblokir utas utama browser (atau perangkat) selama lebih dari 50 milidetik dan mencegah pengguna dari melakukan proses apapun.

Cara menghitung dan mengoptimalkan TBT

Anda dapat menghitung Total Blocking Time (TBT) Anda dengan Long Tasks API.

Untuk mengoptimalkan skor TBT Anda, Anda juga harus fokus pada urutan dan preferensi untuk memuat sumber daya, bersama dengan jumlah dan ukuran permintaan.

Ini dari situs yang sama dari sebelumnya. Seperti yang mungkin Anda perhatikan, utas utama benar-benar sibuk selama lebih dari 5 detik tanpa henti. LCP mereka masih dimuat setelah hampir 2,5 detik… Yang penting di sini untuk diperhatikan adalah bahwa permintaan tugas terlama mereka lebih dari 350 MS. Ini berarti dianggap memblokir utas utama selama lebih dari 300 MS.

Juga, semua waktu yang diblokir dihitung sebagai bagian dari Total Waktu Pemblokiran. Ini tidak hanya mencakup elemen di bagian paruh atas tetapi berlaku untuk semua komponen halaman web. Ini menciptakan riwayat browser yang berbahaya untuk situs web Anda.

Jika TBT Anda lebih dari 300 Milidetik, ini mungkin akan sangat merugikan retensi pengguna dan tingkat konversi Anda.

Anda dapat melihat contoh perhitungan untuk TBT untuk utas utama di atas. Dalam contoh ini, ada empat permintaan. Google Chrome dapat membuat 6 permintaan dari server yang sama sekaligus. Hanya 50 MS pertama yang akan berjalan dengan lancar; setelah itu akan mulai melakukan banyak tugas secara bersamaan, sebanyak yang dimungkinkan oleh daya CPU/Jaringan. Ingat, seorang manusia dapat melihat satu frame setiap 16 MS. Google peduli setiap milidetik bagi pengguna.

Dalam contoh ini, Total Waktu Pemblokiran adalah 1 detik dan 100 MS.

Langkah selanjutnya dalam pengoptimalan kecepatan halaman

Dalam seri ini sejauh ini, kita sekarang telah memeriksa bagaimana browser membuat halaman web, yang memungkinkan kita untuk melihat dalam artikel ini bagaimana metrik baru yang terkait dengan bagaimana pemuatan halaman di browser dapat memengaruhi kecepatan halaman. Kami telah melihat beberapa metrik baru teratas, dan cara mengukur dan mengoptimalkannya.

Pada artikel berikutnya dalam seri ini tentang kecepatan halaman di situs web saat ini, kita akan membahas topik yang telah menjadi subjek utama dalam SEO dan pengembangan web: mengoptimalkan aset JavaScript untuk meningkatkan kecepatan halaman dan rendering halaman.

Mulai Uji coba Gratis Anda