Meningkatkan Vital Web Inti, Studi Kasus Majalah yang Menghancurkan

“Mengapa Data Web Inti saya gagal?” Banyak pengembang telah mengajukan pertanyaan itu kepada diri mereka sendiri akhir-akhir ini. Terkadang cukup mudah untuk menemukan jawaban atas pertanyaan itu dan situs hanya perlu berinvestasi dalam kinerja . Kadang-kadang, ini sedikit lebih rumit dan, meskipun berpikir situs Anda hebat dalam kinerja karena alasan tertentu, itu masih gagal. Itulah yang terjadi pada smashingmagazine.com kami sendiri dan mencari tahu, dan memperbaiki, masalah ini membutuhkan sedikit penggalian.

Teriakan Untuk Bantuan

Semuanya dimulai dengan serangkaian tweet Maret lalu dengan teriakan minta tolong:

Nah, ini menggelitik minat saya! Saya penggemar berat Majalah Smashing dan saya sangat tertarik dengan kinerja web dan Core Web Vitals. Saya telah menulis beberapa artikel di sini sebelumnya di Core Web Vitals, dan saya selalu tertarik untuk melihat apa yang ada di Daftar Periksa Kinerja Web tahunan mereka. Jadi, Smashing Magazine tahu tentang kinerja web, dan jika mereka kesulitan, maka ini bisa menjadi kasus uji yang menarik untuk dilihat!

Beberapa dari kami membuat beberapa saran di utas itu tentang apa masalahnya setelah menggunakan beberapa alat analisis kinerja web favorit kami seperti WebPageTest atau PageSpeed ​​Insights.

Menyelidiki Masalah LCP

Masalahnya adalah LCP terlalu lambat di seluler. LCP, atau Cat Konten Terbesar, adalah salah satu dari tiga Data Web Inti yang harus Anda "luluskan" untuk mendapatkan peningkatan peringkat pencarian penuh dari Google sebagai bagian dari Pembaruan Pengalaman Halaman mereka. Seperti namanya, LCP bertujuan untuk mengukur kapan konten halaman terbesar digambar (atau "dilukis") ke layar. Seringkali ini adalah gambar pahlawan atau teks judul. Hal ini dimaksudkan untuk mengukur apa yang kemungkinan besar akan dilihat oleh pengunjung situs.

Metrik sebelumnya mengukur variasi cat pertama ke layar (sering kali ini adalah warna header atau latar belakang); konten insidental yang sebenarnya tidak diinginkan pengguna dari halaman. Konten terbesar seringkali merupakan indikator yang baik atau apa yang paling penting. Dan bagian "puas" dari nama tersebut menunjukkan bahwa metrik ini dimaksudkan untuk diabaikan (misalnya warna latar belakang); mereka mungkin konten terbesar, tetapi mereka tidak "puas", jadi jangan menghitung untuk LCP dan sebagai gantinya algoritme mencoba menemukan sesuatu yang lebih baik.

LCP hanya melihat viewport awal. Segera setelah Anda menggulir ke bawah atau berinteraksi dengan halaman, elemen LCP diperbaiki dan kami dapat menghitung berapa lama waktu yang dibutuhkan untuk menggambar elemen tersebut sejak halaman pertama kali mulai dimuat — dan itulah LCP Anda!

Ada banyak cara untuk mengukur Data Web Inti Anda, tetapi cara yang pasti — meskipun itu bukan cara terbaik, seperti yang akan kita lihat segera — adalah di Google Search Console (GSC). Dari perspektif SEO, tidak masalah apa yang dikatakan alat lain kepada Anda, GSC adalah apa yang dilihat Google Penelusuran. Tentu saja, apa yang dialami pengguna Anda lebih penting daripada apa yang dilihat oleh beberapa perayap mesin telusur, tetapi salah satu hal hebat tentang inisiatif Core Web Vitals adalah ia mengukur pengalaman pengguna yang sebenarnya daripada apa yang dilihat Google Bot! Jadi, jika GSC mengatakan Anda memiliki pengalaman buruk, maka Anda memiliki pengalaman buruk menurut pengguna Anda .

Search Console memberi tahu Smashing Magazine bahwa LCP mereka di seluler untuk sebagian besar halaman mereka perlu ditingkatkan. Keluaran yang cukup standar dari bagian GSC itu dan cukup mudah ditangani: buat saja elemen LCP Anda menggambar lebih cepat! Ini seharusnya tidak memakan waktu terlalu lama. Tentu saja tidak enam bulan (atau begitulah yang kami pikir). Jadi, pertama-tama adalah mencari tahu apa elemen LCP itu.

Menjalankan halaman artikel yang gagal melalui WebPageTest menyoroti elemen LCP:

Meningkatkan Gambar LCP

Oke, jadi foto penulis artikel adalah elemen LCP. Naluri pertama adalah bertanya apa yang bisa kita lakukan untuk membuatnya lebih cepat? Ini melibatkan mempelajari air terjun, melihat kapan gambar diminta, berapa lama waktu yang dibutuhkan untuk mengunduh, dan kemudian memutuskan bagaimana mengoptimalkannya. Di sini, gambar dioptimalkan dengan baik dalam hal ukuran dan format (biasanya pilihan pertama dan termudah untuk meningkatkan kinerja gambar!). Gambar disajikan dari domain aset terpisah (seringkali buruk untuk kinerja), tetapi tidak akan mungkin untuk mengubahnya dalam jangka pendek, dan Majalah Smashing telah menambahkan petunjuk sumber daya preconnect untuk mempercepatnya sebaik mungkin. bisa.

Seperti yang saya sebutkan sebelumnya, Majalah Smashing tahu tentang kinerja web, baru-baru ini bekerja untuk meningkatkan kinerjanya, dan telah melakukan semuanya dengan benar di sini, tetapi masih gagal. Menarik…

Saran lain digulirkan, termasuk mengurangi beban, menunda pekerja layanan (untuk menghindari pertengkaran), atau menyelidiki prioritas HTTP/2, tetapi tidak memiliki dampak yang diperlukan pada waktu LCP. Jadi kami harus membuka tas alat kinerja web kami untuk semua tip dan trik untuk melihat apa lagi yang bisa kami lakukan di sini.

Jika sumber daya sangat penting untuk pemuatan halaman, Anda dapat memasukkannya ke dalam sebaris, sehingga disertakan dalam HTML itu sendiri. Dengan begitu, halaman tersebut mencakup semua yang diperlukan untuk melakukan pengecatan awal tanpa penundaan. Misalnya, Smashing Magazine telah menyejajarkan CSS penting untuk memungkinkan pengecatan pertama yang cepat tetapi tidak menyejajarkan gambar penulis. Inlining adalah pedang bermata dua dan harus digunakan dengan hati-hati. Ini memperkuat halaman dan berarti tampilan halaman berikutnya tidak mendapat manfaat dari fakta bahwa data sudah diunduh. Saya bukan penggemar over-inlining karena ini dan berpikir itu harus digunakan dengan hati-hati.

Jadi, biasanya tidak disarankan untuk membuat gambar sebaris. Namun, di sini gambar itu menyebabkan masalah nyata bagi kami, cukup kecil, dan langsung ditautkan ke halaman. Ya, jika Anda membaca banyak artikel oleh satu penulis itu, percuma saja mengunduh ulang gambar yang sama beberapa kali alih-alih mengunduh gambar penulis sekali dan menggunakannya kembali, tetapi kemungkinan besar, Anda di sini untuk membaca artikel yang berbeda oleh penulis yang berbeda .

Ada beberapa kemajuan dalam format gambar baru-baru ini, tetapi AVIF menyebabkan kegemparan karena sudah ada di sini (setidaknya di Chrome dan Firefox), dan AVIF memiliki hasil kompresi yang mengesankan dibandingkan format JPEG lama yang biasanya digunakan untuk foto. Vitaly tidak ingin membuat inline versi JPEG dari gambar penulis, tetapi menyelidiki apakah inlining versi AVIF akan berhasil. Mengompresi gambar penulis menggunakan AVIF, dan kemudian mem-base64-ing gambar ke dalam HTML menghasilkan peningkatan 3 KB pada berat halaman HTML — yang kecil dan dapat diterima.

Karena AVIF hanya didukung di Chrome pada saat itu (ia datang ke Firefox setelah semua ini), dan karena Core Web Vitals adalah inisiatif Google, itu terasa sedikit "menjijikkan" mengoptimalkan browser Google karena dekrit Google. Chrome sering menjadi yang terdepan dalam dukungan fitur baru dan itu patut dipuji, tetapi selalu terasa sedikit aneh ketika kedua sisi bisnisnya saling memengaruhi. Namun, ini adalah format gambar standar baru daripada beberapa format khusus Chrome (meskipun awalnya hanya didukung di Chrome), dan merupakan peningkatan kinerja yang progresif (pengguna Safari masih mendapatkan konten yang sama, hanya saja tidak secepat ), jadi dengan tambahan AVIF twist, Smashing mengambil saran dan membuat gambar menjadi inline dan memang melihat hasil yang mengesankan di alat lab. Masalah terpecahkan!

LCP Alternatif

