Efek kedip dalam pengujian A/B: mengapa hal itu memengaruhi hasil Anda (dan bagaimana cara menghindarinya)

Diperbarui pada 19 Oktober 2026

13 milidetik. Itulah waktu yang dibutuhkan otak manusia untuk mengidentifikasi sebuah gambar, menurut sebuah studi oleh para ahli saraf di MIT yang diterbitkan pada tahun 2014. Namun, skrip untuk alat pengujian A/B sisi klien sering kali membutuhkan beberapa ratus milidetik untuk memodifikasi halaman. Selama waktu ini, pengunjung Anda melihat versi asli, lalu variannya. Mereka telah melihat keduanya. Namun, pengujian Anda mengasumsikan bahwa mereka hanya melihat satu versi saja.

Efek kedip ini memperkenalkan bias sistematis ke dalam pengukuran Anda, hampir selalu merugikan varian tersebut, dan dapat menyebabkan Anda membuang ide yang bagus atau memvalidasi ide yang buruk. Panduan ini menjelaskan dari mana efek ini berasal, berapa biaya sebenarnya, bagaimana mengukurnya di situs Anda sendiri, dan bagaimana cara menghilangkannya.

Apa yang dimaksud dengan efek kedip dalam pengujian A/B?

Efek kedip (atau FOOC, "Flash of Original Content") adalah tampilan singkat halaman asli sebelum varian yang diuji diterapkan, karena skrip pengujian memodifikasi halaman setelah browser mulai menampilkannya. Pengunjung merasakan adanya perubahan mendadak: judul yang berubah, tombol yang berubah warna, blok yang bergeser.

Fenomena ini khusus untuk pengujian sisi klien. Dalam model ini, server selalu mengirimkan halaman HTML yang sama; file JavaScript, yang dimuat oleh browser, yang menentukan grup mana pengunjung berada dan menulis ulang DOM sesuai dengan itu. Hingga skrip ini diunduh, diinterpretasikan, dan dieksekusi, kontrol akan ditampilkan. Jika Anda baru mengenal kosakata ini (DOM, varian, kontrol, alokasi), panduan kami dapat membantu. glosarium pengujian A/B mengulangi setiap istilah.

Mengapa Flicker memengaruhi hasil Anda?

Kedipan tersebut hanya memengaruhi salah satu dari dua kelompok: kontrol menampilkan tanpa artefak, varian muncul dengan kedipan. Oleh karena itu, Anda tidak lagi membandingkan "desain A versus desain B", tetapi "desain A versus desain B dengan cacat tampilan". Ini adalah bias, bukan gangguan: bias ini tidak hilang dengan meningkatkan ukuran sampel.

Dua mekanisme bekerja melawan varian ini:

1. Kehilangan kepercayaan diri. Halaman yang "melompat-lompat" menunjukkan situs web yang dirancang dengan buruk. Pada alur pembayaran atau formulir permintaan penawaran, kesan ini saja sudah cukup untuk menimbulkan kecurigaan.
2. Efek perbandingan. Pengunjung telah melihat harga, judul, atau gambar lama. Jika varian tersebut menampilkan harga yang dicoret atau janji yang lebih kuat, mereka akan melihat kedua versi tersebut, yang mengubah persepsi mereka terhadap penawaran.

Terkadang, sebaliknya, elemen yang "muncul" menarik perhatian dan memperkuat varian tersebut. Dalam kedua kasus tersebut, hasil yang Anda baca di dasbor analitik tidak sesuai dengan tampilan varian setelah diimplementasikan secara langsung tanpa skrip. Ini adalah salah satu sumber yang diremehkan. positif palsu (dan negatif palsu) dalam pengujian A/B.

5 penyebab teknis kedipan layar

Kedipan muncul segera setelah varian diterapkan setelah rendering halaman pertama. Lima faktor, yang dapat dikombinasikan, memperpanjang penundaan ini.

1. Lokasi skrip

Naskah ditempatkan di bagian akhir <body> kode ini hanya dieksekusi setelah seluruh HTML selesai diurai: browser sudah menampilkan semuanya. Kode ini harus berada setinggi mungkin dalam daftar kode. <head>, sebelum stylesheet dan skrip pihak ketiga lainnya.

2. Menggunakan pengelola tag

