Panduan Mendalam Untuk Mengukur Vital Web Inti

Google telah mengumumkan bahwa mulai 1 Mei, mereka akan mulai mempertimbangkan "Pengalaman Halaman" sebagai bagian dari peringkat Penelusuran , yang diukur dengan seperangkat metrik yang disebut Core Web Vitals. Tanggal itu semakin dekat dan saya yakin banyak dari kita yang diminta untuk memastikan bahwa kita melewati Core Web Vitals, tetapi bagaimana Anda bisa tahu jika Anda lolos?

Menjawab pertanyaan itu sebenarnya lebih sulit daripada yang Anda perkirakan dan sementara banyak alat sekarang mengekspos Vital Web Inti ini, ada banyak konsep dan seluk-beluk penting untuk dipahami. bahkan alat Google seperti PageSpeed Insights dan laporan Core Web Vitals di Google Search Console tampaknya memberikan informasi yang membingungkan.

Mengapa demikian dan bagaimana Anda bisa yakin bahwa perbaikan Anda benar-benar berhasil? Bagaimana Anda bisa mendapatkan gambaran akurat tentang Core Web Vitals untuk situs Anda? Dalam posting ini, saya akan mencoba menjelaskan sedikit lebih banyak tentang apa yang terjadi di sini dan menjelaskan beberapa nuansa dan kesalahpahaman dari alat-alat ini.

Apa Itu Inti Web Vital?

Core Web Vitals adalah sekumpulan tiga metrik yang dirancang untuk mengukur pengalaman "inti" apakah situs web terasa cepat atau lambat bagi pengguna, dan memberikan pengalaman yang baik.

Halaman web harus berada dalam ukuran hijau untuk ketiga Core Web Vitals untuk mendapatkan keuntungan dari peningkatan peringkat apa pun.

1.Largest Contentful Paint (LCP)

Metrik ini mungkin yang paling mudah dipahami – ini mengukur seberapa cepat Anda mendapatkan item terbesar yang digambar di laman – yang mungkin merupakan bagian konten yang diminati pengguna. Ini bisa berupa gambar spanduk, sepotong teks, atau Masa bodo. Fakta bahwa ini adalah elemen konten terbesar di halaman adalah indikator yang baik bahwa ini adalah bagian yang paling penting. LCP relatif baru, dan kami biasa mengukur First Contentful Paint (FCP) yang serupa, tetapi LCP telah dilihat sebagai metrik yang lebih baik ketika konten yang kemungkinan ingin dilihat pengunjung digambar.

LCP seharusnya mengukur kinerja pemuatan dan merupakan proksi yang baik untuk semua metrik lama yang kami gunakan dalam komunitas kinerja yang biasa digunakan (yaitu Time to First Byte (TTFB), DOM Content Loaded, Start Render, Speed Index) – tetapi dari pengalaman pengguna. Ini tidak mencakup semua informasi yang dicakup oleh metrik tersebut, tetapi merupakan metrik tunggal yang lebih sederhana yang mencoba memberikan indikasi yang baik tentang pemuatan halaman.

2. Penundaan Input Pertama (FID)

Metrik kedua ini mengukur waktu antara saat pengguna berinteraksi dengan halaman, misalnya mengklik link atau tombol, dan saat browser memproses klik tersebut. Itu ada untuk mengukur interaktivitas halaman . Jika semua konten dimuat, tetapi halaman tidak responsif, ini merupakan pengalaman yang membuat pengguna frustrasi.

Poin pentingnya adalah bahwa metrik ini tidak dapat disimulasikan karena sangat bergantung pada kapan pengguna benar-benar mengklik atau berinteraksi dengan halaman dan kemudian berapa lama waktu yang dibutuhkan untuk ditindaklanjuti. Total Blocking Time (TBT) adalah proxy yang baik untuk FID saat menggunakan alat pengujian tanpa interaksi pengguna langsung, tetapi juga mengawasi Time to Interactive (TTI) saat melihat FID.

3. Pergeseran Tata Letak Kumulatif (CLS)

Metrik yang sangat menarik, tidak seperti metrik lain yang muncul sebelumnya karena sejumlah alasan. Ini dirancang untuk mengukur stabilitas visual halaman – pada dasarnya seberapa banyak halaman itu melompat saat konten baru masuk ke tempatnya. Saya yakin kita semua telah mengklik sebuah artikel, mulai membaca, dan kemudian teksnya melompat-lompat saat gambar, iklan, dan konten lainnya dimuat.

Ini cukup menggelegar dan mengganggu bagi pengguna, jadi sebaiknya meminimalkannya. Lebih buruk lagi adalah ketika tombol yang akan Anda klik tiba-tiba bergerak dan Anda mengklik tombol lain sebagai gantinya! CLS mencoba memperhitungkan pergeseran tata letak ini.

Lab versus RUM

Salah satu poin penting yang perlu dipahami tentang Core Web Vitals adalah bahwa mereka didasarkan pada metrik lapangan atau Metrik Pengguna Nyata (RUM). Google menggunakan data anonim dari pengguna Chrome untuk metrik masukan dan membuatnya tersedia di Laporan Pengalaman Pengguna Chrome (CrUX) . Data itulah yang mereka gunakan untuk mengukur ketiga metrik ini untuk peringkat pencarian. Data CrUX tersedia di sejumlah alat, termasuk di Google Search Console untuk situs Anda.

Fakta bahwa data RUM digunakan, merupakan perbedaan penting karena beberapa metrik ini (kecuali FID) tersedia di alat kinerja web sintetis atau "berbasis lab" seperti Lighthouse yang telah menjadi pokok pemantauan kinerja web bagi banyak orang di masa lalu . Alat ini menjalankan pemuatan halaman pada jaringan dan perangkat yang disimulasikan, lalu memberi tahu Anda apa metriknya untuk pengujian tersebut.

Jadi, jika Anda menjalankan Lighthouse di mesin pengembang bertenaga tinggi dan mendapatkan skor yang bagus, itu mungkin tidak mencerminkan apa yang dialami pengguna di dunia nyata, jadi apa yang akan digunakan Google untuk mengukur pengalaman pengguna situs web Anda.

