Halloween e doar repetiția. Black Friday e adevăratul film de groază.Sezonul Black Friday a început. Fiecare secundă de așteptare te costă vânzări. Încearcă Nightmare Mode →

← Înapoi la blog

Guides

24 de versiuni pentru fiecare produs: cum poate fi pus în cache un magazin Magento B2B

7 noiembrie 2026 - de Alexandru-Manuel Carabus

Ți s-a spus că un magazin B2B cu prețuri pe grupuri de clienți nu poate fi pus în cache? La Vitacom, fiecare produs are 24 de versiuni în cache, iar clienții firme autentificați primesc și ei pagini din cache, cu prețul grupului lor. Cum funcționează, ce nu intră niciodată în cache și verificarea de cinci minute pe care o poți face singur.

Un perete de vitrine în miniatură cu 24 de compartimente, fiecare cu aceeași cutie de produs pregătită, unul cu ușa portocalie: 24 de versiuni ale aceluiași produs, gata servite din cache.

Dacă vinzi B2B pe Magento, probabil ai auzit fraza: „Avem prețuri pe grupuri de clienți, deci nu putem pune paginile în cache.” Sună logic. Fiecare firmă vede alt preț, așa că pare imposibil să păstrezi o singură copie a paginii pentru toată lumea.

Nu e nevoie de o singură copie. La Vitacom, fiecare produs are 24 de versiuni în cache, iar un client B2B autentificat primește și el o pagină din cache, cu prețul grupului lui. Mai jos explicăm cum funcționează, ce nu intră niciodată în cache și cum verifici singur, în cinci minute, dacă magazinul tău folosește cache-ul sau îl ocolește.

De ce B2B pare imposibil de pus în cache

Cache-ul paginilor (pe Magento, de obicei Varnish) păstrează o copie gata făcută a fiecărei pagini. Următorul vizitator o primește în milisecunde, fără ca Magento să mai ruleze codul și interogările din baza de date.

Pe un magazin B2C, toată lumea vede același preț, deci o copie ajunge. Pe un magazin B2B apare teama firească: ce se întâmplă dacă firma A vede prețul negociat de firma B? Ca să evite riscul, multe magazine fac unul din două lucruri:

  • opresc cache-ul pentru clienții autentificați, adică exact pentru cei care cumpără cel mai mult;
  • sau ajung să ocolească cache-ul fără să știe, din cauza unei setări greșite.

La auditul Vitacom din noiembrie 2025 am găsit a doua situație. Varnish era instalat, dar ocolit: anteturile trimise de magazin făceau paginile să sară peste cache. Fiecare vizită construia pagina de la zero, cu până la 15 milioane de operații în baza de date pentru o singură pagină.

Ce înseamnă „24 de versiuni”

Magento știe, la fiecare vizită, câteva lucruri despre context: pe ce magazin este clientul și din ce grup de clienți face parte. Varnish poate păstra câte o copie separată a paginii pentru fiecare combinație.

Vitacom are trei magazine pe aceeași instalare Magento (retail, B2B și export) și clienți organizați pe grupuri. Calculul arată așa:

  • 1 versiune pentru vizitatorii neautentificați;
  • 7 versiuni, câte una pentru fiecare grup de clienți;
  • deci 8 versiuni pe magazin, înmulțit cu 3 magazine: 24 de versiuni pentru fiecare produs.

Un client B2B care se autentifică primește copia grupului său, cu prețurile grupului său. Un client dintr-un alt grup primește altă copie. Nimeni nu vede prețul altcuiva, pentru că fiecare grup are propria pagină.

Ce nu intră niciodată în cache

Unele pagini sunt personale și nu au ce căuta într-o copie comună:

  • checkout-ul, unde sunt adresa, livrarea și plata fiecărui client;
  • paginile de cont: comenzile, adresele, datele firmei.

La Vitacom, aceste pagini nu sunt puse niciodată în cache. Ele se construiesc pentru fiecare client, la fiecare vizită. Paginile de produs vin din cache, pentru vizitatorii neautentificați și pentru fiecare grup.

Schemă: trei magazine Vitacom, retail, B2B și export, fiecare cu 8 versiuni în cache ale aceleiași pagini de produs, una pentru vizitatorii neautentificați și câte una pentru fiecare din cele 7 grupuri de clienți. 8 versiuni × 3 magazine = 24 de versiuni pentru fiecare produs. Checkout-ul și paginile de cont nu intră niciodată în cache.
Schemă: trei magazine Vitacom, retail, B2B și export, fiecare cu 8 versiuni în cache ale aceleiași pagini de produs, una pentru vizitatorii neautentificați și câte una pentru fiecare din cele 7 grupuri de clienți. 8 versiuni × 3 magazine = 24 de versiuni pentru fiecare produs. Checkout-ul și paginile de cont nu intră niciodată în cache.

Ce s-a schimbat la Vitacom

Cache-ul pe grupuri de clienți a intrat în producție în noaptea de 19 mai 2026, odată cu Liquid Framework și Hyvä Checkout. Ce s-a văzut imediat:

  • încărcarea procesorului bazei de date a coborât de la 200% până la 350% (100% înseamnă un nucleu) la, în cea mai mare parte, sub 50%, imediat după lansare;
  • serverul a putut fi redus la 8 nuclee și 32 GB, după 64 de nuclee și 256 GB la audit.

