Villogás az A/B tesztben: miért torzítja az eredményt, és hogyan kerüld el

Scheo · 2026-10-29 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha kliensoldali eszközzel futtatsz A/B tesztet, a látogató böngészője először az eredeti oldalt kapja meg, és a tesztelő szkript csak ezután írja át a kiválasztott változat szerint. Ha az átírás késik, a látogató egy pillanatra az eredeti címsort, gombot vagy képet látja, aztán az oldal hirtelen átvált. Ezt hívják villogásnak (angolul flicker, néha FOOC, vagyis flash of original content). Elsőre kozmetikai hibának tűnik, pedig a mérésedet és a Core Web Vitals mutatóidat is ronthatja. Az alábbiakban végigmegyünk azon, mi történik ilyenkor a böngészőben, melyik megoldás hogyan hat a sebességre, és hogyan veszed fel videóra a villogást, mielőtt élesben elindítod a tesztet.

Mi az a villogás (flicker) az A/B tesztben?

A villogás az a rövid időszak, amíg a látogató a teszt B változata helyett az eredeti A változatot látja, mert a módosító szkript később fut le, mint ahogy a böngésző kirajzolja az oldalt. Gyors kapcsolaton ez néhány száz ezredmásodperc, lassú mobilneten akár egy másodpercnél is hosszabb lehet.

A folyamat lépései jól követhetők. A böngésző letölti a HTML-t, elkezdi feldolgozni, és amint tudja, kirajzolja az első tartalmat. A tesztelő eszköz szkriptje közben egy külső szerverről töltődik le, lekéri a beállításokat, eldönti, melyik csoportba kerül a látogató, és csak ezután módosítja a DOM-ot. Ha a kirajzolás megelőzi a módosítást, a látogató látja az átmenetet. Minél nagyobb a szkript, minél lassabb a hálózat, és minél több más szkript versenyez a fő szálért (címkekezelő, chatablak, süti-sáv), annál hosszabb a villanás.

Szerveroldali tesztnél ez a jelenség nem lép fel, mert a szerver már a kiválasztott változat HTML-jét küldi el. A villogás tehát a böngészőben futó, utólag átíró megoldások mellékhatása. Gyakori súlyosbító tényező, ha a tesztszkriptet a Google Címkekezelőn keresztül töltöd be, mert így előbb a címkekezelőnek kell letöltődnie és lefutnia, és csak utána indul a tesztszkript letöltése.

Miért torzítja a villogás a teszt eredményét?

A villogás azért torzít, mert a B csoport látogatói valójában két változatot látnak egymás után, és a B változat ráadásul később jelenik meg, így a mért különbségbe a késés és a zavaró váltás hatása is belekeveredik.

Három mechanizmust érdemes külön kezelni.

• Szennyezett expozíció. A B csoportba sorolt látogató egy pillanatig az A változatot látja. Ha a teszt egy új címsort vizsgál, a látogató mindkettőt elolvashatja, így a reakciója már nem tisztán a B változatra vonatkozik.
• Aszimmetrikus sebesség. Az A csoportnál általában nincs átírás, a B csoportnál van. Ha a B változat emiatt lassabbnak érződik, a gyengébb eredményt a sebesség is okozhatja, és egy jó ötletet feleslegesen vetsz el.
• Figyelemterelés. A mozgó, ugráló oldal feltűnő. Egyes látogatók épp a változásra figyelnek fel, ami a B változat felé billentheti a kattintásokat (újdonsághatás), mások zavarónak érzik, és kilépnek.

Szakmai feltételezés. Az, hogy a villogás melyik irányba torzít, oldalanként eltér. Előfordulhat, hogy felnagyítja a különbséget, és az is, hogy eltakarja. Ezért egy villogva futott tesztből levont következtetést óvatosan kezelj, akkor is, ha a tesztelő eszköz szignifikánsnak mutatja.

Saját tapasztalat. A leglátványosabb villanást a hajtás feletti, vagyis az első képernyőn látható elemek cseréje okozza, például a fő címsor, a nagy fejléckép vagy a fő gomb szövege. Az oldal alján végzett változtatásnál a látogató jellemzően oda sem ér, mire az átírás lefut.

Hogyan rontja a villogás az LCP-t és a CLS-t?

A villogás ellen bevetett elrejtés jellemzően késlelteti a legnagyobb tartalmi elem megjelenését (LCP), az utólagos DOM-módosítás pedig elrendezés-elmozdulást okozhat, ami a CLS-értéket növeli.

