Mengukur dan mengoptimalkan Google Core Web Vitals: Panduan teknis SEO

Mengumpulkan data tentang kinerja situs Anda adalah langkah pertama untuk memberikan pengalaman pengguna yang luar biasa. Selama bertahun-tahun, Google telah menyediakan berbagai alat untuk menilai dan melaporkan kinerja web.

Diantaranya adalah Core Web Vitals, serangkaian sinyal kinerja yang dianggap penting oleh Google untuk semua pengalaman web.

Artikel ini membahas kumpulan Data Web Inti terkini serta tips dan alat utama untuk meningkatkan kinerja web Anda guna memberikan pengalaman halaman yang baik bagi pengguna.

Sekilas tentang evolusi kinerja web

Lewatlah sudah hari-hari ketika meningkatkan kinerja situs sangatlah mudah.

Di masa lalu, sumber daya yang membengkak dan koneksi yang lamban sering kali menghambat situs web. Namun Anda dapat mengungguli pesaing dengan mengompresi beberapa gambar, mengaktifkan kompresi teks, atau memperkecil style sheet dan modul JavaScript Anda.

Saat ini, kecepatan koneksi lebih cepat. Sebagian besar sumber daya dikompresi secara default dan banyak plugin menangani kompresi gambar, penerapan cache, dll.

Pencarian Google untuk web yang lebih cepat terus berlanjut. PageSpeed ​​Insights (PSI) masih aktif di web.dev, berfungsi sebagai alat terbaik untuk mengevaluasi pemuatan halaman individual.

Meskipun banyak yang merasa bahwa peringkat PSI terlalu bersifat menghukum, namun hal ini masih merupakan hal yang paling dekat dengan bagaimana Google dapat menimbang dan memberi peringkat situs melalui sinyal kecepatan halaman.

Untuk lulus uji kecepatan laman Google versi terbaru, Anda harus memenuhi Penilaian Data Web Inti.

Memahami Data Web Inti

Data Web Inti adalah serangkaian metrik yang diintegrasikan ke dalam sinyal penelusuran pengalaman halaman yang lebih luas yang diperkenalkan pada tahun 2021. Setiap metrik “mewakili aspek berbeda dari pengalaman pengguna, dapat diukur di lapangan, dan mencerminkan pengalaman dunia nyata dari pengguna yang kritis- hasil yang sentris,” menurut Google.

Kumpulan metrik Core Web Vitals saat ini meliputi:

• Cat Puas Pertama
• Penundaan Input Pertama (untuk digantikan oleh Interaksi ke Cat Berikutnya)
• Interaksi ke Cat Berikutnya
• Saatnya ke Byte Pertama
• Cat Contentful Terbesar
• Pergeseran Tata Letak Kumulatif

Web.dev menjelaskan cara kerja setiap metrik sebagai berikut.

Cat Contentful Pertama (FCP)

“Metrik First Contentful Paint (FCP) mengukur waktu sejak halaman mulai dimuat hingga saat bagian mana pun dari konten halaman ditampilkan di layar. Untuk metrik ini, “konten” mengacu pada teks, gambar (termasuk gambar latar belakang), elemen <svg> , atau elemen <canvas> non-putih.”

Apa artinya ini bagi SEO teknis

FCP cukup mudah dimengerti. Saat halaman web dimuat, elemen tertentu tiba (atau “dicat”) sebelum elemen lainnya. Dalam konteks ini, “melukis” berarti rendering di layar.

Setelah bagian mana pun dari laman dirender – katakanlah bilah navigasi utama dimuat sebelum elemen lainnya – FCP akan dicatat pada saat itu.

Anggap saja seberapa cepat halaman mulai dimuat secara nyata bagi pengguna. Pemuatan halaman belum selesai, namun sudah dimulai.

Penundaan Masukan Pertama (FID)