LCP akan sangat bergantung pada kondisi jaringan dan kekuatan pemrosesan perangkat yang digunakan (dan banyak pengguna Anda kemungkinan besar menggunakan banyak perangkat dengan daya lebih rendah daripada yang Anda sadari! ). Namun, hal yang berlawanan adalah, setidaknya untuk banyak situs Barat, ponsel kita mungkin tidak cukup bertenaga rendah seperti yang disarankan oleh alat seperti Lighthouse dalam mode seluler, karena ini cukup dibatasi. Jadi Anda mungkin melihat data lapangan Anda di seluler lebih baik daripada menguji dengan saran ini (ada beberapa diskusi tentang mengubah pengaturan seluler Lighthouse ).

Demikian pula, FID sering kali bergantung pada kecepatan prosesor dan bagaimana perangkat dapat menangani semua konten yang kami kirim ke sana – baik itu gambar untuk diproses, elemen hingga tata letak pada halaman dan, tentu saja, semua JavaScript yang ingin kami kirimkan. ke browser untuk melakukan churn.

CLS, secara teori, lebih mudah diukur dalam alat karena tidak terlalu rentan terhadap variasi jaringan dan perangkat keras, jadi Anda akan mengira CLS tidak tunduk pada perbedaan antara LAB dan RUM – kecuali untuk beberapa pertimbangan penting yang mungkin awalnya tidak terlihat jelas. :

  • Ini diukur sepanjang umur halaman dan tidak hanya untuk pemuatan halaman seperti yang dilakukan alat biasa, yang akan kita bahas lebih lanjut nanti di artikel ini. Hal ini menyebabkan banyak kebingungan saat pemuatan halaman yang disimulasikan lab memiliki CLS yang sangat rendah, tetapi skor CLS bidang jauh lebih tinggi, karena CLS yang disebabkan oleh pengguliran atau perubahan lain setelah pemuatan awal yang biasanya diukur oleh alat pengujian.
  • Ini dapat bergantung pada ukuran jendela browser – biasanya alat seperti PageSpeed Insights, mengukur seluler dan desktop, tetapi ponsel yang berbeda memiliki ukuran layar yang berbeda, dan desktop sering kali jauh lebih besar daripada kumpulan alat ini ( Uji Halaman Web baru-baru ini meningkatkan ukuran layar defaultnya untuk mencoba mencerminkan penggunaan dengan lebih akurat).
  • Pengguna yang berbeda melihat hal yang berbeda di halaman web . Spanduk cookie, konten yang disesuaikan seperti promosi, Adblocker, pengujian A / B untuk menyebutkan beberapa item yang mungkin berbeda, semua memengaruhi konten apa yang diambil dan apa yang mungkin dialami oleh pengguna CLS.
  • Ini masih berkembang dan tim Chrome telah sibuk memperbaiki shift "tak terlihat" dan sejenisnya yang seharusnya tidak diperhitungkan dalam CLS. Perubahan yang lebih besar tentang bagaimana CLS sebenarnya diukur juga sedang berlangsung. Ini berarti Anda dapat melihat nilai CLS yang berbeda bergantung pada versi Chrome mana yang sedang dijalankan.

Menggunakan nama yang sama untuk metrik di alat pengujian berbasis lab, jika metrik tersebut mungkin bukan merupakan cerminan yang akurat dari versi kehidupan nyata akan membingungkan dan beberapa menyarankan kami harus mengganti nama beberapa atau semua metrik ini di Lighthouse untuk membedakan metrik yang disimulasikan ini dari metrik RUM dunia nyata yang memberdayakan peringkat Google.

Metrik Performa Web Sebelumnya

Hal lain yang membingungkan adalah bahwa metrik ini baru dan berbeda dari metrik yang biasanya kami gunakan di masa lalu untuk mengukur kinerja web dan yang ditampilkan oleh beberapa alat tersebut, seperti PageSpeed Insights – alat audit online gratis. Cukup masukkan URL yang ingin Anda audit dan klik Analisis, dan beberapa detik kemudian Anda akan disajikan dengan dua tab (satu untuk seluler dan satu untuk desktop) yang berisi banyak informasi:

Di bagian atas adalah skor performa Lighthouse yang besar dari 100. Hal ini telah lama dikenal dalam komunitas performa web dan sering kali dikutip sebagai metrik performa utama yang bertujuan dan meringkas kerumitan banyak metrik menjadi sederhana , nomor yang mudah dipahami. Itu memiliki beberapa tumpang tindih dengan tujuan Core Web Vitals, tetapi ini bukan ringkasan dari tiga Core Web Vitals (bahkan versi berbasis lab), tetapi dari berbagai metrik yang lebih luas.

Saat ini, enam metrik membentuk skor kinerja Lighthouse – termasuk beberapa Vital Web Inti dan beberapa metrik lainnya:

  • First Contentful Paint (FCP)
  • SpeedIndex (SI)
  • Cat Konten Terbesar (LCP)
  • Time to Interactive (TTI)
  • Total Waktu Pemblokiran (TBT)
  • Pergeseran Tata Letak Kumulatif (CLS)

Untuk menambah kerumitan, masing-masing dari keenam ini memiliki bobot yang berbeda dalam skor Kinerja dan CLS, meskipun menjadi salah satu Vital Web Inti, saat ini hanya 5% dari skor Kinerja Lighthouse (Saya akan bertaruh uang untuk peningkatan ini segera setelah Iterasi CLS berikutnya dirilis). Semua ini berarti Anda bisa mendapatkan skor kinerja Lighthouse berwarna hijau yang sangat tinggi dan menganggap situs web Anda baik-baik saja, namun masih gagal melewati ambang Core Web Vitals. Oleh karena itu, Anda mungkin perlu memfokuskan kembali upaya Anda sekarang untuk melihat ketiga metrik inti ini.

Bergerak melewati skor hijau besar di tangkapan layar itu, kami pindah ke data lapangan dan kami mendapatkan titik kebingungan lainnya: First Contentful Paint ditampilkan di data bidang ini bersama dengan tiga Core Web Vitals lainnya, meskipun bukan bagian dari Core Web Vital dan, seperti dalam contoh ini, saya sering menemukannya ditandai sebagai peringatan meskipun yang lainnya lolos. (Mungkin ambang batas untuk ini perlu sedikit penyesuaian?) Apakah FCP nyaris gagal menjadi Core Web Vital, atau mungkin terlihat lebih baik jika diimbangi dengan empat metrik? Bagian data lapangan ini penting dan kita akan kembali lagi nanti.