Hivatalosan igazolt. A web.dev dokumentációja szerint az LCP jó értéke legfeljebb 2,5 másodperc, a CLS-é legfeljebb 0,1, a valós felhasználók 75. percentilisén mérve. Az LCP-definíció azt is rögzíti, hogy a nulla átlátszóságú, a felhasználó számára láthatatlan elemek nem számítanak LCP-jelöltnek. Ebből következik, hogy ha egy elrejtő szkript az egész oldalt átlátszóvá teszi, az LCP addig nem rögzül, amíg az elrejtés le nem kerül.

A CLS-nél akkor van gond, ha az átírás más méretű elemet tesz a régi helyére. Ha a B változat címsora két sorral hosszabb, vagy egy új sávot szúr be a fejléc alá, minden alatta lévő tartalom lejjebb ugrik. A böngésző ezt váratlan elmozdulásként számolja, mert nem a felhasználó váltotta ki. A web.dev leírása szerint csak a felhasználói interakciót követő 500 ezredmásodpercen belüli elmozdulás mentesül, a betöltéskor lefutó tesztszkript ebbe nem tartozik bele.

Az INP-re is hathat a teszt, ha a szkript hosszú feladatokkal foglalja a fő szálat épp akkor, amikor a látogató először kattint. Ez főleg nagy, sok változatot tartalmazó tesztkonfigurációknál fordul elő.

Milyen megoldások vannak a villogás ellen, és hogyan hatnak a sebességre?

Négy fő út van. Az elrejtő szkript eltünteti a villanást, cserébe késlelteti a megjelenést. Az aszinkron betöltés gyors, de villog. A szerveroldali és az edge-oldali szétosztás villogás nélkül működik, viszont fejlesztői munkát kér.

1. Elrejtő szkript (anti-flicker snippet)

Az elrejtő szkript a fejléc legelején átlátszóvá teszi az oldalt vagy annak egy részét, és csak akkor fedi fel, amikor a tesztelő eszköz jelzi, hogy végzett, vagy amikor lejár egy időkorlát. A 2023-ban megszűnt Google Optimize is ilyen kódrészletet adott, alapértelmezetten 4000 ezredmásodperces korláttal, és a legtöbb kliensoldali eszköz ma is hasonló megoldást használ. Egy leegyszerűsített, csak a tesztelt szekciót elrejtő változat így néz ki.

<style>.ab-rejt .hero{opacity:0 !important}</style>

<script>document.documentElement.classList.add('ab-rejt');setTimeout(function(){document.documentElement.classList.remove('ab-rejt')},800);</script>

A tesztelő eszköz a módosítás után maga veszi le az ab-rejt osztályt. Az időkorlát vészfék arra az esetre, ha a szkript nem töltődik be.

Hatás a teljesítményre. A villanás eltűnik, az LCP viszont annyival csúszhat, ameddig az elrejtés tart. Ha az egész html elemet rejted el 4 másodpercig, és a tesztszkript lassú hálózaton nem érkezik meg, a látogató 4 másodpercig fehér oldalt néz. Ezért csak a tesztelt területet rejtsd el (a példában a .hero szekciót), és az időkorlátot vedd lényegesen rövidebbre, jellemzően 500 és 1000 ezredmásodperc közé. Saját tapasztalat. Szűkített elrejtéssel és rövid korláttal a villanás a látogatók többségénél eltűnik, a nagyon lassú kapcsolatúak pedig legrosszabb esetben az eredeti változatot látják, üres képernyő helyett.

2. Aszinkron vagy szinkron betöltés elrejtés nélkül

Aszinkron betöltésnél a tesztszkript async attribútummal töltődik, nem blokkolja a kirajzolást, és nincs elrejtés. Az oldal ugyanolyan gyorsan jelenik meg, mint teszt nélkül, a változat viszont utólag cserélődik, így a villogás szinte mindig látszik.

Hatás a teljesítményre. Az LCP az A változat elemére rögzülhet, majd a csere után újra, ha a B elem nagyobb. A CLS romlik, ha a csere mérete eltér. Ezt a módszert csak hajtás alatti, kis méretű módosításoknál tartjuk elfogadhatónak.

A másik véglet a szinkron, blokkoló betöltés a fejlécben. Ilyenkor nincs villogás, de minden oldalbetöltés a külső tesztszerver sebességéhez kötődik, az első tartalom és az LCP is később jelenik meg, és ha a tesztszerver kiesik, az egész oldal megáll. Ezt csak akkor válaszd, ha az eszköz gyártója kifejezetten ezt javasolja, és a szkript kicsi.

3. Szerveroldali szétosztás

A szerver (vagy a CMS, a webshopmotor) dönti el, melyik csoportba kerül a látogató, a döntést egy sütiben eltárolja, és rögtön a megfelelő HTML-t küldi. A böngészőnek nincs mit átírnia, ezért villogás sincs.

