WooCommerce cart fragments lassulás felismerése és javítása

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

Ha egy WooCommerce webshop lassabban tölt be, mint amire a tárhely alapján számítanál, és a gyorsítótár-bővítmény sem segít sokat, érdemes megnézni egy kérést, ami sok oldalon csendben fut a háttérben. Ez a wc-ajax=get_refreshed_fragments, köznapi nevén a cart fragments. Ebben a cikkben megnézzük, mit csinál, hogyan találod meg, és milyen áron lehet visszafogni. A szövegben külön jelölöm, mi hivatalosan igazolt, mi saját tapasztalat, és mi szakmai feltételezés.

Mi az a wc-ajax=get_refreshed_fragments kérés?

A get_refreshed_fragments egy AJAX kérés, amivel a WooCommerce frissíti az oldal kosárhoz kötődő részeit (a fejléc kosárszámlálóját és a mini kosár tartalmát), akkor is, ha maga az oldal gyorsítótárból érkezett. A kérést a wc-cart-fragments nevű szkript indítja, POST metódussal, a /?wc-ajax=get_refreshed_fragments címre.

Hivatalosan igazolt. A szkript és a végpont a WooCommerce forráskódjának része. A válasz egy JSON objektum, ami CSS-szelektorokat és hozzájuk tartozó HTML-darabokat (fragmenseket) tartalmaz, mellé pedig egy kosár-hash értéket. A böngésző ezekkel cseréli le az oldalon a megfelelő elemeket.

Az alapgondolat jó. A lapgyorsítótár mindenkinek ugyanazt a HTML-t adja, a kosár viszont látogatónként más. A fragmens-kérés ezt az ellentmondást oldja fel, csak drágán.

Miért fut le szinte minden oldalbetöltéskor?

A szkript a böngésző sessionStorage tárolójában őrzi az utoljára kapott fragmenseket, és egy sütiben tárolt kosár-hash alapján dönti el, hogy azok még érvényesek-e. Ha nincs tárolt adat, ha a hash nem egyezik, vagy ha egy kosárművelet frissítést kér, új kérés indul.

Hivatalosan igazolt. A sessionStorage lapfüggő, tehát minden új böngészőlap és minden új munkamenet üres tárolóval indul. Egy új látogató első oldalbetöltésekor ezért szinte biztosan lefut a kérés, és a kosár minden módosítása után is újra.

Hivatalosan igazolt. A WooCommerce 7.8-as kiadási közleménye szerint a core azóta alapból nem tölti be a cart fragments szkriptet minden oldalon, csak ott, ahol arra szükség van.

Saját tapasztalat. Sok webshopon ennek ellenére minden oldalon ott a szkript, mert a téma, egy oldalépítő fejléc-kosár modulja vagy egy bővítmény újra betölti. Ezért ne a verziószámból indulj ki, hanem nézd meg a saját oldaladon.

Hogyan rontja a válaszidőt és a gyorsítótárazhatóságot?

A fragmens-kérést a lapgyorsítótár nem szolgálja ki, ezért a szerver minden alkalommal betölti a WordPresst, az összes aktív bővítményt és a WooCommerce munkamenet-kezelését, és csak utána válaszol. Hiába jön a HTML egy pillanat alatt a gyorsítótárból, a kérés ugyanúgy PHP-folyamatot foglal.

Hivatalosan igazolt. A POST kéréseket a szabványos HTTP-gyorsítótárak és a WordPress gyorsítótár-bővítmények általában nem tárolják, és a válasz látogatónként eltér, így tárolni sem volna értelme.

Saját tapasztalat. Sok bővítménnyel futó oldalon a kérés válaszideje gyakran több száz ezredmásodperc, terhelt osztott tárhelyen ennél is több. Amíg a kérés fut, a fejléc kosárszámlálója a gyorsítótárazott, esetleg hibás értéket mutatja.

Szakmai feltételezés. A legnagyobb kárt jellemzően nem egyetlen látogatónál okozza, hanem csúcsidőben. Ha sok új látogató érkezik egyszerre (hírlevél-kiküldés, kampányindítás, AI-botok és crawlerek hulláma), a fragmens-kérések lefoglalják a PHP-folyamatokat, és a gyorsítótárazatlan oldalak, például a pénztár, sorban állnak. Ez rontja a mért TTFB értéket és a vásárlói élményt is, de hogy nálad mekkora a hatás, azt csak méréssel tudod meg.

