Apa saja Pertanyaan SEO Online Anda?

Jika anda memiliki pertanyaan, Portal SEO atau Forum SEO untuk Tips SEO atau Tutorial SEO sebagai Forum Portal TIps Tutorial SEO Online anda.

3 Faktor Penting Core Web Vital SEO

Core Web Vitals 3 Faktor Penting SEO Portal SEO Online

Core Web Vital metrik kecepatan yang merupakan bagian sinyal Page Experience Google yang digunakan untuk mengukur User Experience.

Metrik mengukur beban visual dengan Largest Contentful Paint (LCP), stabilitas visual dengan Kumulatif Tata Letak Shift (CLS), dan interaktivitas dengan First Input Delay (FID).

Pengalaman halaman dan metrik Core Web Vital yang disertakan akan secara resmi digunakan untuk halaman peringkat pada Mei 2021.

Cara termudah untuk melihat metrik situs Anda adalah dengan laporan Core Web Vitals pada Google Search Console.

Dengan laporan tersebut, Anda dapat dengan mudah melihat apakah halaman Anda dikategorikan sebagai “URL buruk”, “URL perlu perbaikan”, atau “URL yang baik”.

Di dalam laporan, Anda dapat menemukan informasi yang lebih detail tentang masalah tertentu dan daftar halaman yang terpengaruh.

Core Web Vitals – Pembaruan Faktor Peringkat Page Experience Google

Faktor Peringkat Page Experience Google Core Web Vital Portal SEO Online

Source : Google.com

Core Web Vitals, metrik pengalaman pengguna baru dari Google, terdiri dari tiga metrik yang harus diperhatikan oleh webmaster dan SEO di masa mendatang: pemuatan, interaktivitas, dan stabilitas visual.

Karena Core Web Vitals didasarkan pada pengalaman pengguna, mereka diukur dengan data lapangan yang berbeda dengan data lab yang digunakan sebelumnya yang menunjukkan momen tertentu selama proses pemuatan halaman.

Dalam kombinasi dengan komponen lain yang berkaitan dengan keamanan situs web dan keramahan pengguna, Core Web Vitals akan ditambahkan ke faktor peringkat Pengalaman Halaman pada Mei 2021.

Fakta singkat tentang Core Web Vitals

  1. Fakta 1: Metrik dibagi antara desktop dan seluler, tetapi hanya sinyal seluler yang akan digunakan untuk halaman peringkat. Google beralih ke 100% pengindeksan yang memprioritaskan seluler pada bulan Maret, jadi masuk akal untuk menggunakan sinyal kecepatan seluler karena laman yang diindeks juga akan didasarkan pada versi seluler.
  2. Fakta 2: Data berasal dari Laporan Pengalaman Pengguna Chrome (CrUX), yang mencatat data dari pengguna Chrome yang diikutsertakan. Metrik akan dinilai pada persentil ke-75 pengguna, jadi jika 70% pengguna Anda termasuk dalam kategori “baik” dan 5% berada dalam kategori “perlu perbaikan”, laman Anda masih dinilai sebagai “perlu perbaikan”.
  3. Fakta 3: Metrik akan dinilai untuk setiap halaman, tetapi jika tidak ada cukup data, John Mueller menyatakan bahwa sinyal dari bagian situs atau keseluruhan situs dapat digunakan.
  4. Fakta 4: Dengan penambahan metrik baru ini, AMP dihapus sebagai persyaratan dari fitur Berita Utama di seluler. Karena artikel baru tidak benar-benar memiliki data tentang metrik kecepatan, kemungkinan metrik dari kategori halaman yang lebih besar atau bahkan seluruh domain dapat digunakan untuk ini.
  5. Fakta 5: Aplikasi Halaman Tunggal tidak mengukur beberapa metrik, FID dan LCP, melalui transisi halaman. Kami akan membicarakan tentang apa itu sebentar lagi.
  6. Fakta 6: Metrik dapat berubah dari waktu ke waktu, dan ambang batasnya mungkin juga. Google telah mengubah metrik yang digunakan untuk mengukur kecepatan di alat mereka selama bertahun-tahun serta ambang batasnya untuk apa yang dianggap cepat atau tidak. Kemungkinan besar ini semua akan berubah lagi di masa mendatang. Faktanya, kami melakukan beberapa pekerjaan untuk meningkatkan metrik sebelumnya tahun lalu, tetapi kami perlu melakukan beberapa pekerjaan lagi untuk meningkatkan metrik baru.