“FID mengukur waktu sejak pengguna pertama kali berinteraksi dengan suatu halaman (yaitu, saat mereka mengeklik tautan, mengetuk tombol, atau menggunakan kontrol khusus yang didukung JavaScript) hingga saat browser benar-benar dapat memulai. memproses event handler sebagai respons terhadap interaksi tersebut.”

Apa artinya ini bagi SEO teknis

FID adalah metrik respons interaksi pengguna yang ditetapkan untuk digantikan oleh Interaction to Next Paint (INP) pada bulan Maret 2024.

Jika pengguna berinteraksi dengan elemen pada halaman (yaitu link, mengurutkan tabel, atau menerapkan navigasi tersaring), berapa lama waktu yang dibutuhkan situs untuk mulai memproses permintaan tersebut?

Interaksi ke Cat Berikutnya (INP)

“INP adalah metrik yang menilai respons keseluruhan halaman terhadap interaksi pengguna dengan mengamati latensi semua interaksi klik, ketuk, dan keyboard yang terjadi sepanjang masa kunjungan pengguna ke halaman. Nilai INP akhir adalah interaksi terpanjang yang diamati, mengabaikan outlier.”

Apa artinya ini bagi SEO teknis

Seperti disebutkan, POLRI akan menggantikan FID sebagai Core Web Vital pada Maret 2024.

INP memperhitungkan informasi yang lebih dalam (tampaknya berasal dari keyboard) dan kemungkinan besar lebih detail dan canggih.

Waktu ke Byte Pertama (TTFB)

“TTFB adalah metrik yang mengukur waktu antara permintaan sumber daya dan saat byte pertama respons mulai tiba.”

Apa artinya ini bagi SEO teknis

Setelah “sumber daya” (misalnya, gambar tersemat, modul JavaScript, stylesheet CSS, dll.) diminta, berapa lama waktu yang dibutuhkan situs untuk mulai menyediakan sumber daya tersebut?

Katakanlah Anda mengunjungi halaman web, dan di halaman itu ada gambar yang disematkan. Itu mulai memuat tetapi belum selesai memuat. Berapa lama hingga byte pertama gambar tersebut dikirimkan dari server ke klien (browser web)?

Cat Contentful Terbesar (LCP)

“Metrik Largest Contentful Paint (LCP) melaporkan waktu render gambar atau blok teks terbesar yang terlihat dalam area pandang, relatif terhadap saat halaman pertama kali mulai dimuat.”

Apa artinya ini bagi SEO teknis

LCP adalah salah satu metrik terpenting namun paling sulit untuk dipenuhi.

Setelah sebagian besar media visual (misalnya teks atau gambar) dimuat, LCP akan dicatat.

Anda dapat membaca ini sebagai, berapa lama waktu yang dibutuhkan untuk memuat sebagian besar konten utama halaman?

Mungkin masih ada bagian kecil yang dimuat di bagian bawah halaman, dan hal-hal yang tidak diperhatikan oleh sebagian besar pengguna.

Namun, pada saat LCP dicatat, sebagian besar halaman Anda telah dimuat. Jika hal ini memakan waktu terlalu lama, Anda akan gagal dalam pemeriksaan LCP.

Pergeseran Tata Letak Kumulatif (CLS)

“CLS adalah ukuran lonjakan skor perubahan tata letak terbesar untuk setiap perubahan tata letak tak terduga yang terjadi sepanjang umur halaman.

Pergeseran tata letak terjadi setiap kali elemen yang terlihat mengubah posisinya dari satu bingkai yang dirender ke bingkai berikutnya. (Lihat di bawah untuk detail tentang cara penghitungan skor pergeseran tata letak individual.)

Semburan pergeseran tata letak, dikenal sebagai jendela sesi, adalah ketika satu atau lebih pergeseran tata letak individual terjadi secara berurutan dengan waktu kurang dari 1 detik di antara setiap pergeseran dan maksimum 5 detik untuk total durasi jendela.

Ledakan terbesar adalah jendela sesi dengan skor kumulatif maksimum dari semua perubahan tata letak dalam jendela tersebut.”

