Gyorsítótár és optimalizálás: kizárások

Ez a fejezet azt sorolja fel, mit kell kizárni, ha egy gyorsítótár-, minifikáló vagy teljesítménybővítménynek meg kell mondani, hogy hagyja békén a Pixel Managert.

Röviden: szinte minden esetben nem kell semmit kizárnod. Az oldal teljes gyorsítótárazása a bővítmény tervezéséből adódóan támogatott, és a leggyakoribb optimalizáló bővítményekhez a Pixel Manager maga regisztrálja a szükséges JavaScript-kizárásokat. Kézi kizárást csak akkor vegyél fel, ha ténylegesen elromlik a követés, vagy az optimalizálód nincs az automatikus listán.

Amit a bővítmény magától kezel

Ezeknél a bővítményeknél a Pixel Manager futásidőben regisztrálja a kizárásait. Nincs mit bekapcsolni vagy kézzel hozzáadni.

Bővítmény	Mit zár ki a Pixel Manager automatikusan
WP Rocket	JS-minifikálás, JS-összevonás, inline JS-optimalizálás, valamint a JS késleltetése a kosár-, pénztár- és megerősítő oldalon
LiteSpeed Cache	JS-minifikálás és -összevonás, a késleltetés az első interakcióig („Load JS Deferred: Delayed” és Guest Mode), és a ?ver gyorsítótár-bélyeg, ha a „Remove Query Strings” be van kapcsolva
SiteGround Optimizer	JS-összevonás (az inline is), JS-minifikálás, a jQuery halasztása
Autoptimize	JS-minifikálás (már minifikáltként kezeli) és a szkriptek áthelyezése
WP-Optimize	JS-minifikálás
Optimocha (Speed Booster Pack)	JS-optimalizálás (a Pixel Managert a kizárási listára teszi, a bevételi listáról leveszi)
FlyingPress	Késleltetés az első interakcióig a követőszkriptekre a kosár-, pénztár- és megerősítő oldalon

A bővítmény a gyorsítótárat is kiüríti, ha módosítod a beállításait, aktiválod vagy frissíted, hogy ne szolgáljon ki elavult HTML-t. Ez lefedi a bővítményréteget (NitroPack, WP Rocket, LiteSpeed, Autoptimize, Hummingbird, W3 Total Cache, WP-Optimize, WP Super Cache, WP Fastest Cache, FlyingPress), a tárhelyréteget (SiteGround, WP Engine, Kinsta, Nginx Helper, Proxy Cache Purge) és a Cloudflare-t.

A kiürítés nem azonos a kizárással. A NitroPack, a W3 Total Cache, a WP Super Cache, a WP Fastest Cache, a Hummingbird, a Perfmatters, a Swift Performance, a Breeze, a Cloudflare Rocket Loader és minden más, a fenti táblázatban nem szereplő optimalizáló esetén a Pixel Manager csak kiüríti a gyorsítótárat. Ha ezek közül valamelyik elrontja a követést, vedd fel kézzel az alábbi kizárásokat.

Bővítményfrissítés után

Ez az a pillanat, amikor egy egyébként ártalmatlan gyorsítótár teljesen kikapcsolhatja a követést, ezért érdemes megérteni.

A bővítmény minden kiadása a pixelkódját webpack-csomagokban (chunk) szállítja, amelyek fájlnevében tartalomhash van. A hash kiadásonként változik, ezért a frissítés után az előző kiadás csomagfájljai már nem léteznek. Ez addig nem gond, amíg a böngésző a friss oldalt kapja. Ha egy gyorsítótárréteg a frissítés előtti oldalt szolgálja ki, a böngésző a régi szkriptet tölti be, ami olyan csomagnevekre kérdez rá, amelyeket a telepített kiadás már nem tartalmaz. Ezek a kérések 404-gyel jönnek vissza. Ha éppen a hozzájárulási modul csomagja hibázik, a Pixel Manager biztonsági okból minden hozzájárulási kategóriát megtagadottnak vesz, és semmit nem küld el, ahelyett hogy hozzájárulás nélkül követne.