Apakah Core Web Vitals penting untuk SEO?

Hanya untuk menetapkan ekspektasi, ingatlah bahwa ada lebih dari 200 faktor peringkat.

Saya tidak mengharapkan banyak peningkatan dari peningkatan Core Web Vitals.

Tidak diketahui seberapa besar pengaruhnya terhadap peringkat, tetapi sepertinya itu bukan sinyal yang kuat, terutama mengingat banyak komponen pengalaman laman telah digunakan oleh Google untuk menentukan peringkat.

Core Web Vitals berdasarkan 3 Metrik Inti

Pada awal Mei 2020, Google mengumumkan peluncuran Core Web Vitals baru mereka yang akan datang, indikator utama yang akan mereka gunakan untuk menentukan peringkat pengalaman pengguna di situs web.

Saat Core Web Vitals Google diluncurkan pada Mei 2021, mereka akan menyertakan tiga metrik yang, jika digabungkan dengan variabel lain, akan membentuk faktor peringkat baru untuk pengalaman pengguna yang stabil dan aman di situs web.

Detail lebih lanjut tentang Faktor Peringkat Pengalaman Halaman dapat ditemukan di artikel terkait.

Core Web Vitals diukur dengan data lapangan yang telah disediakan oleh Google di beberapa laporan dan alat, termasuk Lighthouse, Wawasan Kecepatan Laman, dan Alat Pengembang Google. Core Web Vitals terdiri dari tiga metrik yang meliputi:

  • Largest Contentful Paint
  • First Input Delay
  • Cumulative Layout Shift

Seiring waktu, Core Web Vitals akan disesuaikan dengan perkembangan teknis terbaru dan perubahan perilaku pengguna.

Sehubungan dengan hal ini, Google akan mengevaluasi ulang Core Web Vitals setiap tahun. Artinya, metrik inti juga dapat berubah.

Fokus pada tiga metrik inti yang jelas dan koheren membawa sejumlah manfaat. Google dapat menganalisis situs web berdasarkan KPI yang dikomunikasikan dengan jelas.

Ini memberi webmaster, pengembang web, dan SEO dasar yang kuat ketika memperdebatkan posisi mereka terkait dengan pekerjaan dan anggaran tertentu dengan pelanggan. atau manajemen mereka, yang dapat ditunjukkan bukti hasil positif yang tegas dari data vital web inti yang dioptimalkan.

Di Mana Dapat Mengakses Laporan Core Web Vitals?

Core Web Vitals Google telah diintegrasikan ke dalam semua alat analisis Google.

Misalnya, Core Web Vitals dapat diakses melalui PageSpeed Insights, yang juga menyertakan skor kecepatan halaman (antara nol dan 100) yang dihasilkan dari Lighthouse.

Hasil untuk Core Web Vitals ditampilkan, di satu sisi, dalam bentuk data lapangan dan data lab.

Data lapangan adalah data anonim yang digunakan untuk membuat situs web di browser yang digunakan oleh pengguna nyata di berbagai perangkat dan pada berbagai kecepatan koneksi.

Sebaliknya, data lab didasarkan pada simulasi pemuatan halaman di satu perangkat dalam kondisi jaringan yang ditentukan. Inilah mengapa nilainya bisa berbeda.

Hasil Core Web Vitals juga dapat diakses di Google Search Console berupa gambaran langsung metrik untuk domain yang diberikan, menunjukkan berapa banyak dan URL apa yang dianggap baik (hijau), yang perlu ditingkatkan (kuning), atau yang buruk (merah).

Data di Search Console didasarkan pada laporan pengalaman pengguna di Chrome dan mencerminkan data pengguna yang sebenarnya untuk situs web masing-masing untuk pengguna di seluruh dunia:

Tiga KPI awal di Core Web Vitals dijelaskan lebih detail di bawah ini. Juga disertakan tip pengoptimalan dan tautan lainnya.

Google Memberi Peringkat Core Web Vitals Secara Terpisah untuk Desktop dan Seluler

Sementara itu, Analis Tren Webmaster Google John Mueller membuat beberapa penambahan pada Core Web Vitals di Jam Kerja Google Jerman pada tanggal 29 Oktober 2020.

Menurutnya, metrik tambahan untuk waktu muat, sebagaimana ditentukan secara mendetail di Google Lighthouse, misalnya, tidak memainkan peran untuk pengalaman halaman sebagai faktor peringkat.

Selanjutnya, Google Core Web Vitals akan ditentukan secara terpisah untuk seluler dan desktop.

Dalam kebanyakan kasus, nilai seluler untuk Core Web Vitals lebih buruk daripada untuk halaman desktop.

Google kemudian mengevaluasi ini secara terpisah; Untuk halaman maka tidak ada efek negatif pada peringkat di hasil pencarian desktop, tetapi mungkin untuk peringkat seluler, lanjut Mueller.

3 Komponen Vital Web Inti

1. Largest Contentful Paint (LCP) – Loading

LCP adalah satu-satunya elemen terlihat terbesar yang dimuat di viewport.

largest contentful paint core web vital portal seo online

Source : PageSpeed Insight GoogleLargest Contentful Paint (LCP) mengukur waktu yang berlalu hingga elemen konten terbesar di halaman dimuat. Ini bisa berupa gambar, blok teks, atau elemen dengan gambar latar belakang.

Untuk LCP, waktu muat hingga 2,5 detik adalah baik, apa pun antara 2,5 dan 4 detik perlu perbaikan – dan apa pun yang lebih rendah dari 4 detik itu buruk.

LCP halaman ditentukan berdasarkan status pemuatan halaman – karena, dalam banyak kasus, elemen terbesar dimuat di bagian akhir. Mari kita lihat contoh situs web CNN yang ditunjukkan di bawah ini:

Google telah melakukan yang terbaik untuk membuat dokumentasi di Core Web Vitals individual sedetail dan sejelas mungkin.

Elemen terbesar biasanya akan menjadi gambar unggulan atau mungkin tag <h1> tetapi bisa berupa salah satu dari ini:

  • <img> elemen
  • <image> elemen di dalam elemen <svg>
  • Gambar di dalam elemen <video>
  • Gambar latar belakang dimuat dengan fungsi url ()
  • Blok teks

<svg> dan <video> mungkin ditambahkan di masa mendatang.

Cara melihat LCP

Di PageSpeed Insights, elemen LCP akan ditentukan di bagian Diagnostik. Untuk halaman yang diuji, LCP adalah gambar unggulan kami di postingan blog.

Di Chrome DevTools, ikuti langkah-langkah berikut:

  • Performa> centang “Screenshot”
  • Klik ‘Mulai membuat profil dan muat ulang halaman’
  • LCP ada pada grafik waktu
  • Klik node; ini adalah elemen untuk LCP

Mengoptimalkan LCP

Dengan elemen LCP kita pada halaman ini dan banyak halaman lainnya menjadi gambar unggulan, kita mungkin dapat membuatnya lebih baik dengan pramuat gambar ini atau mungkin membuat seluruh gambar menjadi sejajar untuk membuat gambar diunduh bersama dengan kode HTML.

Pada dasarnya, kami ingin memuat gambar ini lebih cepat dari yang kami lakukan saat ini.

