Karyawan AI untuk Audit Core Web Vitals: Bedakan Data Lapangan dan Lab

Ditulis oleh Nugraha Labib Mujaddid, pembuat AgentBuff.

Skor PageSpeed yang hijau belum membuktikan pelanggan nyaman memakai website Anda. Audit Core Web Vitals dengan karyawan AI harus memisahkan pengalaman pengguna nyata, pengujian laboratorium, dan bukti perbaikan. Kalau ketiganya dicampur, tim bisa merayakan skor sementara tombol pilih varian masih terasa lambat di ponsel pelanggan.

Panduan ini ditujukan untuk UMKM dengan website sendiri, online seller, kreator kelas, solopreneur, usaha jasa, profesional, dan mahasiswa pengelola situs proyek. Fokusnya bukan mengejar angka sempurna, melainkan menghasilkan antrean perbaikan yang jelas: halaman mana, masalah apa, bukti dari mana, siapa penanggung jawabnya, dan bagaimana menguji ulang. Semua contoh merupakan ilustrasi operasional, bukan hasil pengujian pelanggan atau janji kenaikan penjualan.

Mengapa dua laporan bisa sama-sama benar?

PageSpeed Insights menyediakan data lapangan dan laboratorium. Data pengalaman pengguna berasal dari Chrome User Experience Report atau CrUX, sedangkan diagnosis laboratorium memakai Lighthouse pada kondisi simulasi.[7] Artinya, dua bagian pada laporan yang sama menjawab pertanyaan berbeda.

Data lapangan menjawab bagaimana pengalaman pengguna yang tercakup pengukuran. Data laboratorium membantu menemukan masalah pada skenario pengujian tertentu. Perbedaan perangkat, jaringan, cache, lokasi, dan interaksi membuat hasil keduanya dapat berbeda tanpa berarti salah satu alat rusak.[6] Jangan meminta agen menyatukan keduanya menjadi satu nilai rata-rata.

Rekomendasi editorial kami adalah memperlakukan audit sebagai proses pengambilan keputusan berbukti. Agen mengumpulkan laporan yang diizinkan, memeriksa konteks angka, dan menyiapkan tiket. Pengelola website menentukan perubahan teknis, sementara pemilik usaha menyetujui prioritas dan risiko. Jika alat pengujian tidak tersedia, keluaran agen adalah rencana dan daftar bukti yang dibutuhkan, bukan angka rekaan.

Kenali LCP, INP, dan CLS tanpa tertukar

Dokumentasi Web Vitals menyebut tiga Core Web Vitals: Largest Contentful Paint atau LCP untuk pemuatan, Interaction to Next Paint atau INP untuk respons interaksi, serta Cumulative Layout Shift atau CLS untuk kestabilan visual.[5] Gunakan nama metrik lengkap ketika pertama kali mencatatnya agar laporan tidak berubah menjadi kumpulan singkatan.

Ambang kategori baik adalah LCP paling lama 2,5 detik, INP paling lama 200 milidetik, dan CLS paling tinggi 0,1. Evaluasi pengalaman lapangan menggunakan persentil ke-75 dan memisahkan perangkat seluler dari desktop.[5] CLS bukan durasi, sehingga jangan menambahkan satuan detik pada nilainya.

Persentil ke-75 bukan rata-rata dan bukan jaminan setiap pengunjung mendapat pengalaman baik. Catat juga distribusi yang tersedia serta cakupan datanya. Untuk status penilaian, simpan keputusan yang benar-benar dilaporkan alat. Dokumentasi PSI menjelaskan pengecualian saat data INP tidak cukup: penilaian dapat lulus berdasarkan LCP dan CLS yang baik; bila LCP atau CLS tidak cukup datanya, penilaian tidak dapat dilakukan.[7] Jangan menciptakan status lengkap dari metrik yang kosong.

1. Pilih halaman berdasarkan pekerjaan pelanggan

Mulailah dari perjalanan yang bernilai, bukan hanya beranda. Untuk toko, pilih halaman kategori, detail produk, dan jalur menuju checkout. Untuk konsultan, pilih halaman layanan serta permintaan konsultasi. Untuk kreator, pilih halaman kelas dan pendaftaran. Untuk mahasiswa, pilih halaman proyek yang memang akan dibagikan kepada penilai.

Buat kartu cakupan yang mencatat URL, template, tujuan pengunjung, pemilik, versi rilis, tanggal pemeriksaan, dan apakah halaman bersifat publik atau membutuhkan login. Jangan mengirim URL privat, token, atau parameter berisi data pelanggan ke layanan pengujian publik. Untuk halaman terbatas, minta pengelola teknis menentukan metode uji yang sesuai.

Pisahkan website milik sendiri dari etalase marketplace yang tidak dapat Anda ubah. Agen boleh menjelaskan keterbatasan, tetapi tidak boleh menjanjikan penghapusan script atau perubahan template pada layanan pihak lain. Mulai dengan sejumlah kecil halaman yang mewakili jenis template dan tugas pengguna, lalu perluas berdasarkan temuan.

2. Buat kontrak bukti sebelum membaca skor