Google Tag Manager memuat tag-nya secara asinkron. Oleh karena itu, skrip pengujian menunggu kontainer GTM itu sendiri dimuat, lalu dipicu. Analis Simo Ahava mengukur perbedaan tersebut di situs yang sama, dengan lalu lintas terbagi menjadi dua: halaman tersebut tetap tersembunyi. Rata-rata 964 ms dengan tag yang melewati GTM, dibandingkan dengan 581 ms dengan cuplikan yang disisipkan langsung ke halaman.. Hampir 400ms hilang semata-mata karena metode integrasi.

3. Pemuatan asinkron

Skrip asinkron tidak memblokir tampilan: inilah keunggulannya dalam hal kecepatan, dan alasan mengapa ia menghasilkan kedipan. Kita akan kembali membahas ini di bagian selanjutnya.

4. Ukuran skrip dan latensi

Berkas yang berisi konfigurasi untuk semua pengujian akun, termasuk yang dijeda, membutuhkan waktu lebih lama untuk dieksekusi. Jika berkas tersebut disajikan dari server yang jauh dari pengunjung, setiap perjalanan bolak-balik akan menambah puluhan milidetik.

5. Cara varian tersebut dikodekan

Modifikasi yang menunggu elemen ada di DOM sebelum menuliskannya kembali (misalnya, "ganti teks tombol setelah dimuat") akan diterapkan setelah elemen tersebut ditampilkan. Editor WYSIWYG terkadang menghasilkan kode jenis ini secara default. Dokumentasi untuk Optimizely sistem mengenali hal itu: perubahan visualnya menunggu elemen tersebut tersedia, yang menyebabkan kedipan ketika banyak perubahan sedang dalam antrian.

Cuplikan sinkron atau asinkron: keputusan sebenarnya

Cuplikan sinkron memblokir tampilan hingga dieksekusi: tidak ada kedipan, tetapi layar putih jika skrip lambat. Cuplikan asinkron memungkinkan halaman dimuat: tidak ada layar putih, tetapi kedipan. Tidak ada cara ketiga yang gratis.

Optimizely merekomendasikan untuk memuat cuplikan secara sinkron. sambil memungkinkan modifikasi varian tertentu untuk berjalan secara asinkron. VWO (diganti namanya) Wingify (pada tahun 2026) menyembunyikan isi halaman sambil menunggu pustakanya; Kameleoon menyoroti integrasi "asinkron yang memblokir".

Pilihan yang tepat bergantung pada satu pertanyaan: apakah latensi skrip Anda terkendali? Jika file berukuran kecil dan disajikan dari CDN yang dekat dengan pengunjung Anda, mode sinkron akan menambah beberapa puluh milidetik dan menghilangkan masalah tersebut. Jika tidak, setiap perlambatan jaringan akan mengakibatkan layar kosong. Inilah inti permasalahannya. pengiriman varian yang sangat cepat : buat mode pemblokiran cukup singkat sehingga tidak terasa.

Cuplikan anti-kedip: berguna, tetapi ada harganya.

Cuplikan anti-kedip menyembunyikan halaman (atau sebagian darinya) menggunakan aturan CSS saat skrip pengujian berjalan, lalu menampilkannya kembali. Ini menghilangkan kedipan yang terlihat, tetapi menggeser biaya: halaman ditampilkan kemudian untuk semua orang.

Prinsipnya sederhana. Sebaris kode yang ditempatkan di bagian atas <head> terapan opacity: 0 atau visibility: hidden pada <body>. Saat alat menerapkan varian, alat tersebut menghapus aturan itu. Jika alat tidak merespons, batas waktu maksimum akan tetap menampilkan halaman. Nilai defaultnya cukup besar: cuplikan lama dari Google Optimize menunggu hingga 4 detik, dan kode Pintar dari VWO / Wingify menetapkan toleransi sebesar 2000 ms untuk pengaturan dan 2500 ms untuk pustaka..

Angka-angka ini signifikan. Selama seluruh waktu ini, tidak ada satu piksel pun yang ditampilkan. Audit yang diterbitkan oleh DebugBear di halaman beranda AdRoll menunjukkan Largest Contentful Paint (LCP) sebesar 6,0 detik dengan masking diaktifkan, dibandingkan dengan 2,7 detik setelah masking dinonaktifkan. Google menganggap LCP di atas 2,5 detik "perlu perbaikan" dan di atas 4 detik "buruk": anti-flicker yang dikonfigurasi dengan buruk dapat mengubah halaman yang sehat menjadi hasil negatif.

Tiga aturan untuk menggunakannya tanpa merusak:

• Sembunyikan hanya area yang diuji (blok pahlawan, bentuknya), bukan <body> seluruhnya. Bagian halaman lainnya ditampilkan secara normal dan LCP hanya terpengaruh jika elemen tersembunyi itu sendiri adalah elemen LCP.
• Persingkat waktu tunggu pada 1000-1500 ms, bukan 2000-4000 ms. Lebih dari itu, pengunjung yang melihat halaman kosong akan lebih dirugikan daripada pengunjung yang melihat kilatan cahaya.
• Aktifkan masking hanya pada halaman yang memuat pengujian.. Sistem anti-kedip yang diterapkan di seluruh situs memberikan sanksi kepada ribuan halaman yang tidak melakukan pengujian apa pun.

Mengukur kedipan di lokasi Anda: metode A/A'

Untuk menentukan apakah efek kedip memengaruhi pengujian Anda, jalankan pengujian A/A': dua kelompok melihat halaman yang persis sama, tetapi satu kelompok menerima modifikasi tak terlihat yang diterapkan oleh skrip pengujian. Perbedaan signifikan antara kedua kelompok tersebut mengukur biaya mekanisme injeksi itu sendiri, terlepas dari pertimbangan pemasaran apa pun.

Operasi A/A standar saja tidak cukup: tidak ada grup yang mengalami modifikasi, oleh karena itu tidak ada yang mengalami flicker. Inilah metode yang kami rekomendasikan di BlastOptimize sebelum meluncurkan serangkaian pengujian pada situs baru atau templat halaman baru.

Protokol 4 langkah

1. Buat varian A' Fungsi ini menerapkan modifikasi tanpa efek visual pada elemen yang ingin Anda uji (misalnya, menulis ulang teks judul dengan teks yang sama, atau menambahkan atribut). data- (pada tombol). Jalur teknisnya identik dengan varian sebenarnya.
2. Instrumen penundaan Catat waktu antara tampilan pertama (First Contentful Paint) dan penerapan perubahan. Cuplikan di bawah ini sudah cukup.
3. Biarkan proses tersebut berjalan hingga menyelesaikan satu siklus penuh. (setidaknya 2 minggu untuk meratakan efek hari kerja/akhir pekan) dengan target konversi Anda yang biasa, seperti yang didefinisikan dalam konfigurasi tujuan dan pelacakan.
4. Bacalah dua angka : waktu median dan persentil ke-90 (pengunjung lambat), kemudian selisih konversi antara A dan A'.

<script>
// À appeler dans le code de la variante A', juste après la modification
(function () {
  var fcp = performance.getEntriesByName('first-contentful-paint')[0];
  var applique = performance.now();
  var delai = fcp ? Math.round(applique - fcp.startTime) : null;
  // delai > 0 : la variante s'applique APRÈS le premier affichage = flicker visible
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: 'flicker_delay', flicker_ms: delai });
})();
</script>

Cara menafsirkan

• Penundaan negatif atau nol Varian ini diterapkan sebelum rendering pertama. Tidak akan terjadi kedipan.
• Penundaan median kurang dari 100 ms Kedipan jarang dirasakan secara sadar, tetapi cukup untuk dilihat (ingat 13 ms). Pantau persentil ke-90.
• Penundaan median lebih besar dari 300 ms Kedipan terlihat oleh sebagian besar pengunjung. Jangan menjalankan pengujian apa pun di halaman ini sampai integrasi telah diperbaiki.
• Perbedaan konversi yang signifikan antara A dan A' Mekanisme injeksi itu sendiri memiliki efek yang terukur. Semua pengujian Anda pada templat ini mengalami bias ini.

Angka ini menunjukkan ukuran efek minimum yang dapat diinterpretasikan pada halaman ini. Jika A/A' menunjukkan −2% untuk A', varian yang memperoleh +1,5% sebenarnya dapat memperoleh +3,5%, dan varian pada −1% mungkin bersifat netral.

9 koreksi konkret, dari yang paling menguntungkan hingga yang paling mahal

Sebagian besar kedipan dapat diperbaiki tanpa mengubah alat: dengan memindahkan skrip, meringankannya, dan membuat kode varian dalam CSS daripada JavaScript. Berikut adalah tuas-tuas tersebut, diurutkan berdasarkan rasio usaha/keuntungan.