A bolt ekkor minden szempontból egészségesnek látszik, kivéve hogy a böngészős követés elhallgat. A rendelések továbbra is jönnek, és a szerveroldali konverziók is érkeznek, ezért a csökkenés egyenletes esésként látszik minden böngészőben és csatornán, miközben a bevétel nagyjából állandó.

Mit ürítsd ki

A Pixel Manager frissítés, aktiválás és beállításmódosítás után kiüríti, amit el tud érni. Nem ér el mindent, és épp azok a rétegek maradnak, amelyek túlélik a bővítményszintű kiürítést:

1. Az oldal-gyorsítótár bővítmény (NitroPack, WP Rocket, LiteSpeed, W3 Total Cache és a többi). Automatikusan kiürül.
2. A tárhely saját gyorsítótárrétege (SiteGround, WP Engine, Kinsta, Nginx, Varnish). Automatikusan kiürül, ahol a tárhely ad rá lehetőséget.
3. A CDN, ha az oldal előtt áll és nem Cloudflare. Nem ürül ki automatikusan, kézzel kell kiüríteni.
4. A látogató böngészőjének gyorsítótára, ha egy optimalizáló eltávolítja a ?ver jelölést a szkript-URL-ekből. Lásd a LiteSpeed Cache „Remove Query Strings” beállítását lent.

Ha több réteget is használsz, kívülről befelé ürítsd őket: előbb a CDN, aztán a tárhelyréteg, végül az oldal-gyorsítótár bővítmény. Ha a legbelső réteggel kezded, az a régi külső rétegből töltődik újra.

Egyes régebbi kiadásokban az automatikus kiürítés csendben meghiúsult a NitroPackon, a Kinstán és a Proxy Cache Purge-on. Ha ezeket használod és nem a legújabb kiadáson vagy, minden frissítés után ürítsd ki kézzel azt a réteget. A friss kiadásban a Pixel Manager által felismert, de ki nem üríthető gyorsítótár értesítést jelenít meg a WordPress adminban ahelyett, hogy csendben meghibásodna.

Hogyan ismered fel

Nyisd meg a boltot privát böngészőablakban, adminként kijelentkezve, és nyisd meg a böngészőkonzolt. Ha az alábbiak bármelyike megjelenik, még valahol a követőkönyvtár egy elavult példányát szolgálják ki:

• egy piros sor, amely így kezdődik: [PMW] Consent module failed to load. Ennél a látogatónál a követés ki van kapcsolva.
• 404 egy .chunk.min.js végű fájlra a Network fülön, általában ChunkLoadError kíséretében.
• egy sor, amely így kezdődik: Pixel Manager: this script file is version, és megnevezi a böngészőben futó és a szerveren telepített verziót is. Ez csak akkor jelenik meg, ha a szkriptfájl elavult, de körülötte az oldal friss, vagyis a „Remove Query Strings” esetében. Egy teljesen gyorsítótárazott oldal megegyező, elavult verziószámot hordoz, ezért az ellenőrzés nem látja az eltérést.

Mindhárom esetben a megoldás ugyanaz: ürítsd ki a fenti rétegeket ebben a sorrendben, és töltsd újra friss privát ablakban.

Mi töri el a követést, és mi nem

Nem minden optimalizálás jelent gondot. Ha a szükségesnél többet zársz ki, teljesítményt veszítesz haszon nélkül.

Biztonságos, nem kell kizárni:

• Az oldal HTML-jének teljes gyorsítótárazása. A Pixel Manager erre épül: a kosár tartalma és az elavulhatatlan termékadatok az oldal betöltése után, a szerverről töltődnek le, soha nem a gyorsítótárazott HTML-ben vannak.
• A defer használata a Pixel Manager szkriptjén. A halasztás csak a betöltési sorrendet változtatja, azt nem, hogy lefut-e a szkript.
• A Pixel Manager fájljainak CDN-ről kiszolgálása, a gzip/Brotli tömörítés, a statikus .js fájlok HTTP-gyorsítótárazása.
• CSS-, kép- és betűtípus-optimalizálás, a képek lusta betöltése.