Setiap laporan perlu identitas yang stabil. Simpan ID pemeriksaan, URL yang diminta, URL akhir setelah redirect, waktu pengambilan, jenis perangkat, sumber laporan, cakupan URL atau origin, serta periode data bila tersedia. Tambahkan tautan atau salinan laporan yang dapat dibuka reviewer.

Untuk hasil laboratorium, catat versi alat dan konfigurasi yang tersedia pada laporan, termasuk jaringan, emulasi, dan lingkungan. Jangan menebak konfigurasi dari nama kategori “mobile”. Jika ada nilai yang tidak tersedia, tulis tidak tersedia. Kekosongan metadata membatasi kekuatan perbandingan, bukan alasan mengisinya dengan asumsi.

Rekomendasi format keluaran: satu baris untuk satu kombinasi halaman, perangkat, sumber, dan putaran pengujian. Dengan begitu, laporan desktop tidak menimpa mobile dan hasil setelah rilis tidak menggantikan baseline. Karyawan AI dapat merapikan struktur ini dari ekspor yang Anda berikan tanpa memerlukan izin mengubah website.

3. Periksa apakah data benar-benar milik URL tersebut

PSI memakai periode pengumpulan 28 hari sebelumnya. Ketika data halaman tidak cukup, laporan dapat beralih ke tingkat origin, yang mencakup pengalaman pada berbagai halaman website. Jika origin juga kekurangan data, pengalaman pengguna nyata tidak ditampilkan.[7] Ini sangat relevan untuk website baru atau halaman dengan sedikit sampel.

Karena itu, label “origin” harus tetap terbawa ke ringkasan. Jangan menulis “halaman pendaftaran lulus” jika yang tersedia hanya agregat domain. Sebaliknya, tidak adanya CrUX bukan bukti website lambat ataupun cepat. Status yang benar adalah belum ada data lapangan yang memadai dari sumber tersebut.

Untuk kebutuhan lebih rinci, pemilik dapat mempertimbangkan real-user monitoring dengan bantuan pengembang. Dokumentasi Web Vitals menjelaskan bahwa CrUX tidak menyediakan seluruh telemetri per kunjungan yang diperlukan untuk diagnosis mendalam.[5] Pengumpulan tambahan harus punya tujuan, akses, dan aturan privasi yang jelas. Jangan merekam isi formulir, identitas pelanggan, atau parameter sensitif hanya untuk mengukur performa.

4. Gunakan lab untuk diagnosis, bukan pengganti pengguna

Ambil laporan laboratorium dengan kondisi yang konsisten dan simpan seluruh putaran yang disepakati. Sebagai prosedur internal, tim bisa menjalankan tiga putaran untuk melihat variasi awal, tetapi jumlah itu bukan standar Google atau bukti statistik menyeluruh. Jangan memilih hanya percobaan terbaik.

Lighthouse memberi diagnosis dalam lingkungan simulasi. Skor performanya dapat berubah antarpercobaan karena variasi jaringan, perangkat keras, dan perebutan sumber daya.[7] Laporkan metrik serta konteksnya, bukan sekadar perubahan warna lingkaran. Bila hasil sangat tidak stabil, selidiki lingkungan sebelum menyatakan perubahan kode berhasil.

Jangan menyalin Total Blocking Time atau TBT ke kolom INP. TBT adalah metrik laboratorium yang membantu diagnosis masalah interaktivitas, tetapi bukan bagian dari Core Web Vitals dan tidak sama dengan pengalaman interaksi pengguna nyata.[5][6] Bila perlu menelusuri tombol lambat, minta pengembang merekam skenario interaksi yang relevan, bukan menganggap tes pemuatan awal telah mencakup semua tindakan.

5. Ubah indikasi menjadi tiket yang dapat dikerjakan

Gunakan empat bagian pada setiap temuan: pengamatan, hipotesis, pemeriksaan lanjutan, dan keputusan. Contohnya, “LCP mobile pada laporan URL berada di luar kategori baik” adalah pengamatan jika ada bukti. “Foto hero penyebabnya” masih hipotesis sampai elemen dan jalur pemuatannya diperiksa.

Untuk LCP, minta tim teknis mengidentifikasi elemen yang terkait serta hambatan yang terukur. Untuk INP, catat tindakan pengguna yang terasa terlambat, kondisi halaman, dan bukti diagnosis. Untuk CLS, simpan rekaman pergeseran serta posisi elemen yang berubah. Daftar ini merupakan rekomendasi kerja, bukan kesimpulan otomatis tentang penyebab di situs Anda.

Jika bukti memang menunjuk aset gambar, lanjutkan ke workflow optimasi gambar website.[8] Artikel tersebut membahas paket aset dan cara pengirimannya; audit di sini menentukan prioritas performa lintas metrik. Jangan mengompresi semua gambar atau menghapus semua integrasi hanya karena satu laporan memberi saran umum.

6. Prioritaskan dampak tanpa menjanjikan pendapatan