Mengoptimalkan untuk Largest Contentful Paint

  • Server merespons terlalu lambat: Semakin lama browser perlu menerima konten dari server, semakin lama waktu yang dibutuhkan untuk memuat halaman bagi pengguna. Inilah mengapa Google merekomendasikan menggunakan kerangka kerja seperti React daripada seluruh file HTML, sehingga konten halaman dikirim ke browser secara dinamis. Mungkin juga membantu untuk membuat Jaringan Pengiriman Konten (CDN) untuk memungkinkan permintaan dikirim dari server yang terletak paling dekat dengan pengguna. Selain caching yang efisien, masuk akal untuk menyiapkan koneksi pihak ketiga lebih awal untuk mencegah penundaan yang dapat dihindari di bagian akhir pemuatan halaman.
  • Pemblokiran render JavaScript dan CSS: Sebelum browser benar-benar dapat merender elemen konten, yang berarti memvisualisasikannya untuk pengguna, mark-up HTML harus diurai dalam apa yang disebut Model Objek Dokumen (DOM). Masalahnya di sini, bagaimanapun, adalah bahwa parser HTML berhenti setiap kali CSS atau sumber daya JavaScript harus dimuat. Untuk mengatasi masalah ini, Google merekomendasikan meminimalkan file CSS atau JavaScript, menunda gaya non-kritis atau JS dan menyebariskan atribut CSS penting.
  • Sumber daya dimuat terlalu lambat: Gambar, video, atau blok konten sering kali dapat menyebabkan sumber daya dimuat terlalu lambat. Di sini, Google merekomendasikan pengurangan gambar ke ukuran yang dibutuhkan, misalnya menggunakan format file yang lebih baru yang memiliki kompresi gambar yang superior seperti JPEG 2000, JPEG XR atau WebP. Pendekatan lain adalah dengan memuat sumber daya utama dan mengompresi file HTML, CSS, atau JavaScript menggunakan Gzip. Adaptasi Penyajian juga dapat membantu di sini, memberi Anda pilihan untuk mengatur halaman agar hanya memuat gambar kecil daripada video jika kecepatan koneksi kurang dari 4G, misalnya.
  • Client-Side Rendering: Client-Side Rendering, di mana halaman web dirender langsung di browser dengan bantuan kerangka kerja JavaScript seperti React atau Angular, adalah cara yang efektif untuk memastikan bahwa Largest Contentful Paint memuat lebih cepat bagi pengguna.
  • Tip pengoptimalan lainnya: Dalam posting blog khusus Google memberikan sejumlah tip untuk meningkatkan Cat Konten Terbesar.

2. First Input Delay (FID) – interaktivitas

FID adalah waktu dari saat pengguna berinteraksi dengan halaman Anda sampai halaman tersebut dapat merespons.

Anda juga bisa menganggapnya sebagai daya tanggap. Ini tidak termasuk scroll atau zoom.

Contoh interaksi:

  • mengklik link atau tombol
  • memasukkan teks ke dalam bidang kosong
  • memilih menu tarik-turun
  • mengklik kotak centang.

Mencoba mengeklik sesuatu dan tidak terjadi apa-apa di laman itu bisa membuat frustasi.

First Input Delay Core Web Vital Portal SEO Online

Source : PageSpeed Insight Google

First Input Delay (FID) mengukur waktu dari saat pengguna pertama kali berinteraksi dengan situs hingga titik di mana browser dapat merespons interaksi itu.

Seringkali pengguna akan pergi ke situs web dan langsung mengklik teks atau mengklik tombol tanpa menunggu halaman dimuat sepenuhnya terlebih dahulu.

Sangat sering tidak banyak yang akan terjadi karena browser sibuk memuat halaman.

Untuk menghentikan pengguna menjadi tidak sabar dan meninggalkan halaman lagi karena browser tidak menanggapi masukan mereka, metrik FID mengukur penundaan yang terjadi antara masukan pengguna dan tanggapan browser.

Menurut Google, apa pun yang di bawah 100 milidetik itu baik, apa pun yang antara 100 dan 300 milidetik perlu ditingkatkan, sementara nilai FID di atas 300 milidetik dianggap buruk.

Detail tentang Penundaan Masukan Pertama dapat ditemukan di dokumentasi Google tentang Penundaan Masukan Pertama.

Tidak semua pengguna akan berinteraksi dengan halaman, jadi mereka mungkin tidak memiliki nilai FID. Ini juga mengapa alat uji lab tidak akan memiliki nilai karena tidak berinteraksi dengan halaman. Gunakan Total Blocking Time (TBT) sebagai gantinya.