Jika tidak ada data bidang yang tersedia untuk URL tertentu yang sedang diuji, maka data asal untuk seluruh domain akan ditampilkan (ini disembunyikan secara default ketika data bidang tersedia untuk URL tertentu seperti yang ditunjukkan di atas).

Setelah data lapangan, kami mendapatkan data lab, dan kami melihat enam metrik yang menyusun skor kinerja di bagian atas. Jika Anda mengklik sakelar di kanan atas, Anda bahkan mendapatkan sedikit lebih banyak deskripsi dari metrik tersebut:

Seperti yang Anda lihat, versi lab dari LCP dan CLS disertakan di sini dan, karena merupakan bagian dari Core Web Vitals, mereka mendapatkan label biru untuk menandainya sebagai sangat penting. PageSpeed Insights juga menyertakan tautan kalkulator yang berguna untuk melihat pengaruh skor ini pada skor total di atas, dan memungkinkan Anda menyesuaikannya untuk melihat apa yang akan meningkatkan setiap metrik terhadap skor Anda. Tapi, seperti yang saya katakan, skor kinerja web kemungkinan akan turun sedikit sementara Core Web Vitals menikmati semua perhatian saat ini.

Lighthouse juga melakukan hampir 50 pemeriksaan lainnya pada Peluang dan Diagnostik ekstra. Ini tidak secara langsung memengaruhi skor, atau Core Web Vitals, tetapi dapat digunakan oleh pengembang web untuk meningkatkan kinerja situs mereka . Ini juga muncul di PageSpeed Insights di bawah semua metrik, jadi hanya gambar di atas. Anggap ini sebagai saran tentang cara meningkatkan kinerja, daripada masalah khusus yang perlu ditangani.

Diagnostik akan menunjukkan kepada Anda elemen LCP dan perubahan yang telah berkontribusi pada skor CLS Anda yang merupakan bagian informasi yang sangat berguna saat mengoptimalkan Core Web Vitals Anda!

Jadi, sementara di masa lalu pendukung kinerja web mungkin sangat berkonsentrasi pada skor dan audit Lighthouse, saya melihat ini memusatkan perhatian pada tiga metrik Inti Web Vital – setidaknya untuk periode berikutnya saat kita memusatkan perhatian pada mereka. Metrik Lighthouse lainnya, dan skor keseluruhan, masih berguna untuk mengoptimalkan performa situs Anda, tetapi Core Web Vitals saat ini menggunakan sebagian besar tinta pada performa web baru dan postingan blog SEO.

Melihat Situs Web Inti Untuk Situs Anda

Cara termudah untuk melihat sekilas di Core Web Vitals untuk masing-masing URL, dan untuk keseluruhan asal, adalah dengan memasukkan URL ke PageSpeed Insights seperti yang dibahas di atas. Namun, untuk melihat bagaimana Google melihat Core Web Vitals untuk seluruh situs Anda, dapatkan akses ke Google Search Console . Ini adalah produk gratis yang dibuat oleh Google yang memungkinkan Anda memahami bagaimana Google "melihat" seluruh situs Anda, termasuk Core Web Vitals untuk situs Anda (meskipun ada beberapa – harus kami katakan – " frustrasi " dengan seberapa sering data diperbarui di sini ).

Google Search Console telah lama digunakan oleh tim SEO, tetapi dengan masukan bahwa pengembang situs perlu menangani Core Web Vitals, tim pengembang juga harus mendapatkan akses ke alat ini jika belum melakukannya. Untuk mendapatkan akses, Anda memerlukan akun Google, dan kemudian memverifikasi kepemilikan situs Anda melalui berbagai cara (menempatkan file di server web Anda, menambahkan data DNS … dll.).

Laporan Core Web Vitals di Google Search Console memberikan ringkasan tentang bagaimana situs Anda memenuhi Core Web Vitals selama 90 hari terakhir:

Idealnya, agar dianggap lulus Core Web Vitals sepenuhnya, Anda ingin semua halaman Anda berwarna hijau , tanpa kuning atau merah. Meskipun amber adalah indikator bagus yang akan segera Anda lewati, sebenarnya hanya warna hijau yang dihitung, jadi jangan puas dengan yang terbaik kedua. Apakah Anda ingin semua laman Anda lewat atau hanya yang utama terserah Anda, tetapi sering kali akan ada masalah serupa di banyak laman, dan memperbaikinya untuk situs dapat membantu meningkatkan jumlah URL yang tidak lolos ke lebih mudah dikelola. tingkat di mana Anda dapat membuat keputusan itu.

Awalnya, Google hanya akan menerapkan peringkat Core Web Vitals ke seluler , tetapi itu pasti hanya masalah waktu sebelum itu diluncurkan ke desktop juga , jadi jangan abaikan desktop saat Anda berada di sana untuk meninjau dan memperbaiki halaman Anda.

Mengklik salah satu laporan akan memberi Anda detail lebih lanjut tentang web vitals mana yang gagal dipenuhi, lalu pengambilan sampel URL yang terpengaruh. Google Search Console mengelompokkan URL ke dalam beberapa keranjang untuk, secara teori, memungkinkan Anda menangani halaman serupa bersama-sama. Anda kemudian dapat mengeklik URL untuk menjalankan Wawasan PageSpeed guna menjalankan audit kinerja cepat pada URL tertentu (termasuk menampilkan data bidang Vital Web Inti untuk laman itu jika tersedia). Anda kemudian memperbaiki masalah yang disorot, menjalankan kembali PageSpeed Insights untuk mengonfirmasi bahwa metrik lab sekarang sudah benar, lalu melanjutkan ke halaman berikutnya.

Namun, begitu Anda mulai melihat laporan Core Web Vitals (secara obsesif bagi sebagian dari kita!), Anda mungkin merasa frustrasi karena laporan ini tampaknya tidak diperbarui untuk mencerminkan kerja keras Anda. Tampaknya diperbarui setiap hari saat grafik bergerak, namun sering kali hampir tidak berubah bahkan setelah Anda merilis perbaikan – mengapa?

Demikian pula, data bidang PageSpeed Insights dengan keras kepala masih menunjukkan bahwa URL dan situs gagal. Lalu bagaimana ceritanya di sini?

Laporan Pengalaman Pengguna Chrome (CrUX)