Berikan prioritas berdasarkan pentingnya perjalanan pengguna, kekuatan bukti, luas halaman terdampak, upaya implementasi, dan risiko regresi. Template detail produk yang dipakai banyak halaman mungkin membutuhkan penanganan berbeda dari halaman profil yang jarang berubah. Namun prioritas tetap perlu disepakati dengan pemilik bisnis, bukan diputuskan dari satu skor.

Pisahkan temuan teknis dari akibat bisnis. “Respons interaksi membaik pada skenario uji” tidak sama dengan “penjualan naik”. Artikel ini tidak memberi estimasi kenaikan konversi karena tidak ada eksperimen bisnis yang dilakukan. Jika tim ingin menilai dampak komersial, desain evaluasi tersendiri dengan data yang memang diizinkan.

Performa juga bukan pengganti fungsi. Setelah perubahan, gunakan panduan uji formulir website untuk memeriksa apakah permintaan tetap tersimpan dan diteruskan ke penerima yang tepat.[9] Halaman ringan yang kehilangan tombol kirim tidak memenuhi kebutuhan pelanggan.

7. Verifikasi rilis dan hindari kesimpulan terlalu cepat

Setiap perubahan memerlukan persetujuan, identitas rilis, waktu penerapan, dan cara kembali ke versi sebelumnya. Uji ulang skenario laboratorium pada kondisi sebanding, periksa jalur bisnis, lalu simpan hasil aktual. Agen tidak boleh menerbitkan perubahan produksi hanya karena menemukan rekomendasi di laporan.

Karena data lapangan PSI mencakup 28 hari sebelumnya, laporan setelah rilis masih dapat membawa pengalaman sebelum perubahan.[7] Jangan menjanjikan status lapangan akan langsung berubah begitu cache dibersihkan. Tandai tanggal rilis dan jendela pengamatan, kemudian bedakan bukti awal dari hasil yang sudah mencerminkan periode sesudah perubahan.

Tutup tiket hanya sesuai kriteria yang disepakati. Status yang berguna antara lain diagnosis selesai, perubahan disetujui, rilis diterapkan, lab diuji ulang, dan lapangan masih dipantau. Pemisahan ini mencegah kalimat “sudah diperbaiki” menutupi pekerjaan yang sebenarnya belum diverifikasi.

Contoh: halaman kelas kreator di Bandung

Bayangkan kreator menjual kelas kerajinan lewat website sendiri. Desktop terlihat baik, tetapi pembeli mengeluhkan tombol memilih jadwal. Ini ilustrasi, bukan studi kasus. Agen menyiapkan inventaris halaman kelas, memilih laporan mobile yang tersedia, dan mencatat apakah data berasal dari URL atau origin.

Ketika laporan lab terlihat baik, agen tidak menolak keluhan pelanggan. Tim teknis diminta memeriksa interaksi memilih jadwal pada perangkat uji yang disepakati. Agen menyimpan rekaman, menautkan temuan ke versi halaman, dan memisahkan dugaan tentang widget dari bukti penyebab. Pemilik menyetujui perbaikan terbatas, bukan penghapusan seluruh alat pemasaran.

Setelah rilis, tim mengulang interaksi, memeriksa formulir pendaftaran, dan memantau data lapangan dengan batas periodenya. Laporan akhir menyatakan apa yang terbukti dan apa yang masih menunggu. Nilai agen terletak pada kerapian alur bukti, bukan keberanian menyebut semua masalah selesai.

Instruksi siap pakai untuk karyawan AI

Audit performa daftar URL milik saya dengan akses baca. Pisahkan data lapangan dan lab, mobile dan desktop, serta URL dan origin. Catat waktu, periode, konfigurasi, sumber, dan bukti setiap angka. Jangan mengisi metrik yang tidak tersedia. Susun tiket berisi pengamatan, hipotesis, pemeriksaan lanjutan, owner, dan kriteria uji ulang. Jangan mengubah website, mengirim data privat ke layanan publik, atau menyimpulkan dampak penjualan. Laporkan keterbatasan alat dan keputusan manusia yang masih diperlukan.

AgentBuff menjelaskan karyawan AI melalui chat, sambungan alat kerja, dan tugas terjadwal.[1] Dalam workflow ini, perannya dapat berupa koordinator laporan dan antrean review. Kemampuan menjalankan Lighthouse, membaca laporan privat, atau mengubah website tetap bergantung pada tools serta izin yang benar-benar tersedia, bukan kemampuan bawaan yang dijanjikan artikel ini.

Mulailah dari satu perjalanan pelanggan dan satu daftar temuan yang dapat diuji. Jika ingin mempertimbangkan platform, ajukan akses AgentBuff. Saat diperiksa, akun baru masih dibuka bertahap lewat pengajuan; tautan tersebut bukan janji aktivasi instan.[2]

Tentang penulis

Nugraha Labib Mujaddid adalah pembuat AgentBuff.

Sources

[1] https://agentbuff.id [2] https://agentbuff.id/register [5] https://web.dev/articles/vitals [6] https://web.dev/articles/lab-and-field-data-differences [7] https://developers.google.com/speed/docs/insights/v5/about [8] https://agentbuff.id/blog/karyawan-ai-optimasi-gambar-website [9] https://agentbuff.id/blog/karyawan-ai-uji-formulir-website-lead