Pembaruan Google Mei 2021: lihat lebih dekat Core Web Vitals

PEMBARUAN: Dunia pemasaran digital terus berubah, tetapi jangan khawatir, kami ada di atasnya. Google telah berubah pikiran tentang algoritma yang akan datang.

Baca perubahan terbaru di sini di pembaruan kami, tetapi jangan ragu untuk membaca blog ini juga.

Pada Mei 2021, Google akan memperkenalkan metrik Core Web Vitals (CWV) untuk menjadi bagian dari algoritme peringkat pencarian mereka. Inilah yang perlu Anda ketahui, dan lakukan sebelum itu…

Kita semua tahu situs cepat itu penting. Mereka menciptakan pengalaman pengguna yang lebih baik, menghasilkan peningkatan rasio konversi dan sudah memperhitungkan peringkat penelusuran seluler di Google bersama dengan metrik pengalaman laman lainnya seperti kesesuaian untuk seluler.

Tapi Google tidak berhenti di situ. Kembali pada Mei 2020, mereka memberi tahu kami tentang Data Web Inti dan pada 10 November 2020, mereka mengumumkan bahwa pada Mei 2021, Data Web Inti akan dimasukkan sebagai sinyal pencarian dalam algoritme peringkat keseluruhan.

Selain itu, mereka berencana untuk "menguji indikator visual yang menyoroti halaman dalam hasil pencarian yang memiliki pengalaman halaman yang luar biasa." Jadi kami tidak hanya memiliki peluang peningkatan peringkat yang lebih tinggi melalui pengoptimalan CWV, tetapi kami juga memiliki prospek peningkatan rasio klik-tayang dari halaman hasil mesin pencari.

Bertindak sekarang untuk mengaudit dan memperbaiki potensi masalah yang ditandai dengan metrik CWV baru ini akan memberi situs kami peluang yang lebih baik untuk mendapatkan peringkat Google yang lebih tinggi saat perubahan ini mulai berlaku pada tahun 2021.

Tapi pertama-tama, rekap…

Rekap: apa itu Core Web Vitals?

Data Web Inti adalah kumpulan 3 metrik pengalaman halaman baru yang masuk ke skor kecepatan situs secara keseluruhan. Metrik ini telah mengambil peran penting dalam alat Google PageSpeed ​​Insights PSI dan pemantauan Kinerja Lighthouse di tempat lain.

Metrik CWV baru terdiri dari berikut ini:

Cat Contentful Terbesar (LCP)

Ini adalah waktu yang dibutuhkan sebelum elemen paruh atas terbesar diberikan kepada pengguna. Ini menyumbang 25% dari mekanisme skor kecepatan keseluruhan dan oleh karena itu sangat penting untuk merampingkan pengiriman item terbesar menjadi 2,5 detik atau lebih rendah di ponsel.

Banyak faktor yang berkontribusi pada LCP yang tinggi termasuk responsivitas server, skrip dan gaya pemblokiran render, kompleksitas CSS, font, dan gambar

Penundaan Input Pertama (FID)

Ini mengukur interaktivitas; seberapa responsif halaman terhadap input pengguna misalnya melalui ketukan atau klik. Kecepatan target saat browser merespons input pertama harus 100 md atau kurang.

Jika browser mengurai atau mengeksekusi banyak JavaScript selama pemuatan halaman, ini akan mengikat CPU atau memblokir 'Utas Utama', menyebabkan perangkat menjadi kurang responsif terhadap input. FID tinggi biasanya merupakan indikator JavaScript yang kompleks. Ini bisa berupa satu skrip atau fungsi atau banyak skrip.

Metrik PSI yang ada untuk Time to Interactivity dan Total Blocking Time terkait dengan FID, dan secara kolektif menyumbang 35% dari skor kecepatan keseluruhan.

Pergeseran Tata Letak Kumulatif (CLS)

Ini adalah ukuran stabilitas visual dari konten paruh atas. Meskipun hanya terdiri dari 5% dari skor kecepatan keseluruhan, itu masih layak dipertimbangkan dalam gambaran keseluruhan. CLS yang tinggi sering kali dapat menunjukkan satu atau beberapa perubahan dalam tata letak visual selama pemuatan halaman, misalnya saat spanduk dimuat, menggeser konten halaman ke bawah.