Hogyan találod meg a böngésző Network paneljén?

Nyisd meg az oldalt inkognitó ablakban, kapcsold be a fejlesztői eszközök Network paneljét, és a szűrőbe írd be azt, hogy wc-ajax. Ha megjelenik egy get_refreshed_fragments sor, a szkript fut az oldalon.

1. Nyiss inkognitó ablakot, hogy a sessionStorage és a sütik üresek legyenek.
2. Nyisd meg a fejlesztői eszközöket (F12), és válaszd a Network fület. Pipáld be a Disable cache opciót.
3. Töltsd be a főoldalt, egy kategóriaoldalt és egy blogbejegyzést is.
4. A szűrőbe írd be, hogy wc-ajax.
5. Kattints a kérésre. A Timing fülön a Waiting for server response sor mutatja, mennyit dolgozott a szerver.
6. Az Initiator oszlopban megnézheted, melyik szkript indította. Ha ott a cart-fragments.min.js szerepel, megtaláltad.

A Response fülön a JSON-ban látszik, milyen szelektorokat frissít a kérés. Ebből derül ki, mely sablonelemek függnek tőle, és ezt a javítás előtt érdemes leírnod.

Ha azt is tudni akarod, ki tölti be a szkriptet, a Sources panelen vagy az oldal forrásában keresd a wc-cart-fragments azonosítót. A szkript előtti és utáni elemekből gyakran kiderül, melyik téma vagy bővítmény hozta be.

Hogyan azonosítod a szervernaplóban?

Az access logban a kérés POST /?wc-ajax=get_refreshed_fragments sorként jelenik meg, ezért egy egyszerű szövegkereséssel megszámolható, milyen gyakran fut, és ha a naplóformátum tartalmazza, az is, mennyi ideig tart.

Néhány hasznos parancs, ha SSH-hozzáférésed van (az útvonalat igazítsd a saját szerveredhez):

• Napi darabszám: grep -c 'get_refreshed_fragments' /var/log/nginx/access.log
• Óránkénti eloszlás: grep 'get_refreshed_fragments' access.log | awk '{print substr($4,2,14)}' | sort | uniq -c
• Arány az összes kéréshez, ami a fenti darabszám osztva a wc -l access.log eredményével.

Hivatalosan igazolt. Nginx alatt a log_format direktívában a $request_time változóval, Apache alatt a %D formátumkóddal naplózható a kérés feldolgozási ideje. Alapból egyik sem szerepel a naplóban, ezt külön be kell kapcsolni.

Saját tapasztalat. Árulkodó jel, ha a fragmens-kérések száma közel jár a HTML-oldalletöltésekéhez, vagy ha a PHP lassú naplójában (slow log) gyakran szerepel ez a végpont. Ha a tárhely panelje mutat PHP-folyamat telítettséget, vesd össze az időpontokat a fragmens-kérések óránkénti eloszlásával.

Milyen megoldások közül választhatsz?

Három bevált irány van: a szkript kikapcsolása a nem kosároldalakon, a futtatás csak nem üres kosárnál, vagy a kosárikon sablonszintű megoldása fragmensek nélkül. Mindegyik csökkentheti a terhelést, és mindegyiknél elromolhat valami a kosárszámlálóban. A kódrészleteket gyerektémában vagy saját kis bővítményben helyezd el, és először tesztkörnyezetben próbáld ki.

1. Kikapcsolás a nem kosároldalakon

A legegyszerűbb lépés, ha a szkriptet mindenhol kiveszed a kosár- és a pénztároldal kivételével.

add_action( 'wp_enqueue_scripts', function () {
if ( is_cart() || is_checkout() ) { return; }
wp_dequeue_script( 'wc-cart-fragments' );
}, 100 );

A 100-as prioritás azért kell, hogy a kód a téma és a bővítmények után fusson, különben azok újra betölthetik a szkriptet.