Apa artinya ini bagi SEO teknis

Dulu, ketika pengoptimalan kecepatan halaman masih lebih sederhana, banyak pemilik situs menyadari bahwa mereka dapat mencapai peringkat kecepatan halaman yang sangat tinggi hanya dengan menunda semua sumber daya yang memblokir render (umumnya, lembar CSS dan modul JavaScript).

Ini bagus dalam mempercepat pemuatan halaman tetapi membuat web menjadi pengalaman navigasi yang lebih mengganggu dan mengganggu.

Jika CSS Anda – yang mengontrol semua gaya laman Anda – ditangguhkan, maka konten laman dapat dimuat sebelum aturan CSS diterapkan.

Ini berarti konten halaman Anda akan dimuat tanpa gaya, dan kemudian melompat sedikit saat CSS dimuat.

Ini sangat menjengkelkan jika Anda memuat halaman dan mengeklik tautan, tetapi kemudian tautan tersebut melompat dan Anda mengeklik tautan yang salah.

Jika Anda sedikit OCD seperti saya, pengalaman seperti itu benar-benar menyebalkan (walaupun hanya memakan waktu beberapa detik).

Karena pemilik situs mencoba “mempermainkan” peringkat kecepatan halaman dengan menunda semua sumber daya, Google memerlukan metrik tandingan, yang akan mengimbangi semua peningkatan kecepatan halaman terhadap defisit pengalaman pengguna.

Masukkan Pergeseran Tata Letak Kumulatif (CLS). Ini adalah salah satu pelanggan yang licik, yang akan merusak hari Anda jika Anda mencoba menerapkan peningkatan kecepatan halaman secara luas tanpa memikirkan pengguna Anda.

CLS pada dasarnya akan menganalisis pemuatan halaman Anda untuk mencari perubahan yang salah dan aturan CSS yang tertunda.

Jika jumlahnya terlalu banyak, Anda akan gagal dalam penilaian Core Web Vitals meskipun telah memenuhi semua metrik terkait kecepatan.

Menilai Data Web Inti Anda untuk hasil UX dan SEO yang lebih baik

Salah satu cara terbaik untuk menganalisis kinerja satu laman web adalah dengan memuatnya ke PageSpeed ​​Insights. Tampilan dibagi menjadi kombinasi:

• Data tingkat URL.
• Data asal (tingkat domain).
• data laboratorium.
• Data lapangan.

Untuk memahami hal ini, kita perlu melihat sebuah contoh:

https://pagespeed.web.dev/analisis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Di sini, kita dapat melihat peringkat dan metrik kecepatan halaman untuk beranda TechCrunch.

Di atas, Anda dapat melihat bahwa Penilaian Vital Web Inti telah gagal.

Di web yang mengutamakan seluler, penting untuk memilih tab Hasil seluler , yang seharusnya ditampilkan secara default (inilah hasil yang paling penting).

Pilih tombol Asal sehingga Anda melihat rata-rata data umum di seluruh domain situs Anda, bukan hanya halaman beranda (atau halaman mana pun yang Anda masukkan untuk memindai).

Lebih jauh ke bawah halaman, Anda akan melihat peringkat kecepatan halaman numerik yang lama dan familier:

Jadi, apa perbedaan antara penilaian Core Web Vitals yang baru dan peringkat kecepatan halaman yang lama?

Pada dasarnya, penilaian Core Web Vitals yang baru (Lulus/Gagal) didasarkan pada data lapangan (pengguna sebenarnya).

Peringkat numerik lama didasarkan pada simulasi perayapan seluler dan data lab, yang hanya merupakan perkiraan.

Pada dasarnya, Google telah beralih ke penilaian Core Web Vitals dalam hal mengubah peringkat pencarian.

Untuk lebih jelasnya, data laboratorium yang disimulasikan dapat memberikan rincian yang bagus mengenai apa yang salah, namun Google tidak menggunakan peringkat numerik tersebut dalam algoritma pemeringkatan mereka.

