Google Analytics Menyebabkan Vital Web Inti Gagal: Langkah Selanjutnya

Diterbitkan: 2024-03-26

Bagi pemilik bisnis online yang ingin menarik, melibatkan, dan mengonversi pengguna, kegagalan Core Web Vitals adalah peringatan penting.

Data Web Inti yang Gagal

Tolok ukur resmi mengenai seberapa menyenangkan situs web Anda bagi pengguna di dunia nyata, Data Web Inti Google adalah serangkaian tiga metrik kinerja:

  • Largest Contentful Paint (LCP) mengukur waktu muat awal
  • Interaction to Next Paint (INP) mengukur daya tanggap
  • Pergeseran Tata Letak Kumulatif (CLS) mengukur stabilitas tata letak

Bersama-sama, metrik ini menawarkan cara standar untuk mengukur kinerja situs berdasarkan interaksi pengguna sebenarnya. Lulus penilaian menunjukkan bahwa situs Anda dimuat dengan cepat, bereaksi dengan cepat, dan tidak berperilaku abnormal saat pengguna berinteraksi dengannya.

Jadi, merupakan kejutan besar ketika Analytics milik Google tampaknya menyebabkan kegagalan penilaian Core Web Vitals.

Mari kita selidiki!

Bagaimana Cara Kerja Google Analytics?

Google Analytics bekerja dengan melacak interaksi pengguna di situs web dan memberikan wawasan tentang perilaku pengguna, sumber lalu lintas, dan konversi. Ini diterapkan di situs web dengan menambahkan cuplikan kode pelacakan yang disediakan oleh Google Analytics.

Cuplikan JavaScript ini, juga dikenal sebagai Tag Situs Global (gtag.js), masuk ke bagian situs Anda di setiap laman web yang ingin Anda lacak:

Cuplikan kode pelacakan Google Analytics

Kode ini mengumpulkan data tentang interaksi pengguna, seperti tampilan halaman, klik, dan konversi, dan mengirimkannya ke server Google untuk dianalisis. Pemilik situs web kemudian dapat mengakses data ini melalui dasbor Google Analytics untuk mendapatkan wawasan tentang kinerja situs web dan keterlibatan pengguna.

Sejauh ini bagus.

Sekarang, mari kita lihat apa yang terjadi di balik terpal.

Dampak Terhadap Kinerja (Melihat Lebih Dekat)

Setelah diperiksa lebih dekat dengan cache yang dinonaktifkan dan tidak ada optimalisasi kinerja aktif, kami melihat gtag.js dimuat sebagai permintaan HTTP tunggal dengan berat sangat kecil 111kB, bersama dengan gtag Microsoft Clarity sebesar 769B.

Pemeriksaan halaman untuk Kode Pelacakan Google Analytics

Sejauh pemuatan laman awal, kode pelacakan Google Analytics menampilkan perilaku yang diharapkan dan tidak berkontribusi pada permintaan HTTP yang berlebihan, JavaScript yang tidak digunakan, atau thread utama yang diblokir.

Lalu, dari manakah kesalahpahaman itu berasal?

Apakah Google Analytics Benar-Benar Mempengaruhi Data Web Inti?

Menambahkan pelacakan Google Analytics ke situs web Anda saja tidak berisiko gagal dalam penilaian Core Web Vitals (atau khususnya Lagest Contentful Paint). Hal ini karena cuplikan yang ditempatkan di bagian atas halaman web sangat ringan dan tidak menghalangi proses penting apa pun dalam merender konten halaman.

Jadi, mengapa pemilik situs menghubungkan Core Web Vitals yang gagal ke Google Analytics?

Perbedaan Antara Data Lab dan Data Lapangan

Pengalaman kami menunjukkan bahwa masih banyak kesalahpahaman dalam membaca laporan Google PageSpeed. Terutama karena perkembangan laporan dari waktu ke waktu.

Mari kita hilangkan kebingungan ini.