Jadi, kami membiarkan tempat tidur itu masuk dan menunggu sekitar 28 hari yang biasa untuk nomor Core Web Vitals semuanya berubah menjadi hijau ... tetapi tidak. Mereka berpindah-pindah antara hijau dan kuning jadi kami tentu saja memperbaiki keadaan, tetapi belum menyelesaikan masalah sepenuhnya. Setelah tinggal lama di bagian "perlu perbaikan" kuning, Vitaly mengulurkan tangan untuk melihat apakah ada ide lain.

Gambar itu menggambar dengan cepat. Tidak secara instan (masih butuh waktu untuk memproses gambar) tetapi sedekat mungkin. Sejujurnya, saya kehabisan ide tetapi melihat lagi dengan mata segar. Dan kemudian muncul ide alternatif — apakah kami mengoptimalkan elemen LCP yang tepat ? Penulis tentu saja penting, tetapi apakah pembaca benar-benar datang ke sini untuk melihatnya? Meskipun ego kita ingin mengatakan ya, dan bahwa mug indah kita yang bersinar jauh lebih penting daripada konten yang kita tulis, para pembaca mungkin tidak berpikir demikian (pembaca, ya — apa yang bisa Anda lakukan!).

Pembaca datang untuk artikel, bukan penulis. Jadi elemen LCP harus mencerminkan hal itu, yang mungkin juga memecahkan masalah gambar gambar LCP. Untuk melakukan itu, kami hanya menempatkan judul di atas gambar penulis, dan sedikit meningkatkan ukuran font di ponsel. Ini mungkin terdengar seperti trik licik untuk mengelabui Dewa SEO Inti Web Vital dengan mengorbankan pengguna, tetapi dalam kasus ini, ini membantu keduanya! Meskipun banyak situs mencoba untuk meretas atau mengoptimalkan GoogleBot dengan cepat dan mudah daripada pengguna nyata, ini bukan kasusnya dan kami cukup nyaman dengan keputusan di sini. Faktanya, penyesuaian lebih lanjut menghapus gambar penulis sepenuhnya di tampilan seluler, di mana ada ruang terbatas dan artikel itu saat ini terlihat seperti ini di seluler, dengan elemen LCP disorot:

Di sini kami menunjukkan judul, informasi penting tentang artikel dan awal ringkasan — jauh lebih berguna bagi pengguna, daripada mengambil semua ruang layar ponsel yang berharga dengan foto besar!

Dan itulah salah satu hal utama yang saya sukai dari Core Web Vitals: mereka mengukur pengalaman pengguna.

Untuk meningkatkan metrik, Anda harus meningkatkan pengalaman.

“

Dan SEKARANG kami akhirnya selesai. Teks menarik jauh lebih cepat daripada gambar sehingga harus menyelesaikan masalah LCP. Terima kasih banyak dan selamat malam!

Saya Benci Grafik CWV Itu Di Google Search Console…

Sekali lagi kami kecewa. Itu tidak menyelesaikan masalah dan tidak lama sebelum grafik Google Search Console kembali menjadi kuning:

Pada titik ini, kita harus berbicara lebih banyak tentang pengelompokan halaman dan Data Web Inti. Anda mungkin telah memperhatikan dari grafik di atas bahwa hampir seluruh grafik berayun sekaligus. Tapi ada juga kelompok inti sekitar 1.000 halaman yang tetap hijau hampir sepanjang waktu. Mengapa demikian?

Nah, Google Search Console mengkategorikan halaman ke dalam pengelompokan halaman dan mengukur metrik Data Web Inti dari pengelompokan halaman tersebut. Ini adalah upaya untuk mengisi data yang hilang untuk halaman-halaman yang tidak mendapatkan lalu lintas yang cukup untuk memiliki data pengalaman pengguna yang berarti. Ada beberapa cara yang bisa mereka lakukan untuk mengatasi ini: mereka bisa saja tidak memberikan peningkatan peringkat apa pun ke halaman tersebut, atau mungkin menganggap yang terbaik dan memberikan dorongan penuh ke halaman tanpa data apa pun. Atau mereka bisa saja kembali ke data vital web inti tingkat asal. Sebaliknya, mereka mencoba melakukan sesuatu yang lebih pintar, yang merupakan upaya untuk membantu, tetapi dalam banyak hal juga lebih membingungkan: Pengelompokan halaman .

Pada dasarnya, setiap halaman diberi pengelompokan halaman. Bagaimana mereka melakukan ini tidak dijelaskan, tetapi URL dan teknologi yang digunakan pada halaman telah disebutkan sebelumnya. Anda juga tidak dapat melihat pengelompokan apa yang telah dipilih Google untuk setiap halaman Anda, dan jika algoritme mereka melakukannya dengan benar, yang merupakan hal lain yang membuat frustrasi pemilik situs web, meskipun mereka memberikan contoh URL untuk setiap skor Data Web Inti yang berbeda di bawah grafik di Google Search Console dari mana pengelompokan terkadang dapat tersirat.

