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

> Mely szkripteket, útvonalakat és végpontokat kell kizárni egy gyorsítótár-, minifikáló vagy teljesítménybővítményben; NitroPack, LiteSpeed Cache, Cloudflare Rocket Loader és a sütiket eltávolító tárhelyek.

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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/altalanos/)), 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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/hibaelharitas-gyik-altalanos/) 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.