Grafik performa bisa terlihat membaik hanya karena nilai kosong terhapus dan tanggalnya bergeser. Sebelum memakai CrUX History untuk menilai perubahan website, pastikan setiap angka masih terhubung dengan periode, perangkat, dan cakupan halaman yang benar.
Saya menyarankan memeriksa tabel dasarnya lebih dahulu. Grafik yang rapi tidak banyak membantu kalau titik “minggu ini” sebenarnya milik periode lain. Pemeriksaan ini berguna bagi developer, pengelola website, dan analis yang menerima ekspor performa dari tim lain.
Tetapkan apa yang sedang dibandingkan
Simpan permintaan bersama respons aslinya. Catat apakah objeknya satu URL atau seluruh origin, perangkat yang dipilih, metrik, waktu pengambilan, serta periode yang dikembalikan. Beri label berbeda untuk halaman produk dan keseluruhan domain.
Jika laporan lama memakai seluruh perangkat sedangkan laporan baru hanya ponsel, jangan menghubungkan keduanya menjadi satu garis tanpa penjelasan. Perbedaan populasi dapat ikut mengubah angka. Prinsip cakupan ini juga menjadi dasar membedakan data lapangan dan pengujian lab.
Dokumentasi CrUX menjelaskan bahwa History diperbarui mingguan, tetapi setiap pengamatan merangkum periode 28 hari yang saling bertumpang tindih. Nilai tersebut bukan rata-rata dari tujuh hari yang berdiri sendiri. Gunakan tanggal dalam respons sebagai rujukan. Kontrak CrUX History API.
Hubungkan tanggal dan nilai berdasarkan posisi
Di respons History, collectionPeriods berisi rentang tanggal. Deret seperti percentilesTimeseries.p75s mengikuti urutan periode tersebut. Maka nilai pada posisi ketiga harus tetap berpasangan dengan rentang ketiga, termasuk ketika nilainya kosong.
Periksa panjang kedua deret sebelum membuat tabel. Jika jumlahnya berbeda, hentikan penggabungan otomatis dan simpan respons untuk diagnosis. Mengambil jumlah yang lebih pendek secara diam-diam akan menyembunyikan masalah struktur data.
Berikut contoh sintetis untuk LCP pada satu cakupan yang sama. Angkanya dibuat untuk menjelaskan pemrosesan, bukan hasil pengukuran website tertentu.
| Posisi | Periode pengumpulan | LCP p75 | Status |
|---|---|---|---|
| 0 | 1–28 September | 2.800 ms | Tersedia |
| 1 | 8 September–5 Oktober | Kosong | Tidak tersedia |
| 2 | 15 September–12 Oktober | 2.500 ms | Tersedia |
Jika nilai kosong dibuang lebih dahulu, deret angka berubah menjadi [2800, 2500]. Ketika dipasangkan dengan dua tanggal pertama, angka 2.500 ms salah ditempatkan pada periode yang berakhir 5 Oktober. Grafiknya tampak sah, tetapi waktu perubahan sudah keliru.
Bangun baris dari daftar periode, lalu ambil nilai metrik pada posisi yang sama. Simpan kolom status agar pembaca dapat membedakan data tersedia dan data yang belum dapat dinilai.
Pertahankan celah sebagai celah
Untuk periode yang tidak memiliki data memenuhi syarat, CrUX History dapat mengembalikan null pada deret persentil dan string "NaN" pada kepadatan histogram. Keduanya bukan angka nol. Penjelasan kelayakan metrik dan nilai kosong.
Jangan mengubah null menjadi nol lewat konversi tipe yang longgar. Jangan pula mengisi nilai terakhir ke periode kosong lalu menampilkannya sebagai pengamatan aktual. Pada grafik, celah boleh dibiarkan terputus dengan keterangan yang jelas.
Jika perangkat lunakmu membutuhkan angka, pisahkan kolom nilai dari kolom ketersediaan. Baris yang tidak tersedia dikeluarkan dari operasi numerik terkait, tetapi tanggalnya tetap berada dalam tabel. Untuk interpolasi yang memang diperlukan dalam analisis lain, tampilkan sebagai estimasi terpisah dan jelaskan metodenya.
Jangan menamai rata-rata p75 sebagai p75 gabungan
P75 menggambarkan sebuah posisi dalam distribusi. Rata-rata beberapa p75 tidak otomatis menghasilkan p75 dari seluruh kunjungan yang digabung. Dua kelompok bisa memiliki ukuran dan bentuk distribusi yang berbeda.
Misalnya, dashboard mengambil empat titik awal dan empat titik akhir lalu menghitung rata-ratanya. Itu boleh dipakai sebagai ringkasan buatan tim jika definisinya jelas. Namai “rata-rata empat pengamatan p75”, sertakan tanggalnya, dan jangan menyebutnya penilaian resmi untuk seluruh periode.
Jika tujuanmu lebih sederhana, tampilkan nilai awal dan akhir beserta perubahan absolut. Pada ilustrasi tadi, selisihnya minus 300 ms. Persentase terhadap 2.800 ms sekitar minus 10,7%. Perhitungan itu hanya membandingkan dua pengamatan; ia belum menjelaskan penyebab perubahannya.
Baseline nol atau tidak tersedia membutuhkan perlakuan berbeda. Jangan menghasilkan persentase tak terhingga atau mengganti pembagi dengan angka kecil agar rumus tetap berjalan. Tuliskan alasan perubahan relatif tidak dihitung.
Letakkan perubahan website pada rentang yang tepat
Tambahkan catatan rilis pada grafik: kapan perubahan diterapkan, template yang terdampak, dan apakah peluncurannya bertahap. Satu pengamatan setelah rilis bisa masih mencakup banyak hari sebelum rilis karena periode pengumpulannya bertumpang tindih.
Bandingkan pula perubahan komposisi kunjungan, perangkat, dan halaman yang tercakup bila datanya tersedia. Penurunan LCP yang bersamaan dengan rilis mendukung hipotesis perbaikan, tetapi tidak sendirian membuktikan sebab-akibat.
Gunakan pengujian lab untuk memeriksa mekanisme teknis yang diubah, lalu data lapangan untuk melihat pengalaman yang teramati. Simpan keduanya sebagai bukti dengan fungsi berbeda. Hindari memindahkan hasil lab ke celah data CrUX seolah berasal dari sumber yang sama.
Jadikan pemeriksaan ini bagian dari laporan
Sebelum membagikan grafik, periksa lima hal: cakupan tetap sama, tanggal sejajar dengan nilai, satuan konsisten, celah tetap terlihat, dan catatan rilis tidak dipakai sebagai bukti kausal tunggal.
Mulai dari satu deret yang sedang kamu gunakan. Tampilkan tiga baris pertama, tiga baris terakhir, serta semua baris kosong. Jika tabel itu bisa dijelaskan dengan tepat, barulah grafiknya layak membantu keputusan tentang pekerjaan performa berikutnya.