Pengelompokan halaman dapat bekerja dengan baik untuk situs seperti Smashing Magazine. Untuk situs lain, pengelompokan halaman mungkin kurang jelas, dan banyak situs mungkin hanya memiliki satu pengelompokan. Situs Smashing, bagaimanapun, memiliki beberapa jenis halaman yang berbeda: artikel, halaman penulis, panduan, dan sebagainya. Jika halaman artikel lambat karena gambar penulis adalah gambar LCP yang lambat dimuat, maka kemungkinan besar akan terjadi pada semua halaman artikel. Dan perbaikannya kemungkinan akan sama untuk semua halaman artikel. Jadi, mengelompokkannya bersama-sama di sana masuk akal (dengan asumsi Google dapat secara akurat mengetahui pengelompokan halaman).

Namun, hal yang dapat membingungkan adalah ketika halaman mendapatkan cukup pengunjung untuk mendapatkan skor Data Web Inti sendiri dan lolos, tetapi halaman tersebut digabungkan dengan grup yang gagal. Anda dapat memanggil CrUX API untuk semua halaman di situs Anda, melihat sebagian besar lulus, lalu bingung ketika halaman yang sama ditampilkan sebagai gagal di Search Console karena telah dikelompokkan dalam grup dengan URL yang gagal dan sebagian besar lalu lintas untuk grup itu karena gagal. Saya masih bertanya-tanya apakah Search Console harus menggunakan data Core Web Vital tingkat halaman saat itu, daripada selalu menggunakan data pengelompokan.

Bagaimanapun, itu menyumbang ayunan besar. Pada dasarnya, semua artikel (yang jumlahnya sekitar 3.000) tampaknya berada dalam pengelompokan halaman yang sama (bukan tidak masuk akal!) dan pengelompokan halaman tersebut lolos atau gagal. Ketika beralih, grafik bergerak secara dramatis .

Anda juga bisa mendapatkan data yang lebih detail tentang Core Web Vitals melalui CrUX API. Ini tersedia di tingkat asal (yaitu untuk seluruh situs), atau untuk URL individual (jika ada cukup data), tetapi tidak mengganggu di tingkat pengelompokan halaman. Saya telah melacak LCP level asal menggunakan CrUX API untuk mendapatkan ukuran LCP yang lebih tepat dan itu juga menunjukkan kisah yang menyedihkan:

Kita dapat melihat bahwa kita tidak pernah benar-benar “menyelesaikan” masalah dan jumlah halaman “Bagus” (garis hijau di atas) masih terlalu dekat dengan tingkat kelulusan 75%. Selain itu, skor LCP p75 (garis putus-putus yang menggunakan sumbu kanan) tidak pernah benar-benar bergerak cukup jauh dari ambang 2500 milidetik. Tidak heran jika halaman yang lewat dan yang gagal dibalik-balik. Sedikit hari yang buruk, dengan beberapa pemuatan halaman yang lebih lambat, sudah cukup untuk membalik seluruh pengelompokan halaman ke dalam kategori "perlu perbaikan". Kami membutuhkan sesuatu yang lebih untuk memberi kami ruang kepala untuk dapat menyerap "hari-hari buruk" ini.

Pada titik ini, tergoda untuk mengoptimalkan lebih jauh . Kami tahu judul artikel adalah elemen LCP jadi apa yang bisa kami lakukan untuk lebih meningkatkannya? Yah, itu menggunakan font, dan font selalu menjadi kutukan kinerja web sehingga kami dapat memeriksanya.

Tapi tunggu sebentar. Smashing Magazine ADALAH situs yang cepat. Menjalankannya melalui alat kinerja web seperti Lighthouse dan WebPageTest menunjukkan hal itu — bahkan pada kecepatan jaringan yang lebih lambat. Dan itu melakukan segalanya dengan benar! Itu dibangun sebagai generator situs statis sehingga tidak memerlukan pembuatan sisi server apa pun, itu menggariskan segalanya untuk cat awal sehingga tidak ada kendala pemuatan sumber daya selain HTML itu sendiri, itu di-host oleh Netlify di CDN jadi harus berada di dekat penggunanya.

Tentu, kita bisa melihat menghapus font, tapi jika Smashing Magazine tidak bisa memberikan pengalaman yang cepat mengingat semua itu, lalu bagaimana orang lain bisa? Melewati Core Web Vitals seharusnya tidak mustahil, atau mengharuskan Anda untuk hanya berada di situs biasa tanpa font atau gambar. Sesuatu yang lain ada di sini dan inilah saatnya untuk mencari tahu lebih banyak tentang apa yang sedang terjadi daripada hanya membabi buta mencoba putaran pengoptimalan lainnya.