Penyebab FID

JavaScript bersaing untuk utas utama. Hanya ada satu utas utama, dan JavaScript bersaing untuk menjalankan tugas di sana.

Saat tugas sedang berjalan, halaman tidak dapat merespons masukan pengguna. Penundaan inilah yang dirasakan. Semakin lama tugas tersebut, semakin lama pula penundaan yang dialami pengguna. Jeda antar tugas adalah peluang halaman harus beralih ke tugas masukan pengguna dan merespons apa yang ingin mereka lakukan.

Mengoptimalkan FID

Saya tidak melihat kekhawatiran apa pun pada situs kami untuk FID, tetapi secara umum, Anda ingin menghentikan tugas yang panjang dan menangguhkan JavaScript yang tidak diperlukan hingga nanti.

  • Membagi tugas yang lama: Penundaan sering kali disebabkan oleh eksekusi JavaScript, yang berarti pengguna mungkin tidak dapat berinteraksi dengan situs web. Memecah tugas dapat membantu dalam hal ini. Untuk Google, tugas yang panjang adalah saat sepotong kode memblokir utas utama selama lebih dari 50 milidetik.
  • Memprioritaskan interaktivitas: Dengan kata lain, memprioritaskan kode yang penting untuk interaktivitas situs, artinya ini dimuat terlebih dahulu.
  • Menggunakan Web Worker: Dengan Web Worker, file JavaScript yang berat dapat dijalankan di utas terpisah, yang berarti utas utama tidak diblokir.
  • Mengurangi waktu eksekusi JavaScript: Semua file JavaScript yang dijalankan saat situs web dimuat, harus diteliti dengan tujuan untuk menunda file yang tidak penting.
  • Tips pengoptimalan lainnya: Dalam postingan blog khusus Google juga memberikan berbagai tips tentang cara meningkatkan First Input Delay.

3. Cumulative Layout Shift  (CLS) – Stabilitas Visual

CLS mengukur bagaimana elemen bergerak atau seberapa stabil tata letak halaman. Ini memperhitungkan ukuran konten dan jarak pergerakannya.

Satu masalah utama dengan metrik adalah bahwa metrik terus mengukur bahkan setelah pemuatan halaman awal.

Google menerima masukan tentang metrik khusus ini, jadi kami mungkin akan melihat beberapa perubahan di masa mendatang.

cumulative layout shift core web vital portal seo online

Source : PageSpeed Insight Google

Dapat mengganggu jika Anda mencoba mengeklik sesuatu pada laman yang bergeser dan Anda akhirnya mengeklik sesuatu yang tidak Anda inginkan.

Itu terjadi pada saya sepanjang waktu. Saya mengklik satu hal, dan tiba-tiba, saya mengklik iklan dan bahkan tidak di situs yang sama.

Itu membuat frustrasi sebagai pengguna. Bisa mengganggu jika Anda mencoba mengeklik sesuatu di laman yang bergeser dan Anda akhirnya mengeklik sesuatu yang tidak Anda inginkan.

Itu terjadi pada saya sepanjang waktu. Saya mengklik satu hal, dan tiba-tiba, saya mengklik iklan dan bahkan tidak di situs yang sama. Itu membuat frustasi sebagai pengguna.

Penyebab umum CLS meliputi:

  • Gambar tanpa dimensi
  • Iklan, sematan, dan iframe tanpa dimensi
  • Menyuntikkan konten dengan JavaScript
  • Menerapkan font atau gaya di akhir pemuatan

Cumulative Layout Shift (CLS) mengacu pada stabilitas visual selama interaktivitas di situs web. Saat situs web dimuat, pergeseran tata letak dapat terjadi karena mendorong elemen ke bawah halaman, misalnya, saat elemen berikutnya dimuat di atas.

Saat konten bergeser saat halaman dimuat dan pengguna sudah berinteraksi dengan situs.

