Pengujian sisi server: pengujian klien, server, atau edge untuk pengujian A/B bebas kedip Anda.

Diperbarui pada 20 Oktober 2026

Peningkatan kecepatan seluler sebesar 0,1 detik meningkatkan rasio konversi sebesar 8,4% pada situs ritel yang diteliti oleh Deloitte untuk Google, dan pengiriman formulir sebesar 21,6% pada situs penghasil prospek. Angka ini menimbulkan pertanyaan yang kurang menyenangkan bagi tim CRO mana pun: apakah alat pengujian A/B Anda menyebabkan Anda kehilangan sebagian keuntungan yang ingin Anda ukur karena latensi?

Pengujian sisi server mengatasi pertanyaan ini dengan memindahkan keputusan "siapa yang melihat versi mana" keluar dari browser. Namun, arsitektur ini memiliki biaya tersendiri: keterlibatan pengembang, kebutuhan untuk mendesain ulang cache CDN, dan penghitungan pengunjung yang lebih kompleks. Panduan ini membandingkan tiga lokasi yang mungkin untuk keputusan ini (browser, server, edge), menjelaskan peran feature flag, dan menyediakan kerangka kerja untuk memilih, pengujian demi pengujian.

Pengujian sisi server: jawaban singkatnya

Pengujian sisi server adalah metode pengujian A/B di mana server memilih varian untuk setiap pengunjung dan mengembalikan halaman yang sudah dibuat, tanpa modifikasi lebih lanjut di browser: oleh karena itu tidak ada kedipan atau skrip pengujian yang menunda tampilan. Sebagai imbalannya, setiap varian harus dikodekan dan diimplementasikan oleh tim teknis.

Dalam praktiknya, server membaca pengidentifikasi tetap (cookie, ID pengguna yang masuk), menghitung penugasan, dan kemudian merender templat yang sesuai. Varian B bukanlah "versi A yang dimodifikasi oleh JavaScript": ini adalah halaman yang berbeda, atau perilaku aplikasi yang berbeda, yang disajikan sejak byte pertama.

Perbedaan ini membuka ruang lingkup yang tidak dapat dicakup dengan baik oleh pengujian sisi klien: algoritma rekomendasi, aturan penetapan harga, urutan hasil pencarian, jumlah langkah dalam alur penjualan, dan logika API yang digunakan oleh situs web dan aplikasi seluler. Untuk definisi dasar (varian, alokasi, sampel), glosarium pengujian A/B menjelaskan kosakata yang digunakan di bagian selanjutnya dari artikel ini.

Klien, server, edge: di mana keputusan dibuat?

Pada dasarnya, semua pengujian A/B bermuara pada keputusan alokasi dan rendering. Yang membedakan arsitektur adalah di mana keputusan ini dibuat dan kapan rendering berlangsung.

Di sisi klien: keputusan dibuat di browser.

Server mengembalikan halaman asli. Skrip pengujian dimuat, memilih varian, dan kemudian memodifikasi DOM (teks, warna, urutan blok). Ini adalah model yang digunakan oleh editor visual: seorang pemasar membuat varian dalam hitungan menit, tanpa tiket pengembangan. Harga yang harus dibayar adalah jeda waktu antara menampilkan halaman asli dan menerapkan varian.

Sisi server: keputusan di dalam aplikasi.

Aplikasi (PHP, Node, Python, Java, dll.) menggabungkan SDK atau logika penugasan. Keputusan dibuat sebelum rendering HTML. Pengujian berada di dalam kode: satu kali deployment untuk membuat varian, dan pembersihan di akhir.

Di ujung jurang: keputusan di CDN

Sebuah fungsi yang berjalan di jaringan pengiriman (Cloudflare Workers, Vercel Routing Middleware, Lambda@Edge, Fastly Compute) mencegat permintaan sebelum mencapai server asal. Fungsi tersebut membaca atau mengatur cookie penugasan, kemudian menulis ulang URL ke versi A atau B, yang keduanya telah dibuat sebelumnya dan disimpan dalam cache.

Biaya milidetik

Kecepatan bukanlah masalah teknis sekunder: di 37 situs merek dan lebih dari 30 juta sesi, peningkatan 0,1 detik pada empat indikator kecepatan meningkatkan kemajuan di seluruh saluran pembelian. Studi tersebut Milliseconds Make Millions yang diterbitkan di web.dev merinci hasil berdasarkan sektor: +8,4% konversi di sektor ritel, +10% pemesanan di sektor perjalanan, +21,6% formulir yang dikirim dalam pembuatan prospek.