Alasan mengapa Web Vitals lambat diperbarui, adalah karena data bidang didasarkan pada data 28 hari terakhir di Laporan Pengalaman Pengguna Chrome (CrUX) , dan di dalamnya, hanya persentil ke-75 dari data tersebut. Menggunakan data selama 28 hari, dan persentil ke-75 adalah hal yang baik, karena mereka menghilangkan variasi dan ekstrim untuk memberikan refleksi yang lebih akurat dari kinerja situs Anda tanpa menyebabkan banyak gangguan yang sulit untuk ditafsirkan.

Metrik kinerja sangat rentan terhadap jaringan dan perangkat, jadi kami perlu menghaluskan gangguan ini untuk mendapatkan kisah nyata tentang kinerja situs web Anda bagi sebagian besar pengguna. Namun, sisi kebalikannya adalah mereka sangat lambat untuk memperbarui, membuat umpan balik yang sangat lambat dari memperbaiki masalah, sampai Anda melihat hasil koreksi itu tercermin di sana.

Persentil ke-75 (atau p75) khususnya menarik dan penundaan yang ditimbulkannya, karena menurut saya itu tidak dipahami dengan baik. Ini melihat metrik yang diperoleh 75% pengunjung Anda untuk tampilan halaman selama 28 hari tersebut untuk masing-masing Core Web Vitals.

Oleh karena itu, skor Core Web Vital tertinggi dari 75% pengguna kami (atau sebaliknya skor Core Web Vital terendah yang dimiliki oleh 75% pengunjung Anda kurang dari). Jadi ini bukan rata-rata dari 75% pengguna ini, tetapi nilai terburuk dari kumpulan pengguna tersebut.

Hal ini menyebabkan penundaan dalam pelaporan yang tidak dapat dilakukan oleh rata-rata penggiliran berbasis non-persentil. Kita harus sedikit berhitung di sini (saya akan mencoba membuatnya seminimal mungkin), tetapi katakanlah, demi kesederhanaan bahwa setiap orang mendapat LCP 10 detik untuk bulan lalu, dan Anda memperbaikinya jadi sekarang hanya membutuhkan waktu 1 detik, dan katakanlah setiap hari Anda memiliki jumlah pengunjung yang sama persis setiap hari dan mereka semua mencetak LCP ini.

Dalam skenario yang terlalu sederhana tersebut, Anda akan mendapatkan metrik berikut:

Hari LCP 28 hari Berarti 28 hari p75
Hari 0 10 10 10
Hari 1 1 9.68 10
Hari ke-2 1 9.36 10
Hari ke-3 1 9.04 10
Hari ke 20 1 3.57 10
Hari 21 1 3.25 10
Hari 22 1 2.93 1
Hari 23 1 2.61 1
Hari 27 1 1.32 1
Hari 28 1 1 1

Jadi Anda dapat melihat bahwa Anda tidak melihat peningkatan drastis pada skor CrUX hingga hari ke-22 ketika tiba-tiba skor tersebut melompat ke nilai baru yang lebih rendah (setelah kita melewati 75% dari rata-rata 28 hari – bukan kebetulan!). Hingga saat itu, lebih dari 25% pengguna Anda didasarkan pada data yang dikumpulkan sebelum perubahan, jadi kami mendapatkan nilai lama 10, dan karenanya nilai p75 Anda tertahan di 10.

Oleh karena itu, sepertinya Anda tidak membuat kemajuan sama sekali untuk waktu yang lama, sedangkan rata-rata rata-rata (jika digunakan) akan menunjukkan tanda turun bertahap yang dimulai dengan segera sehingga kemajuan benar-benar dapat dilihat. Sisi positifnya, selama beberapa hari terakhir, mean sebenarnya lebih tinggi dari nilai p75 karena p75, menurut definisi, menyaring titik ekstrem sepenuhnya.

Contoh pada tabel di atas, meskipun disederhanakan secara besar-besaran, menjelaskan satu alasan mengapa banyak orang mungkin melihat grafik Web Vitals seperti di bawah ini, di mana suatu hari semua halaman Anda melewati ambang dan kemudian bagus ( woohoo! ):

Ini mungkin mengejutkan bagi mereka yang mengharapkan perubahan yang lebih bertahap (dan seketika) saat Anda mengerjakan masalah halaman, dan karena beberapa halaman dikunjungi lebih sering daripada yang lain. Pada catatan terkait, juga biasa melihat grafik Search Console mengalami periode kuning , bergantung pada perbaikan Anda dan bagaimana pengaruhnya terhadap ambang batas, sebelum mencapai warna hijau yang manis dan manis:

Dave Smart , menjalankan eksperimen menarik Melacak Perubahan di Data Vital Web Inti Laporan Search Console , tempat ia ingin melihat seberapa cepat waktu yang dibutuhkan untuk memperbarui grafik. Dia tidak memperhitungkan bagian persentil ke-75 dari CrUX (yang membuat kurangnya pergerakan di beberapa grafiknya lebih masuk akal), tetapi masih merupakan eksperimen kehidupan nyata yang menarik tentang bagaimana grafik ini diperbarui dan layak dibaca!

Pengalaman saya sendiri adalah bahwa metodologi 28 hari p75 ini tidak sepenuhnya menjelaskan kelambatan dalam laporan Core Web Vitals, dan kami akan membahas beberapa alasan potensial lainnya sebentar lagi.

Jadi, apakah itu yang terbaik yang dapat Anda lakukan, lakukan perbaikan, lalu tunggu dengan sabar, mengetuk jari Anda, sampai CrUX menganggap perbaikan Anda layak dan memperbarui grafik di Search Console dan PageSpeed Insights? Dan jika ternyata perbaikan Anda tidak cukup baik, maka mulai lagi seluruh siklus? Pada hari ini umpan balik instan untuk memuaskan keinginan kita, dan umpan balik yang ketat bagi pengembang untuk meningkatkan produktivitas , itu tidak terlalu memuaskan sama sekali!

Nah, ada beberapa hal yang dapat Anda lakukan untuk sementara waktu untuk mencoba melihat apakah ada perbaikan yang akan mendapatkan dampak yang diinginkan.

Menggali Data Inti Lebih Detail