Dengan kata lain, Pergeseran Tata Letak Kumulatif menunjukkan apakah dan sejauh mana perubahan tata letak yang tidak terduga (pergeseran) terjadi saat pengguna berinteraksi dengan situs web.

Misalnya, ketika elemen konten baru sedang divisualisasikan dan tombol tiba-tiba bergeser posisi tanpa pengguna menggulir.

Semakin rendah metrik ini, semakin baik. Sebagai bagian dari Core Web Vitals, metrik Pergeseran Tata Letak Kumulatif dihitung sebagai berikut:

Pecahan Dampak x Pecahan Jarak = Skor Pergeseran Tata Letak

Fraksi dampak adalah persentase layar yang terpengaruh oleh pergeseran, sedangkan pecahan jarak menggambarkan persentase ketinggian area pandang saat elemen konten telah turun karena pergeseran tata letak.

Baik pecahan tumbukan maupun pecahan jarak diberikan sebagai nilai antara 0 dan 1. Skor Pergeseran Tata Letak adalah hasil kali dari kedua nilai ini dan terletak di antara 0 dan 1.

Bagi Google, apa pun di bawah 0,1 adalah baik dan apa pun yang lebih tinggi dari 0,25 adalah buruk.

Cara melihat CLS

Di PageSpeed Insights, di bawah Diagnostics, Anda akan menemukan daftar elemen yang berubah.

Menggunakan WebPageTest. Dalam Tampilan Setrip Film, gunakan opsi berikut:

  • Sorot Pergeseran Tata Letak
  • Ukuran Thumbnail: Besar
  • Interval Gambar Kecil: 0,1 dtk

Perhatikan bagaimana font kita ditata ulang antara 5.1s ‑ 5.2s, menggeser layout saat font kustom kita diterapkan.

Anda mungkin ingin mencoba Layout Shift GIF Generator.

Smashing Magazine juga memiliki teknik menarik yang mereka bagikan di mana mereka menguraikan semuanya dengan garis merah solid 3px dan merekam video pemuatan halaman untuk mengidentifikasi di mana perubahan tata letak terjadi.

Mengoptimalkan CLS

Untuk halaman pengujian kami, yang mungkin ingin kami lakukan adalah memuat font kustom kami sebelumnya, menghapus font kustom sepenuhnya (kami ragu akan melakukannya), atau menggunakan font default untuk pemuatan halaman awal dan hanya memuat font kami pada pemuatan halaman berikutnya.

Ini memiliki trade-off dalam branding, gaya, konsistensi, dll, dan kami harus memutuskan jalan terbaik untuk maju.

  • Menentukan ukuran gambar dan elemen video: Menentukan ukuran gambar dan video yang tepat (W x H) akan memastikan tidak ada kejutan yang tidak menyenangkan bagi pengguna. Selain itu, ruang yang dibutuhkan untuk elemen ini juga dapat ditentukan menggunakan rasio aspek dengan CSS. Dengan cara ini browser akan menjaga ruang kosong yang dibutuhkan untuk gambar atau video saat sedang memuat.
  • Iklan tanpa data tinggi / lebar: Menurut Google, iklan adalah salah satu alasan paling umum terjadinya pergeseran tata letak di situs web. Ini karena jaringan periklanan – termasuk Google Ads – sering menggunakan format iklan dinamis. Elemen placeholder dapat membantu di sini – data historis akan memungkinkan Anda memilih ukuran yang paling mungkin untuk ruang iklan tertentu.
  • Elemen konten dinamis: Elemen seperti buletin atau spanduk penawaran khusus, blok konten terkait, atau info GDPR yang diposisikan sebagai blok di konten utama pada halaman dapat mengakibatkan pergeseran tata letak. Di sini, juga, Google merekomendasikan penggunaan elemen placeholder. Melakukannya akan mengesampingkan kejutan yang tidak menyenangkan bagi pengguna jika konten bergeser saat halaman sedang dimuat.
  • Font web: Mengunduh dan merender font web dapat menyebabkan pergeseran tata letak – misalnya saat font fallback diganti dengan font web kustom. Inilah sebabnya mengapa disarankan untuk memuat font terlebih dahulu. Font web yang digunakan juga dapat disimpan di server Anda sendiri.
  • Tips optimasi lainnya: Pada postingan blog ini Google sendiri memberikan berbagai tips bagaimana cara mengurangi atau mencegah Kumulatif Layout Shift