Elrontja a követést, ki kell zárni:

• A Pixel Manager fájljainak JS-minifikálása. A fájlok már minifikáltak, az újbóli minifikálás megrongálhatja a csomagot.
• A JS-összevonás, egyesítés, csomagolás. A Pixel Manager a pixelkódját külön webpack-csomagokként, igény szerint tölti be. Ha a belépő szkriptet újracsomagolják, vagy a belépő szkriptet kizárják, a csomagokat viszont nem, a böngésző nem létező csomagneveket kér, és a konzolban ChunkLoadError jelenik meg. Mindig a teljes bővítménymappát zárd ki, ne egyetlen fájlt.
• A JavaScript késleltetése az első felhasználói interakcióig a kosár-, pénztár- és megerősítő oldalon. Sok vásárló a megerősítő oldalon sem nem kattint, sem nem görget, sem nem mozgatja az egeret, ezért egy késleltetett szkript miatt a vásárlási konverzió sosem megy ki. Más oldaltípusokon a késleltetés általában rendben van.
• A fel nem használt JavaScript eltávolítása, vagy bármi, ami átírja, beágyazza vagy átrendezi az inline szkriptcímkéket. A Pixel Manager adatrétege inline szkript.
• A lekérdezési karakterláncok eltávolítása a statikus erőforrásokról. A belépő szkript egy ?ver jelölést hordoz, amely minden kiadásnál változik. Ha ezt eltávolítják, az URL kiadások között azonos lesz, és az a böngésző vagy CDN, amelyet egy évre gyorsítótárazásra utasítottak, a frissítés előtti szkriptet játssza vissza, ami már nem létező webpack-csomagneveket kér. A tünet 404 egy *.chunk.min.js fájlra és ChunkLoadError, és a frissítés után jelenik meg, nem rögtön.
• A Cloudflare Rocket Loader, amely átrendezi és halasztja az inline szkripteket.

A kizárási lista

1. A Pixel Manager szkriptfájljai

A legbiztonságosabb és leginkább jövőálló szabály a teljes bővítménymappa kizárása. A csomagok fájlnevében tartalomhash van, amely kiadásonként változik, ezért az egyes fájlokat megnevező szabály elavul.

Azt a mappát használd, amelyik a telepítés módjának megfelel:

Terjesztés	Útvonal
Ingyenes változat a WordPress.org-ról	/wp-content/plugins/woocommerce-google-adwords-conversion-tracking-tag/
Pro változat a gyártó oldaláról	/wp-content/plugins/pixel-manager-pro-for-woocommerce/
Pro változat a WooCommerce.com-ról	/wp-content/plugins/woocommerce-pixel-manager/

Ha az optimalizálód helyettesítő mintákat vár, ez a három minden esetet lefed:

*woocommerce-google-adwords-conversion-tracking-tag*
*pixel-manager-pro-for-woocommerce*
*woocommerce-pixel-manager*

Ha egy eszköz konkrét fájlneveket követel, a front end eszközei:

# Ingyenes szint
/wp-content/plugins/<bovitmenymappa>/js/public/free/pmw-public.p1.min.js
/wp-content/plugins/<bovitmenymappa>/js/public/free/*.chunk.min.js

# Pro szint
/wp-content/plugins/<bovitmenymappa>/js/public/pro/pmw-public__premium_only.p1.min.js
/wp-content/plugins/<bovitmenymappa>/js/public/pro/pmw-lazy__premium_only.js
/wp-content/plugins/<bovitmenymappa>/js/public/pro/*.chunk.min.js

Megjegyzések:

• A Pro telepítés a free és a pro mappát is tartalmazza, és a licenc állapotától függően az egyiket szolgálja ki, ezért mindkét könyvtárat zárd ki.
• A Pro belépő szkript nevében a .p1 a szkriptoptimalizálási előbeállítás. .p2 lesz, ha a pmw_script_optimization_preset_version szűrővel megváltoztatod. Egy *pmw-public* jellegű helyettesítő minta mindkettőt lefedi.
• A WordPress szkriptazonosítója (handle) pmw, azoknak az optimalizálóknak, amelyek azonosító szerint zárnak ki, nem URL szerint.

2. Az inline adatréteg

A Pixel Manager a konfigurációját és a termék-, kosár- és rendelésadatokat inline <script> címkékbe írja. Ha az optimalizálód ki tudja zárni az inline szkripteket, általában a kódrészletben lévő egyedi szövegre illeszt. Ezt használd:

pmwDataLayer

A régebbi kiadások wpmDataLayer néven használták. Ha azt akarod, hogy a szabály egy visszalépést is túlélje, add meg mindkettőt:

window.pmwDataLayer
wpmDataLayer

3. Harmadik féltől származó követőkönyvtárak a konverziós oldalakon

A Pixel Manager a gyártói könyvtárakat a hivatalos CDN-jükről tölti be. A kosár-, pénztár- és megerősítő oldalon ezeket nem szabad az első interakcióig késleltetni, különben konverziók vesznek el. A legfontosabbak:

googletagmanager.com/gtag/js
google-analytics.com
connect.facebook.net

Add hozzá a használt többi pixel megfelelőjét is (például analytics.tiktok.com, s.pinimg.com, sc-static.net, static.ads-twitter.com, bat.bing.com).

4. Végpontok, amelyeket sosem szabad gyorsítótárazni

Ezek dinamikus, látogatónkénti kérések. A szokásos WordPress-gyorsítótár-beállítások eleve békén hagyják őket, de ha agresszív élgyorsítótárat, proxy-gyorsítótárat vagy egyedi gyorsítótár-szabályt használsz, zárd ki őket:

/wp-json/pmw/v1/*
/?rest_route=/pmw/v1/*
/wp-admin/admin-ajax.php

A front end által használt AJAX-műveletek: pmw_get_cart_items, pmw_get_product_ids, pmw_purchase_pixels_fired, a Pro változatban pedig pmw_server_to_server_event, pmw_process_transient_session_identifiers és get_acr_order_data_ajax.

Ha a Google Tag Gateway-t helyi mérési útvonallal használod, annak az útvonalnak (például /metrics) is ki kell maradnia az oldal-gyorsítótárból. A Pixel Manager no-store fejléceket küld rá, de az az élgyorsítótár, amely figyelmen kívül hagyja az eredeti szerver fejléceit, mégis elrontaná.

5. Oldalak, amelyeket sosem szabad oldal-gyorsítótárba tenni

A kosár-, pénztár- és megerősítő oldalt gyorsítótár nélkül kell kiszolgálni. A WooCommerce ezt maga deklarálja, és minden elterjedt gyorsítótár-bővítmény alapból betartja, ezért ez csak kézzel írt gyorsítótár-szabályoknál vagy mindent gyorsítótárazó CDN-nél lényeges.

NitroPack

A NitroPack alapból működik a Pixel Managerrel. A Pixel Manager kiüríti a NitroPack gyorsítótárát, ha módosítod a beállításokat, de nem tud kizárást regisztrálni a NitroPackben, mert a NitroPacknek nincs ehhez szűrője. Ha problémát tapasztalsz, ez a kézi eljárás.

Excluded Resources (NitroPack Dashboard → Cache Settings → Cache → Excluded Resources)

Soronként egy bejegyzést vegyél fel, a telepítésednek megfelelő mappával:

*woocommerce-google-adwords-conversion-tracking-tag*
*pixel-manager-pro-for-woocommerce*
*woocommerce-pixel-manager*
pmwDataLayer

Az első három a szkriptfájlokra illeszkedik, az utolsó az inline adatrétegre. A NitroPack külső erőforrásokhoz teljes URL-t, inline szkriptekhez egyetlen egyedi kódsort, helyettesítő karakterként pedig *-ot fogad el.

Delayed Scripts (NitroPack Dashboard → General Settings → JavaScript settings → Delayed Scripts)

A Delayed Scripts bekapcsolós lista, ezért a Pixel Managert csak akkor érinti, ha valamelyik szabályod véletlenül illeszkedik rá. Ellenőrizd, hogy egyetlen szabály sem illeszkedik a pmw, pmwDataLayer, gtag, fbevents.js szavakra vagy a bővítménymappák nevére. Ha valamelyik igen, töröld vagy szűkítsd.

Bármilyen módosítás után ürítsd ki a NitroPack gyorsítótárát, és privát böngészőablakban tesztelj, különben az előzőleg optimalizált HTML-t nézed tovább.

LiteSpeed Cache

A Pixel Manager maga regisztrálja a LiteSpeed kizárásait, ezért egy szokásos telepítésnél nincs kézi beállítás. Két LiteSpeed-beállítást azért érdemes ismerned, mert mindkettő olyan tünetet okoz, ami elromlott bővítménynek látszik.

Remove Query Strings

Page Optimization → Tuning → Remove Query Strings

Ez minden belső szkript-URL-ből eltávolítja a ?ver jelölést, a Pixel Manager belépő szkriptjéből is. Ha a tárhely hosszú gyorsítótár-élettartammal szolgálja ki a statikus fájlokat, a verzió nélküli URL miatt a böngésző és a CDN az utolsó bővítményfrissítés előtt letöltött példányt játssza vissza. Az öreg szkript olyan webpack-csomagneveket kér, amelyeket az új kiadás már nem szállít, és a konzol megtelik 404-gyel és ChunkLoadError-ral. Ha éppen a hozzájárulási csomag hibázik, a Pixel Manager tervezetten minden hozzájárulási kategóriát megtagad, és teljesen leállítja a követést.

A friss kiadás megjelöli a saját szkriptjeit, hogy a LiteSpeed ne nyúljon a lekérdezési karakterláncukhoz. Régebbi kiadásnál, vagy ha a probléma már bekerült egy gyorsítótárba, kapcsold ki a Remove Query Strings beállítást, ürítsd ki a LiteSpeed gyorsítótárát és a CDN vagy tárhely élgyorsítótárát, majd töltsd újra a boltot privát böngészőablakban.

Load JS Deferred: Delayed

Page Optimization → JS Settings → Load JS Deferred

A „Deferred” biztonságos. A „Delayed” nem: minden szkriptet visszatart, amíg a látogató kattint, görget vagy mozgatja az egeret. A vásárlók gyakran a megerősítő oldalra érkeznek, és ezek egyikét sem teszik meg, mielőtt elmennek, ezért a vásárlási konverzió sosem megy ki. A Guest Mode optimalizálás mindig Delayed módban fut.

A friss kiadásban a Pixel Manager magát hozzáadja a JS Deferred / Delayed Excludes listához, valahányszor a Delayed mód aktív. Régebbi kiadásnál add hozzá kézzel ezeket a bejegyzéseket:

pmw
pmwDataLayer
.chunk.min.js
js/public/free/
js/public/pro/

Annak ellenőrzésére, hogy a késleltetés-e az ok: tölts be egy oldalt, várj tíz másodpercet anélkül, hogy bármihez nyúlnál, és futtasd a konzolban a typeof pmw parancsot. Ha undefined, miközben az oldal betöltődött, még semmi sem futott le.

Cloudflare Rocket Loader

A Rocket Loader (Cloudflare Dashboard → Speed → Optimization → Content Optimization) halasztja és átrendezi az inline szkripteket, ami elronthatja az adatréteget. Ha a követés Rocket Loaderrel elromlik, nélküle pedig működik, vagy hagyd kikapcsolva, vagy vegyél fel egy Configuration Rule-t, amely a bolt URL-jeire kikapcsolja a Rocket Loadert.

A Pixel Manager az inline szkriptjeihez magától hozzáadja a data-cfasync="false" attribútumot, ha az Elementort Cloudflare mögött észleli, mert a gyakorlatban ez az összetétel okozott gondot.

Bármilyen más optimalizáló

A recept mindenhol ugyanaz. Keresd meg ezeket a beállításokat, és add hozzá a „A kizárási lista” részben szereplő mintákat:

1. Zárd ki a JavaScript-fájlokat a minifikálásból.
2. Zárd ki a JavaScript-fájlokat az összevonásból, egyesítésből vagy csomagolásból.
3. Zárd ki a Pixel Managert az első interakcióig való késleltetésből, legalább a kosár-, pénztár- és megerősítő oldalon.
4. Zárd ki az inline pmwDataLayer szkriptet az inline JS-optimalizálásból és a szkriptblokkolásból.
5. Hagyd bekapcsolva a defer-t és az oldal-gyorsítótárazást. Ezek rendben vannak.

Lusta betöltés

Ha az optimalizálód szkript-lusta betöltést kínál, és a Pixel Manager saját Lazy-load the Pixel Manager funkcióját is használod (Általános beállítások), az ajánlás: kapcsold be mindkettőt, és zárd ki a Pixel Managert az optimalizáló lusta betöltéséből. A Pixel Manager lusta betöltője ismeri a pénztártölcsért és az A/B-tesztelő eszközöket, és magától kikapcsol ott, ahol a késleltetett betöltés a pontosság rovására menne. Az indoklás a Gyakori kérdések: általános fejezetben van.

Tárhelyek, amelyek eltávolítják a sütiket

Egyes tárhelyek minden olyan sütit eltávolítanak a kérésből, amelyet nem ismernek, mielőtt az elérné a WordPresst. A Pantheon Global CDN-je alapból minden kérésnél ezt teszi. A látogató böngészője még őrzi a sütiket, de a WordPress sosem látja őket.

A böngészőoldali követést ez nem érinti, mert az a böngészőben olvassa a sütiket. A szerveroldali követést viszont igen: a szerver nem tudja olvasni a kérésből a látogató hozzájárulási döntését, a tárolt kattintásazonosítókat és a platformok saját azonosítóit. Ilyenkor a WooCommerce munkamenetben lévő másolatra esik vissza, ami kevésbé megbízható, mert az egyszerre futó pénztárfrissítés felülírhatja.

Hogyan veszed észre

• A Pixel Manager Pro valós boltforgalmon méri ezt, és ha a sütik nem érkeznek meg, a „Your host removes the Pixel Manager cookies” admin értesítést mutatja (a friss kiadásban).
• A hibakeresési jelentésben (Support → Debug report) van egy Cookie Delivery rész ugyanezzel a méréssel.
• Debug szintű naplózásnál minden új rendelésnél bekerül a naplóba, hogy a hozzájárulási pillanatkép from the cookie vagy from the session jött. Ha csak session szerepel, miközben a böngésző fejlesztői eszközei mutatják a pmw_consent sütit, a sütit eltávolítják.

Mit kérj a tárhelytől

Kérd meg a tárhelyet, hogy az alábbi sütiket adja át a WordPressnek. A friss kiadástól minden, a szerver által olvasott Pixel Manager-süti pmw_ előtaggal kezdődik, ezért egyetlen szabály erre az előtagra lefedi az összes jelenlegi és jövőbeli sütit. A régebbi kiadások a _pmw_click_ids sütit is használják.

Süti	Ki állítja be	Mire olvassa a szerver
pmw_*	Pixel Manager	A látogató hozzájárulási döntése, kattintásazonosítók, Google Tag Gateway útvonal
_fbp, _fbc	Meta-pixel	Meta Conversions API
_ga, _ga_*, _gcl_aw, _gcl_dc, _gcl_gb	Google-címke	GA4 Measurement Protocol, Google Ads kattintásazonosítók
_ttp, _ttclid	TikTok-pixel	TikTok Events API
_uetvid, _uetmsclkid	Microsoft UET	Microsoft Ads Conversions API
_epik, _derived_epik, _pin_unauth, _pinterest_ct*	Pinterest-címke	Pinterest Conversions API
_scid, _scid_r	Snapchat-pixel	Snapchat Conversions API
_rdt_uuid, rdtCid	Reddit-pixel	Reddit Conversions API
__kla_id	Klaviyo	Klaviyo
__oppref, __obref, ndclid, _axwrt, _axeid	OpenAI, Outbrain, Nextdoor, AppLovin	Saját Conversions API-juk

Csak azoknak a platformoknak a sorai kellenek, amelyeket használsz.

A sütiknek azokon a kéréseken kell eljutniuk a WordPressig, ahol a szerver olvassa őket. Ezek mind olyan kérések, amelyeket úgysem gyorsítótáraznak:

• a POST kérések, a klasszikus pénztár (?wc-ajax=checkout) és az egyéb ?wc-ajax= kérések is,
• a /wp-admin/admin-ajax.php,
• a WooCommerce Store API a /wp-json/wc/store/ alatt, amelyet a Checkout block és az expressz fizetési gombok (Apple Pay, Google Pay) használnak,
• a kosár-, pénztár- és megerősítő oldal.

Az átadás nem teheti őket az oldal-gyorsítótár kulcsának részévé, és nem kapcsolhatja ki az oldal-gyorsítótárazást. A gyorsítótárazott oldalakon a szerveren semmi nem olvassa őket.

Pantheon

A Pantheon süti-dokumentációja szerint a WordPressnek átadott sütik listája platformszintű beállítás, amely egyetlen webhelyre nem módosítható. Kérdezd meg a Pantheon támogatását, milyen lehetőséged van a csomagodban arra, hogy a fenti sütiket a felsorolt kéréseken a WordPressnek továbbítsák, például egyedi élkonfigurációval az Advanced Global CDN-en.

Miért nem nevezi át a Pixel Manager a sütijeit

Az ilyen tárhelyek általában átengedik a wordpress_*, wp-* vagy woocommerce_* nevű sütiket. A Pixel Manager nem használ ilyen neveket: ezek a WordPresshez és a WooCommerce-hez tartoznak, és ezeken a tárhelyeken egy listán lévő süti minden, azt hordozó látogatónál ki is kapcsolja az oldal-gyorsítótárazást. A sütik szűrése a tárhely döntése, ezért a megoldás is a tárhely beállításában van. Addig a Pixel Manager a munkamenetes tartalékkal működik tovább.

Ellenőrizd, hogy sikerült-e

1. Ürítsd ki az összes használt gyorsítótárréteget, a CDN-t is, majd nyisd meg a boltot privát böngészőablakban.
2. Nyiss meg egy termékoldalt a címhez fűzött ?pmwloggeron paraméterrel, és nézd a böngészőkonzolt. A konzolnaplózó kiír minden eseményt, ahogy lefut.
3. A fejlesztői eszközökben, a Network fülön szűrj a pmw szóra. A belépő szkriptnek és egy vagy több .chunk.min.js fájlnak 200-as állapottal kell betöltődnie. Ha egy csomag 404-et ad, valahol még újracsomagolják a köteget.
4. Keresd a konzolban a ChunkLoadError hibát. Ez a jele annak, hogy a Pixel Manager fájljain még aktív a JS-összevonás vagy -minifikálás.
5. Adj le egy tesztrendelést, és ellenőrizd, hogy a vásárlási esemény lefut a megerősítő oldalon. Ha minden lefut, csak a vásárlás nem, az ok szinte mindig az első interakcióig való késleltetés azon az oldalon.

Ha így sem működik, készíts hibakeresési jelentést a Support → Debug report részen, és küldd el a támogatásnak az optimalizáló bővítményed nevével együtt.