- A Lighthouse nem szimulál interakciót, ezért a késleltetett scriptek a laborban nem terhelnek, a valós adatokban viszont a hatás jóval kisebb lehet.
- Késleltetett mérőkód mellett az interakció nélkül távozó látogató és a köszönőoldali konverzió kimaradhat a GA4-ből és a Meta-ból.
- A sütibanner scriptjét és a Consent Mode alapértelmezett blokkját mindig zárd ki, mert a hozzájárulási állapotnak a címkék előtt kell beállnia.
- A chat, a videó és a közösségi widgetek jó jelöltek a késleltetésre, az űrlap, a fizetés és a hajtás feletti csúszka nem.
- Tesztelj kijelentkezve, inkognitóablakban, előbb interakció nélkül, aztán interakcióval, és figyeld a DebugView-t és a Network fület.
A gyorsítóbővítmények egyik leglátványosabb kapcsolója a JavaScript késleltetése. A WP Rocket „Delay JavaScript execution” beállítása, a Perfmatters „Delay JavaScript” funkciója, a LiteSpeed Cache késleltetett JS-betöltése és a FlyingPress hasonló opciója ugyanarra az elvre épül. A scriptek nem futnak le az oldal betöltésekor, csak amikor a látogató először megmozdítja az egeret, görget, megérinti a képernyőt vagy lenyom egy billentyűt. A laborpontszám ettől gyakran nagyot ugrik, közben viszont az űrlapok, a mérés és a hajtás feletti elemek csendben elromolhatnak. Ebben a cikkben végigmegyünk a tipikus mellékhatásokon, adunk egy kizárási listát és egy tesztelési menetet, a végén pedig arról is írunk, mikor éri meg egyáltalán ez a kompromisszum.
Mit csinál pontosan a „Delay JavaScript” funkció?
A bővítmény átírja a script-tageket úgy, hogy a böngésző ne futtassa őket, majd egy apró betöltő az első felhasználói interakciónál visszaállítja és sorban elindítja mindet.
A gyakorlatban a script type attribútuma egy a böngésző számára ismeretlen értékre változik, a forrás címe pedig adat-attribútumba költözik. Az ismeretlen típusú scriptet a böngésző nem hajtja végre. Amikor jön az első egérmozgás, görgetés, érintés vagy billentyűleütés, a betöltő visszaírja az eredeti értékeket, és a scriptek lefutnak. Néhány bővítményben időkorlát is beállítható, ami után interakció nélkül is betöltődik minden.
Hivatalosan igazolt. A Lighthouse és a PageSpeed Insights labormérése nem szimulál felhasználói interakciót. A késleltetett scriptek ezért a labor szemszögéből gyakorlatilag nem léteznek, így a Total Blocking Time és a fő szál terhelése ennek megfelelően csökken. A PageSpeed Insights felső része viszont a Chrome valós felhasználói adataiból (CrUX) dolgozik, ahol a látogatók igenis kattintanak és görgetnek.
Szakmai feltételezés. A valós adatokban a javulás jó eséllyel jóval kisebb, mint a laborban, és az Interaction to Next Paint (INP) akár romolhat is. Az első interakció pillanatában ugyanis egyszerre zúdul a böngészőre minden visszatartott script, és ha a látogató épp ekkor kattint, a válasz késhet.
Miért nem indul el az űrlap-validáció késleltetés mellett?
Az űrlap validációját, feltételes logikáját és AJAX-os beküldését kezelő script csak az első interakció után töltődik be, ezért az első kattintásnál még hiányozhat, vagy a függőségei rossz sorrendben futnak le.
A tipikus tünetek az alábbiak.
- A küldés gomb sima oldalfrissítést csinál AJAX-os beküldés helyett, és a beküldés hibára fut vagy elveszik.
- A feltételes mezők nem jelennek meg, a többlépéses űrlap nem lép tovább.
- A reCAPTCHA vagy más spamszűrő nem generál tokent, ezért a szerver spamként dobja el a beküldést.
- A konzolban „jQuery is not defined” vagy „$ is not a function” hiba látszik.
- A dátumválasztó, a telefonszám-formázó vagy a fájlfeltöltő nem reagál.
Saját tapasztalat. A leggyakoribb ok az, hogy a jQuery késleltetve van, egy inline script viszont, amelyet a bővítmény nem késleltet, már betöltéskor hívná. A látogató ebből annyit lát, hogy „nem megy az űrlap”, a tulajdonos pedig annyit, hogy kevesebb megkeresés érkezik. Mivel a hiba csak a konzolban jelenik meg, hetekig észrevétlen maradhat.
Hogyan vesznek el GA4- és Meta-események?
Ha a gtag.js, a Google Tag Manager vagy a Meta Pixel késleltetve van, az a látogató, aki interakció nélkül távozik, egyáltalán nem kerül be a mérésbe, és az időhöz kötött mutatók is elcsúszhatnak.
- Elmaradó oldalmegtekintés. Aki elolvassa az első képernyőt, majd görgetés nélkül visszalép, annál nem fut le a
page_view, így a munkamenet sem jön létre. - Elmaradó konverzió a köszönőoldalon. A sikeres beküldés után a látogató jellemzően nem görget és nem kattint, egyszerűen bezárja a lapot. Ha a konverziós címke ott is késleltetve fut, az esemény nem rögzül. A Google Ads és a Meta kampányoptimalizálása pont ezekre az adatokra épül.
- Elmaradó Meta-események. A
PageViewés aViewContentugyanúgy kimarad. A Conversions API szerveroldalról pótolhatja a kiesést, de a böngészős és a szerveres eseményt össze kell párosítani.
Hivatalosan igazolt. A Meta a böngészős Pixel és a Conversions API párhuzamos eseményeit az eseménynév és az event_id egyezése alapján szűri ki duplikátumként. Ha a késleltetés miatt csak az egyik oldal küld, nincs mit párosítani, ez rendben van. A gond akkor kezdődik, amikor a két oldal eltérő azonosítót használ, mert ekkor kettős számolás is előfordulhat.
Szakmai feltételezés. A GA4-ben a késleltetés bekapcsolása után csökkenő munkamenetszámot és gyanúsan javuló elköteleződési arányt láthatsz. Ennek oka az lehet, hogy épp a rövid, nem elköteleződő látogatások esnek ki a mérésből. Ilyenkor a riport szebb, a valóság nem változott.
Mi történik a sütibannerrel és a hozzájárulási móddal?
A késleltetett sütibanner csak az első interakció után jelenik meg, ami zavaró és hibás sorrendhez vezethet, mert a Consent Mode alapértelmezett állapotának a mérőcímkék előtt kell beállnia.
Hivatalosan igazolt. A Google Consent Mode dokumentációja szerint az alapértelmezett hozzájárulási állapotot az oldal betöltésekor, minden adatküldő címke előtt kell megadni. Egy tipikus alapbeállítás így néz ki.
gtag('consent', 'default', { 'ad_storage': 'denied', 'ad_user_data': 'denied', 'ad_personalization': 'denied', 'analytics_storage': 'denied' });
Ha ezt az inline részt vagy a hozzájáruláskezelő (CMP) scriptjét a bővítmény visszatartja, miközben a Tag Manager már fut, a címkék rossz állapottal indulhatnak. Fordított esetben a banner és a mérés is csak görgetésre ébred. A banner ráadásul az első görgetésnél hirtelen felugrik, és ha nem fix pozíciójú elem, elrendezés-elmozdulást (CLS) is okozhat.
Saját tapasztalat. A CMP scriptjét és a consent default blokkot minden telepítésnél kizárjuk a késleltetésből. Ez az a pont, ahol a pár ezredmásodperces nyereség nem ér annyit, mint az adatvédelmi és mérési kockázat.
Miért nem indul el a csúszka vagy a mobilmenü?
A hajtás feletti csúszka, karusszel és mobilmenü JavaScripttel inicializálódik, ezért késleltetéssel az első képernyőn egymásra csúszott képeket, üres sávot vagy nem nyíló menüt lát a látogató.
A csúszkánál jellemzően az összes dia egymás alatt jelenik meg, majd az első görgetéskor hirtelen a helyére ugrik. Ez rossz első benyomás, és a valós CLS-adatokat is ronthatja. A mobilmenünél gyakori, hogy az első érintés csak elindítja a scriptek betöltését, a menü pedig csak a második érintésre nyílik ki. A látogató ezt hibának érzékeli.
Szakmai feltételezés. Ha a legnagyobb tartalmi elem (LCP) egy JavaScripttel felépített csúszka képe, a labor egészen más elemet mérhet LCP-ként, mint amit a valódi látogató lát. A jó laboreredmény ilyenkor félrevezető lehet.
Mit ne késleltessünk? A kizárási lista
Zárd ki mindazt, ami a hajtás feletti megjelenést, a hozzájárulást, az űrlapokat, a fizetést és a konverziómérést szolgálja. Késleltesd nyugodtan, ami a látogató szándékától függ, például a chatet, a videót vagy a közösségi beágyazásokat.
Ne késleltesd
- a sütibanner (CMP) scriptjét és a consent default inline blokkot,
- a jQueryt, ha bármelyik inline vagy nem késleltetett script függ tőle,
- az űrlapbővítmények scriptjeit (Contact Form 7, Gravity Forms, WPForms, Elementor űrlap) és a reCAPTCHA-t azokon az oldalakon, ahol űrlap van,
- a hajtás feletti csúszkát, a mobilmenüt és a fejléc scriptjeit,
- a kosár, a pénztár és a fizetési szolgáltató scriptjeit webshopban,
- a konverziós címkéket a köszönőoldalon, illetve ha a pontos látogatószám fontos, a gtag.js-t vagy a Tag Manager tárolót is.
Jó jelölt a késleltetésre
- chat- és ügyfélszolgálati widgetek,
- YouTube- és Vimeo-beágyazások, közösségi médiás widgetek,
- hajtás alatti értékelés- és hírlevél-widgetek,
- hőtérkép- és munkamenet-rögzítő eszközök, ha elfogadod, hogy az interakció nélküli látogatások kimaradnak.
A kizárásokat a bővítmény beállításaiban, soronként egy mintával adhatod meg. A WP Rocket például a script URL-jének vagy az inline script tartalmának bármely egyedi részletére illeszt, így egy kiinduló lista így nézhet ki.
/jquery-?[0-9.](.*)(.min|.slim|.slim.min)?.jsgoogletagmanager.comgtag(dataLayerconsentcontact-form-7recaptcha
A pontos szintaxis bővítményenként eltér, és a saját CMP-d, űrlapbővítményed nevét is hozzá kell adnod. Minden új kizárás után ürítsd a gyorsítótárat, különben a régi, átírt HTML marad kint.
Hogyan teszteld lépésről lépésre DebugView-val és inkognitóablakkal?
Kijelentkezett állapotban, inkognitóablakban, gyorsítótár-ürítés után nézd végig az oldalt előbb interakció nélkül, utána interakcióval, és közben figyeld a GA4 DebugView-t, a Meta Tesztesemények felületét és a böngésző konzolját.
Az inkognitóablak azért fontos, mert sok gyorsítóbővítmény bejelentkezett adminisztrátornak nem szolgálja ki az optimalizált változatot. Adminként tehát könnyen azt hiheted, hogy minden rendben, miközben a látogatók a késleltetett változatot kapják.
- Ürítsd a bővítmény és a CDN gyorsítótárát.
- Nyiss inkognitóablakot, és ellenőrizd, hogy nem vagy bejelentkezve.
- Kapcsold be a hibakeresést. A legegyszerűbb a Tag Manager előnézete (Tag Assistant), gtag-es telepítésnél pedig ideiglenesen a
gtag('config', 'G-XXXXXXX', { 'debug_mode': true });beállítás. A GA4 DebugView csak a hibakereső módban küldött eseményeket mutatja. - Töltsd be az oldalt, és 15-20 másodpercig ne nyúlj semmihez. A fejlesztői eszközök Network fülén szűrj a
collectés afacebook.com/trkifejezésre. Ha itt nincs kérés, apage_viewkésleltetve fut. - A konzolban futtasd le a
typeof gtag,typeof fbqéswindow.dataLayerparancsot. Azundefinederedmény azt jelzi, hogy a script még nem töltődött be. - Görgess egyet, és nézd meg, megjelenik-e a DebugView-ban a
page_viewés asession_start. Néhány másodperces csúszás normális. - Teszteld az űrlapot előbb hibás adattal (megjelenik-e a validáció), aztán helyessel. A köszönőoldalon ne mozdulj, és figyeld, rögzül-e a konverziós esemény.
- Utasítsd el a sütiket egy új inkognitóablakban, és nézd meg, mi megy ki. Speciális (advanced) Consent Mode mellett cookie nélküli pingek mehetnek, ez várt viselkedés.
- A Meta Események kezelőjében nyisd meg a Tesztesemények felületet, és ott is ellenőrizd a
PageView-t és a konverziót. - Ismételd meg valódi telefonon, külön figyelve a mobilmenü első érintésére és a csúszka első képernyőjére.
Saját tapasztalat. A beállítás után egy-két héttel érdemes összevetni a GA4 munkamenet- és konverziószámát a bekapcsolás előtti, hasonló időszakkal. Ha a munkamenetek érezhetően csökkentek, miközben a hirdetési kattintások száma nem, az erős jel arra, hogy a mérés sérült.
Mikor ér többet a jobb laborpontszám, mint a pontos mérés?
A mi nézőpontunk szerint ritkán. Ha a weboldal hirdetésből él, vagy a döntéseid a GA4-adatokra épülnek, a pontos mérés többet ér néhány laborpontnál.
Hivatalosan igazolt. A Google Search Central szerint a rangsorolási rendszerek a Core Web Vitals valós felhasználói adatait veszik figyelembe, a Lighthouse-pontszámot magát nem. A dokumentáció azt is hangsúlyozza, hogy a jó oldalélmény nem garantál jobb helyezést, a releváns, hasznos tartalom számít a legtöbbet.
Saját tapasztalat. A késleltetés ott hoz tiszta nyereséget, ahol sok a nehéz, harmadik féltől származó, hajtás alatti script (chat, videó, közösségi widget), és ezeket késleltetjük, a mérést és a hozzájárulást viszont kizárjuk. Így a labor és a valós adatok is jó eséllyel javulnak, a mérés pedig ép marad.
Szakmai feltételezés. A teljes, kizárások nélküli késleltetés legfeljebb olyan oldalon lehet elfogadható, ahol nincs konverziómérés és nincs fizetett hirdetés, például egy tisztán tájékoztató blogon. Ha mégis a mérőkódok terhelése a gond, jobb irány a Tag Manager tároló kitakarítása, a nem használt címkék törlése vagy a szerveroldali címkézés, mint a mérés vak késleltetése.
Egy egyszerű döntési szabály segíthet. Ha egy script elmaradása pénzben vagy adatban mérhető kárt okoz, ne késleltesd. Ha csak egy kényelmi funkció indul el pár másodperccel később, késleltesd nyugodtan.
Források és további olvasnivalók
- Google Search Central, Core Web Vitals és az oldalélmény a Google Keresésben
- web.dev, Interaction to Next Paint (INP) és Total Blocking Time
- Chrome for Developers, Lighthouse és Chrome UX Report (CrUX) dokumentáció
- Google Analytics súgó, DebugView és hibakereső mód
- Google Tag Manager súgó, előnézet és hibakeresés (Tag Assistant)
- Google for Developers, Consent Mode dokumentáció
- Meta for Developers, Meta Pixel, Conversions API és eseménydeduplikáció
- WP Rocket dokumentáció, Delay JavaScript execution
Gyakori kérdések
Miért javul ennyit a PageSpeed-pontszám a JavaScript késleltetésétől?
Mert a Lighthouse labormérése nem kattint és nem görget, így a késleltetett scriptek le sem futnak a mérés alatt. A valós felhasználói adatokban (CrUX) a javulás jó eséllyel kisebb, mert a valódi látogatók interakcióba lépnek.
Késleltethetem a Google Tag Managert vagy a gtag.js-t?
Technikailag igen, de akkor az interakció nélkül távozó látogatók és a köszönőoldali konverziók kimaradhatnak a mérésből. Ha hirdetsz, vagy a GA4-adatokra építesz döntéseket, inkább zárd ki őket a késleltetésből.
Miért nem működik az űrlapom a gyorsítóbővítmény bekapcsolása után?
Gyakori ok, hogy a jQuery vagy az űrlapbővítmény scriptje késleltetve van, egy inline script viszont már betöltéskor hívná. Nézd meg a böngésző konzolját, és zárd ki a jQueryt, az űrlapbővítmény scriptjeit és a reCAPTCHA-t.
Miért kell inkognitóablakban tesztelni?
Sok gyorsítóbővítmény bejelentkezett adminisztrátornak nem szolgálja ki az optimalizált változatot, így adminként nem látod azt, amit a látogatók kapnak. Az inkognitóablak kijelentkezett, tiszta állapotot ad.
Hogyan látom a GA4 DebugView-ban a tesztlátogatásomat?
Kapcsold be a Tag Manager előnézetét, vagy gtag-es telepítésnél ideiglenesen a debug_mode paramétert. A DebugView csak a hibakereső módban küldött eseményeket mutatja, néhány másodperces csúszással.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.