Karena inti dari pengukuran adalah data CrUX, mari kita selami lebih dalam lagi dan lihat apa lagi yang dapat dikatakannya kepada kita. Kembali ke PageSpeed Insights, kita dapat melihatnya menampilkan tidak hanya nilai p75 untuk situs, tetapi juga persentase tampilan halaman di setiap kotak hijau, kuning dan merah yang ditunjukkan pada bilah warna di bawah:

Tangkapan layar di atas menunjukkan bahwa CLS gagal dalam penilaian Core Web Vitals dengan nilai p75 0,11, yang berada di atas batas kelulusan 0,1. Namun, meskipun warna fontnya merah, ini sebenarnya adalah peringkat kuning (merah berarti di atas 0,25). Lebih menariknya adalah bahwa bilah hijau berada di 73% – setelah mencapai 75%, halaman ini melewati Core Web Vitals.

Meskipun Anda tidak dapat melihat nilai historis CrUX, Anda dapat memantaunya dari waktu ke waktu. Jika besok naik menjadi 74% maka kita sedang tren ke arah yang benar (tunduk pada fluktuasi!) Dan dapat berharap untuk mencapai keajaiban 75% segera. Untuk nilai yang lebih jauh, Anda dapat memeriksa secara berkala dan melihat peningkatan , lalu memproyeksikan kapan Anda mungkin mulai menunjukkan kelulusan.

CrUX juga tersedia sebagai API gratis untuk mendapatkan angka yang lebih tepat untuk persentase tersebut. Setelah Anda mendaftar untuk kunci API , Anda dapat memanggilnya dengan perintah curl seperti ini (mengganti API_KEY, formFactor, dan URL yang sesuai):

 curl -s --request POST ' https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{"formFactor":"PHONE","url":" https://www.example.com"}'

Dan Anda akan mendapatkan respons JSON, seperti ini:

 { "record": { "key": { "formFactor": "PHONE", "url": "https://www.example.com/" }, "metrics": { "cumulative_layout_shift": { "histogram": [ { "start": "0.00", "end": "0.10", "density": 0.99959769344240312 }, { "start": "0.10", "end": "0.25", "density": 0.00040230655759688886 }, { "start": "0.25" } ], "percentiles": { "p75": "0.00" } }, "first_contentful_paint": { ... } } }, "urlNormalizationDetails": { "originalUrl": "https://www.example.com", "normalizedUrl": "https://www.example.com/" } }

Kebetulan, jika di atas membuat Anda sedikit takut dan Anda ingin cara yang lebih cepat untuk melihat data ini hanya untuk satu URL, maka PageSpeed Insights juga mengembalikan presisi ini yang dapat Anda lihat dengan membuka DevTools lalu menjalankan pengujian PageSpeed Insights, dan menemukan panggilan XHR itu membuat:

Ada juga penjelajah CrUX API interaktif yang memungkinkan Anda membuat kueri sampel dari API CrUX. Padahal, untuk panggilan reguler API, mendapatkan kunci gratis dan menggunakan Curl atau beberapa alat API lainnya biasanya lebih mudah.

API juga dapat disebut dengan "asal", bukan URL, yang akan memberikan nilai ringkasan dari semua kunjungan halaman ke domain tersebut. PageSpeed Insights memaparkan informasi ini, yang dapat berguna jika URL Anda tidak memiliki informasi CrUX yang tersedia untuk itu, tetapi Google Search Console tidak. Google belum menyatakan (dan sepertinya tidak!) Secara tepat bagaimana Core Web Vitals akan memengaruhi peringkat . Akankah skor tingkat asal memengaruhi peringkat, atau hanya skor URL individu? Atau, seperti PageSpeed Insights, apakah Google akan kembali ke skor tingkat awal saat data URL individual tidak ada? Saat ini sulit untuk diketahui dan satu-satunya petunjuk sejauh ini adalah di FAQ:

T : Bagaimana cara menghitung skor untuk URL yang baru-baru ini diterbitkan, dan belum menghasilkan data selama 28 hari?

J : Mirip dengan cara Search Console melaporkan data pengalaman halaman, kami dapat menerapkan teknik seperti mengelompokkan halaman yang serupa dan menghitung skor berdasarkan agregasi tersebut. Ini berlaku untuk halaman yang menerima sedikit atau tanpa lalu lintas, jadi situs kecil tanpa data lapangan tidak perlu khawatir.

API CrUX dapat dipanggil secara terprogram, dan Rick Viscomi dari tim Google CrUX membuat monitor Google Spreadsheet yang memungkinkan Anda memeriksa URL atau asal secara massal, dan bahkan secara otomatis melacak data CrUX dari waktu ke waktu jika Anda ingin memantau dengan cermat sejumlah URL atau asal . Cukup klon sheet, masuk ke Tools → Script editor, dan kemudian masukkan properti skrip CRUX_API_KEY dengan kunci Anda (ini perlu dilakukan di editor lama), lalu jalankan skrip dan itu akan memanggil API CrUX untuk yang diberikan URL atau asal dan tambahkan baris ke bagian bawah lembar dengan data. Ini kemudian dapat dijalankan secara berkala atau dijadwalkan untuk dijalankan secara teratur.

Saya menggunakan ini untuk memeriksa semua URL situs dengan laporan Core Web Vitals yang diperbarui lambat di Google Search Console dan itu memastikan bahwa CrUX tidak memiliki data untuk banyak URL dan sebagian besar lainnya telah berlalu, jadi sekali lagi menunjukkan bahwa Laporan Google Search Console tertinggal – bahkan dari data CrUX yang seharusnya menjadi dasarnya. Saya tidak yakin apakah itu karena URL yang sebelumnya gagal tetapi sekarang tidak memiliki cukup lalu lintas untuk mendapatkan data CrUX yang diperbarui yang menunjukkan mereka lulus, atau jika itu karena hal lain, tetapi ini membuktikan kepada saya bahwa laporan ini pasti lambat .

Saya menduga sebagian besar dari itu disebabkan oleh URL tanpa data di CrUX dan Google Search melakukan yang terbaik untuk memproksi nilai untuk mereka. Jadi, laporan ini adalah tempat yang tepat untuk mulai mendapatkan ikhtisar situs Anda, dan satu untuk memantau ke depannya, tetapi bukan laporan yang bagus untuk mengatasi masalah yang Anda inginkan lebih banyak umpan balik segera.