Rincian skor kecepatan

Diagram di bawah menunjukkan rincian skor kecepatan keseluruhan dan seberapa besar peran metrik CWV baru ini dalam skor GPSI.

Sumber data dari pembaruan skor Lighthouse

Sementara metrik non CWV juga membentuk skor keseluruhan termasuk First Content Paint (FCP), Time to Interactive (TTI) dan Total Blocking Time (TBT), fokus pada tiga metrik CWV akan berdampak langsung pada metrik lainnya. Sebuah LCP cepat tidak mungkin misalnya tanpa FCP cepat dan skor FID tinggi secara langsung dipengaruhi oleh TBT dan TTI.

Kiat untuk optimasi Cat Contentful Terbesar

Metrik LCP terdiri dari banyak faktor individual dan dipengaruhi langsung oleh FCP yang tinggi. Jika FCP ditandai sebagai buruk, Anda mungkin ingin memulai dari sini. Apa pun dari konektivitas jaringan, respons server, Time To First Byte TTFB, dan file yang memblokir render semuanya akan memengaruhi nilai FCP. Untuk menyelam lebih dalam ke beberapa rekomendasi kecepatan halaman yang lebih umum ini, lihat eBuku kecepatan halaman kami tentang subjek selain tip khusus LCP di bawah ini.

Jika nilai LCP jauh lebih tinggi dari FCP, maka kita perlu melihat bagaimana kita bisa lebih merampingkan tampilan elemen terbesar ini.

Tentukan elemen terbesar

Hal pertama yang mungkin ingin Anda lakukan adalah menentukan elemen terbesarnya. Elemen terbesar didasarkan pada area piksel yang dapat berubah pada titik henti sementara yang berbeda, sehingga pemindaian visual mungkin tidak selalu mengidentifikasi elemen yang tepat.

Di PSI, seharusnya ada panel 'Elemen Cat Konten Terbesar' di bagian Diagnostik. Atau, Anda dapat melihat LCP dengan mengarahkan kursor ke indikator di alat Pemantauan Kinerja Chrome seperti yang ditunjukkan di bawah ini.

Di situs Hallam pada contoh di atas, Performance Monitor menunjukkan LCP sebagai heading utama 'Thrive Online'. Idealnya, LCP harus segera mengikuti FCP seperti pada contoh ini dan jika ada celah di antara keduanya, kita perlu mencoba dan memahami alasannya.

Apakah font dioptimalkan?

Jika elemen lipatan atas terbesar adalah tipografi, maka kita perlu memastikan pengiriman font sesederhana mungkin. Ini termasuk:

1. Gunakan tampilan font CSS: swap; untuk memastikan tampilan font segera saat file font sedang dimuat. Baik Google Fonts dan Adobe's Typekit memiliki kemampuan untuk mengatur parameter 'tampilan' font.
2. Coba hosting file font .woff dan .woff2 secara lokal di server alih-alih membuat permintaan lintas domain ke font pihak ketiga. Google Fonts cukup cepat, font Typekit lebih lambat dan beberapa pengecoran font pihak ketiga bisa kurang dapat diandalkan.
3. Memuat file font dapat membantu. Font yang dihosting secara lokal akan sering disertakan dalam lembar gaya utama situs web, tetapi lembar gaya ini harus diunduh dan diuraikan sebelum permintaan tambahan dibuat untuk font di dalamnya. Pramuat memberi tahu browser untuk mulai mengunduh font lebih cepat, tanpa menunggu CSS diurai.
4. Gunakan preconnect dan dns-prefetch untuk pengecoran font pihak ketiga. Arahan ini akan membantu membangun koneksi DNS, TLS, dan TCP antara domain pihak ketiga sebelum permintaan dibuat ke font.
5. Hanya sertakan file font untuk tipografi yang diperlukan untuk tampilan lipat di atas. Aset font untuk pustaka ikon seperti Font Awesome terkenal berat tetapi permintaan untuk ini (dan CSS pustaka ikon yang sesuai) biasanya dapat ditangguhkan dan dimuat setelah elemen <head>.
6. Jangan membuat permintaan lintas domain ke file font dalam lembar gaya situs utama karena ini bergantung pada konektivitas dan pencarian tambahan dari domain pihak ketiga.
7. Pertimbangkan font yang aman untuk web. Ini tidak memerlukan permintaan apa pun ke file font, meskipun bisa sangat terbatas dalam hal estetika.