Iar cifra cu care am câștigat Best Performance Improvement la HIVE Germany 2026: răspunsul serverului a coborât de la 15.814 ms la 12 ms. Cele 12 ms sunt Varnish care servește o pagină de produs din cache. Cele 15.814 ms erau serverul vechi care construia pagina principală de la zero. Sunt pagini diferite, dar amândouă arată cât așteaptă un client primul răspuns, pe magazinul live. Etapele proiectului sunt în Trei lansări, nu una singură.

Verificarea de cinci minute

Nu ai nevoie de un dezvoltator ca să vezi dacă paginile vin din cache. Configurația Varnish standard din Magento adaugă la fiecare răspuns un antet numit X-Magento-Cache-Debug, care spune HIT (din cache) sau MISS (construită acum).

  1. Deschide o pagină de produs în Chrome, fără să fii autentificat.
  2. Apasă F12, alege tabul Network și reîncarcă pagina.
  3. Dă click pe primul rând din listă (pagina însăși) și caută, la Response Headers, X-Magento-Cache-Debug.
  4. Reîncarcă. Prima dată poate scrie MISS. A doua oară ar trebui să scrie HIT.
  5. Autentifică-te cu un cont de test dintr-un grup B2B și repetă pașii 2 până la 4 pe aceeași pagină.

Cum citești rezultatul:

  • HIT la a doua încărcare, și neautentificat, și autentificat: cache-ul funcționează pentru grupul respectiv.
  • Mereu MISS: paginile nu ajung în cache sau sunt șterse prea des. Aici e de lucru.
  • Antetul lipsește: întreabă dezvoltatorul dacă magazinul are Varnish și dacă antetul a fost eliminat intenționat.
Antetul X-Magento-Cache-Debug în răspunsul unei pagini de produs: MISS la prima încărcare, când pagina e construită acum, și HIT după reîncărcare, când vine din cache. Mereu MISS înseamnă că paginile nu ajung în cache; dacă antetul lipsește, întreabă dezvoltatorul dacă magazinul are Varnish.
Antetul X-Magento-Cache-Debug în răspunsul unei pagini de produs: MISS la prima încărcare, când pagina e construită acum, și HIT după reîncărcare, când vine din cache. Mereu MISS înseamnă că paginile nu ajung în cache; dacă antetul lipsește, întreabă dezvoltatorul dacă magazinul are Varnish.

Și o verificare de bun-simț, la fel de importantă: cu două conturi de test din grupuri diferite, deschide același produs. Fiecare cont trebuie să vadă prețul propriului grup.

Pentru dezvoltatorul tău

Pe scurt, partea tehnică

  • Varnish păstrează o copie separată pentru fiecare valoare a cookie-ului X-Magento-Vary. Magento setează acest cookie din contextul vizitei (magazin, grup de clienți), iar VCL-ul îl adaugă la cheia de cache. Așa apar versiunile pe grup.
  • Un singur bloc cu cacheable="false" într-un layout face necacheabilă toată pagina care folosește acel layout. Caută în layout-urile de frontend înainte să concluzionezi că B2B „nu se poate pune în cache”.
  • Invers, paginile de cont proprii trebuie să aibă cacheable="false". Fără el, datele unui client pot ajunge în copia din cache a grupului.
  • În testele noastre pe Magento 2.4.8, cache-ul integrat al Magento nu a servit niciodată un HIT unui client autentificat. Pentru clienți B2B serviți din cache, ai nevoie de Varnish.
  • Antetul de verificat este X-Magento-Cache-Debug (HIT sau MISS).

Ce înseamnă pentru magazinul tău

Dacă ți s-a spus că un magazin B2B nu poate fi pus în cache, întrebarea corectă este: „pentru câte combinații de magazin și grup de clienți?”. Răspunsul e un număr finit, nu „pentru fiecare client”. La Vitacom este 24 pe produs.

Am scris separat despre alte capcane ale B2B pe Hyvä, inclusiv despre afișarea prețurilor pe grupuri, în Magento B2B pe Hyvä: ce merge, ce se strică și cât timp cere.

Pe Magento și Hyvä

Liquid Framework, acceleratorul nostru Hyvä, ține cache-ul plin, pentru vizitatori și pentru fiecare grup de clienți, așa că clienții primesc pagini gata făcute, nu copii lente, construite de la zero.

Ai aflat că magazinul tău B2B „nu se poate pune în cache”? Programează un apel de strategie gratuit, de 30 de minute. Verificăm împreună ce ajunge în cache, pentru vizitatorii neautentificați și pentru fiecare grup, și ce nu.

Primește următorul articol pe email

Un email pe lună cu articolele noi, optimizări de viteză și patch-urile de securitate Magento care merită aplicate.

Un email pe lună. Te dezabonezi dintr-un click. Politica de confidențialitate

Site protejat de reCAPTCHA. Se aplică Politica de confidențialitate și Termenii și condițiile Google.