Menggali Sedikit Lebih Dalam Metrik

Smashing Magazine tidak memiliki solusi RUM, jadi sebagai gantinya kami menyelidiki data Laporan Pengalaman Pengguna Chrome (CrUX) yang dikumpulkan Google untuk 8 juta atau lebih situs web teratas dan kemudian membuat data tersebut tersedia untuk kueri dalam berbagai bentuk. Data CrUX inilah yang mendorong data Google Search Console dan pada akhirnya berdampak pada peringkat. Kami sudah menggunakan CrUX API di atas tetapi memutuskan untuk mempelajari sumber daya CrUX lainnya.

Kami menggunakan peta situs dan skrip Google Spreadsheet untuk melihat semua data CrUX untuk seluruh situs yang menyediakannya (Fabian Krumholz telah membuat alat yang jauh lebih komprehensif untuk mempermudah ini!) dan ini menunjukkan hasil yang beragam untuk halaman . Beberapa halaman berlalu, sementara yang lain, terutama halaman yang lebih tua, gagal.

Dasbor CrUX tidak benar-benar memberi tahu kami banyak hal yang belum kami ketahui dalam contoh ini: LCP berada di garis batas, dan sayangnya tidak dalam tren turun:

Menggali statistik lain (TTFB, First Paint, Online, DOMContentLoaded) tidak memberi kami petunjuk apa pun. Namun, ada peningkatan nyata dalam penggunaan seluler:

Apakah ini bagian dari tren umum dalam adopsi seluler? Mungkinkah itu yang memengaruhi LCP seluler meskipun kami telah melakukan perbaikan? Kami memiliki pertanyaan tetapi tidak ada jawaban atau solusi.

Satu hal yang ingin saya lihat adalah distribusi global lalu lintas. Kami melihat di Google Analytics banyak lalu lintas dari India ke artikel lama — mungkinkah itu menjadi masalah?

Koneksi India

Data CrUX tingkat negara tidak tersedia di dasbor CrUX tetapi tersedia di kumpulan data BigQuery CrUX, dan menjalankan kueri di sana di tingkat asal www.smashingmagazine.com menunjukkan perbedaan besar dalam nilai LCP (SQL disertakan di tab kedua dari tautan itu jika Anda ingin mencoba hal yang sama di domain Anda sendiri). Berdasarkan 10 negara teratas di Google Analytics, kami memiliki data berikut:

Lalu lintas India adalah proporsi besar untuk Majalah Smashing (16%) dan tidak memenuhi target untuk LCP di tingkat asal. Itu bisa menjadi masalah dan tentu saja layak untuk diselidiki lebih lanjut . Ada juga data Filipina dan Pakistan dengan skor yang sangat buruk tetapi jumlah lalu lintasnya relatif kecil.

Pada titik ini, saya memiliki firasat apa yang mungkin terjadi di sini, dan solusi potensial sehingga Smashing Magazine menginstal perpustakaan web-vitals untuk mengumpulkan data RUM dan mempostingnya kembali ke Google Analytics untuk dianalisis. Setelah beberapa hari mengumpulkan, kami menggunakan Laporan Vital Web untuk memberi kami banyak data dengan cara yang belum dapat kami lihat sebelumnya, khususnya, perincian tingkat negara:

Dan itu dia. Semua negara teratas dalam analitik memang memiliki skor LCP yang sangat baik, kecuali satu: India. Smashing Magazine menggunakan Netlify yang merupakan CDN global dan memang ada di Mumbai, jadi seharusnya memiliki kinerja yang sama dengan negara lain, tetapi beberapa negara hanya lebih lambat dari yang lain (lebih lanjut tentang ini nanti).

Namun, lalu lintas seluler untuk India hanya sedikit di luar batas 2.500, dan itu hanya negara kedua yang paling banyak dikunjungi. Tentunya skor USA yang bagus seharusnya sudah cukup untuk mengimbangi itu? Nah, dua grafik di atas menunjukkan urutan negara berdasarkan lalu lintas. Tetapi CrUX menghitung lalu lintas seluler dan desktop secara terpisah (dan tablet, tetapi sepertinya tidak ada yang peduli tentang itu!). Apa yang terjadi jika kita memfilter lalu lintas ke hanya lalu lintas seluler ? Dan satu langkah lebih jauh — hanya lalu lintas Chrome seluler (karena hanya Chrome yang memberi makan CrUX dan hanya Chrome yang diperhitungkan dalam CWV)? Kalau begitu kita mendapatkan gambaran yang jauh lebih menarik:

India sebenarnya adalah pengunjung Chrome seluler teratas, dalam beberapa hal — hampir tiga kali lipat pengunjung tertinggi berikutnya (AS)! Filipina, dengan skor buruknya juga naik ke peringkat tiga, dan Nigeria dan Pakistan dengan skor buruknya juga masuk 10 besar. Sekarang skor LCP keseluruhan yang buruk di ponsel mulai masuk akal.

Meskipun seluler telah mengambil alih desktop sebagai cara paling populer untuk mengakses Internet di dunia Barat , masih ada campuran yang adil antara seluler dan desktop di sini — sering dikaitkan dengan jam kerja kita di mana banyak dari kita duduk. depan desktop. Miliaran pengguna berikutnya mungkin tidak sama, dan seluler memainkan peran yang jauh lebih besar di negara-negara tersebut. Statistik di atas menunjukkan ini bahkan berlaku untuk situs seperti Smashing Magazine yang mungkin Anda pertimbangkan akan mendapatkan lebih banyak lalu lintas dari desainer dan pengembang yang duduk di depan desktop saat merancang dan mengembangkan!

Selain itu karena CrUX hanya mengukur dari pengguna Chrome , itu berarti negara-negara dengan lebih banyak iPhone (seperti AS) akan memiliki proporsi yang jauh lebih kecil dari pengguna seluler mereka yang terwakili di CrUX dan juga di Core Web Vitals, jadi juga memperkuat efek dari negara-negara tersebut.

Vital Web Inti Bersifat Global

Data Web Inti tidak memiliki ambang batas yang berbeda per negara, dan tidak masalah jika situs Anda dikunjungi oleh negara yang berbeda — itu hanya mendaftarkan semua pengguna Chrome dengan cara yang sama. Google telah mengkonfirmasi ini sebelumnya, jadi Smashing Magazine tidak akan mendapatkan peningkatan peringkat untuk skor USA yang bagus, dan tidak untuk pengguna India. Sebaliknya, semua pengguna masuk ke dalam wadah peleburan , dan jika skor untuk pengelompokan laman tersebut tidak memenuhi ambang batas, maka sinyal peringkat untuk semua pengguna akan terpengaruh.

Sayangnya, dunia bukanlah tempat yang rata. Dan kinerja web sangat bervariasi menurut negara, dan menunjukkan perbedaan yang jelas antara negara kaya dan negara miskin. Teknologi membutuhkan biaya, dan banyak negara lebih fokus untuk membuat populasi mereka online sama sekali, daripada terus meningkatkan infrastruktur ke teknologi terbaru dan terhebat.

Kurangnya browser lain (seperti Firefox atau iPhone) di CrUX selalu diketahui, tetapi kami selalu menganggapnya sebagai titik buta untuk mengukur kinerja Firefox atau iPhone. Contoh ini menunjukkan dampak yang jauh lebih besar , dan untuk situs dengan lalu lintas global, hasilnya sangat condong ke pengguna Chrome, yang sering kali berarti negara miskin, yang sering berarti konektivitas yang lebih buruk.

Haruskah Data Web Inti Dibagi Berdasarkan Negara?

Di satu sisi, tampaknya tidak adil untuk mempertahankan situs web dengan standar yang sama jika infrastrukturnya sangat bervariasi. Mengapa Majalah Smashing harus dihukum atau diadakan dengan standar yang lebih tinggi daripada situs web serupa yang hanya dibaca oleh desainer dan pengembang dari dunia Barat? Haruskah Smashing Magazine memblokir pengguna India untuk menjaga agar Core Web Vitals tetap senang (saya ingin menjadi cukup jelas di sini bahwa ini tidak pernah muncul dalam diskusi, jadi tolong anggap ini sebagai poin yang penulis sampaikan dan bukan sulap tentang Smashing!).

Di sisi lain, "menyerah" di beberapa negara dengan menerima kelambatan mereka berisiko secara permanen menurunkan mereka ke tingkat yang lebih rendah di mana banyak dari mereka berada. Bukanlah kesalahan rata-rata pembaca India dari Smashing Magazine bahwa infrastruktur mereka lebih lambat dan dalam banyak hal, ini adalah orang-orang yang pantas mendapat sorotan dan upaya lebih, daripada kurang!

Dan ini bukan hanya debat negara kaya versus negara miskin. Mari kita ambil contoh website Prancis yang ditujukan untuk pembaca di Prancis, didanai oleh iklan atau penjualan dari Prancis, dan memiliki situs web cepat di negara tersebut. Namun, jika situs tersebut dibaca oleh banyak orang Kanada Prancis, tetapi menderita karena perusahaan tersebut tidak menggunakan CDN global, maka haruskah perusahaan tersebut menderita di Penelusuran Google Prancis karena tidak secepat pengguna Kanada tersebut? Haruskah perusahaan "diperlukan tebusan" oleh ancaman Core Web Vitals dan harus berinvestasi dalam CDN global untuk menjaga agar para pembaca Kanada itu, dan agar Google senang?