Bagi mereka yang ingin mempelajari lebih lanjut CrUX, ada tabel bulanan data CrUX yang tersedia di BigQuery (hanya di tingkat asal, bukan untuk masing-masing URL) dan Rick juga telah mendokumentasikan cara membuat dasbor CrUX berdasarkan yang dapat menjadi cara yang baik untuk memantau kinerja situs web Anda secara keseluruhan selama berbulan-bulan.

Informasi Lain Tentang Data Crux

Jadi, dengan hal di atas, Anda harus memiliki pemahaman yang baik tentang dataset CrUX, mengapa beberapa alat yang menggunakannya tampak lambat dan tidak menentu untuk diperbarui, dan juga bagaimana menjelajahinya lebih jauh. Tetapi sebelum kita beralih ke alternatifnya, ada beberapa hal lagi yang perlu dipahami tentang CrUX untuk membantu Anda benar-benar memahami data yang ditampilkannya. Jadi, inilah kumpulan informasi berguna lainnya yang telah saya kumpulkan tentang CrUX sehubungan dengan Core Web Vitals.

CrUX hanya untuk Chrome . Semua pengguna iOS tersebut, dan browser lain (Desktop Safari, Firefox, Edge … dll.), Belum lagi browser yang lebih lama (Internet Explorer – cepat dan menghilang kan!) Tidak memiliki pengalaman pengguna yang tercermin dalam data CrUX dan seterusnya tampilan Google tentang Core Web Vitals.

Sekarang, penggunaan Chrome sangat tinggi (meskipun mungkin bukan untuk pengunjung situs Anda?), Dan dalam banyak kasus, masalah kinerja yang disorotnya juga akan memengaruhi peramban lain tersebut, tetapi itu adalah sesuatu yang harus diperhatikan. Dan memang terasa sedikit “menjijikkan” untuk sedikitnya, bahwa posisi monopoli Google dalam penelusuran, kini mendorong orang untuk mengoptimalkan browser mereka. Kami akan berbicara di bawah tentang solusi alternatif untuk tampilan terbatas ini.

Versi Chrome yang digunakan juga akan berdampak karena metrik ini (khususnya CLS) masih berkembang serta bug ditemukan dan diperbaiki . Ini menambah dimensi kompleksitas lain untuk memahami data. Adapeningkatan berkelanjutan pada CLS di versi terbaru Chrome , dengan pendefinisian ulang CLS berpotensi mendarat di Chrome 92. Sekali lagi, fakta bahwa data lapangan sedang digunakan berarti mungkin perlu beberapa waktu agar perubahan ini masuk ke pengguna, dan kemudian ke dalam data CrUX.

CrUX hanya untuk pengguna yang masuk ke Chrome , atau mengutip definisi sebenarnya:

“[CrUX] dikumpulkan dari pengguna yang telah memilih untuk menyinkronkan riwayat penjelajahan mereka, belum menyiapkan frasa sandi Sinkronisasi, dan mengaktifkan pelaporan statistik penggunaan.”

Laporan Pengalaman Pengguna Chrome , Pengembang Google

Jadi, jika Anda mencari informasi di situs yang sebagian besar dikunjungi dari jaringan perusahaan, yang setelannya dinonaktifkan oleh kebijakan TI pusat, Anda mungkin tidak akan melihat banyak data – terutama jika pengguna korporat yang malang itu masih dipaksa untuk menggunakan Internet. Penjelajah juga!

CrUX mencakup semua halaman, termasuk yang biasanya tidak muncul ke Google Penelusuran seperti "halaman noindexed / robboted / login akan disertakan" (meskipun ada ambang minimum untuk URL dan asal yang akan diekspos di CrUX). Sekarang kategori halaman tersebut kemungkinan besar tidak akan disertakan dalam hasil Google Penelusuran sehingga pengaruh peringkat terhadapnya mungkin tidak penting, tetapi mereka masih akan disertakan dalam CrUX. Namun, laporan Core Web Vitals di Google Search Console tampaknya hanya menampilkan URL yang diindeks , sehingga tidak akan muncul di sana.

Angka asal yang ditampilkan di PageSpeed Insights dan dalam data CrUX mentah akan menyertakan halaman non-indeks, non-publik, dan seperti yang saya sebutkan di atas, kami tidak yakin akan dampaknya. Situs yang saya kerjakan memiliki persentase besar pengunjung yang mengunjungi halaman login kami, dan sementara halaman publik sangat berperforma tinggi, halaman login tidak, dan itu sangat merusak skor Web Vitals asli.

API CrUX dapat digunakan untuk mendapatkan data dari URL yang masuk ini , tetapi alat seperti PageSpeed Insights tidak bisa (karena mereka menjalankan browser yang sebenarnya sehingga akan dialihkan ke halaman masuk). Setelah kami melihat data CrUX dan menyadari dampaknya, kami memperbaikinya, dan angka asal sudah mulai menurun, tetapi seperti biasa, butuh waktu untuk memberi makan.

Halaman yang tidak terindeks atau masuk juga sering kali merupakan "aplikasi", daripada kumpulan halaman individual sehingga mungkin menggunakan metodologi Aplikasi Halaman Tunggal dengan satu URL asli, tetapi banyak halaman berbeda di bawahnya. Hal ini dapat berdampak pada CLS khususnya karena itu diukur selama masa pakai halaman (meskipun mudah-mudahan perubahan CLS yang akan datang akan membantu dengan itu ).

Seperti yang disebutkan sebelumnya, laporan Core Web Vitals di Google Search Console, meskipun berdasarkan CrUX, jelas bukan datanya. Seperti yang saya nyatakan sebelumnya, saya menduga ini terutama disebabkan oleh Google Search Console yang mencoba memperkirakan Web Vitals untuk URL yang tidak memiliki data CrUX. Contoh URL dalam laporan ini juga rusak dengan data CrUX.

Saya telah melihat banyak contoh URL yang telah diperbaiki, dan data CrUX baik di PageSpeed Insights, atau secara langsung melalui API, akan menunjukkannya lewat Web Vitals, namun saat Anda mengklik garis merah di laporan Core Web Vitals dan dapatkan URL contoh, URL yang lulus ini akan dimasukkan seolah-olah gagal . Saya tidak yakin heuristik apa yang digunakan Google Search Console untuk pengelompokan ini, atau seberapa sering dan contoh URL diperbarui, tetapi menurut saya bisa dilakukan dengan memperbarui lebih sering!