Apakah gambar dioptimalkan?

Cukup sering, elemen lipatan atas terbesar akan menjadi gambar yang sangat penting untuk memastikan gambar dioptimalkan. Berikut ini adalah praktik yang baik secara umum tetapi sangat penting untuk elemen LCP.

1. Gunakan jenis file gambar yang benar. Gambar JPG harus digunakan untuk foto, SVG untuk grafik vektor dan ikon atau PNG untuk gambar non-fotografi yang lebih kompleks dan jika diperlukan transparansi.
2. Pastikan gambar JPG disimpan atau menghasilkan kualitas sekitar 50-60%. Pada tingkat ini, seharusnya tidak ada penurunan kualitas yang terlihat. Juga, pastikan gambar memiliki metadata yang dilucuti darinya.
3. Plugin atau layanan kompresi seperti tinypng.com dapat secara otomatis dan massal mengoptimalkan gambar dan menghapus data meta yang tidak perlu.
4. Gambar harus berukuran tepat untuk area tempat gambar ditampilkan. Jangan menampilkan gambar desktop berkualitas tinggi di perangkat seluler.
5. Gambar harus dikeluarkan menggunakan tag <img> standar dengan atribut 'srcset' untuk gambar responsif.
6. Gambar paruh bawah atau di luar layar harus menggunakan atribut loading="lazy".
7. Gunakan format file gambar .web generasi berikutnya untuk tingkat kompresi yang lebih baik. Ini dapat dengan mudah menghemat 30% dan dalam banyak kasus jauh lebih tinggi.
8. Pertimbangkan untuk memuat gambar paro atas terbesar untuk memulai pengunduhan lebih cepat daripada konten lain yang berpotensi kurang penting.

Kurangi file yang memblokir render

File JavaScript atau CSS apa pun yang dimuat di elemen <head></head> dianggap sebagai pemblokiran render karena file ini perlu diunduh sebelum halaman dapat mulai dirender. Ini dapat berdampak besar pada metrik FCP dan LCP. Render memblokir file di kepala hanya boleh digunakan jika sangat penting untuk tampilan awal di atas flip pada halaman.

Menghapus file yang tidak digunakan di <head>, memuat file yang tidak penting di footer, atau menggabungkan beberapa file menjadi lebih sedikit file akan mengurangi jumlah aset yang memblokir render.

Jangan gunakan JavaScript untuk menampilkan LCP

Sebelum CWV, ini bukan masalah besar. Biasanya JavaScript digunakan untuk menganimasikan atau menampilkan elemen paruh atas seperti teks yang memudar atau carousel pahlawan, seringkali dengan sedikit atau tanpa dampak pada skor kecepatan.

Jika tampilan elemen terbesar bergantung pada JavaScript, ini sering kali dapat menyebabkan penundaan yang lama karena JavaScript harus diunduh, diuraikan, dan dieksekusi sebelum elemen muncul. File JavaScript biasanya (dan cukup tepat) dimuat setelah elemen <head> sehingga tidak 'memblokir render', tetapi ini berarti mereka masih dapat memblokir render LCP secara efektif.

Lihatlah contoh di bawah ini (logo kabur dan judul diubah) ini berasal dari situs dengan skor tinggi di PSI. LCP (teks judul utama) beberapa detik lebih jauh dari FCP yang disebabkan oleh persyaratan JavaScript (diwakili oleh pita kuning) untuk mengunduh, mengurai, dan mengeksekusi sebelum teks dapat memudar.

Teks memudar itu sendiri juga bisa menjadi masalah, menyebabkan tampilan elemen terbesar tertunda.

Teknik JavaScript seperti ini dapat segera mengurangi skor kecepatan keseluruhan sebesar 25% dan tidak boleh digunakan untuk menghalangi atau mencegah pemuatan elemen terbesar dengan cara apa pun.

Jalankan Script di Window Load

JavaScript jarang diperlukan (dan seharusnya tidak diperlukan) untuk menampilkan konten penting di paro atas, namun masalah umum yang kami lihat adalah bahwa fungsi dapat dipicu segera setelah DOM siap. Dalam kerangka kerja jQuery yang populer, ini dilakukan melalui acara 'siap'. Google Pengelola Tag juga dapat memicu fungsi atau 'tag' pada siap.