1. Letakkan cuplikan tersebut di bagian atas. <head>, Sebelum CSS dan skrip pihak ketiga lainnya. Keuntungan langsung, hanya butuh lima menit kerja.
2. Keluar dari skrip pengujian dari Google Tag Manager. Integrasikan secara permanen ke dalam template. Perbedaan 400ms yang diukur oleh Simo Ahava berasal dari hal ini.
3. Tambahkan preconnect ke domain yang menjalankan skrip tersebut (<link rel="preconnect" href="…">) untuk membuka koneksi bahkan sebelum browser menemukan tag tersebut.
4. Buat kode untuk modifikasi visual menggunakan CSS. Aturan CSS yang disuntikkan ke dalam <head> diterapkan segera setelah elemen digambar, tanpa menunggu elemen tersebut ada di DOM. Ubah warna, sembunyikan blok, atau susun ulang dua elemen dengan order penggunaan flexbox tidak memerlukan JavaScript. Ini juga merupakan rekomendasi dalam dokumentasi. Optimizely pada varian yang berkedip.
5. Bersihkan kode yang dihasilkan oleh editor visual : Hapus selektor yang berlebihan, kelompokkan modifikasi pada elemen yang sama, hindari penulisan ulang blok HTML secara keseluruhan jika perubahan teks sudah cukup.
6. Arsipkan hasil pengujian yang telah selesai. Setiap pengujian yang dijeda dan tetap ada dalam konfigurasi akan meningkatkan ukuran file untuk semua pengunjung.
7. Hanya area yang diuji yang disembunyikan., dengan waktu tunggu yang singkat (1000-1500 ms), bukan seluruh halaman selama 4 detik.
8. Hindari pengujian pengalihan pada halaman dengan lalu lintas masuk yang tinggi. Pengalihan ke URL B setelah memuat URL A mengakibatkan dua kali pemuatan halaman: ini adalah bentuk flicker yang paling mahal.
9. Sajikan skrip dari CDN yang dekat dengan pengunjung Anda., dengan konfigurasi yang dibatasi hanya pada pengujian yang aktif di halaman yang dikunjungi. Ini adalah faktor yang paling sedikit bisa Anda kendalikan, karena bergantung pada alatnya: tanyakan kepada penyedia Anda atau lihat halaman tentang distribusi skrip BlastOptimize sedekat mungkin dengan pengunjung.

Kapan harus beralih ke sisi server?

Pengujian sisi server menghilangkan kedipan layar secara sengaja: server memilih varian dan mengirimkan HTML yang benar secara langsung; tidak ada skrip yang menulis ulang halaman di browser. Kelemahannya sudah diketahui: setiap pengujian melalui pengembang, editor visual menjadi tidak dapat digunakan, dan siklus iterasi menjadi lebih panjang. Pengujian sisi server dibenarkan untuk pengujian elemen struktural (algoritma penetapan harga, proses pembayaran, navigasi), untuk halaman di mana penyimpangan sekecil apa pun dalam LCP (Life Cycle Principle) akan menimbulkan biaya yang besar, atau ketika analisis A/A Anda mengungkapkan bias yang tidak dapat diatasi oleh sembilan koreksi yang disebutkan di atas. Untuk pengujian judul, visual, atau tombol, pendekatan sisi klien yang terintegrasi dengan baik tetap lebih cepat untuk diimplementasikan. Pilihan arsitektur ini layak mendapatkan panduan tersendiri, yang akan kami dedikasikan untuk pengujian sisi server.

Daftar periksa anti-kedip sebelum setiap peluncuran

Sebelum meluncurkan pengujian ke tahap produksi, periksa sepuluh poin ini. Hanya satu "tidak" pada empat poin pertama sudah cukup untuk menunda peluncuran.

• ☐ Cuplikan kode tersebut dikodekan secara permanen di dalam <head>, di posisi pertama di antara skrip, tidak termasuk pengelola tag.
• ☐ Mode pemuatan (sinkron/asinkron) diketahui dan didokumentasikan untuk halaman ini.
• ☐ Varian tersebut telah diverifikasi pada ponsel pintar sungguhan dengan jaringan yang dibatasi ke "4G lambat" di dalam alat pengembangan.
• ☐ Jeda antara tampilan pertama dan penerapan varian diukur (median dan persentil ke-90).
• ☐ Modifikasi visual dilakukan di CSS jika memungkinkan.
• ☐ Jika masking digunakan, maka masking akan menargetkan area yang diuji dan waktu tunggunya ≤ 1500ms.
• ☐ LCP halaman dengan dan tanpa pengujian dibandingkan (perbedaan target: kurang dari 100 ms).
• ☐ Tes yang telah selesai telah diarsipkan dari akun.
• ☐ Tidak ada uji coba pengalihan yang diluncurkan pada halaman masuk utama tanpa alasan yang kuat.
• ☐ Tes 'A/A' telah dilakukan pada templat halaman ini selama 6 bulan terakhir.

