Taktik pertumbuhan penerbit untuk musim pilihan raya | WEBINAR
Taktik pertumbuhan penerbit untuk musim pilihan raya | WEBINAR
Pada penghujung modul ini, anda harus mempunyai pemahaman yang jelas tentang pelbagai komponen yang menyumbang kepada Pengalaman Halaman, mengapa ia penting dan cara setiap satu boleh dioptimumkan untuk meningkatkan pengalaman pengguna tapak anda dan SEOnya.
Tempoh Video
17:09
Jawab Kuiz
Ambil Kuiz Modul Semasa
Bahan
Templat sedia untuk digunakan
Sumber
Laporan dan Sumber
2.3.1 Apakah Itu Pengalaman Halaman?
Pengalaman halaman ialah satu set isyarat — termasuk Core Web Vitals (CWVs), kemesraan mudah alih, HTTPS dan garis panduan interstisial yang mengganggu — yang Google gunakan untuk mengekstrapolasi pengalaman pengguna di tapak web.
Pengalaman halaman ialah penilaian prestasi tapak dan bukannya kandungannya. Walaupun Google masih mengutamakan perkaitan kandungan semasa menjawab pertanyaan pengguna, pengalaman halaman secara berkesan adalah pemutus seri apabila beberapa tapak menawarkan tahap liputan yang serupa.
Isyarat pengalaman empat halaman ialah:
CWV mengukur pengalaman pengguna dengan memfokuskan pada seberapa cepat halaman dimuatkan, responsifnya terhadap input pengguna dan juga kestabilan visualnya. Terdapat tiga metrik untuk ini:
Kemas kini Google April 2015 memperkenalkan metrik mesra mudah alih carian, yang meningkatkan kedudukan halaman mesra mudah alih di SERP mudah alih.
Secara berkesan, Google akan mengutamakan laman web yang memastikan kandungannya mudah dibaca pada peranti mudah alih - yang bermaksud tidak perlu mengezum, sasaran sentuhan seperti butang log masuk tidak terlalu dekat antara satu sama lain, tidak ada tatal mendatar dan kandungan yang tidak dapat dimainkan dielakkan.
Kemas kini digunakan untuk halaman individu, bukan keseluruhan laman web, dan juga tidak mempengaruhi kandungan yang dilihat pada penyemak imbas desktop/komputer riba.
HTTPS, atau Protokol Pemindahan Hypertext Secure, adalah versi selamat dari protokol komunikasi internet HTTP.
HTTPS, atau HTTP, membentuk bahagian pertama setiap URL yang dikenali sebagai "skema". Ini datang sebelum nama domain, yang merupakan segmen URL yang dikenali sebagai "kuasa".
Perbezaan antara HTTPS dan HTTP ialah bekas yang selamat manakala yang terakhir tidak. Apa ini bermakna dalam amalan ialah pengguna yang masuk ke tapak melalui sambungan HTTP menghantar butiran peribadi mereka dalam teks biasa yang tidak disulitkan.
HTTPS menjamin sambungan itu, yang bermaksud sebarang data yang dihantar antara penyemak imbas pengguna dan pelayan laman web disulitkan di sepanjang jalan. Tapak yang menginginkan sambungan selamat memerlukan sijil SSL, yang mana penyemak imbas pengguna dan mengesahkan.
Interstitial adalah format iklan mudah alih yang hanya muncul dalam rehat semulajadi dalam kandungan - seperti ketika pengguna bergerak dari satu artikel ke seterusnya - meliputi skrin dalam proses.
Interstitial dilihat sebagai mengganggu apabila mereka menyekat atau sebahagiannya mengaburkan pandangan pengguna mengenai kandungan. Kotak dialog di laman web mudah alih yang berkelakuan sama juga berada di bawah kategori ini.
Kebanyakan set kemahiran terkuat penerbit cenderung menjadi penciptaan kandungan, penerbitan dan pemasaran, meninggalkan sedikit ruang untuk memahami dan mengoptimumkan pelbagai tiang pengalaman halaman.
Sumber terhingga bermakna penerbit akan berjuang untuk membenarkan masa dan wang yang diperlukan untuk menggali ke belakang laman web individu, apalagi seluruh laman web.
Walaupun penerbit dapat menumpukan masa untuk menangani masalah ini, seperti yang dapat kita lihat dari atas, pengalaman halaman adalah isu yang pelbagai yang memerlukan pendekatan holistik untuk memberikan keuntungan prestasi yang bermakna.
Mengetahui yang mana dari empat isyarat pengalaman untuk mula bekerja boleh menjadi sakit kepala dalam dan dari dirinya sendiri.
Pengalaman halaman sangat penting untuk penerbit SEO, kerana kandungan yang hebat tidak mencukupi untuk menjamin penempatan teratas dalam SERPS.
Google masih menghargai maklumat terbaik sebelum apa -apa lagi, yang bermaksud kandungan unik atau berita "sudu" akan berfungsi dengan baik walaupun pengalaman halaman adalah "subpar" . Walau bagaimanapun, dalam kes -kes di mana beberapa penerbit menyediakan liputan topikal yang sangat baik, pengalaman halaman menjadi faktor penentu penting yang mempengaruhi kedudukan SERP.
Setiap satu daripada empat tiang pengalaman mempunyai kesan yang berbeza pada SEO laman web. Kesan yang paling segera datang dari memberi tumpuan kepada CWV, yang akan diterjemahkan ke dalam laman web yang lebih cepat.
Banyak kajian telah menunjukkan bahawa lebih lama laman web mengambil untuk memuatkan, semakin cepat penonton kehilangan minat dan semakin tinggi kadar lantunan menjadi.
Sebagai contoh, kajian Google dari 2018 mendapati bahawa kebarangkalian melantun melonjak 32% apabila masa beban halaman naik dari 1 saat hingga 3 saat.
Satu lagi kajian Google dari 2020 mendapati bahawa laman berita yang lulus ujian CWV menyaksikan kadar pengabaian 22% lebih rendah daripada yang gagal. Yahoo! Sementara itu, Jepun meningkatkan skor CLSnya sebanyak 0.2 dan menyaksikan 15.1% uptick dalam paparan halaman setiap sesi dan kenaikan 13.3% dalam tempoh sesi.
Walaupun Google telah menyatakan dengan jelas bahawa ia tidak menggunakan kadar lantunan sebagai isyarat ranking , kadar lantunan yang tinggi bercakap kepada faktor Google yang peduli - iaitu kelajuan beban halaman, responsif dan kestabilan visual.
Penerbit yang mensasarkan penonton pada peranti mudah alih perlu memastikan laman web mereka menghantar isyarat mesra mudah alih yang kedua -dua Google dan Bing boleh mengambil. Kedua -dua enjin carian akan mengutamakan laman web yang mesra apabila menyampaikan hasil carian kepada pengguna mudah alih.
Berbanding dengan CWV dan keramahan mudah alih, melaksanakan HTTPS akan memberi impak yang lebih kecil kepada SEO penerbit. Google berkata pada tahun 2014 bahawa ia akan menggunakannya sebagai isyarat ranking dan mula menandakan semua tapak HTTP sebagai "tidak selamat" di Chrome pada tahun 2018. Walau bagaimanapun, manfaat terbesar di sini adalah keselamatan data yang dipertingkatkan, terutamanya jika modul perniagaan anda didasarkan pada pendapatan langganan.
Sementara itu, iklan interstisial atau kotak dialog, boleh mengehadkan keupayaan merangkak web untuk merangkak dan mengindeks halaman, menghalang enjin carian dari bahkan dapat menarafkannya, meninggalkan sahaja yang memaparkan hasil carian yang tinggi ..
Langkah pertama ke arah meningkatkan pengalaman halaman bermula dengan menilai keberkesanan semasa laman web anda.
Terdapat pelbagai alat pihak pertama dan ketiga untuk mencapai ini tetapi, untuk panduan ini, kami akan melihat alat pihak pertama Google.
Sekarang kita tahu bahawa CWV adalah faktor ranking yang penting. Tetapi bagaimana mereka diukur? Jadual di bawah menyenaraikan parameter di mana nombor CWV yang optimum harus jatuh untuk pengalaman halaman terbaik.
Sekarang kita tahu apa yang kita perlukan untuk mengukur dan dengan berapa banyak, kita dapat melihat bagaimana untuk mengukur pengalaman halaman.
Berikut adalah senarai beberapa kaedah yang paling biasa digunakan.
Pilihan pertama yang dibuka kepada penerbit adalah yang paling mencabar secara teknikal dan bukan satu yang kami cadangkan walaupun mempertimbangkan melainkan jika anda mempunyai pemaju yang baik untuk membantu pelaksanaannya.
Kami bercakap tentang mengumpulkan data pengguna dari laman web anda, satu proses yang dikenali sebagai Pemantauan Pengguna Sebenar (RUM), dan kemudian menganalisis hasil dalam Google Analytics 4 (GA4). Google mempunyai alat lain, seperti PageSpeed Insights (PSI), yang menggunakan pensampelan data untuk menilai laman web anda. Tetapi jika matlamatnya adalah untuk mempunyai gambar pengalaman pengguna yang lengkap untuk laman web anda, maka anda memerlukan data dunia nyata yang dikumpulkan dari laman web anda.
Kami menasihatkan menggunakan GA4 untuk tugas ini untuk alasan mudah bahawa Google berhasrat untuk memulakan "menunaikan surpet" generasi sebelumnya Google Analytics, Universal Analytics (UA), dari pertengahan 2010.
Sebagai penerbit, anda sepatutnya telah menubuhkan akaun GA4 dengan jangkaan suis. Sekiranya anda tidak mempunyai, sila ikuti panduan Google tentang cara menetapkannya untuk kali pertama atau bagaimana untuk menambahkannya ke laman web yang sudah ada .
Setelah itu dilakukan, langkah seterusnya adalah menghubungkan gudang data BigQuery Google ke GA4 dari Admin Analytics. Menghubungkan BigQuery akan membolehkan anda menanyakan data anda menggunakan SQL. Berikut adalah panduan bagaimana untuk menghubungkan kedua -duanya .
Dengan langkah-langkah tersebut, kami kini boleh menambah perpustakaan Web-Vitals ke laman web anda.
Perpustakaan, yang merupakan perpustakaan JavaScript modular yang sangat kecil untuk pengumpulan data, boleh didapati di GitHub.
Perpustakaan boleh dipasang sama ada dari repositori dalam talian NPM sumber terbuka dengan menjalankan "NPM Pasang Web-Vitals" di terminal arahan anda atau melalui<script> tags on a content distribution network (CDN).
Inilah contoh skrip seperti itu:
Sebaik sahaja perpustakaan Web-Vitals telah dipasang, data pengguna kemudiannya boleh dihantar ke Google Tag Manager (GTM), menggunakan tag templat tersuai Google yang disyorkan yang dibuat dan diselenggarakan oleh Simo Ahava.
Sebaik sahaja tag telah dipasang, metrik CWV dan data atribusi yang berkaitan kemudiannya boleh ke hadapannya ke GA4.
Sebaik sahaja anda telah menyediakan analisis untuk menjejaki data GTM, anda akan dapat melihat data acara di antara muka BigQuery. Data ini kemudiannya boleh dipersoalkan seperti:
Setelah pertanyaan dikembalikan, laporan itu harus kelihatan seperti ini:
Kami benar -benar perlu menekankan bahawa ini adalah penyelesaian pemaju dan, sebenarnya, lebih baik daripada ini. Walau bagaimanapun, mengamalkan penyelesaian ini akan memberi anda bacaan yang paling tepat pada prestasi laman web anda.
Untuk penjelasan yang lebih terperinci mengenai proses ini, lihat panduan Google untuk melihat CWV di GA4 .
Walaupun ini adalah pendekatan yang paling tepat untuk memantau CWV, terdapat pendekatan yang lebih mudah untuk menangani masalah ini.
PSI kurang tepat daripada menggunakan pendekatan GA/RUM, bagaimanapun, ia sering disebut sebagai salah satu alat yang paling penting untuk mengukur CWV - terima kasih kepada kemudahan penggunaan alat.
Walaupun ia hanya boleh menggunakan sampel pengalaman pengguna sebenar yang diambil dari Laporan Pengalaman Pengguna Chrome (Crux) dalam tempoh 28 hari sebelumnya, PSI menyediakan antara muka pengguna yang mudah dan mudah untuk memahami . Ini bermakna menafsirkan data adalah proses yang lebih mudah.
Seperti yang dapat anda lihat dalam contoh kami di bawah, memeriksa tapak Forbes dengan segera menyediakan banyak maklumat ke dalam laman web desktop dan mudah alih penerbit.
PSI menggunakan kategori hijau, ambar dan merah dari atas apabila memberikan kebaikan, memerlukan peningkatan dan gred prestasi yang lemah.
Pendekatan pensampelan Crux bermakna bahawa walaupun penilaian di atas Forbes mengambil beberapa pengalaman pengguna dunia nyata di laman web ini, ia tidak boleh menjadi faktor dalam semua data pengguna tapak.
Pendekatan pensampelan ini menjadi masalah untuk laman web yang lebih kecil, yang kebanyakannya tidak akan dipaparkan dalam data medan Crux.
Walau bagaimanapun, PSI masih boleh menawarkan diagnosis maya laman web anda menggunakan data makmal yang ditarik dari alat rumah api sumber terbuka . Lihat contoh di bawah:
Masalah dengan pendekatan ini ialah Lighthouse mengumpul datanya menggunakan tetapan peranti dan rangkaian yang telah ditetapkan, yang tidak akan mencerminkan tetapan pengguna anda. Ini bermakna ia adalah pengganti miskin untuk perkara sebenar.
GSC adalah alat yang direka untuk menyediakan penerbit dengan pandangan mata burung mengenai isu-isu CWV laman web mereka, membuka pintu kepada pendekatan holistik untuk meningkatkan prestasi tapak.
Ia melakukan ini dengan mengumpulkan laporan prestasi URL berdasarkan status, jenis metrik atau persamaan topikal. Ia tidak mengenal pasti isu -isu dengan halaman individu, menafikan peluang untuk melaksanakan perbaikan pada tahap berbutir.
Di sinilah PSI masuk. Perlu diperhatikan, walaupun, laporan halaman individu PSI mungkin berbeza dengan ketara dari hasil kumpulan GSC. Itu kerana halaman individu hanya satu komponen hasil kumpulan agregat GSC.
Log masuk ke papan pemuka GSC, pengguna akan melihat tab Web Vitals Core di sebelah kiri. Mengklik pada tab ini memaparkan laporan CWV mudah alih dan desktop yang berasingan untuk kumpulan URL.
Walaupun terdapat tiga metrik CWV - LCP, FID dan CLS - URL akan menerima gred keseluruhan berdasarkan metrik prestasi terburuk mereka untuk peranti tertentu yang juga akan mempengaruhi laporan kumpulan.
Sebagai contoh, jika URL di mudah alih menerima FID yang lemah dan LCP yang baik, ia akan dilabelkan sebagai miskin di telefon bimbit.
Sekali lagi, penting untuk diperhatikan bahawa GSC tidak dimaksudkan untuk perbaikan berbutir. Walau bagaimanapun, ia adalah baik untuk penerbit yang mempunyai banyak halaman yang serupa. Sebagai contoh, laman berita mungkin mempunyai reka bentuk dan susun atur yang agak standard untuk halaman artikel mereka yang menggunakan imej sebagai elemen terbesar di atas lipatan. Dalam kes ini, GSC dapat dengan cepat membantu mengenal pasti masalah LCP merentasi pelbagai URL.
Alat akhir dalam Google Prestasi Mengukur Toolkit adalah Lighthouse . Alat ini sama sekali berbeza daripada yang berlaku sebelum ini kerana ia meniru prestasi pengguna berdasarkan set parameter yang ditubuhkan.
Ia tidak menggunakan data medan dan lebih terhad dari segi kegunaan praktikal. Sebagai contoh, data medan dipengaruhi oleh sambungan rangkaian pengguna dan jarak mereka ke pelayan tapak, sedangkan rumah api menunaikan peranti pertengahan untuk mengumpul data dalam persekitaran terkawal.
Ia juga penting untuk memahami bahawa skor Lighthouse bukan sekadar penggabungan skor CWV. Ia tidak termasuk FID, kerana data makmal oleh sifatnya tidak termasuk interaksi pengguna akhir, sambil menambah jumlah masa menyekat (TBT), indeks kelajuan (SI) dan masa untuk metrik interaktif (TTI) ke dalam campuran. Bagi mereka yang ingin mensimulasikan pengalaman FID di makmal, TBT boleh digunakan sebagai proksi.
Walau bagaimanapun, kami akan mengesyorkan terhadap penggunaan Lighthouse sebagai sumber pengukuran utama. Sebaliknya ia harus digunakan sebagai alat pendamping bersama PSI untuk membantu menyelesaikan masalah halaman tertentu.
Penerbit yang ingin menggunakan Lighthouse dalam ujian mereka boleh melakukannya melalui Chrome Devtools yang dibakar terus ke pelayar Chrome, lanjutan untuk penyemak imbas tersebut atau di web.dev/measure .
Mercusuar akan mengaudit laman web anda dan memberikan skor daripada 100 di empat bidang:
Inilah yang kelihatan seperti ketika kami meletakkan laman web kami melalui pilihan Web.dev.
Reka bentuk web mudah alih berbeza dari reka bentuk web desktop tradisional di peranti mudah alih yang mempunyai skrin yang lebih kecil, umumnya sukan perkakasan yang kurang kuat dan bergantung semata -mata pada input sentuhan.
Tapak mesra mudah alih mengutamakan pengalaman pengguna dengan mengikuti satu set amalan terbaik yang akan kami pelajari sedikit kemudian. ujian mesra mudah alih Google .
Memasuki URL laman web mesra mudah alih mengembalikan hasil berikut:
Halaman yang gagal ujian ini akan muncul dengan beberapa pilihan untuk meneruskan. Kami akan masuk ke dalam mereka sedikit kemudian.
Memeriksa sama ada laman web anda mempunyai sambungan selamat adalah proses yang sangat mudah, yang melibatkan pembukaan penyemak imbas anda dan melihat simbol di sebelah kiri URL di bar alamat.
Di Chrome sambungan selamat akan dilambangkan melalui simbol padlock tertutup seperti ini:
Sambungan yang tidak selamat akan mempunyai simbol maklumat seperti itu:
Menentukan sama ada iklan interstisial anda mengganggu atau tidak semudah memasuki laman web anda ke dalam alat dalam talian dan menunggu untuk mengembalikan tanda atau tidak.
Ia memerlukan mengkaji iklan interstisial dan kotak dialog di laman web anda dan memutuskan sama ada mereka lulus parameter tertentu.
Fikirkan parameter ini sebagai soalan, sebagai contoh:
Jika anda menjawab ya kepada mana -mana soalan ini, mungkin penunjuk bahawa kotak iklan atau dialog mengganggu.
Sekarang kita mempunyai pemahaman yang kukuh terhadap komponen yang berbeza dari empat komponen yang dihitung ke arah pengalaman halaman, serta cara untuk memantau prestasi mereka, mari kita teruskan untuk meneroka betapa tepatnya kita dapat meningkatkan isyarat kedudukan laman web kami
Kami akan melihat CWV terlebih dahulu, sebagai debug dan mengoptimumkan LCP, CLS dan FID akan memberi impak terbesar ke atas keupayaan anda untuk bersaing untuk tempat teratas dalam kedudukan SERP yang banyak dipertikaikan.
Walaupun keramahan mudah alih sangat penting untuk laman web yang mensasarkan pengguna mudah alih, meningkatkan CWV akan meningkatkan prestasi halaman untuk tapak tanpa mengira sama ada ia dilihat pada peranti mudah alih atau desktop.
Menangani HTTPS dan interstitial yang mengganggu telah ditinggalkan hingga akhir kerana mereka lebih mudah dan kurang bermanfaat.
Terdapat beberapa pilihan ketika meningkatkan prestasi CWV, yang telah kita rosak ke dalam urutan kepentingan yang kita percaya mereka merit.
Mengoptimumkan vital web teras mana -mana halaman adalah spektrum tindakan dan penting untuk mengetahui di mana untuk mula memaksimumkan sumber anda.
Seperti yang telah kita nyatakan di atas, cat kandungan terbesar (LCP) mengukur berapa lama masa yang diperlukan untuk memuatkan sepenuhnya teks atau aset imej terbesar yang dapat dilihat di atas lipatan.
Gunakan PSI untuk mengenal pasti kandungan halaman mana yang mencetuskan ujian LCP, dengan menuju ke bahagian diagnosis laporan dan mengklik pada "Elemen Cat Kandungan Terbesar". Inilah yang kita lihat dari laman utama SODP:
Skor LCP yang miskin biasanya boleh dikurangkan ke masa tindak balas pelayan yang perlahan, membuat JavaScript dan CSS menyekat, masa beban sumber atau penyampaian klien, atau gabungan semua empat.
Mengoptimumkan halaman anda sebenarnya melibatkan mengoptimumkan empat subparts yang berbeza dari proses beban LCP:
Semua langkah ini mesti dioptimumkan untuk anda melihat peningkatan dalam skor LCP anda. Walau bagaimanapun, ini tidak bermakna semua sub-bahagian adalah sama pentingnya.
Google telah mencadangkan jumlah masa LCP harus dipecahkan dengan TTFB dan masa beban sumber setiap perakaunan sekitar 40% manakala beban sumber dan kelewatan unsur harus setiap akaun kurang dari 10%.
Sebaik -baiknya, kedua -dua ini sepatutnya hampir sama dengan sifar dan mengambil keutamaan ke atas dua fasa yang lain.
Terdapat dua cara untuk membantu mengurangkan kelewatan beban sumber yang hampir sama dengan sifar:
Kami akan mengatakan ini secara langsung, kami mengesyorkan berunding dengan pemaju web anda sebelum menyelam ke dalam perbaikan ini. Ini adalah operasi backend dan memerlukan tangan yang berpengalaman untuk menjadikannya berfungsi seperti yang dikehendaki.
Penemuan Sumber
Setiap pelayar web dilengkapi dengan pengimbas preload, yang tugasnya membantu parser HTML utama pelayar dalam mengesan kandungan halaman.
Walaupun parser HTML utama memproses markup mentah sehingga ia menjadi sumber penyekatan - seperti skrip yang tidak mengandungi async atau menangguhkan , pengimbas preload menduduki peranan yang lebih spekulatif.
Dalam erti kata lain, pengimbas preload sedang mencari sumber untuk mengambil sebelum parser HTML utama mencapai mereka dan terus berfungsi walaupun parser disekat. Pengimbas preload boleh digunakan untuk mencari dan memuatkan LCP sebagai dekat dengan permintaan halaman awal yang mungkin.
Untuk memastikan sumber LCP dapat ditemui dari sumber HTML, pemaju mempunyai pilihan khusus aset.
Sebagai contoh, jika LCP adalah imej maka SRC atau SRCSET perlu hadir dalam kod sumber. Sementara itu, imej latar belakang CSS dapat dimuatkan dengan memasukkan dalam markup HTML atau di tajuk. Akhirnya, fon juga boleh dimuatkan melalui .
Walau bagaimanapun, perlu diperhatikan bahawa dengan menggunakan pramuat untuk mengurangkan masa beban LCP boleh memperkenalkan masalah baru ke dalam campuran, seperti menghilangkan async . Ada sebab kami menganjurkan bercakap dengan pemaju anda mengenai perkara ini.
Untuk maklumat lanjut mengenai subjek ini, lihat Dives Deep Google ke dalam kedua -dua pengoptimuman LCP dan pengimbas preload .
Keutamaan sumber
Pelayar cuba memuat turun aset CSS, font, skrip, imej dan iframe secepat mungkin dengan memberikan keutamaan. Pelayar sangat baik untuk memikirkan keutamaan aset, tetapi itu tidak bermakna mereka tidak sempurna.
Untuk mengoptimumkan keutamaan aset, pemaju boleh menggunakan petunjuk keutamaan berasaskan markup untuk memberi isyarat kepada penyemak imbas yang aset mempunyai keutamaan yang lebih tinggi. Sebagai contoh, pemaju boleh menggunakan JavaScript dan API Fetch untuk menandakan imej LCP dengan FetchPriority = "High" , mempercepatkan metrik CWV tertentu.
Perlu diingat bahawa petunjuk keutamaan hanya berfungsi pada pelayar berasaskan kromium , seperti Google Chrome dan Microsoft Edge.
Pemaju anda mungkin telah melaksanakan pemuatan malas untuk di bawah aset lipatan, periksa dengan mereka untuk memastikan, tetapi juga berbaloi untuk menggunakannya sebagai petunjuk keutamaan untuk aset di atas lipatan.
Untuk maklumat lanjut mengenai pemuatan keutamaan, kami sangat mengesyorkan menyemak panduan Google untuk memuatkan sumber .
Pasukan dev gergasi carian dapat menggunakan petunjuk keutamaan untuk meningkatkan LCP dari 2.6 saat hingga 1.9 saat dalam ujian penerbangan Google.
FID menjejaki berapa lama penyemak imbas pengguna untuk mula memproses input pertama - tidak termasuk menatal dan zum.
Langkah ini adalah mengenai menangkap pengalaman pengguna berinteraksi dengan laman web, yang bermaksud bahawa laman web yang lembap akan menjaringkan gol buruk. Menjaga skor FID di bawah 100 milisaat adalah sasaran.
Responsiveness yang lemah umumnya datang kepada penggunaan JavaScript yang berlebihan, yang pelayar akan memproses lebih awal daripada input.
Kod yang menggunakan tumpuan penyemak imbas untuk 50 milisaat atau lebih digelar tugas yang panjang dan dilihat sebagai tanda kambing JavaScript. Memecahkan tugas -tugas panjang ini ke dalam potongan kecil kod dapat menangani prestasi yang lambat dan meningkatkan FID.
Tetapi itu bukan satu -satunya kawasan yang patut dibincangkan dengan pemaju anda. Adalah penting untuk membincangkan bagaimana pelaksanaan skrip pihak pertama dan pihak ketiga dapat melambatkan tapak anda. Pemuatan kod dan ciri-ciri yang progresif dapat membantu menangani cabaran-cabaran yang pertama, sementara pemuatan dan pengulas beban atas permintaan dapat membantu dengan yang terakhir.
Pilihan lain ialah menggunakan pekerja web untuk menjalankan JavaScript di latar belakang dan mencegah penyemak imbas anda mendapat skrip pemprosesan.
CLS pada dasarnya adalah pengukuran kestabilan visual laman web anda. Jika pelawat anda kehilangan tempat di halaman terima kasih kepada kandungan yang dipindahkan untuk membuat jalan untuk iklan dan imej untuk dimuatkan, maka laman web anda akan menjaringkan gol dengan buruk.
Semakin kurang susun atur halaman anda melantun, semakin baik skor CLS anda. Google menghakimi laman web dengan mempertimbangkan gangguan dalam viewport serta sejauh mana aset melonjak berbanding dengannya.
Meminimumkan peralihan susun atur yang tidak dijangka pada dasarnya berkisar sekitar menetapkan ruang untuk iklan, imej dan video tertanam.
Ingat SRC atau SRCSET yang kita lihat ketika bercakap mengenai penemuan sumber? Nah ini cukup penting untuk meningkatkan skor CLS.
Untuk imej statik, tetapkan lebar dan ketinggian menggunakan SRC untuk memberitahu penyemak imbas untuk menempah ruang untuk aset pemuatan yang lebih perlahan, dengan itu mengelakkan perubahan susun atur.
Lihat kod contoh dari Google di bawah:
Imej responsif memerlukan SRCSET untuk menentukan lebar maksimum dan ketinggian had yang boleh dipilih oleh penyemak imbas. Pastikan anda menggunakan imej dengan nisbah aspek yang sama.
Inilah contoh lain:
Semasa berurusan dengan iklan terdapat beberapa langkah yang boleh anda ambil:
Reserving Space Static juga dinasihatkan jika anda berhasrat untuk melaksanakan iframes, kandungan tertanam dan kandungan dinamik, seperti Panggilan ke Tindakan (CTAS).
Apabila penyemak imbas memuat turun dan membuat fon web ada kemungkinan sama ada flash teks yang tidak disengajakan (FOUT) atau flash teks yang tidak kelihatan (FOIT) yang berlaku. Yang pertama berlaku sebagai fon sandaran yang ditukar dengan fon baru, sementara yang terakhir adalah hasil kelewatan dalam fon baru yang diberikan.
Anda boleh menyelesaikan kedua -dua masalah dengan menggunakan Untuk memberitahu pengimbas preload untuk merebut fon web lebih awal. Fon preloaded mempunyai peluang yang lebih besar untuk memenuhi cat pertama.
Terdapat penyelesaian lain dalam panduan penyelesaian masalah CLS serta menyelam yang mendalam menggunakan pramuat untuk mengelakkan FOIT .
Jika anda sedang mencari penambahbaikan kelajuan tapak dan masih menggunakan pilihan hosting tunggal pelayan tradisional, maka mungkin masa untuk mempertimbangkan beralih ke rangkaian penghantaran kandungan (CDN).
CDN terdiri daripada rangkaian pelayan yang terletak di pusat data yang berbeza di seluruh dunia yang mengedarkan kandungan laman web untuk meningkatkan prestasi. Walaupun kedua -dua pilihan pelayan tunggal - juga dikenali sebagai hosting tempatan - dan CDN menyampaikan kandungan laman web kepada pelawat, hanya CDN yang boleh menjadi faktor di lokasi geografi pengguna dan kemudian memilih pelayan terdekat untuk mengurangkan masa beban.
Geografi bukanlah satu -satunya kelebihan, bagaimanapun, kerana CDN juga lebih baik dilengkapi untuk menguruskan pancang lalu lintas yang tiba -tiba serta sumber pelayan akar seperti jalur lebar.
Akhirnya, pengalaman melayari lebih cepat menghantar isyarat CWV yang kuat ke Google. Walaupun Cloudflare adalah salah satu penyedia CDN yang paling terkenal di pasaran, terdapat beberapa pesaing yang serius untuk dipertimbangkan .
Terlepas dari pembekal hosting yang anda gunakan, pelayan mereka akan terikat dengan kekangan perkakasan tertentu.
Pelayan sebahagian besarnya mengandungi komponen utama yang sama yang membolehkan komputer riba/desktop anda berfungsi - iaitu CPU dan RAM - yang mengendalikan semua tugas akaun anda. Anda sepatutnya dapat menggunakan papan pemuka penyedia hosting anda untuk memeriksa CPU dan RAM yang dipasang pada pelayan anda dan juga dapat meminta sumber tambahan untuk meningkatkan prestasi tapak anda.
Jika anda melihat CPU pelayan anda maka penting untuk memahami bahawa hanya satu teras yang digunakan untuk memenuhi permintaan pelawat untuk laman web. Ini bermakna kelajuan jam satu teras yang lebih cepat sentiasa menjadi. CPU multi-core dapat memproses pelbagai paparan halaman dan perkhidmatan pelayan lain.
Ini adalah satu lagi untuk pemaju anda.
Semak pangkalan data anda secara separuh-kerap untuk memastikan ia tidak menjadi kembung dengan foto dan fail yang tidak digunakan. Memadam fail yang tidak perlu akan mengecilkannya, mempercepatkan masa beban halaman purata.
Menggunakan imej yang benar -benar besar boleh dan akan melambatkan laman web anda. Berapa besar? Apa -apa yang melebihi 1MB terlalu besar.
Dan seperti yang sudah kita ketahui, masa beban yang lebih perlahan akan membawa kepada kadar lantunan yang lebih tinggi dan menghantar isyarat yang tidak diingini ke Google.
Bagi mereka yang ada di WordPress, terdapat beberapa plugin pengoptimuman imej untuk dipilih dari yang dapat menyelaraskan tugas manual yang membosankan. Selain itu, ramai juga datang dengan ciri-ciri lain seperti pemuatan malas dan penentuan auto.
Sama ada laman web mesra mudah alih atau tidak berkisar sama ada anda telah mempermudahkan dan menyelaraskan laman web anda untuk pengalaman melayari mudah alih.
Pengguna mudah alih berinteraksi dengan halaman yang berbeza dan mempunyai kesabaran yang lebih sedikit untuk masa beban perlahan dan sukar untuk menavigasi tapak. Sekiranya laman web anda gagal ujian mesra mudah alih yang diterangkan di atas, atau walaupun ia diluluskan tetapi anda berminat untuk mengoptimumkan selanjutnya, maka mari kita pergi ke beberapa amalan terbaik.
Ini sepatutnya menjadi kebimbangan utama setiap penerbit. Cara mudah untuk menangani kemudahan penggunaan adalah dengan bertanya kepada diri sendiri seperti:
Jawapan -jawapan ini akan pergi jauh ke arah mengenal pasti titik sakit pengguna. Sebagai contoh, anda tidak mahu membuat pengguna anda menyesuaikan skrin mereka untuk melihat kandungan anda. Anda dapat melihat apa yang kami maksudkan dalam contoh di bawah.
Untuk mengoptimumkan kandungan anda untuk peranti mudah alih, terdapat tiga pilihan pembangunan:
Kami telah mengarahkan mereka dari segi kemudahan pelaksanaan dan kami mengesyorkan mengamalkan reka bentuk yang responsif, kerana ia adalah yang paling kurang menuntut tiga pilihan.
Pemaju hanya menambah nama meta = "Viewport" tag ke kod sedia ada laman web
Kelebihan di sini adalah anda hanya perlu mengekalkan satu laman web, yang boleh dipaparkan dengan mudah di mana -mana jenis skrin.
Sebaliknya, reka bentuk dinamik berfungsi dengan melayani kod HTML yang berbeza berdasarkan peranti pengguna. Halaman perlu menggunakan header HTTP yang berbeza untuk mengelakkan kod yang salah disampaikan kepada peranti yang salah.
Akhirnya, terdapat subdomain mudah alih, yang kami tidak menasihatkan memandangkan jumlah sumber yang diperlukan untuk dilaksanakan dengan berkesan. Subdomain mudah alih adalah tapak yang berasingan sepenuhnya yang memisahkan keperluan hosting. Untuk memastikan bahawa crawler memahami hubungan antara domain dan subdomain, anda perlu memasukkan rel = "kanonik" .
Kerana reka bentuk responsif adalah pilihan paling mudah, ia adalah yang kami cadangkan untuk penerbit. Untuk melihat lebih dekat reka bentuk responsif, lihat panduan pelaksanaan Google .
Berikut adalah senarai cepat pertimbangan teknikal untuk sebarang reka bentuk:
Langkah terakhir ini adalah cara paling mudah untuk meningkatkan pengalaman halaman, tetapi juga jauh untuk meningkatkan ketenangan fikiran pengguna anda.
Beralih ke HTTPS Melindungi dan menyulitkan maklumat pengguna anda, ia juga membantu menghalang serangan manusia di tengah (MITM). Di samping itu, mempunyai sijil SSL menghapuskan amaran pelayar mengenai kekurangan keselamatan.
Pembekal hosting anda benar -benar boleh memberi anda keselamatan HTTPS, jika tidak maka ia mungkin bernilai mempertimbangkan langkah ke satu yang dilakukan. Terdapat beberapa penyedia hosting yang terkenal yang menyediakan HTTPS secara percuma . Selain itu, penyedia hosting yang menyediakan sijil SSL menggunakan perkhidmatan mereka sendiri dan bukannya luaran, menjadikan proses lebih mudah dan lebih cepat untuk dilaksanakan.
Jika anda ingin meminta dan memasang sijil SSL dari Pihak Berkuasa Sijil (CAS), terdapat empat langkah yang perlu anda ikuti. Ini adalah:
Adalah penting untuk memastikan apabila memindahkan laman web anda ke HTTPS bahawa ia tidak memberi kesan kepada strategi pendapatan iklan anda. Masalahnya ialah httpTidak akan berfungsi di laman web menggunakan HTTPS.
Kami menasihati perundingan dengan rakan kongsi iklan anda sebelum membuat sebarang perubahan ke laman web anda.
Untuk maklumat lanjut, lihat panduan komprehensif Google mengenai subjek ini.
Iklan interstisial yang mengganggu dan kotak dialog menjadikannya sukar untuk enjin carian untuk memahami kandungan laman web, yang boleh menjejaskan prestasi SERP.
Ia akan menjadi lebih baik jika ada cara untuk mewujudkan interstitial yang tidak mengganggu pengalaman pengguna, tetapi itulah titik keseluruhan iklan tersebut. Mereka mengambil alih keseluruhan skrin pada pemecahan kandungan untuk memberi perhatian pengguna.
Oleh itu, penerbit akan lebih baik menggunakan iklan spanduk dan bukan iklan interstisial, kerana mereka hanya mengambil sebahagian kecil daripada hartanah skrin. Lebih baik mempertaruhkan kebutaan spanduk daripada kekecewaan pengguna.
Penerbit boleh menggunakan sepanduk yang disokong pelayar atau spanduk HTML yang mudah yang dihubungkan ke halaman destinasi CTA.
Kotak dialog juga boleh digunakan untuk kempen promosi, tetapi ini boleh direka untuk menjadi tidak bersahaja. Anda perlu memastikan pengguna dapat mengakses kandungan tanpa gangguan.
Tidak ada pintasan sebenar untuk mengoptimumkan pengalaman halaman anda dan penting untuk anda menetapkan mata di atas. Dengan itu dikatakan, ia patut menunjukkan bahawa walaupun WordPress adalah platform penerbitan yang paling popular di dunia, ini tidak semestinya bermakna ia adalah CMS terbaik ketika datang untuk meningkatkan prestasi CWV.
Melihat laporan Teknologi CWVS menunjukkan bahawa hanya sekitar 29% laman web WordPress mempunyai CWV yang baik, manakala 41% laman web Wix mendapat tanda hijau.
Ia bernilai menimbang sama ada beralih ke CMS khusus boleh meningkatkan CWV anda secara asli.
Terdapat banyak alasan untuk ditutup ketika mengoptimumkan pengalaman halaman dan memulakan boleh menjadi sedikit menakutkan. Walau bagaimanapun, penting untuk diingat bahawa anda makan gajah dengan mengambil satu gigitan pada satu masa.
Bertujuan untuk skor "baik" di semua metrik CWV anda tidak perlu untuk membantu laman web anda memanjat SERPS. Lebih daripada itu, bagaimanapun, menetapkan matlamat yang tinggi itu boleh menjadi produktif yang produktif kerana ia boleh menjadi usaha yang merendahkan diri.
Sebaliknya, bertujuan untuk kemenangan kecil ketika datang ke CWV anda, fokus pada menangani hasil "miskin" tanpa terlalu membimbangkan tentang bar "keperluan pembaikan". Itu boleh datang kemudian, apabila anda mempunyai lebih banyak masa dan sumber untuk mendedikasikan proses tersebut.
Kami sudah bercakap tentang Yahoo! Skor CLS yang lebih baik di Jepun, mari kita lihat beberapa lagi laman web yang dapat kita pelajari beberapa pelajaran dari.
Harian India The Economic Times, yang melayani lebih daripada 45 juta pengguna aktif bulanan, memotong skor CLSnya sebanyak 250% dari 0.25 hingga 0.09 dan masa LCPnya 80% dari 4.5 saat hingga 2.5 saat.
Antara Oktober 2020 dan Julai 2021, penerbit memangkas skor LCP dalam julat "miskin" sebanyak 33%, manakala nilai CLS dalam julat "miskin" jatuh sebanyak 65%. Keuntungan ini membolehkan masa ekonomi untuk lulus ambang CWV di seluruh asalnya sambil mengurangkan kadar lantunan keseluruhan sebanyak 43%.
Penerbit mencapai ini dalam beberapa cara, dengan yang pertama adalah untuk mengutamakan keutamaan muat turun aset menggunakan petunjuk keutamaan. Ia juga menangani tugas -tugas yang panjang, memecahkan potongan kod untuk memastikan sumber -sumber yang kritikal untuk di atas rendering halaman lipat dimuatkan terlebih dahulu.
Laman web berita UK meningkatkan skor CLS dari 0.25 hingga 0.1 , sambil meningkatkan bilangan URL yang menerima gred lulus dari 57% hingga 72%.
Telegraph menggunakan Chrome Devtools untuk mengenal pasti contoh individu susun atur peralihan.
Sebelum itu menggunakan WebpageTest untuk mencari di mana dalam garis masa peralihan susun atur berlaku.
Dengan data ini, pasukan mula memberi tumpuan kepada mengurangkan perubahan susun atur dengan menangani kawasan ini
Untuk iklan, telegraf mula menempah ruang untuk mereka dan menggunakan saiz iklan yang paling biasa untuk menentukan dimensi. Ini juga membantu menghentikan iklan daripada runtuh apabila dilihat pada tablet.
Pasukan itu menangani masalah yang sama dengan imej sebaris di bahagian atas artikel, yang tidak mempunyai dimensi yang ditentukan.
The Telegraph membuat pelarasan lain, seperti menggerakkan tajuk ke bahagian atas markup dan menggunakan ruang letak untuk video tertanam, tetapi akhirnya menggambarkan proses itu sebagai "agak mudah" sementara masih mempunyai kesan yang signifikan.
Meningkatkan pengalaman halaman tidak perlu menggembirakan. Ukur empat tiang pengalaman halaman dan kemudian tentukan sumber apa yang anda boleh dedahkan untuk meningkatkan hasil anda.
Jika anda seorang penerbit yang lebih kecil, pengimbangan sumber akan menjadi penting dan kami akan mengesyorkan mengenal pasti buah gantung yang agak rendah untuk projek pertama anda.
Melihat pendekatan Telegraph, mereka memberi tumpuan kepada satu aspek CWV daripada ketiga -tiga dan membuat penambahbaikan yang ketara. Masa ekonomi memberi tumpuan kepada dua daripada tiga untuk menyampaikan beberapa hasil yang mengagumkan.