Hatás a teljesítményre. Nincs elrejtés és nincs utólagos DOM-csere, így az LCP és a CLS a két változatnál azonos alapon mérhető. Két dologra figyelj. Ha az oldal teljes oldalas gyorsítótárból jön (WordPressnél ez a cache bővítmény), a gyorsítótár kulcsába bele kell venni a csoport sütijét, különben minden látogató ugyanazt a változatot kapja. A sütifüggő gyorsítótárazás ugyanakkor csökkentheti a találati arányt, ami a szerver válaszidejét (TTFB) ronthatja, ezért a változatonkénti gyorsítótárat érdemes tudatosan beállítani.

4. Edge-oldali szétosztás

Az edge-megoldás a CDN peremszerverén fut, például Cloudflare Workers, Vercel Edge Middleware vagy Fastly Compute alatt. A kérés még a származási szerver előtt átfut egy rövid függvényen, ami csoportot választ, beállítja a sütit, és vagy a változat útvonalára írja át belsőleg a kérést, vagy a HTML-t módosítja továbbítás közben. Egy vázlat a csoportválasztásra.

const m = (request.headers.get('Cookie') || '').match(/ab_hero=(A|B)/);

const csoport = m ? m[1] : (Math.random() < 0.5 ? 'A' : 'B');

const url = new URL(request.url); if (csoport === 'B') url.pathname = '/b' + url.pathname;

A válaszhoz ezután hozzáadod a Set-Cookie fejlécet a csoport értékével, hogy a látogató a következő oldalon is ugyanabban a csoportban maradjon.

Hatás a teljesítményre. Villogás nincs, a peremszerveren futó döntés jellemzően néhány ezredmásodpercet vesz igénybe, és a változatok külön-külön gyorsítótárazhatók. Szakmai feltételezés. Kis és közepes oldalaknál ez adja a legjobb arányt a sebesség és a fejlesztési munka között, mert a meglévő CMS-hez alig kell hozzányúlni. Hátránya, hogy CDN-hozzáférés kell hozzá, és valakinek karban kell tartania a kódot.

Melyiket válaszd?

• Elrejtő szkript akkor jó, ha kliensoldali eszközt használsz, és a tesztelt elem a hajtás felett van. Szűkített elrejtéssel és rövid korláttal az LCP-romlás kezelhető.
• Aszinkron betöltés elrejtés nélkül csak kis, hajtás alatti változtatásra való, mert látható villogással jár.
• Szerveroldali szétosztás akkor éri meg, ha van fejlesztőd, és a teszt a sablont, az oldalszerkezetet vagy a pénztárfolyamatot érinti.
• Edge-oldali szétosztás akkor jó, ha már CDN mögött van az oldalad, és villogás nélküli, gyors tesztet szeretnél a CMS átírása nélkül.

Hogyan veszed fel a villogást lassított hálózattal?

A Chrome DevTools Performance paneljén hálózati és processzor-lassítással felvett képsor ezredmásodperc pontossággal megmutatja, mikor látszik az eredeti tartalom, és mikor jelenik meg a változat.

1. Nyisd meg a tesztelt oldalt inkognitó ablakban, hogy a bővítmények és a régi sütik ne zavarjanak. Ha az eszköz enged kényszerített csoportot (például URL-paraméterrel vagy előnézeti linkkel), állítsd a B változatra.
2. Nyisd meg a DevToolst (F12), a Network fülön kapcsold be a Disable cache opciót, a hálózati lassításnál pedig válaszd a Slow 4G profilt.
3. A Performance fülön a beállításoknál válassz 4x CPU-lassítást, és kapcsold be a Screenshots opciót.
4. Indítsd a felvételt a Record and reload gombbal, és várd meg a betöltés végét.
5. A képsorban keresd meg azt a kockát, ahol először látszik tartalom, és azt, ahol a B változat megjelenik. A kettő közti idő a villanás hossza. A Timings sávban látod az LCP jelölőjét is, a Layout shifts sávban pedig a CLS-t okozó elmozdulásokat.
6. Ismételd meg legalább háromszor, mert az egyes mérések szórnak, és vedd fel ugyanígy az A változatot is összehasonlításnak.

Ha videót szeretnél mutatni a csapatnak, a WebPageTest filmszalag-nézete és videóexportja ugyanezt mutatja egy választott mobilprofilon. Egyszerű képernyőfelvétel is megteszi, ha a lassítás be van kapcsolva, és a felvételt lassítva nézed vissza.