Sebaliknya, penilaian Core Web Vitals tidak memberikan banyak informasi terperinci. Namun, penilaian ini diperhitungkan dalam algoritma pemeringkatan Google.

Jadi, tujuan utama Anda adalah menggunakan diagnostik laboratorium yang lebih kaya sehingga pada akhirnya Anda lulus penilaian Data Web Inti (diperoleh melalui data lapangan).

Ingatlah bahwa ketika Anda membuat perubahan pada situs Anda, meskipun peringkat numerik mungkin langsung mengamati perubahan, Anda harus menunggu hingga Google mengambil lebih banyak data lapangan sebelum Anda akhirnya dapat lulus penilaian Data Web Inti.

Anda akan melihat bahwa penilaian Core Web Vitals dan peringkat kecepatan halaman lama menggunakan beberapa metrik yang sama.

Misalnya, keduanya merujuk pada First Contentful Paint (FCP), Largest Contentful Paint (LCP), dan Cumulative Layout Shift (CLS).

Di satu sisi, jenis metrik yang diperiksa oleh masing-masing sistem pemeringkatan cukup mirip. Yang berbeda adalah tingkat detail dan sumber data yang diperiksa.

Anda harus berusaha untuk lulus penilaian Core Web Vitals berbasis lapangan. Namun, karena datanya tidak terlalu kaya, Anda mungkin ingin memanfaatkan data laboratorium tradisional dan diagnostik untuk mencapai kemajuan.

Harapannya adalah Anda dapat lulus penilaian Core Web Vitals dengan mengatasi peluang lab dan diagnostik. Namun perlu diingat, kedua tes ini tidak berhubungan secara intrinsik.

Menilai CWV Anda melalui PageSpeed ​​Insights

Sekarang setelah Anda mengetahui metrik utama Data Web Inti dan bagaimana metrik tersebut secara teknis dapat dipenuhi, sekarang saatnya untuk melihat contohnya.

Mari kita kembali ke pemeriksaan TechCrunch:

https://pagespeed.web.dev/analisis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Dalam hal ini, FID puas, dan INP hanya gagal dengan selisih tipis.

CLS mempunyai beberapa masalah, namun masalah utama ada pada LCP dan FCP.

Mari kita lihat apa yang disampaikan PageSpeed ​​Insights dalam kaitannya dengan Peluang dan Diagnostik .

Sekarang kita harus beralih dari data lapangan ke data laboratorium dan berupaya mengisolasi pola apa pun yang mungkin berdampak pada Data Web Inti:

Di atas, Anda dapat melihat sub-navigasi kecil di pojok kanan atas kotak berwarna hijau.

Anda dapat menggunakan ini untuk mempersempit berbagai peluang dan diagnostik ke metrik Data Web Inti tertentu.

Namun dalam kasus ini, data menceritakan kisah yang sangat jelas tanpa menyempit.

Pertama, kita disuruh mengurangi JavaScript yang tidak digunakan. Artinya terkadang, JavaScript dimuat tanpa dieksekusi.

Ada juga catatan untuk mengurangi CSS yang tidak terpakai. Dengan kata lain, beberapa gaya CSS sedang dimuat, namun tidak diterapkan (masalah serupa).

Kami juga diminta untuk menghilangkan sumber daya yang memblokir render, yang hampir selalu terkait dengan modul JavaScript dan lembar CSS.

Sumber daya yang memblokir perenderan harus ditangguhkan untuk menghentikannya memblokir pemuatan halaman. Namun, seperti yang telah kami telusuri, hal ini dapat mengganggu peringkat CLS.

Oleh karena itu, sebaiknya mulai membuat CSS penting dan jalur rendering JavaScript penting. Melakukan hal ini akan memasukkan JavaScript dan CSS yang diperlukan ke paro atas sambil menunda sisanya.