CrUX didasarkan pada tampilan halaman . Itu berarti laman Anda yang paling populer akan memiliki pengaruh besar pada data CrUX asal Anda. Beberapa halaman akan keluar masuk CrUX setiap hari saat memenuhi ambang batas ini atau tidak, dan mungkin data asal ikut bermain untuk itu? Juga jika Anda memiliki kampanye besar untuk suatu periode dan banyak kunjungan, kemudian melakukan perbaikan tetapi memiliki lebih sedikit kunjungan, Anda akan melihat proporsi yang lebih besar dari data yang lebih lama dan lebih buruk.

Data CrUX dipisahkan menjadi Seluler , Desktop , dan Tablet – meskipun hanya Seluler dan Desktop yang terekspos di sebagian besar alat. CrUX API dan BigQuery memungkinkan Anda melihat data Tablet jika Anda benar-benar menginginkannya, tetapi sebaiknya Anda berkonsentrasi pada Seluler lalu Desktop. Selain itu, perhatikan dalam beberapa kasus (seperti CrUX API), ini ditandai sebagai TELEPON daripada SELULER untuk mencerminkannya berdasarkan faktor bentuk, bukan berdasarkan data yang berada di jaringan seluler.

Secara keseluruhan, banyak dari masalah ini adalah dampak dari pengumpulan data lapangan (RUM), tetapi semua nuansa ini bisa sangat berpengaruh saat Anda ditugaskan untuk "memperbaiki Vital Web Inti kami". Semakin Anda memahami bagaimana Core Web Vitals ini dikumpulkan dan diproses, semakin banyak data yang masuk akal, dan semakin banyak waktu yang dapat Anda habiskan untuk memperbaiki masalah yang sebenarnya, daripada bertanya-tanya mengapa tidak melaporkan apa yang menurut Anda seharusnya. menjadi.

Mendapatkan Umpan Balik Lebih Cepat

Oke, jadi sekarang Anda harus memiliki pegangan yang baik tentang bagaimana Core Web Vitals dikumpulkan dan diekspos melalui berbagai alat, tetapi itu masih menyisakan masalah tentang bagaimana kami bisa mendapatkan umpan balik yang lebih baik dan lebih cepat. Menunggu 21-28 hari untuk melihat dampak dalam data Crux – hanya untuk menyadari perbaikan Anda tidak cukup – terlalu lambat. Jadi, meskipun beberapa tips di atas dapat digunakan untuk melihat apakah CrUX sedang tren ke arah yang benar, itu masih belum ideal. Oleh karena itu, satu-satunya solusi adalah melihat melampaui CrUX untuk meniru apa yang dilakukannya, tetapi mengekspos data lebih cepat.

Ada sejumlah produk RUM komersial hebat di pasar yang mengukur kinerja pengguna situs Anda dan mengekspos data di dasbor atau API untuk memungkinkan Anda melakukan kueri data secara lebih mendalam dan pada frekuensi yang jauh lebih terperinci daripada yang diizinkan CrUX. Saya tidak akan memberikan nama produk apa pun di sini untuk menghindari tuduhan favoritisme, atau menyinggung siapa pun yang saya tinggalkan! Karena Core Web Vitals diekspos sebagai API browser (setidaknya oleh browser berbasis Chromium, browser lain seperti Safari dan Firefox belum mengekspos beberapa metrik yang lebih baru seperti LCP dan CLS ), mereka seharusnya, secara teori, merupakan data yang sama terkena CrUX dan oleh karena itu ke Google – dengan peringatan di atas yang sama dalam pikiran!