Pertimbangkan untuk memicu semua JavaScript yang tidak diperlukan untuk tampilan kritis konten pada peristiwa pemuatan jendela, setelah konten halaman utama dimuat untuk mencegah potensi gangguan apa pun dengan rendering konten paruh atas dan elemen LCP.

Nyalakan LCP

Tidak peduli seberapa baik dioptimalkan dan disederhanakan gambar, hampir selalu dibutuhkan waktu lebih lama untuk mengunduh dan menampilkan vs elemen tipografi. Meskipun sangat mungkin untuk mencapai skor LCP yang cepat untuk gambar, terkadang tweak untuk mengurangi elemen gambar terbesar sehingga lebih kecil dari elemen teks terbesar akan berarti teks dapat digunakan untuk LCP.

Ini dapat membuat perbedaan besar pada skor, jika desain memungkinkan, seperti yang ditunjukkan pada contoh di bawah ini di mana LCP telah dialihkan ke elemen teks.

Kiat untuk pengoptimalan Penundaan Input Pertama

Seperti yang telah kami sebutkan sebelumnya, FID mengukur seberapa responsif halaman terhadap input pengguna. Ini menggabungkan Time To Interactive TTI dan Total Blocking Time TBT yang dapat mencapai hingga 35% dari skor kecepatan keseluruhan.

Metrik ini terutama dipengaruhi oleh penguraian dan eksekusi skrip saat halaman sedang dimuat; memblokir utas utama CPU dan berpotensi memengaruhi respons perangkat, terutama untuk perangkat smartphone kelas bawah.

Penting untuk dicatat bahwa 'Data Lab' yang ditampilkan di PSI tidak mengukur FID secara langsung. Hal ini disebabkan sifat interaktif pengukuran dari ketukan atau klik oleh pengguna yang sulit untuk disimulasikan. Sebaliknya, dikumpulkan oleh 'Data Lapangan'; pengukuran yang dikumpulkan dari pengguna sebenarnya selama periode 28 hari berdasarkan Laporan Pengalaman Pengguna Chrome CrUX.

Dengan demikian, mengoptimalkan FID secara langsung sedikit lebih sulit, karena kami tidak dapat mengubah sesuatu dan menunggu 28 hari untuk mengumpulkan lebih banyak data. Oleh karena itu, kami harus menggunakan metrik TTI dan TBT di Data Lab untuk ini, karena waktu yang rendah untuk metrik ini akan berkorelasi dengan FID yang rendah.

Jadi, bagaimana kita mengoptimalkan metrik ini?

Audit JavaScript Anda

JavaScript dapat datang dalam berbagai bentuk dan ukuran dan tidak jarang satu penyematan video, widget obrolan, skrip ReCaptcha, atau integrasi HubSpot menjadi satu-satunya penyebab di balik metrik FID, TTI, dan TBT yang tinggi.

Panel diagnostik di Page Speed ​​Insights adalah tempat yang baik untuk memulai. Bagian untuk 'Minimalkan pekerjaan utas utama' akan memberi tahu Anda berapa banyak waktu eksekusi yang diambil oleh JavaScript, bagian 'Kurangi waktu eksekusi JavaScript' akan menunjukkan file mana yang memiliki waktu penguraian dan eksekusi tinggi dan 'Kurangi dampak pihak ketiga code' akan menyorot dan mengelompokkan skrip pihak ketiga yang berdampak tinggi.

Tangkapan layar di bawah ini menunjukkan situs yang mengalami beberapa skrip berat, dengan metrik Waktu untuk Interaktif 15 detik. Banyak skrip berasal dari pihak ketiga termasuk HubSpot dan Vimeo.

Untuk analisis dan visualisasi yang lebih dalam tentang bagaimana skrip ini memengaruhi pemuatan halaman, alat Monitor Kinerja Chrome dapat menjadi cara yang bagus untuk menelusuri skrip dan fungsi apa yang diaktifkan, dampak relatif skrip ini, dan pada titik mana halaman memuat ini skrip panjang sedang dieksekusi.