Pendekatan ini memungkinkan pemilik situs untuk memenuhi permintaan pemuatan halaman sekaligus menyeimbangkan dengan metrik CLS. Ini bukan hal yang mudah untuk dilakukan dan biasanya membutuhkan web developer senior.

Karena kami juga menemukan CSS dan JavaScript yang tidak digunakan, kami juga dapat melakukan audit kode JavaScript umum untuk melihat apakah JavaScript dapat diterapkan dengan lebih cerdas.

Mari kita kembali ke Peluang dan Diagnostik :

Sekarang, kami ingin fokus pada diagnostik. Google sengaja membatasi pemeriksaan ini melalui koneksi 4G yang buruk, sehingga item seperti thread utama berfungsi begitu lama (17 detik).

Hal ini disengaja untuk memuaskan pengguna dengan bandwidth rendah dan/atau perangkat lambat yang umum terjadi di seluruh dunia.

Saya ingin menarik perhatian Anda di sini untuk “Minimalkan pekerjaan thread utama.” Entri tunggal ini sering kali merupakan tambang emas wawasan.

Secara default, sebagian besar tugas rendering dan eksekusi skrip (JavaScript) halaman web didorong melalui thread pemrosesan utama browser web klien (satu thread pemrosesan tunggal). Anda dapat memahami bagaimana hal ini menyebabkan kemacetan pemuatan halaman yang signifikan.

Meskipun semua JavaScript Anda diperkecil dengan sempurna dan dikirim ke browser pengguna dengan cepat, JavaScript harus menunggu dalam antrian pemrosesan thread tunggal secara default, artinya hanya satu skrip yang dapat dieksekusi sekaligus.

Jadi, mengirimkan banyak JavaScript dengan cepat ke pengguna Anda setara dengan menembakkan selang pemadam kebakaran ke dinding bata dengan jarak satu sentimeter.

Pengirimannya bagus, tapi tidak semuanya berhasil!

Semakin banyak Google mendorong respons kecepatan sisi klien sebagai tanggung jawab kami. Suka atau tidak, begitulah (jadi sebaiknya Anda mengenalnya).

Anda mungkin berkata dengan frustrasi, “Mengapa seperti ini!? Peramban web telah memiliki akses ke berbagai rangkaian pemrosesan selama bertahun-tahun, bahkan peramban seluler pun telah menyusulnya. Tidak perlu menjadi canggung seperti ini, kan?”

Sebenarnya ya. Beberapa skrip bergantung pada keluaran skrip lain sebelum skrip itu sendiri dapat dijalankan.

Kemungkinan besar, jika semua browser tiba-tiba mulai memproses semua JavaScript secara paralel, di luar urutan, sebagian besar web mungkin akan mogok dan terbakar.

Jadi, ada alasan bagus mengapa eksekusi skrip berurutan adalah perilaku default untuk browser web modern. Saya terus menekankan kata “default.” Mengapa demikian?

Itu karena ada pilihan lain. Salah satunya adalah mencegah browser klien memproses skrip apa pun dengan memprosesnya atas nama pengguna. Ini dikenal sebagai rendering sisi server (SSR).

Ini adalah alat yang ampuh untuk menghilangkan simpul eksekusi JavaScript sisi klien tetapi juga sangat mahal.

Server Anda harus memproses semua permintaan skrip (dari semua pengguna) lebih cepat daripada rata-rata browser pengguna Anda memproses satu skrip. Biarkan hal itu meresap sejenak.

Bukan penggemar opsi itu? Oke, mari kita jelajahi paralelisasi JavaScript. Ide dasarnya adalah memanfaatkan pekerja web untuk menentukan skrip mana yang akan dimuat secara berurutan vs. skrip mana yang dapat dimuat secara paralel.

Meskipun Anda dapat memaksa JavaScript untuk memuat secara paralel, melakukan hal ini secara default sangat tidak disarankan. Mengintegrasikan teknologi seperti ini dalam banyak kasus akan mengurangi kebutuhan akan RSK.