Saját tapasztalat. Gyors irodai kapcsolaton a villanás gyakran észrevétlen marad, ezért a lassítás nélküli „megnéztem, nem villog” ellenőrzés félrevezető. A mobilos látogatók egy része gyengébb hálózaton érkezik, és nekik a lassított felvétel áll közelebb a valósághoz.

Mit ellenőrizz az A/B teszt indítása előtt?

Indítás előtt nézd meg, hogyan töltődik a szkript, mekkora területet és meddig rejt el, látszik-e villanás lassított felvételen, és egyformán mérik-e mindkét csoportot.

• Kliensoldali tesztnél a tesztszkript a fejléc elején töltődik, és nem a címkekezelőn keresztül, késve.
• Az elrejtés csak a tesztelt szekcióra vonatkozik, és az időkorlát 1000 ezredmásodperc alatt van.
• A lassított felvételen (Slow 4G, 4x CPU) a B változatnál nem látszik az eredeti tartalom.
• A B változat elemei ugyanakkora helyet foglalnak, mint az A elemei, vagy fenntartott helyük van (min-height, aspect-ratio).
• Az A csoport is ugyanazt a szkriptet és elrejtést kapja, hogy a két csoport sebessége összevethető legyen.
• A konverziós mérés (GA4-esemény, hirdetési pixel) mindkét változatban ugyanúgy és ugyanott sül el.
• A csoport-hozzárendelés sütiben megmarad, a visszatérő látogató nem vált csoportot.
• Ha külön URL-en fut a változat, ideiglenes (302) átirányítást és a változaton az eredetire mutató canonical címkét használsz, ahogy a Google Search Central tesztelési útmutatója javasolja.
• A teszt alatt figyeled a valós felhasználói adatot (saját RUM-mérés, CrUX, Search Console Core Web Vitals jelentés), és összeveted a teszt előtti állapottal.
• Feljegyezted a teszt kezdőnapját, hogy egy későbbi sebességváltozást vissza tudj kötni hozzá.

Mit kezdj egy olyan teszttel, ami már villogva futott?

Egy villogva futott teszt eredményét ne dobd ki azonnal, de ne is építs rá nagy döntést, inkább ismételd meg javított betöltéssel.

Először vedd fel lassított hálózaton a villanást, hogy lásd, mekkora volt. Ha csak hajtás alatti elemet érintett, és a villanás rövid, az eredmény jó eséllyel használható. Ha a fő címsor vagy a fejléckép cserélődött látványosan, nézd meg a tesztelő eszközben vagy a GA4-ben eszköz szerint is az eredményt. Ha a különbség mobilon jóval kisebb vagy ellentétes, mint asztali gépen, az arra utal, hogy a lassabb betöltés is beleszólt. Ilyenkor javítsd ki a betöltést (szűkített elrejtés, edge-oldali szétosztás), és futtasd újra a tesztet ugyanazzal a hipotézissel.

Mi hivatalos információ ebben a témában, és mi tapasztalat?

A mérőszámok definíciói és a keresőbarát tesztelés szabályai hivatalos forrásból származnak, a villogás eredményre gyakorolt hatása viszont oldalanként eltér, és ezt csak a saját oldaladon végzett méréssel tudod meg.

• Hivatalosan igazolt. Az LCP és a CLS küszöbértékei, a láthatatlan elemek kizárása az LCP-jelöltek közül és az interakció utáni 500 ezredmásodperces CLS-mentesség a web.dev dokumentációjában szerepel. A Google Search Central tesztelési útmutatója tiltja az álcázást (cloaking), és ideiglenes átirányítást, canonical címkét és csak a szükséges ideig futó teszteket javasol.
• Saját tapasztalat. A hajtás feletti elemek cseréje villog a legjobban, a szűkített elrejtés rövid korláttal a legtöbb látogatónál megszünteti a villanást, gyors kapcsolaton pedig a hiba gyakran rejtve marad.
• Szakmai feltételezés. A villogás torzításának iránya oldalfüggő. A rövid ideig tartó, kisebb LCP-romlás a keresési láthatóságot jó eséllyel alig érinti, mert a CrUX 28 napos ablakon összesít, egy hónapokig futó, lassító teszt viszont már látszhat a mutatókban. Ezt a Google nem erősítette meg számszerűen.

Források és további olvasnivalók

• web.dev, Largest Contentful Paint (LCP)
• web.dev, Cumulative Layout Shift (CLS)
• web.dev, Interaction to Next Paint (INP)
• Google Search Central, A/B tesztek és webhelykísérletek minimális hatással a Google Keresésre
• Chrome for Developers, Chrome DevTools Performance panel dokumentáció
• Chrome UX Report (CrUX) dokumentáció
• W3C, Largest Contentful Paint és Layout Instability specifikáció
• Cloudflare Workers dokumentáció