Contoh di bawah ini berasal dari situs yang sama dan menampilkan JavaScript yang diwakili oleh bilah kuning, merah muda, dan oranye, dengan bilah yang lebih panjang menunjukkan tugas yang dieksekusi lebih lama. Saat kita mengklik tugas yang lebih panjang ini, kita dapat melihat skrip yang disorot berkorelasi dengan skrip besar yang disorot oleh PSI di atas.

Setelah kami memiliki gambaran yang lebih baik tentang skrip apa yang memengaruhi kinerja, ada beberapa teknik yang dapat kami gunakan untuk meminimalkan dampaknya seperti yang diuraikan di bawah ini.

Muat Skrip secara tidak sinkron

JavaScript secara default akan dijalankan secara berurutan. Jika ada skrip yang tidak bergantung pada pemuatan skrip lain, skrip ini harus dimuat dengan atribut 'async' sehingga tidak memblokir penguraian dan eksekusi skrip lain.

Muat JavaScript secara kondisional

Masalah umum yang kita lihat di banyak situs adalah bahwa skrip berat dimuat secara global atau di halaman saat tidak diperlukan. Jika Anda perlu menggunakan ReCaptcha, misalnya, untuk membantu menghentikan spam pada pengiriman formulir, pastikan untuk hanya memuat skrip pada halaman yang memiliki formulir.

Merampingkan bundel JavaScript

Pustaka JavaScript seperti UI jQuery atau Bootstrap sering digunakan untuk menyediakan fitur dan fungsi JavaScript tambahan. Jika menggunakan bundel, pastikan untuk hanya menyertakan fitur yang relevan di dalam bundel untuk menyimpan JavaScript yang tidak perlu diunduh dan diuraikan.

Lazy memuat skrip saat dibutuhkan

Bahkan jika JavaScript hanya dimuat pada halaman yang diperlukan, skrip itu sendiri tidak perlu menguraikan dan mengeksekusi selama pemuatan halaman atau acara pemuatan jendela. Memuat JavaScript hanya ketika benar-benar dibutuhkan dapat membuat perbedaan besar pada metrik TTI, TBT, dan FID. Berikut beberapa contohnya:

1. Penyematan video seperti YouTube dan Vimeo biasanya berdampak tinggi. Pertimbangkan untuk hanya memuat skrip ini saat mengeklik gambar mini video.
2. Integrasi formulir pihak ketiga seperti HubSpot bisa intensif. Jika formulir muncul di modal, atau di bagian bawah halaman, pertimbangkan untuk memuat atau menyuntikkan skrip yang diperlukan pada gulir atau aktivasi modal alih-alih memuat halaman.
3. Widget obrolan langsung dapat memengaruhi skor kecepatan keseluruhan hingga 35%. Pertimbangkan untuk memindahkan widget obrolan langsung ke halaman kontak khusus yang mendukung CTA 'obrolan langsung' global, atau memasukkan skrip obrolan langsung hanya ketika tombol 'obrolan dengan kami' diklik.
4. Menambahkan atribut 'loading=”lazy” pada konten berbasis iFrame yang disematkan dapat membantu, tetapi ini adalah fitur browser baru dan akan memerlukan pengujian tergantung pada embed iFrame yang digunakan.

Menilai alat intelijen bisnis

Menganalisis perilaku pengguna dengan alat seperti Hotjar atau perangkat lunak Pengujian A/B seperti VWO sangat penting untuk intelijen bisnis dan dalam banyak kasus, manfaatnya akan lebih besar daripada dampaknya pada kecepatan situs.

Karena itu, masih ada baiknya mengevaluasi pentingnya menjalankan alat-alat ini 24/7 tergantung pada seberapa sering data dianalisis. Pengujian A/B harus dimatikan jika tidak ada pengujian aktif yang berjalan misalnya dan alat analisis perilaku seperti Hotjar dapat dinonaktifkan setelah cukup banyak data dikumpulkan dan diproses.

Kiat untuk optimasi Pergeseran Tata Letak Kumulatif

Pergeseran Tata Letak Kumulatif (CLS) mungkin hanya menyumbang 5% dari skor kecepatan keseluruhan, tetapi tetap saja, bagian penting dari gambaran keseluruhan terutama karena jumlah elemen pergeseran yang tinggi pada pemuatan halaman dapat menjadi pengalaman yang menggelegar bagi pengguna.

Tentukan elemen CLS