Nah, jika proporsi yang cukup signifikan dari pemirsa Anda menderita maka itulah inisiatif Core Web Vital yang seharusnya muncul. Namun, ini adalah dilema moral yang menarik yang merupakan efek samping dari inisiatif Core Web Vitals yang dikaitkan dengan peningkatan peringkat SEO : uang selalu mengubah banyak hal!

Salah satu idenya adalah menjaga batasannya tetap sama, tetapi mengukurnya per negara . Situs Google Penelusuran Prancis dapat memberikan peningkatan peringkat kepada pengguna tersebut dalam bahasa Prancis (karena pengguna tersebut lulus CWV untuk situs ini), sementara Google Penelusuran Kanada mungkin tidak (karena gagal). Itu akan menyamakan kedudukan dan mengukur situs untuk setiap negara, bahkan jika targetnya sama.

Demikian pula, Majalah Smashing dapat berperingkat baik di AS dan negara-negara lain tempat mereka lulus, tetapi diperingkatkan terhadap situs India lainnya (di mana fakta bahwa mereka berada di segmen "perlu perbaikan" mungkin sebenarnya masih lebih baik daripada banyak situs di sana, dengan asumsi mereka semua mengalami kendala kinerja yang sama).

Sayangnya, saya pikir itu akan memiliki efek negatif, dengan beberapa negara lagi diabaikan sementara situs hanya membenarkan investasi kinerja web untuk negara yang lebih menguntungkan. Plus, seperti yang sudah diilustrasikan oleh contoh ini, Core Web Vitals sudah cukup rumit tanpa membawa hampir 200 dimensi tambahan ke dalam permainan dengan memiliki satu untuk setiap negara di dunia!

Jadi Bagaimana Cara Memperbaikinya?

Jadi kami sekarang akhirnya tahu mengapa Majalah Smashing berjuang untuk lulus Core Web Vitals tetapi apa, jika ada, yang bisa dilakukan untuk itu? Penyedia hosting (Netlify) sudah memiliki CDN Mumbai, yang karenanya harus menyediakan akses cepat bagi pengguna India, jadi apakah ini masalah Netlify untuk memperbaikinya? Kami telah mengoptimalkan situs sebanyak mungkin, jadi apakah ini hanya sesuatu yang harus mereka jalani? Yah tidak, sekarang kita kembali ke ide kita sebelumnya: mengoptimalkan font web sedikit lebih banyak .

Kami dapat mengambil opsi drastis untuk tidak mengirimkan font sama sekali. Atau mungkin tidak mengirimkan font ke lokasi tertentu (meskipun itu akan lebih rumit, mengingat sifat SSG dari situs web Smashing Magazine). Atau, kita bisa menunggu dan memuat font di front end, berdasarkan kriteria tertentu, tapi itu berisiko memperlambat font untuk orang lain saat kita menilai kriteria itu. Kalau saja ada beberapa sinyal browser yang mudah digunakan kapan kita harus mengambil tindakan drastis ini. Sesuatu seperti header SaveData, yang dimaksudkan persis untuk ini!

SaveData Dan prefers-reduced-data

SaveData adalah setelan yang dapat diaktifkan pengguna di browser mereka saat mereka benar-benar ingin… menyimpan data dengan baik. Ini dapat berguna bagi orang-orang dengan paket data terbatas, bagi mereka yang bepergian dengan biaya roaming yang mahal, atau bagi mereka yang berada di negara-negara yang infrastrukturnya tidak secepat yang kita inginkan.

Pengguna dapat mengaktifkan setelan ini di browser yang mendukungnya, lalu situs web dapat menggunakan informasi ini untuk mengoptimalkan situs mereka lebih dari biasanya. Mungkin mengembalikan gambar berkualitas lebih rendah (atau mematikan gambar sepenuhnya!), atau tidak menggunakan font. Dan hal terbaik tentang pengaturan ini adalah Anda bertindak atas permintaan pengguna, dan tidak secara sewenang-wenang membuat keputusan untuk mereka (banyak pengguna India mungkin memiliki akses cepat dan tidak menginginkan versi situs web yang dibatasi!).

Informasi Simpan Data tersedia dalam dua (segera menjadi tiga!) cara:

1. Header SaveData dikirim pada setiap permintaan HTTP. Ini memungkinkan backend dinamis untuk mengubah HTML yang dikembalikan.
2. API JavaScript NetworkInformation.saveData . Ini memungkinkan skrip front-end untuk memeriksa ini dan bertindak sesuai dengan itu.
3. Kueri media prefers-reduced-data akan datang, memungkinkan CSS untuk menyetel opsi berbeda bergantung pada setelan ini. Ini tersedia di belakang bendera di Chrome, tetapi belum diaktifkan secara default saat menyelesaikan standarisasi.