Namun, penerapannya akan sangat rumit dan akan membutuhkan (Anda dapat menebaknya!) waktu dari pengembang web senior.

Orang yang sama yang Anda pekerjakan untuk melakukan audit kode JavaScript lengkap mungkin dapat membantu Anda dalam hal ini juga. Jika Anda menggabungkan paralelisasi JavaScript dengan jalur rendering JavaScript yang penting, maka Anda benar-benar berhasil.

Dalam contoh ini, inilah hal yang sangat menarik:

Anda dapat langsung melihat bahwa saat thread utama ditempati selama 17 detik, eksekusi JavaScript memakan waktu 12 detik.

Apakah itu berarti 12 detik dari 17 detik kerja thread adalah eksekusi JavaScript? Hal ini sangat mungkin terjadi.

Kita tahu bahwa semua JavaScript didorong melalui thread utama secara default.

Begitulah cara WordPress, CMS aktif, diatur secara default.

Karena situs ini menjalankan WordPress, 12 detik waktu eksekusi JavaScript tersebut kemungkinan besar berasal dari 17 detik kerja thread utama.

Itu merupakan wawasan yang bagus karena ini memberi tahu kita bahwa sebagian besar waktu pemrosesan utama dihabiskan untuk mengeksekusi JavaScript. Dan melihat jumlah skrip yang direferensikan, hal itu tidak sulit dipercaya.

Mengambil perang salib ke Chrome Dev Tools

Saatnya untuk mengambil langkah teknis dan melepaskan roda pelatihan.

Buka contoh baru Chrome. Anda harus membuka profil tamu untuk memastikan tidak ada plugin yang berantakan atau diaktifkan untuk menggembungkan temuan kami.

Ingat: lakukan tindakan ini dari profil Chrome tamu yang bersih.

Muat situs yang ingin Anda analisis. Dalam kasus kami, itu adalah TechCrunch.

Terima cookie sesuai kebutuhan. Setelah halaman dimuat, buka Chrome DevTools (klik kanan halaman dan pilih Inspect ).

Navigasikan ke Performa > Tangkapan Layar.

Tekan tombol muat ulang untuk merekam pemuatan halaman. Sebuah laporan kemudian akan dibuat:

Di sinilah kita semua perlu menarik napas dalam-dalam dan berusaha untuk tidak panik.

Di atas, dalam kotak berwarna hijau, Anda dapat melihat panel tipis yang menggambarkan permintaan dari waktu ke waktu.

Di dalam kotak ini, Anda dapat menyeret mouse untuk memilih irisan waktu, dan halaman serta analisis lainnya akan beradaptasi secara otomatis.

Wilayah yang saya pilih secara manual adalah wilayah yang ditutupi kotak biru semi transparan.

Di situlah pemuatan halaman utama terjadi dan yang ingin saya teliti.

Dalam hal ini, saya secara kasar memilih rentang waktu dan peristiwa antara 32 ms dan 2,97 detik. Mari fokuskan pandangan kita pada bagian dalam thread utama:

Anda tahu bagaimana sebelumnya, saya mengatakan bahwa sebagian besar tugas rendering dan eksekusi JavaScript dipaksa melalui kemacetan thread utama?

Nah, sekarang kita sedang melihat bagian dalam thread utama itu dari waktu ke waktu. Dan ya, dengan warna kuning, Anda dapat melihat banyak tugas skrip.

Di beberapa baris teratas, seiring berjalannya waktu, semakin banyak potongan kuning tua yang mengonfirmasi semua skrip yang dijalankan dan berapa lama waktu yang dibutuhkan untuk memprosesnya. Anda dapat mengklik potongan batang individual untuk mendapatkan pembacaan setiap item.

Meskipun ini adalah visual yang kuat, Anda akan menemukan visual yang lebih kuat di bagian Ringkasan :