Flickr ditambahkan ke dalam daftar kesalahan umum dalam pengujian A/B yang membatalkan suatu pengujian bahkan sebelum analisis statistik. Hal ini menjadi lebih berbahaya lagi pada tes multivariat, di mana beberapa area dimodifikasi secara bersamaan dan di mana setiap kombinasi dapat menghasilkan kilatan yang berbeda, dan pada situs e-commerce, di mana halaman produk memuat banyak gambar dan skrip pihak ketiga.

Pertanyaan yang Sering Diajukan (FAQ)

Apakah efek kedip berdampak pada SEO?

Secara tidak langsung, ya. Kedipan itu sendiri bukanlah penalti, tetapi perbaikan yang diimplementasikan dengan buruk adalah penalti: anti-kedipan yang mengaburkan halaman menurunkan LCP (Low Page Content), dan varian yang menyisipkan blok meningkatkan CLS (Cumulative Layout Shift). Kedua metrik ini merupakan bagian dari Core Web Vitals yang dipertimbangkan oleh Google. Bandingkan data bidang dari Search Console pada halaman yang diuji dan yang belum diuji untuk memverifikasi hal ini.

Perangkat saya mengklaim "100% bebas kedip": dapatkah saya mempercayainya?

Tanyakan caranya. "Bebas kedipan" seringkali berarti "dengan masking": kedipan menghilang, tetapi halaman dimuat kemudian. Periksa tiga hal: metode pemuatan cuplikan, nilai batas waktu masking, dan perbedaan LCP yang diukur dengan dan tanpa skrip. Tes A/A akan menyelesaikan masalah ini di situs Anda sendiri. Anda akan menemukan perbedaan pendekatan dalam panduan kami. komparatif BlastOptimize / Kameleoon dan dalam diri kita perbandingan dengan AB Tasty.

Apakah cuplikan sinkron benar-benar memperlambat situs saya?

Ini menunda tampilan awal pengunduhan skrip dan waktu eksekusi. Dengan file kecil yang disajikan dari CDN, perbedaannya hanya beberapa puluh milidetik. Dengan file besar atau server yang lambat, perbedaannya bisa mencapai ratusan milidetik, dan gangguan penyedia layanan dapat memblokir halaman hingga waktu habis jaringan. Ukur LCP dengan dan tanpa cuplikan kode tersebut sebelum mengambil keputusan.

Bisakah saya mengunggah alat pengujian A/B saya melalui Google Tag Manager?

Secara teknis ya, tetapi konfigurasi ini menghasilkan kedipan paling banyak karena GTM memuat tag-nya secara asinkron. Pengukuran yang dipublikasikan menunjukkan sekitar 400ms masking tambahan dibandingkan dengan integrasi langsung. Gunakan GTM hanya untuk memicu peristiwa pelacakan, bukan untuk skrip yang memodifikasi halaman.

Apakah banner persetujuan memperburuk flicker?

Bisa saja. Jika alat pengujian Anda hanya memuat setelah cookie diterima, atau jika platform manajemen persetujuan memblokir skrip saat membaca pilihan pengunjung, penerapan varian akan tertunda. Periksa urutan eksekusi antara banner dan cuplikan pengujian dalam sesi yang bersih, tanpa cookie.

Poin-poin penting

• Efek kedip adalah tampilan singkat halaman asli sebelum varian ditampilkan. Ini khusus untuk pengujian sisi klien.
• Ini bukan sekadar cacat visual sederhana: ini secara sistematis memengaruhi perbandingan, karena hanya satu dari dua kelompok yang mengalaminya.
• Penyebab utamanya adalah penempatan skrip yang buruk, proses melalui GTM, pemuatan asinkron, ukuran file yang terlalu besar, dan varian yang dikodekan dalam JavaScript dan bukan CSS.
• Fitur anti-kedip menutupi gejalanya tetapi menunda tampilan: targetkan area yang diuji dan pertahankan waktu tunggu ≤ 1500ms.
• Ukur sebelum Anda melakukan koreksi: tes A/A' memberikan biaya sebenarnya dari mekanisme injeksi di lokasi Anda.
• Sisi server secara sengaja menghilangkan kedipan, dengan konsekuensi ketergantungan pada pengembang.

Anda ingin melihat bagaimana BlastOptimize apakah menu tersebut menyajikan variannya? Lihat di sini penawaran dan harga untuk meluncurkan pengujian A/A awal di situs Anda.