Alat untuk mengukur Vital Web Inti

Perbedaan antara data lab dan data lapangan adalah data lapangan melihat pengguna nyata, kondisi jaringan, perangkat, caching, dll.

Dan data lab secara konsisten diuji berdasarkan kondisi yang sama dengan harapan hasil pengujian dapat diulang.

Field data

Lab data

Saya suka laporan di GSC karena Anda dapat melihat data untuk banyak halaman sekaligus, tetapi datanya agak tertunda dan rata-rata penggiliran 28 hari sehingga perubahan mungkin memerlukan beberapa waktu untuk muncul di laporan.

Di Chrome 88, Google menambahkan Core Web Vitals langsung di DevTools.

Anda juga dapat menemukan bobot skor untuk Lighthouse kapan saja dan melihat perubahan historisnya.

Kesimpulan

Vital Web Inti Google ditetapkan untuk menjadi metrik inti untuk mengukur pengalaman pengguna.

Core Web Vitals awalnya akan diluncurkan dengan tiga metrik inti untuk memuat (Largest Contentful Paint), interaktivitas situs (Penundaan Input Pertama), dan stabilitas visual (Pergeseran Tata Letak Kumulatif).

Terlebih lagi, Core Web Vitals akan digabungkan dengan faktor peringkat yang ada seperti keramahan seluler atau HTTPS untuk menghadirkan faktor peringkat Google yang sepenuhnya baru: Pengalaman Halaman!

Untuk transparansi yang lebih besar pada Core Web Vitals, Google telah mengeluarkan semua dan menerbitkan dokumentasi mendalam yang memberi webmaster, pengembang, dan SEO semua informasi yang mereka butuhkan untuk sepenuhnya memahami bagaimana kriteria individu ditetapkan, elemen apa yang penting, dan, banyak lagi yang terpenting, bagaimana situs web sekarang dapat dioptimalkan untuk Core Web Vitals baru.

Jika Anda belum melakukannya, sebaiknya gunakan Search Console untuk menjalankan pemeriksaan yang sesuai pada proyek web Anda sendiri untuk melihat bagaimana kinerjanya di bagian depan Core Web Vitals.

Mayoritas situs web memiliki ruang untuk perbaikan – dan Google telah memberi kami alat yang sangat kami butuhkan untuk melakukan hal itu!

Dipersenjatai dengan dokumentasi mendalam Google dan tips pengoptimalan untuk Core Web Vitals yang digabungkan dengan alat analisis seperti Lighthouse,

Anda dapat memanfaatkan waktu semaksimal mungkin sambil menunggu faktor peringkat Pengalaman Halaman yang baru diluncurkan.

Anda ingin meningkatkan Core Web Vitals sehingga pengguna Anda memiliki pengalaman yang lebih baik.

Masih harus dilihat apa dampaknya bagi SEO, tetapi seperti yang saya sebutkan di artikel kecepatan halaman saya, mereka akan membantu Anda mencatat lebih banyak data di analytics Anda yang “terasa” seperti peningkatan.

Bekerja dengan pengembang Anda untuk optimasi kecepatan web ; mereka adalah ahlinya di sini.

Kecepatan halaman bisa sangat rumit. Jika Anda sendirian, Anda mungkin perlu mengandalkan plugin atau layanan untuk menangani ini seperti WP Rocket atau NitroPack.

Cuplikan Video Google Chrome Developers tentang Core Web Vital

 

Demikian artikel Tips SEO tentang 3 Faktor Penting SEO Core Web VitalPortal SEO Online : Forum Portal Tips Tutorial SEO Online Terlengkap dan Terupdate

[wpcd_coupon id=5816]
[wpcd_coupon id=5814]
[wpcd_coupon id=5812]

Tags:  , , , , , ,