Terkadang tampak jelas elemen atau elemen apa yang menyebabkan perubahan konten, tetapi selalu layak untuk memverifikasi ini melalui panel Layout Shift di PSI seperti yang ditunjukkan di bawah ini.

Metrik CLS harus di bawah 0,1, tetapi dalam contoh di atas, ini melebihi lebih dari 400% dan akan mengakibatkan penurunan skor sebesar 5%. Jika ini adalah masalah global, itu 5% di setiap halaman.

Pergeseran elemen harus diidentifikasi dan ditangani dalam urutan dampak dan dapat mencakup elemen di atas dan di bawah flip. Kami telah menyoroti beberapa penyebab dan resolusi paling umum dari pergeseran tata letak di bawah ini.

Hati-hati dengan animasi

Ini cukup umum untuk teknik animasi tertentu yang digunakan untuk mengubah cara konten disajikan kepada pengguna misalnya dengan memudar atau menggeser gambar, teks atau panel konten saat pengguna menggulir halaman ke bawah. Meskipun ini mungkin secara estetis menyenangkan (tergantung pada siapa Anda bertanya), penting bahwa teknik ini tidak mengubah konten apa pun selama pemuatan halaman.

Jika Anda harus menyembunyikan dan kemudian memudarkan konten ke pengguna, pastikan ukuran wadah atau tinggi halaman total tidak berubah saat konten dimuat. Konten dapat disembunyikan (jika perlu) menggunakan aturan visibilitas CSS daripada display: none; yang akan mempertahankan jumlah ruang yang dibutuhkannya.

Tentukan dimensi gambar

Jika tag <img> tidak memiliki atribut lebar dan tinggi yang disetel, atau CSS tidak digunakan untuk mengatur dimensi atau rasio gambar, browser perlu mengunduh gambar terlebih dahulu sebelum dapat menentukan area piksel yang diperlukan. tampilan masuk. Ini dapat menyebabkan pergeseran konten apa pun yang dirender di bawah gambar, saat gambar dimuat.

Menentukan lebar dan tinggi gambar, atau mengatur dimensi atau rasio gambar (atau wadah induk) dalam CSS sebelum gambar diunduh akan memastikan browser akan mengetahui area di mana gambar perlu ditampilkan dan menghindari kemungkinan tata letak bergeser.

Spanduk

Iklan, bilah undang-undang cookie, atau informasi lain apa pun yang digunakan untuk menampilkan informasi penting dalam spanduk mungkin merupakan salah satu penyebab paling umum dari CLS yang tinggi.

Biasanya konten spanduk dimuat dari sumber data eksternal, atau melalui JavaScript dari situs yang sama yang berarti ukuran wadah spanduk mungkin tidak dapat dihitung hingga konten dimuat. Ketika ini terjadi, konten di bawah spanduk akan bergeser ke bawah setelah konten spanduk dimuat dan ditampilkan kepada pengguna.

Ada beberapa resolusi untuk ini:

1. Tetapkan tinggi minimum untuk spanduk atau wadah spanduk di CSS sehingga browser dapat merender placeholder secara efektif. Padahal ini bisa menjadi masalah jika jumlah kontennya dinamis dan tidak diketahui.
2. Benar-benar atau perbaiki posisi spanduk di bagian atas atau bawah layar. Untuk spanduk yang dapat ditutup atau ditutup, ini merupakan pertimbangan yang baik karena elemen tetap tidak akan mempengaruhi posisi elemen lainnya.
3. Lihatlah rendering sisi server dari konten spanduk jika memungkinkan yang berarti konten dan dimensi spanduk dapat dimuat di muka sebelum mencapai pengguna.

Ringkasan

Semoga, Anda akan menemukan beberapa teknik yang disorot di atas berguna dalam mendiagnosis dan memecahkan masalah kinerja seputar Data Web Inti Google yang baru. Selama beberapa bulan terakhir di Hallam, kami telah membantu sejumlah klien meningkatkan kinerja situs web mereka baik dalam hal audit kecepatan kami dan peningkatan langsung yang dilakukan oleh tim pengembangan kami.

Jika Anda merasa artikel ini bermanfaat, Anda mungkin juga ingin melihat eBuku kinerja situs web kami yang membahas lebih dalam beberapa rekomendasi umum seputar kecepatan halaman yang dapat dimanfaatkan oleh siapa pun yang membangun atau mengelola situs web.