Kockázat. A fejléc kosárszámlálója a gyorsítótárazott HTML-ben lévő értéket mutatja, ami jó eséllyel 0. Aki termékoldalon kosárba tesz valamit, majd átmegy egy kategóriaoldalra, üres kosarat láthat a fejlécben, és ez bizalmatlanságot kelthet. Az AJAX-os kosárba tétel közvetlenül utána még frissíti a számot, mert a WooCommerce add-to-cart válasza saját maga is visszaküldi a fragmenseket, de a következő gyorsítótárazott oldalon a hiba visszajön.

Szakmai feltételezés. Ez a megoldás akkor elfogadható, ha a fejlécben nincs számláló, csak egy kosárra mutató ikon, vagy ha a gyorsítótár-bővítmény a kosársütinél amúgy is kihagyja a gyorsítótárat.

2. Futtatás csak nem üres kosárnál

A WooCommerce a woocommerce_items_in_cart sütit akkor állítja be, ha a kosárban van termék. Erre építve a szkript csak azoknál tölthető be, akiknek tényleg van mit frissíteni.

add_action( 'wp_enqueue_scripts', function () {
if ( empty( $_COOKIE['woocommerce_items_in_cart'] ) ) {
wp_dequeue_script( 'wc-cart-fragments' );
}
}, 100 );

Kockázat. Ez a kód a szerveren fut, tehát csak akkor működik, ha a PHP egyáltalán lefut. Ha a lapgyorsítótár a sütitől függetlenül kiszolgálja a tárolt HTML-t, akkor az a változat jut el mindenkihez, amelyik az első, üres kosarú látogatónál készült, szkript nélkül. Ilyenkor a kosaras látogató is elavult számot lát.

Saját tapasztalat. A gyakori WordPress gyorsítótár-bővítmények és sok tárhelyszintű gyorsítótár alapbeállításként kihagyja a gyorsítótárat, ha a woocommerce_items_in_cart süti jelen van. Ezt ne feltételezd, hanem ellenőrizd. Tegyél egy terméket a kosárba, töltsd újra a kategóriaoldalt, és nézd meg a válaszfejlécekben, hogy a gyorsítótár HIT vagy MISS állapotot jelez. CDN használatakor (például teljes oldalas edge cache) külön is nézd meg a süti alapú kivételt.

További kockázat a több eszközös bejelentkezett vásárló. Ha valaki a telefonján tett kosárba terméket, és a gépén bejelentkezik, a sütik a belépéskor állnak be, így jellemzően rendben lesz, de ezt is teszteld.

3. Sablonszintű kosárikon

A legtisztább, de legtöbb munkát igénylő út az, ha a kosárszámláló nem fragmensből, hanem egy könnyű sütiből vagy igény szerinti lekérdezésből kapja az értékét. Így a gyorsítótárazott oldalak egyáltalán nem hívják a szervert a kosár miatt.

Az egyik lehetőség egy saját süti, ami a kosár darabszámát tárolja:

add_action( 'woocommerce_set_cart_cookies', function ( $set ) {
$db = ( $set && WC()->cart ) ? WC()->cart->get_cart_contents_count() : 0;
wc_setcookie( 'kosar_db', $db );
} );

A sablonban a számláló egy egyszerű elem lesz, például <span class='kosar-szamlalo'></span>, amit néhány sor JavaScript tölt ki:

function kosarFrissit() {
var m = document.cookie.match(/(?:^|; )kosar_db=(\d+)/);
document.querySelectorAll('.kosar-szamlalo').forEach(function (el) {
el.textContent = m ? m[1] : '0';
});
}
document.addEventListener('DOMContentLoaded', kosarFrissit);
jQuery(document.body).on('added_to_cart removed_from_cart', kosarFrissit);

Szakmai feltételezés. A woocommerce_set_cart_cookies hook a WooCommerce forráskódjában szerepel, de a viselkedését verziófrissítés után érdemes újra ellenőrizni. A blokkos témáknál a WooCommerce Mini Cart blokkja a Store API-t használja, és jellemzően csak megnyitáskor tölti be a kosár tartalmát. Ha blokkos témád van, előbb ezt próbáld ki, mielőtt saját megoldást írsz.