Bagi mereka yang tidak memiliki akses ke produk RUM ini, Google juga telah menyediakan pustaka JavaScript Web Vitals , yang memungkinkan Anda mendapatkan akses ke metrik ini dan melaporkannya kembali sesuai keinginan Anda. Ini dapat digunakan untuk mengirim data ini kembali ke Google Analytics dengan menjalankan script berikut di halaman web Anda:

 <script type="module"> import {getFCP, getLCP, getCLS, getTTFB, getFID} from ' https://unpkg.com/web-vitals?module' ; function sendWebVitals() { function sendWebVitalsGAEvents({name, delta, id, entries}) { if ("function" == typeof ga) {
ga('send', 'event', { eventCategory: 'Web Vitals', eventAction: name, // The id value will be unique to the current page load. When sending // multiple values from the same page (eg for CLS), Google Analytics can // compute a total by grouping on this ID (note: requires eventLabel to // be a dimension in your report). eventLabel: id, // Google Analytics metrics must be integers, so the value is rounded. // For CLS the value is first multiplied by 1000 for greater precision // (note: increase the multiplier for greater precision if needed). eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta), // Use a non-interaction event to avoid affecting bounce rate. nonInteraction: true, // Use sendBeacon() if the browser supports it. transport: 'beacon' }); } } // Register function to send Core Web Vitals and other metrics as they become available getFCP(sendWebVitalsGAEvents); getLCP(sendWebVitalsGAEvents); getCLS(sendWebVitalsGAEvents); getTTFB(sendWebVitalsGAEvents); getFID(sendWebVitalsGAEvents); } sendWebVitals(); </script>

Sekarang saya menyadari ironi menambahkan skrip lain untuk mengukur dampak situs web Anda, yang mungkin lambat sebagian karena terlalu banyak JavaScript, tetapi seperti yang Anda lihat di atas, skrip tersebut cukup kecil dan pustaka yang dimuatnya hanya lebih jauh. 1,7 kB terkompresi (4,0 kB tidak terkompresi). Selain itu, sebagai modul (yang akan diabaikan oleh browser lama yang tidak memahami web vitals), pelaksanaannya ditunda sehingga tidak terlalu memengaruhi situs Anda, dan data yang dapat dikumpulkannya dapat sangat berharga untuk membantu Anda menyelidiki situs Anda. Core Web Vital, dengan cara yang lebih real-time daripada yang dimungkinkan oleh data CrUX.

Skrip mendaftarkan fungsi untuk mengirim peristiwa Google Analytics ketika setiap metrik tersedia. Untuk FCP dan TTFB, hal ini terjadi segera setelah halaman dimuat, untuk FID setelah interaksi pertama dari pengguna, sedangkan untuk LCP dan CLS adalah saat halaman dinavigasi menjauh atau di-background dan LCP serta CLS yang sebenarnya sudah diketahui dengan pasti. Anda dapat menggunakan alat pengembang untuk melihat suar ini dikirim untuk halaman itu, sedangkan data CrUX terjadi di latar belakang tanpa terungkap di sini.

Manfaat meletakkan data ini di alat seperti Google Analytics adalah Anda dapat membagi data berdasarkan semua informasi lain yang Anda miliki di sana, termasuk faktor bentuk (desktop atau seluler), pengunjung baru atau kembali, konversi corong, versi Chrome , dan seterusnya. Dan, karena ini adalah data RUM, ini akan dipengaruhi oleh penggunaan nyata – pengguna pada perangkat yang lebih cepat atau lebih lambat akan melaporkan kembali nilai yang lebih cepat atau lebih lambat – daripada pengujian pengembang pada mesin spesifikasi tinggi mereka dan mengatakan itu baik-baik saja.

Pada saat yang sama, Anda perlu mengingat bahwa alasan data CrUX dikumpulkan selama 28 hari, dan hanya melihat persentil ke-75 adalah untuk menghilangkan varians. Memiliki akses ke data mentah memungkinkan Anda melihat data yang lebih terperinci , tetapi itu berarti Anda lebih rentan terhadap variasi yang ekstrim. Namun, selama Anda mengingatnya, menyimpan akses awal ke data bisa sangat berharga.

Phil Walton dari Google membuat dasbor Web-Vitals , yang dapat diarahkan ke akun Google Analytics Anda untuk mengunduh data ini, menghitung persentil ke-75 (sehingga membantu dengan variasi!) Dan kemudian menampilkan skor Core Web Vitals Anda, sebuah histogram informasi , data deret waktu, dan 5 halaman teratas yang dikunjungi dengan elemen teratas yang menyebabkan skor tersebut.

Dengan menggunakan dasbor ini, Anda dapat memfilter halaman individual (menggunakan filter ga:pagePath==/page/path/index.html ), dan melihat grafik yang sangat memuaskan seperti ini dalam satu hari setelah Anda merilis perbaikan, dan mengetahui perbaikan Anda telah berhasil dan Anda dapat melanjutkan ke tantangan berikutnya !:

Dengan sedikit lebih banyak JavaScript, Anda juga dapat memaparkan lebih banyak informasi (seperti apa itu elemen LCP, atau elemen mana yang menyebabkan paling banyak CLS) ke dalam Dimensi Kustom Google Analytics. Phil menulis Debug Web Vitals yang sangat baik di kolom posting tentang ini yang pada dasarnya menunjukkan bagaimana Anda dapat meningkatkan skrip di atas untuk mengirim informasi debug ini juga, seperti yang ditunjukkan dalam versi skrip ini .

Dimensi ini juga dapat dilaporkan di dasbor (menggunakan ga:dimension1 sebagai Debug dimension , dengan asumsi ini dikirim kembali ke Google Analytics, Dimensi Pelanggan 1 di skrip), untuk mendapatkan data seperti ini untuk melihat elemen LCP seperti yang terlihat oleh browser tersebut:

Seperti yang saya katakan sebelumnya, produk RUM komersial akan sering mengekspos data semacam ini juga (dan lebih banyak lagi!), Tetapi bagi mereka yang baru saja mencelupkan kaki mereka ke dalam air dan tidak siap untuk komitmen finansial dari produk tersebut, ini setidaknya menawarkan percobaan pertama. ke dalam metrik berbasis RUM dan betapa bermanfaatnya metrik tersebut untuk mendapatkan umpan balik penting yang lebih cepat tentang peningkatan yang Anda terapkan. Dan jika ini membangkitkan selera Anda akan informasi ini, maka lihatlah produk RUM lain di luar sana untuk melihat bagaimana mereka dapat membantu Anda juga.

Saat melihat pengukuran alternatif dan produk RUM, ingatlah untuk melihat kembali apa yang dilihat Google untuk situs Anda, karena mungkin berbeda. Akan memalukan untuk bekerja keras pada kinerja, namun tidak mendapatkan semua manfaat peringkat ini pada saat yang bersamaan! Jadi pantau terus grafik Search Console tersebut untuk memastikan Anda tidak melewatkan apa pun.

Kesimpulan

Core Web Vitals adalah sekumpulan metrik utama yang menarik yang ingin mewakili pengalaman pengguna dalam menjelajahi web. Sebagai pendukung kinerja web yang tajam, saya menyambut baik setiap dorongan untuk meningkatkan kinerja situs dan dampak peringkat dari metrik ini tentunya telah menciptakan gebrakan besar dalam kinerja web dan komunitas SEO.

Meskipun metriknya sendiri sangat menarik, yang mungkin lebih menarik adalah penggunaan data CrUX untuk mengukurnya. Ini pada dasarnya memaparkan data RUM ke situs web yang tidak pernah mempertimbangkan untuk mengukur kinerja situs di lapangan dengan cara ini sebelumnya. Data RUM adalah apa yang sebenarnya dialami pengguna, dalam semua pengaturan liar dan bervariasi mereka, dan tidak ada pengganti untuk memahami bagaimana kinerja dan pengalaman situs web Anda yang sebenarnya.

Tapi alasan mengapa kita begitu lama bergantung pada data lab adalah karena data RUM _is_ berisik. Langkah-langkah yang diambil CrUX untuk mengurangi ini memang membantu memberikan tampilan yang lebih stabil, tetapi mengorbankan hal itu sehingga sulit untuk melihat perubahan terbaru.

Semoga posting ini menjelaskan beberapa cara untuk menjelaskan berbagai cara mengakses data Core Web Vitals untuk situs web Anda, dan beberapa batasan dari masing-masing metode. Saya juga berharap ini dapat menjelaskan beberapa data yang selama ini Anda perjuangkan untuk dipahami, serta menyarankan beberapa cara untuk mengatasi keterbatasan tersebut.

Selamat mengoptimalkan!

April 19, 2021

codeorayo

Ampuh! Ini rahasia mengembangkan aplikasi secara instan, tinggal download dan kembangkan. Gabung sekarang juga! Premium Membership [PRIVATE] https://premium.codeorayo.com

Leave a Reply

Your email address will not be published. Required fields are marked *