Bandingkan angka-angka ini dengan pengujian sisi klien yang dikonfigurasi dengan buruk. Cuplikan anti-kedip yang umum membuat halaman tidak terlihat sampai pengunjung ditugaskan, dengan penundaan keamanan yang sering diatur ke 4 detik: empat puluh kali lipat dari 100 milidetik dalam penelitian. Pengujian kemudian mengukur efek dari varian Anda ditambah efek dari penundaan tersebut, dan tidak ada jaminan bahwa penundaan ini akan identik antara A dan B.

Alat-alat sisi klien terbaru telah mengurangi masalah ini. Beberapa vendor mengiklankan skrip terkompresi berukuran 11 hingga 15 KB dan penerapan varian tersebut dalam beberapa puluh milidetik, dibandingkan dengan 80 hingga 150 KB untuk alat-alat lama. Ini persis logika dari difusi sangat cepat dari BlastOptimize Pendekatan pertama mengurangi jeda waktu antara tampilan awal dan varian hingga hampir tidak terlihat. Pendekatan sisi server melangkah lebih jauh dengan menghilangkan jeda waktu ini, dengan konsekuensi implementasi yang lebih kompleks. Kedua pendekatan tersebut tidak saling eksklusif; keduanya hanya mencakup jenis pengujian yang berbeda.

Biaya sebenarnya dari pengembangan sisi server bukanlah nol.

Menghilangkan flicker tidak berarti menghilangkan latensi. SDK yang menanyakan API jarak jauh pada setiap permintaan untuk mengetahui alokasi menambahkan satu perjalanan pulang-pergi jaringan sebelum rendering. Praktik terbaiknya adalah evaluasi lokal: SDK mengunduh konfigurasi pengujian di latar belakang, menyimpannya di memori, dan menghitung alokasi tanpa panggilan jaringan. Di sisi edge, Vercel menyatakan bahwa 99% pembacaan konfigurasi dari penyimpanan globalnya memerlukan waktu kurang dari 15 ms. Tanpa langkah pencegahan ini, Anda hanya memindahkan penundaan dari browser ke server.

Fitur unggulan: mesin pengujian sisi server

Feature flag adalah sebuah saklar dalam kode yang menentukan, untuk setiap pengguna, versi fitur mana yang akan dijalankan; begitu menawarkan beberapa nilai yang didistribusikan sebagai persentase, itu menjadi pengujian A/B sisi server. Inilah mengapa sebagian besar platform eksperimen sisi server dibangun berdasarkan sistem flag.

Skema umumnya sederhana: kode meminta nilai flag dari SDK. nouveau_tunnel untuk pengguna 8214, SDK mengembalikan "variant_b", aplikasi merender terowongan dalam dua langkah, bukan tiga. Penugasan bersifat deterministik: pengidentifikasi yang sama selalu memberikan varian yang sama, umumnya melalui hash dari ID yang dikombinasikan dengan kunci uji.

Apa yang dibawa bendera di luar ujian?

• Berhenti segera Jika varian tersebut menurunkan metrik pengaman (kesalahan server, waktu respons, nilai pesanan rata-rata), Anda dapat menghapusnya dari antarmuka tanpa melakukan penyebaran ulang.
• Pengerahan bertahap Varian yang menang meningkatkan trafik dari 50% hingga 100% secara bertahap, sambil memantau kesalahan.
• Konsistensi multi-saluran Bendera yang sama mengontrol situs web, aplikasi seluler, dan API. Pengunjung yang memulai dari perangkat seluler dan menyelesaikannya di desktop akan tetap berada dalam versi yang sama jika mereka teridentifikasi.

Hutang bendera

Setiap pengujian sisi server meninggalkan kode kondisional. Tim yang menjalankan sepuluh pengujian per kuartal tanpa pembersihan akan mendapati diri mereka, setahun kemudian, memiliki empat puluh cabang mati dalam kode mereka. Tetapkan aturan sederhana: sebuah flag pengujian memiliki tanggal akhir, dan menghapus cabang yang gagal adalah bagian dari definisi "selesai". Disiplin ini selaras dengan yang dijelaskan dalam artikel kami tentang... kesalahan umum dalam pengujian A/B : Tes yang tidak lengkap akan mencemari tes selanjutnya.

Pengujian di perangkat tepi (edge ​​testing): kompromi yang semakin populer.

Pengujian edge membuat keputusan penugasan di CDN, sebelum server asal, dan menyajikan versi halaman yang telah dibuat sebelumnya: ini menggabungkan tidak adanya kedipan sisi server dengan kecepatan cache. Ini adalah arsitektur yang paling cocok untuk situs statis atau yang dihasilkan secara otomatis (Next.js, Astro, situs e-commerce headless).