Jadi pertanyaannya adalah, apakah banyak pembaca Majalah Smashing (dan khususnya di negara-negara yang berjuang dengan Core Web Vitals) menggunakan opsi ini dan apakah ini sesuatu yang dapat kami gunakan untuk melayani mereka di situs yang lebih cepat? Nah, ketika kami menambahkan skrip web-vitals yang disebutkan di atas, kami juga memutuskan untuk mengukurnya, serta Jenis Koneksi yang Efektif. Anda dapat melihat skrip lengkapnya di sini. Setelah beberapa saat mengizinkannya untuk dikumpulkan, kami dapat menampilkan hasilnya di dasbor /Google Analytics sederhana, bersama dengan versi browser Chrome:

Jadi, kabar baiknya adalah sebagian besar pengguna ponsel India (sekitar dua pertiga) memiliki pengaturan ini . ECT kurang berguna dengan sebagian besar ditampilkan sebagai 4g. Saya telah berpendapat sebelumnya bahwa API ini menjadi semakin tidak berguna karena sebagian besar pengguna diklasifikasikan di bawah pengaturan 4g ini. Plus menggunakan nilai ini secara efektif untuk beban awal penuh dengan masalah.

Lebih banyak kabar baik karena sebagian besar pengguna tampaknya menggunakan Chrome terbaru, jadi akan mendapat manfaat dari fitur-fitur baru seperti kueri media prefers-reduced-data ketika sudah tersedia sepenuhnya.

Ilya from the Smashing team applied the JavaScript API version to their font-loader script so additional fonts are not loaded for these users. The Smashing folks also applied the prefers-reduce-data media query to their CSS so fallback fonts are used rather than custom web fonts for the initial render, but this will not be taking effect for most users until that setting moves out of the experimental stage.

I Love That Graph In Google Search Console

And did it work? Well, we'll let Google Search Console tell that store as it showed us the good news a couple of weeks later:

Additionally, since this was introduced in mid-November, the original level LCP score has steadily ticked downwards:

There's still not nearly enough headroom to make me comfortable, but I'm hopeful that this will be enough for now, and will only improve when the prefers-reduced-data media query comes into play — hopefully soon.

Of course, a surge in traffic from mobile users with bad connectivity could easily be enough to flip the site back into the amber category, which is why you want that headroom, so I'm sure the Smashing team will be keeping a close eye on their Google Search Console graph for a bit longer, but I feel we've made the best efforts basis to improve the experience of users so I am hopeful it will be enough.

Impact Of The User Experience Ranking Factor

The User Experience ranking factor is supposed to be a small differentiator at the moment, and maybe we worried too much about a small issue that is, in many ways outside of our control? If Smashing Magazine is borderline, and the impact is small, then maybe the team should worry about other issues instead of obsessing over this one? But I can understand that and, as I said, Smashing Magazine are knowledgeable in performance and so understand why they wanted to solve — or at the very least understand! — this issue.

So, was there any impact? Interestingly we did see a large uptick in search impression in the last week at the same time as it flipped to green:

It's since reverted back to normal, so this may have been an unrelated blip but interesting nonetheless!

Kesimpulan

So, an interesting case study with a few important points to take away:

• When RUM (including CrUX or Google Search Console) tells you there's a problem, there probably is! It's all too easy to try to compare your experiences and then blame the metric.
• Implementing your own RUM solution gives you access to much more valuable data than the high-level data CrUX is intended to provide, which can help you drill down into issues, plus also give you potentially more information about the devices your site visitors are using to visit your site.
• Core Web Vitals are global, and that causes some interesting challenges for global sites like Smashing Magazine. This can make it difficult to understand CrUX numbers unless you have a RUM solution and perhaps Google Search Console or CrUX could help surface this information more?
• Chrome usage also varies throughout the world, and on mobile is biased towards poorer countries where more expensive iPhones are less prevalent.
• Core Web Vitals are getting much better at measuring User Experience. But that doesn't mean every user has to get the same user experience — especially if they are telling you (through things like the Save Data option) that they would actually prefer a different experience.

I hope that this case study helps others in a similar situation, who are struggling to understand their Core Web Vitals. And I hope you can use the information here to make the experience better for your website visitors.

Selamat mengoptimalkan!

Note: It should be noted that Vitaly, Ilya and others at the Smashing team did all the work here, and a lot more performance improvements were not covered in the above article. I just answered a few queries for them on this specific problem over the last 6 months and then suggested this article might make an interesting case study for other readers to learn from.