Setelah diperkenalkannya Core Web Vitals, tim Google bekerja keras untuk mengalihkan perhatian ke apa yang kami sebut “data lapangan”—yang kini ditampilkan di bagian paling atas laporan Anda sebagai penilaian Core Web Vitals.

Itu dihasilkan dengan data dari pengguna nyata yang berinteraksi dengan situs web Anda dari kumpulan data CrUX (alias Laporan Pengalaman Pengguna Chrome).

Amazon.com Lulus Data Web Inti

Penilaian Core Web Vitals berdasarkan data lapangan untuk amazon.com

Sebelum Data Web Inti Google menjadi standar untuk pengalaman pengguna yang luar biasa, kami mengandalkan Skor Kinerja (diukur dari 0 hingga 100)—yang kini ditampilkan setelah penilaian CWV.

Desktop Skor Kinerja Amazon.com di Laporan Google PageSpeed ​​Insights

Skor Kinerja berdasarkan data lab untuk amazon.com

Alasan mengapa hal ini tidak diprioritaskan adalah karena hal ini tidak secara akurat mewakili apa yang terjadi saat pengguna membuka situs Anda. Skor Performa dihasilkan dengan “data lab” dari Lighthouse—dengan kata lain, ini adalah hasil dari lingkungan simulasi.

Seperti yang dapat Anda lihat dari tangkapan layar di atas, Amazon melewati Core Web Vitals dengan sangat baik, tetapi dalam lingkungan yang terkendali, Total Waktu Pemblokiran (TBT), Indeks Kecepatan (SI), dan masalah LCP ditandai untuk perbaikan lebih lanjut. Ini adalah cara yang bagus untuk mengisolasi masalah tertentu dan berupaya mengoptimalkannya.

Namun, pada akhirnya, yang paling penting adalah bagaimana pengalaman pengguna sebenarnya terhadap situs web Anda, dan di situlah fokus utama Anda harus diutamakan.

Putusan Akhir

Kesimpulannya, jika Anda gagal dalam Core Web Vitals, kemungkinan besar pelacakan Google Analytics bukan penyebabnya. Sebaliknya, pastikan Anda tidak membaca hasil lab, bukan hasil lapangan, dan gulir lagi laporan PSI Anda untuk menjelajahi bagian Peluang dan Diagnostik.

Bagaimana dengan Google Pengelola Tag dan Google AdSense?

Pada kenyataannya, pemilik situs jarang menyiapkan analitik dan menghentikannya.

Google Pengelola Tag dan Google AdSense adalah alat populer untuk bisnis online yang ingin melacak peristiwa tertentu dan menjalankan iklan di situs web mereka untuk mendapatkan penghasilan tambahan dari lalu lintas masuk.

Meskipun Google Analytics sendiri bukanlah sumber masalah kinerja, teknisi kami di NitroPack selalu melakukan analisis mendalam untuk mengidentifikasi penyebab sebenarnya.

Dengan menggunakan contoh sebelumnya dengan kiteworks.com , kami melihat bahwa saat berinteraksi dengan halaman beranda, rangkaian tag peristiwa tambahan (gtm.js) dari Tag Manager diaktifkan.

Alat Pemeriksaan Tag Peristiwa Google Pengelola Tag

Dan itu banyak sekali tag gtm.js tambahannya, sehingga menyebabkan jumlah permintaan HTTP yang berlebihan.

Karena kode Google Analytics dimuat terlebih dahulu sebelum yang lainnya, ketika situs web Anda memiliki banyak tag peristiwa, Anda dapat mengharapkan cuplikan GA memanggil semua gtm.js lainnya, yang mengakibatkan penundaan pemuatan dan memperburuk hasil metrik, seperti:

  • Cat Contentful Terbesar
  • Total Waktu Pemblokiran
  • Cat Contentful Pertama (FCP)

Dalam laporan PSI Anda, string seperti itu akan ditandai dengan peringatan “Kurangi JavaScript yang tidak digunakan”:

Kurangi Peringatan JavaScript yang Tidak Digunakan di Laporan Google PageSpeed ​​Insights

Dan jika Google Pengelola Tag Anda terlihat seperti ini, inilah waktunya untuk merapikan dan menata ulang:

Memperbaiki “Kurangi JavaScript yang Tidak Digunakan” yang Disebabkan Oleh Google Pengelola Tag

Langkah pertama Anda adalah menunda skrip pihak ketiga dengan atribut async atau defer dan membiarkannya dimuat di latar belakang. Atribut ini pada dasarnya mengubah skrip menjadi non-pemblokiran dan mengurangi dampak keseluruhan dari kode pihak ketiga.

Meskipun serupa, atribut-atribut ini memiliki perbedaan penting:

  • Skrip dengan atribut defer menjaga urutan relatifnya. Browser tidak menunggu mereka merender halaman tetapi mengeksekusinya secara berurutan. Misalnya, kita memiliki dua skrip—skrip 1 dan skrip 2—dalam urutan itu. Jika kita menunda keduanya, browser akan selalu mengeksekusi skrip 1 terlebih dahulu, meskipun skrip 2 diunduh terlebih dahulu.
  • Skrip dengan atribut async sepenuhnya independen. Yang mana yang dimuat terlebih dahulu akan dieksekusi terlebih dahulu.

Tag Gtm dimuat secara asinkron secara default, namun jika jumlahnya sebanyak ini, Anda seperti memiliki dua antrean permintaan yang sangat panjang—walaupun melewatinya, tag tersebut hanya dapat melewati satu per satu dan mau tidak mau harus menunggu giliran.

Dengan mengoptimalkan jumlah peristiwa Google Pengelola Tag terlebih dahulu dan menundanya berikutnya, Anda dapat memastikan pemuatan awal tidak mengalami penundaan yang tidak perlu.

Kurangi JavaScript yang Tidak Digunakan dan Optimalkan Semua Sumber Daya Situs Anda Dengan NitroPack →

Resiko dan Pengorbanan Dengan Google AdSense

Saat pemilik situs mendedikasikan unit iklan dalam berbagai format di laman web, Google AdSense menyediakan cuplikan kode (HTML/JavaScript) untuk setiap unit iklan yang ditempelkan ke dalam HTML laman situs web mereka tempat iklan akan muncul.

Saat pengguna mengunjungi laman web yang berisi kode iklan AdSense, browser mengeksekusi kode JavaScript yang disediakan AdSense, sehingga menghasilkan pendapatan bagi pemilik situs berdasarkan tayangan.

Iklan Google AdSense di Halaman Artikel Blog

Sayangnya, karena kualitasnya yang memblokir perenderan, iklan AdSense dapat memengaruhi kinerja situs (dan khususnya Web Vitals seperti LCP dan CLS).

Dengan NitroPack, pemilik situs dapat memilih “Optimalkan Iklan” yang akan menunda JS hingga interaksi pengguna. Namun karena AdSense bekerja berdasarkan tayangan, hal ini dapat mengakibatkan hilangnya pendapatan iklan.

Dalam hal ini, berdasarkan perilaku audiens, Anda harus memutuskan apa yang lebih bermanfaat bagi bisnis Anda:

1) kinerja optimal untuk pengalaman browsing yang lebih baik

atau

2) menghasilkan pendapatan iklan sebanyak mungkin namun pada akhirnya kehilangan lalu lintas karena perilaku situs yang tidak stabil.

Pertanyaan Umum

Apakah Google Analytics yang dihosting sendiri sepadan?

Meskipun beberapa pemilik situs mempertimbangkan pelacakan Google Analytics yang dihosting sendiri untuk Data Web Inti yang optimal, hal ini tidak perlu dilakukan. Daripada menambah kerumitan, biaya, dan potensi keterbatasan dibandingkan mengandalkan infrastruktur Google, fokuslah pada pengoptimalan peristiwa Google Pengelola Tag untuk memenuhi standar Data Web Inti.