Arsitektur referensi Cloudflare untuk pengujian A/B dengan Workers menjelaskan alurnya dalam lima langkah: permintaan pengunjung, membaca konfigurasi dari penyimpanan key-value, memeriksa cookie penugasan, mengarahkan ke endpoint A atau B, dan kemudian mengatur cookie jika belum ada. Distribusi berubah tanpa perlu melakukan deployment ulang fungsi.

Vercel membawa logika ini selangkah lebih maju: alih-alih membuat respons bergantung pada cookie, varian tersebut dikodekan dalam jalur URL internal. Setiap kombinasi flag menjadi halaman terpisah dalam cache, dan pengunjung tidak pernah melihat jalur teknis ini. Menurutnya panduan pengujian A/B dalam e-commerce dan Core Web Vitals, Metode ini memungkinkan sebuah tim untuk meningkatkan jumlah tes dari sekitar satu kali per bulan menjadi lima atau enam kali per sprint, tanpa menurunkan indikator kinerja mereka.

Batasan yang perlu diperhatikan: ledakan kombinatorial

Setiap pengujian melipatgandakan jumlah versi yang di-cache. Tiga pengujian simultan dengan dua varian pada halaman yang sama menghasilkan 2 × 2 × 2 = 8 versi. Tambahkan pengujian keempat dengan tiga varian dan Anda akan mendapatkan 24 versi. Tingkat keberhasilan cache secara otomatis menurun. Batasi jumlah pengujian bersamaan per templat, atau gunakan mode ini hanya untuk halaman dengan trafik tinggi. Jika Anda sengaja menggabungkan beberapa elemen, logikanya lebih mirip dengan... uji multivariat, dengan persyaratan volume yang sesuai.

Jebakan di sisi server

Sisi server menghilangkan kedipan tetapi memperkenalkan tiga risiko yang tidak dimiliki sisi klien: cache yang menyajikan varian yang salah, bot yang dihitung sebagai pengunjung, dan penugasan yang dicatat tanpa paparan nyata. Ketiga kesalahan ini mendistorsi hasil tanpa adanya sinyal yang terlihat di halaman tersebut.

1. Cache yang mencampur berbagai varian