Ini merangkum semua data granular, dipecah menjadi bagian tematik sederhana (misalnya, Scripting , Loading , Rendering ) melalui media visual bagan donat yang mudah dicerna.

Seperti yang Anda lihat, pembuatan skrip (eksekusi skrip) menghabiskan sebagian besar pemuatan halaman. Jadi, anggapan kami sebelumnya dari gabungan data lapangan dan laboratorium Google, yang menunjukkan hambatan eksekusi JavaScript di thread utama, tampaknya akurat.

Pada tahun 2023, ini adalah salah satu masalah yang paling banyak ditemui, dengan sedikit solusi sederhana dan siap pakai.

Membuat jalur rendering JavaScript yang penting itu rumit. Dibutuhkan keahlian untuk melakukan audit kode JavaScript, dan mengadopsi paralelisasi JavaScript atau SSR tidaklah mudah.

Sekarang mari kita lihat Pohon Panggilan :

Call Tree seringkali lebih berguna daripada Bottom-Up .

Datanya serupa, tetapi Call Tree akan mengelompokkan tugas secara tematis ke dalam wadah praktis seperti Evaluate Script (eksekusi skrip).

Anda kemudian dapat mengklik grup, memperluasnya dan melihat skrip serta berapa lama waktu yang dibutuhkan untuk memuatnya. 11% waktu dihabiskan untuk memuat pubads_impl.jsm sedangkan 6% waktu dihabiskan untuk memuat opus.js .

Saya tidak tahu modul apa itu (dan Anda mungkin juga tidak tahu), tetapi di sinilah perjalanan pengoptimalan sering kali dimulai.

Sekarang kita dapat mengambil langkah mundur ke:

• Google skrip ini dan lihat apakah skrip tersebut merupakan bagian dari perpustakaan pihak ketiga, apa fungsinya, dan apa dampaknya.
• Konsultasikan dengan pengembang mengenai bagaimana hal ini dapat diterapkan dengan lebih cerdas.
• Persempit masalahnya pada sumber daya individu dan cari alternatifnya.
• Atasi defisit kinerja (atau alternatifnya, perjuangkan lebih banyak sumber daya/bandwidth, lingkungan hosting yang kuat – jika memang diperlukan).

Alat lain untuk mengukur dan mengoptimalkan Core Web Vitals

Jika Anda berhasil bertahan bersama saya sejauh ini, selamat. Dalam hal Data Web Inti mendalam dan analisis kecepatan halaman, kami hanya menggunakan:

• Wawasan Kecepatan Laman
• Chrome DevTools (tab Kinerja )

Ya, Anda benar-benar bisa menjadi ramping itu. Namun, ada alat lain yang mungkin sangat membantu Anda:

• GTMetrix : Sangat berguna untuk grafik air terjunnya (memerlukan akun gratis untuk air terjun), yang dapat Anda pelajari cara membacanya di sini. Jangan lupa bahwa GTMetrix akan berjalan tanpa hambatan secara default, sehingga memberikan hasil yang sangat menguntungkan. Pastikan untuk mengaturnya ke koneksi LTE.
• Google Search Console : Jika Anda menyiapkan ini dan memverifikasi situs Anda, Anda dapat melihat banyak data kinerja dan kegunaan dari waktu ke waktu, termasuk metrik Core Web Vitals di beberapa halaman (agregat).
• Screaming Frog SEO Spider : Ini dapat dihubungkan ke API kecepatan halaman, untuk memungkinkan pengambilan massal nilai Lulus atau Gagal Core Web Vitals (untuk beberapa halaman). Jika Anda menggunakan API kecepatan halaman gratis, jangan memalunya dengan cara yang tidak masuk akal

Meningkatkan peringkat kecepatan halaman Anda dulunya semudah mengompresi dan mengunggah beberapa gambar.

Dewasa ini? Ini adalah perang salib Core Web Vitals yang kompleks.

Bersiaplah untuk terlibat sepenuhnya. Kurang dari itu akan menemui kegagalan.