Kockázat. Ha a kosár olyan úton változik, ami nem állítja be újra a sütit (egyedi bővítmény, kupon, készlethiány miatti automatikus törlés), a szám elcsúszhat. A legördülő mini kosár tartalma sem lesz meg fragmensek nélkül. Ezt vagy elhagyod, és az ikon a kosároldalra visz, vagy kattintásra kéred le a Store API /wp-json/wc/store/v1/cart végpontjáról. A legtöbbet a gondatlan frissítés árthat. Ha egy téma- vagy bővítményfrissítés visszahozza a wc-cart-fragments szkriptet, egyszerre két rendszer írja ugyanazt a számlálót.

Melyik megoldást mikor érdemes választani?

Ha a fejlécben nincs kosárszámláló, az első megoldás elég lehet. Ha van számláló, és a gyorsítótár igazoltan kihagyja a kosársütis kéréseket, a második a legjobb arányú. Ha a webshop sok forgalmat kap, és van fejlesztői kapacitás, a harmadik jó eséllyel a legnagyobb terheléscsökkenést hozza.

Saját tapasztalat. A legtöbb webshopnál a második megoldás és egy alapos gyorsítótár-ellenőrzés együtt hozza a legjobb arányt a ráfordítás és az eredmény között. A hatást a szervernaplóval mérd, előtte és utána ugyanazon a napszakon, mert a Lighthouse-pontszám egymagában félrevezető lehet. A gyorsítótárazott laborméréseknél a fragmens-kérés hatása gyakran alig látszik.

Egyik megoldás sem garantál adott sebességjavulást. Ha a fragmens-kérés lassú, az gyakran egy mélyebb gond tünete (túl sok bővítmény, lassú adatbázis-lekérdezések, telített PHP-folyamatok), és ezek a kikapcsolástól nem tűnnek el, csak ritkábban jönnek elő.

Mit tesztelj a módosítás után?

A módosítás után mindig inkognitó ablakban, gyorsítótár-ürítés után, asztali gépen és mobilon is nézd végig a kosár teljes életútját. Az alábbi lista a leggyakoribb hibákat fogja meg.

1. Üres kosárral a Network panelen nincs get_refreshed_fragments kérés a nem kosároldalakon (vagy csak ott van, ahol szándékosan meghagytad).
2. Termékoldalon kosárba teszel egy terméket, és a számláló azonnal a helyes értéket mutatja.
3. Átlépsz egy kategóriaoldalra és egy blogbejegyzésre, és a számláló ott is helyes.
4. Kategóriaoldalról, AJAX-os kosár gombbal teszel be terméket, és a szám frissül újratöltés nélkül.
5. A kosároldalon módosítod a mennyiséget és törölsz egy tételt, majd visszamész a főoldalra, és a szám követi a változást.
6. A böngésző vissza gombjával visszalépsz egy korábbi oldalra, és nem a régi kosárszám jelenik meg.
7. Két lapon nyitod meg a webshopot, az egyiken változtatsz a kosáron, a másikat újratöltöd, és a szám egyezik.
8. Kijelentkezett kosárral belépsz, és a mentett kosár száma megjelenik.
9. Sikeres rendelés után a számláló 0-ra áll.
10. A gyorsítótár válaszfejlécei kosaras állapotban MISS vagy BYPASS értéket mutatnak, ha a második megoldást választottad.
11. A szervernaplóban egy nap múlva összeveted a fragmens-kérések számát és válaszidejét a korábbi értékkel.
12. A következő téma- és bővítményfrissítés után újra lefuttatod az első pontot, mert egy frissítés visszahozhatja a szkriptet.

Ha bármelyik pont elbukik, inkább hagyd meg a fragmens-kérést egy szűkebb körben. Egy lassabb, de pontos kosárszámláló kisebb baj, mint egy gyors, de hibás.

Források és további olvasnivalók

• WooCommerce Developer Documentation (cart fragments, Store API)
• WooCommerce Developer Blog, a WooCommerce 7.8 kiadási közleménye
• WordPress Developer Resources, wp_dequeue_script és wp_enqueue_scripts
• MDN Web Docs, Window.sessionStorage és Document.cookie
• Chrome DevTools dokumentáció, Network panel
• web.dev, Time to First Byte (TTFB)
• nginx dokumentáció, ngx_http_log_module (log_format)