Pertanyaan ini sering muncul di komunitas teknis, misalnya di forum Adobe Experience League: "Situs saya berada di belakang Akamai atau Cloudflare, bagaimana cara saya menguji sisi server?". Jika CDN menyimpan versi pertama yang dihasilkan dalam cache, semua pengunjung berikutnya akan menerimanya, terlepas dari penugasan mereka. Ada tiga solusi: mengintegrasikan varian ke dalam kunci cache (header Vary (dengan menggunakan cookie khusus, atau jalur internal seperti pada Vercel), pindahkan keputusan ke edge, atau kecualikan dari cache hanya halaman yang sedang diuji selama pengujian. Solusi ketiga adalah yang paling sederhana, tetapi meniadakan sebagian manfaat kecepatan.

2. Robot dan pra-pemuatan

Skrip sisi klien hanya berjalan di browser sungguhan. Namun, logika sisi server diterapkan pada setiap permintaan: robot pengindeks, alat pemantauan, dan pra-pemuatan browser spekulatif. Jika Anda menghitung pengunjung pada saat penugasan, permintaan ini akan memperbesar penyebut Anda. Robot tanpa cookie bahkan dapat ditugaskan ulang pada setiap kunjungan. Hasil yang mungkin terjadi adalah ketidaksesuaian rasio sampel antara A dan B, tanda klasik dari pengujian yang tidak valid. Jenis bias ini secara langsung memengaruhi hasil positif palsu dalam pengujian A/B.

3. Penugasan bukanlah pengungkapan

Server mungkin menetapkan pengguna ke varian B dari modul keranjang belanja baru saat login, meskipun mereka tidak akan pernah melihat keranjang tersebut. Memasukkan hal ini dalam analisis akan mengurangi efek yang terukur. Aturannya: catat peristiwa paparan saat varian tersebut benar-benar ditampilkan atau digunakan, dan hitung rasio konversi Anda berdasarkan paparan tersebut. Definisi ketat tentang konversi terkait berada di bawah. pemantauan tujuan, yang harus identik untuk A dan B.

Metode BlastOptimize: tiga angka yang perlu diperiksa

Sebelum menafsirkan rasio konversi dari pengujian sisi server, periksa tiga angka. Pertama, distribusi paparan: dalam pembagian 50/50 dari 20.000 pengunjung, perbedaan yang lebih besar dari sekitar 1,5 poin (yaitu, kurang dari 9.700 atau lebih dari 10.300 di satu sisi) perlu diselidiki, karena ini mewakili perbedaan lebih dari empat standar deviasi. Kedua, proporsi permintaan tanpa cookie atau JavaScript yang dieksekusi, yang mengungkapkan adanya bot. Ketiga, tingkat keberhasilan cache per varian. Jika salah satu dari ketiganya abnormal, perbaiki sebelum menganalisis. Pemeriksaan ini lebih mudah ditampilkan dalam sebuah tabel. dasbor analitik daripada ekspor bruto.

Pengujian sisi server dan SEO: Aturan Google

Google menerima pengujian A/B, baik sisi klien maupun sisi server, dengan satu syarat: Googlebot harus diperlakukan seperti pengunjung lainnya, tanpa versi khusus. Salah satu varian yang khusus ditujukan untuk robot adalah penyamaran, yang dapat dihukum tanpa memandang teknik yang digunakan.

Dokumentasi Google Search Central tentang dampak pengujian A/B menetapkan empat aturan. Tidak ada penyamaran, termasuk oleh logika server. Pengalihan sementara (302) dan bukan pengalihan permanen (301) jika varian tersebut berada di URL lain. Sebuah tag rel="canonical" pada URL varian yang mengarah ke aslinya, lebih disukai noindex. Dan sebuah pengujian yang berhenti segera setelah data yang terkumpul cukup, dengan URL dan kode pengujian kemudian dihapus.

Kesimpulan: karena varian tersebut ada dalam HTML asli, perayap dapat mengindeks versi B selama pengujian. Jika varian tersebut mengubah judul halaman yang berperingkat baik, batasi durasinya.

Kapan harus memilih apa: matriks pengambilan keputusan

Pilih sisi klien untuk menguji apa yang terlihat dengan cepat, sisi server untuk menguji apa yang dihitung, dan edge untuk menguji seluruh halaman pada situs yang banyak menggunakan cache. Sebagian besar tim yang berpengalaman menggunakan ketiganya tergantung pada pengujian, bukan tergantung pada alat yang digunakan.

Ajukan empat pertanyaan, dengan urutan sebagai berikut:

1. Apakah perubahan tersebut memengaruhi logika bisnis? Harga, algoritma, aturan kelayakan, jumlah langkah, respons API: sisi server, tidak perlu dibahas.
2. Apakah pengujian perlu mencakup beberapa saluran? Situs dan aplikasi, atau situs dan email transaksional: sisi server dengan flag bersama.
3. Apakah halaman tersebut disajikan dari cache atau dihasilkan secara statis? Edge, dengan varian dalam kunci cache.
4. Apakah perubahannya bersifat visual dan apakah harus diterapkan minggu ini? Judul, tagline, visual, urutan blok, label tombol: sisi klien dengan editor visual dan skrip yang ringan. Menunggu sprint untuk menguji label membutuhkan biaya lebih besar daripada milidetik yang dihemat.

Tiga contoh konkret

Seorang pedagang e-commerce ingin menguji pengiriman gratis untuk pembelian di atas €49, bukan €60. Ambang batas ini diperhitungkan dalam keranjang belanja, perhitungan biaya pengiriman, email konfirmasi, dan aplikasi: sisi server. Spesifikasi sektor ini dijelaskan secara rinci di halaman kami tentang pengujian A/B dalam e-commerce.

Vendor SaaS ingin membandingkan dua halaman harga lengkap, termasuk struktur dan alasannya, pada situs Next.js yang di-cache: edge, dengan dua template yang telah dibuat sebelumnya.

Tim pemasaran penghasil prospek ingin menguji tiga form hook sebelum kampanye yang dimulai pada hari Senin: sisi klien. Mode autopilot lalu mengambil alih untuk melanjutkan iterasi berikutnya.

Jika Anda membandingkan platform berdasarkan kriteria ini, perhatikan baik-baik apa yang dicakup oleh setiap penawaran: beberapa memisahkan eksperimen sisi klien dan modul fitur flag menjadi dua produk yang ditagih secara terpisah. Perbandingan kami BlastOptimize vs AB Tasty dan BlastOptimize vs Kameleoon menjelaskan perbedaan cakupan ini, dan daftar harga menunjukkan apa saja yang termasuk di dalamnya.

Daftar periksa sebelum meluncurkan pengujian sisi server

• Pengidentifikasi penugasan bersifat stabil (cookie pihak pertama yang berumur panjang atau ID pengguna yang masuk) dan identik di semua saluran yang relevan.
• SDK mengevaluasi flag secara lokal, tanpa memblokir panggilan jaringan pada setiap permintaan.
• Varian tersebut merupakan bagian dari kunci cache, atau halaman yang diuji dikecualikan dari cache selama pengujian berlangsung.
• Acara pameran dicatat pada saat pembuatan rendering sebenarnya, terpisah dari penugasan.
• Robot dan pramuat dikecualikan dari analisis (filter agen pengguna, eksekusi JavaScript, keberadaan cookie).
• Distribusi presentasi dikendalikan sejak 24 jam pertama.
• Googlebot menerima perlakuan yang sama seperti pengunjung; URL varian dengan pengalihan 302 dan pengalihan kanonik ke URL asli.
• Metrik pengaman (kesalahan, waktu respons server) dipantau, dengan kemungkinan penghentian tanpa penerapan.
• Tanggal penghapusan kode untuk varian yang kalah tercatat dalam backlog.

Pertanyaan yang Sering Diajukan (FAQ)

Apakah pengujian di sisi server benar-benar menghilangkan kedipan layar?

Ya, untuk elemen yang diuji di sisi server: halaman tiba dalam versi finalnya; tidak ada yang dimodifikasi setelah ditampilkan. Jika Anda menggabungkan pengujian sisi server dan pengujian sisi klien pada halaman yang sama, pengujian sisi klien masih dapat menyebabkan kedipan.

Bisakah pengujian sisi server dilakukan di balik CDN seperti Cloudflare atau Akamai?

Ya, asalkan varian tersebut merupakan bagian dari kunci cache, atau keputusan dibuat di edge. Jika tidak, CDN akan menyajikan versi cache pertama kepada semua orang, dan pengujian tersebut tidak lagi mengukur apa pun.

Apakah kedipan sisi klien masih menjadi masalah nyata di tahun 2026?

Risiko tersebut berkurang secara signifikan dengan skrip ringan yang dimuat lebih awal, yang menerapkan varian tersebut dalam beberapa puluh milidetik. Namun, risiko tersebut tetap nyata dengan skrip berat yang dimuat secara asinkron, atau cuplikan anti-kedip dengan penundaan keamanan beberapa detik.

Bisakah seorang pemasar meluncurkan pengujian sisi server tanpa seorang pengembang?

Tidak perlu membuat varian: varian tersebut harus sudah ada dalam kode. Namun, setelah flag terpasang, tim pemasaran dapat memodifikasi distribusi lalu lintas, penargetan, atau menghentikan pengujian dari antarmuka, tanpa perlu melakukan deployment ulang.

Apakah pengujian sisi server berisiko bagi SEO?

Tidak, jika sesuai dengan aturan Google: perlakuan yang sama untuk Googlebot dan pengunjung, pengalihan 302, tautan kanonik ke aslinya, dan durasi terbatas. Bahkan lebih mudah dibaca oleh perayap mesin pencari, karena varian tersebut ada di HTML asli.

Haruskah kita memilih antara sisi klien dan sisi server?

Tidak. Pendekatan hibrida adalah norma: sisi klien untuk pengujian visual cepat, sisi server untuk logika bisnis dan multi-channel, dan sisi tepi untuk halaman yang di-cache. Kuncinya adalah berbagi pengidentifikasi dan definisi konversi yang sama di ketiganya.

Poin-poin penting

• Pengujian sisi server memindahkan keputusan penugasan sebelum rendering: tidak ada lagi kedipan, tidak ada lagi skrip yang menunda tampilan.
• Feature flag adalah pendorong utama di balik ini, dengan adanya hutang kode yang perlu dibersihkan.
• Pengujian tepi menggabungkan operasi bebas kedip dan caching, dengan syarat ledakan jumlah versi dipantau.
• Tiga jebakan spesifik: cache yang mencampur berbagai varian, robot yang dihitung sebagai pengunjung, dan tugas yang dikacaukan dengan pameran.
• Pilih berdasarkan pengujian: visual dan mendesak di sisi klien, logika bisnis di sisi server, seluruh halaman di-cache di edge.

Untuk tes visual Anda, tantangannya tetap menjaga jendela penerapan varian di bawah ambang yang dapat dirasakan. Itulah tujuan dari pengiriman varian yang sangat cepat , dan glosarium BlastOptimize membahas setiap istilah teknis yang dibahas di sini.