Shopify a anunțat că extensiile UI care folosesc API versiunea 2025-10 sau mai nouă sunt limitate la un bundle JavaScript comprimat de maximum 64 KB per extensie. Extensiile de tip full page pentru contul de client pot merge până la 128 KB. Dacă după optimizare bundle-ul rămâne peste limită, dezvoltatorul rulează shopify app build și trimite bundle-ul minificat împreună cu metafile-ul esbuild printr-un formular dedicat de excepție. Shopify analizează conținutul și poate aproba o creștere a limitei doar dacă greutatea rămasă este inevitabilă. Cererile sunt respinse pentru greutate evitabilă: biblioteci grele, dependențe duplicate, traduceri incluse în bundle în loc să fie livrate prin API-urile native de localizare. În plus, pentru a rămâne deployabil după 1 octombrie 2026, fiecare extensie UI existentă trebuie să folosească API versiunea 2026-01 sau mai nouă.

Sursa: Shopify Changelog.

Ce se schimbă, de fapt, în practică

Pentru cine nu lucrează zilnic cu extensii Shopify, discuția despre kilobyți sună ca o problemă de nișă. Nu este. Un bundle este pachetul de cod JavaScript pe care Shopify îl încarcă în browserul cumpărătorului sau al comerciantului atunci când extensia se afișează. Cu cât acel pachet este mai mare, cu atât timpul de încărcare crește, iar pe checkout, pe pagina de cont sau în admin, fiecare milisecundă contează comercial.

Limita de 64 KB se aplică la bundle-ul comprimat, adică după ce codul a trecut prin minificare și compresie. Este un detaliu important: 64 KB comprimat nu înseamnă 64 KB de cod scris de mână, ci un volum care, decomprimat, poate ocupa de câteva ori mai mult. Pentru o extensie simplă, de tip widget sau banner, limita este generoasă. Pentru o extensie care a crescut organic, prin adăugare repetată de funcționalități, de dependențe și de mici biblioteci utilitare, limita devine rapid o problemă.

Al doilea element, poate mai important decât primul, este termenul. După 1 octombrie 2026, o aplicație trebuie să se asigure că fiecare extensie UI existentă folosește API versiunea 2026-01 sau mai nouă, altfel nu mai rămâne deployabilă. Aici nu mai vorbim despre performanță, ci despre capacitatea de a livra actualizări în producție. O extensie rămasă pe o versiune veche de API nu mai poate fi publicată sau actualizată, ceea ce blochează efectiv orice dezvoltare ulterioară.

Cine este afectat și cine poate sta liniștit

Primul grup afectat sunt agențiile și freelancerii care întrețin aplicații Shopify pentru clienți. De multe ori, aceste aplicații au fost construite acum doi-trei ani, au trecut prin mai mulți dezvoltatori și nimeni nu mai știe exact ce se află în package.json. Acesta este scenariul clasic în care limita de bundle lovește ca un perete: nu pentru că extensia ar fi uriașă, ci pentru că nimeni nu a mai curățat dependențele.

Al doilea grup sunt echipele de produs din companiile care vând pe Shopify și au construit extensii proprii pentru contul de client, pentru checkout sau pentru admin. Aici riscul nu este tehnic, ci comercial: dacă extensia nu mai poate fi actualizată, orice modificare de flux, orice campanie care depinde de o componentă custom, orice ajustare de sezon devine blocată.

Cine poate sta mai liniștit? Magazinele care folosesc exclusiv aplicații de pe Shopify App Store, fără extensii proprii. În acel caz, responsabilitatea pentru conformitate aparține vendorului aplicației, nu comerciantului. Chiar și așa, merită o verificare: dacă o extensie de checkout sau de cont de client se comportă ciudat în perioada următoare, este posibil ca furnizorul să fie în plin proces de optimizare.

Cum arată un audit de bundle făcut corect

Ordinea pașilor contează mai mult decât viteza. Iată un traseu propus, care nu înlocuiește documentația oficială, ci o pune în ordine operațională:

  1. Inventar complet. Listează fiecare extensie UI din aplicație și notează versiunea de API folosită. Fără acest pas, orice plan este o presupunere.
  2. Măsurare, nu intuiție. Rulează build-ul și uită-te la dimensiunea reală a bundle-ului comprimat. Nu estima, nu presupune că "e mic".
  3. Analiza metafile-ului. Metafile-ul esbuild arată exact ce module intră în bundle și cât cântărește fiecare. Aici apar de obicei surprizele: biblioteci întregi importate pentru o singură funcție, două versiuni ale aceleiași dependențe, utilitare duplicate.
  4. Curățare înainte de excepție. Elimină dependențele grele, înlocuiește bibliotecile mari cu implementări locale acolo unde are sens, scoate traducerile din bundle și mută-le pe API-urile native de localizare. Abia după aceea are sens să discuți despre o excepție.
  5. Formularul de excepție, doar ca ultim pas. Dacă bundle-ul rămâne peste limită după optimizare, trimiți bundle-ul minificat și metafile-ul. Shopify evaluează dacă greutatea rămasă este inevitabilă. O cerere trimisă înainte de curățare are șanse mici, pentru că exact motivele de respingere sunt cele pe care le-ai fi putut rezolva singur.
  6. Plan de migrare la API 2026-01. Termenul de 1 octombrie 2026 nu se negociază prin formular. Aici nu există excepție, doar conformare.

Un punct de transparență: nu toate aceste afirmații sunt constatări măsurate de noi. Sunt recomandări operaționale derivate din regulile publicate de Shopify. Ceea ce este fapt, conform sursei, este limita de 64 KB, plafonul de 128 KB pentru full page, existența formularului de excepție, motivele de respingere și termenul de 1 octombrie 2026 pentru API 2026-01. Restul este metodă de lucru propusă.

Capcana traducerilor în bundle

Unul dintre motivele explicite de respingere merită tratat separat: traducerile incluse direct în extensie în loc să fie livrate prin API-urile native de localizare. Este o greșeală frecventă, pentru că pare cea mai simplă soluție: adaugi un fișier JSON cu toate textele în mai multe limbi și gata. Problema este că fiecare limbă adaugă greutate permanentă în bundle, chiar și pentru utilizatorii care nu vor vedea niciodată acele texte.

Dacă vinzi în România, Ungaria, Bulgaria și Polonia, discuția nu mai este teoretică. Fiecare piață aduce un set de texte, iar tradițional acestea ajung în bundle. Mutarea lor către API-urile native de localizare reduce greutatea și, în plus, aliniază extensia la modul în care Shopify se așteaptă să fie gestionate limbile. Este una dintre puținele optimizări care rezolvă simultan o problemă tehnică și una de conformitate.

Ce înseamnă pentru tine, ca antreprenor sau marketer român

Să presupunem că ai un magazin Shopify cu volum serios de comenzi și ai investit într-o extensie custom pentru pagina de cont de client, unde clienții își văd istoricul de comenzi, statusul livrării și eventual un program de loialitate. Extensia a fost construită în 2024, a funcționat bine, nimeni nu s-a mai atins de ea.

Ce te lovește în 2026? Nu faptul că limita de bundle este depășită, neapărat. Te lovește combinația dintre două lucruri: dacă extensia folosește o versiune de API mai veche decât 2026-01, după 1 octombrie 2026 nu mai poți livra actualizări. Iar dacă vrei să optimizezi bundle-ul, acea optimizare este, tehnic, tot o actualizare. Rezultatul practic: te trezești că vrei să faci o modificare simplă și nu poți, pentru că mai întâi trebuie să rezolvi conformitatea.

Impactul comercial nu este direct măsurabil în CPA sau în vânzări. Nu avem date că acest lucru scade conversia. Ce știm din structura anunțului este altceva, mai simplu și mai neplăcut: dacă nu te conformezi, pierzi capacitatea de a modifica ceva în extensie. Pentru un marketer care plănuiește o campanie de Black Friday cu o componentă custom în contul de client, aceasta este o dependență reală de planificare, nu o notă tehnică.

Recomandarea practică este să tratezi subiectul ca pe o linie în planificarea trimestrului, nu ca pe o urgență de ultim moment. Verifică versiunile de API, măsoară bundle-urile, decide ce optimizezi intern și ce este inevitabil. Dacă lucrezi cu un dezvoltator extern, cere un raport scurt cu dimensiunea bundle-ului pe fiecare extensie și versiunea de API. Dacă răspunsul este vag, este un semnal de risc.

Contextul mai larg merită urmărit, pentru că presiunea pe performanță și pe conformitate în ecosistemul Shopify nu se oprește aici. Am scris recent despre filtrarea după tip de media în Shopify Catalog API, o schimbare care afectează modul în care sunt structurate datele de produs, și despre Google agentic commerce și ce schimbă pentru retaileri, unde viteza și calitatea datelor contează din ce în ce mai mult. Direcția este aceeași: platformele cer mai puțină greutate inutilă și mai multă claritate structurală.

Ce NU putem afirma pe baza acestei surse

Disciplina de verificare este importantă, mai ales când subiectul este tehnic și tentația de a dramatiza este mare. Pe baza materialului furnizat, nu putem afirma că aceste limite reduc vânzările, nu putem afirma că magazinele care nu se conformează primesc amenzi și nu putem afirma că o extensie care depășește limita se strică imediat pentru utilizatori. Sursa vorbește despre deploy și despre reguli de acceptare a bundle-ului, nu despre penalizări financiare sau despre comportamentul cumpărătorilor.

De asemenea, o verificare incompletă nu dovedește absența unei funcții. Dacă rulezi un audit superficial și nu găsești problema, nu înseamnă că problema nu există. Înseamnă că metoda de verificare a fost insuficientă. Aici recomandarea este simplă: dacă nu ai instrumentele sau timpul să analizezi metafile-ul esbuild și să urmărești dependențele, apelează la cineva care o face regulat, înainte de a trage concluzii.

Întrebări frecvente

Se aplică limita de 64 KB tuturor extensiilor Shopify? Conform sursei, limita se aplică extensiilor UI care folosesc API versiunea 2025-10 sau mai nouă. Extensiile de tip full page pentru contul de client au un plafon mai mare, de 128 KB comprimat. Nu toate tipurile de extensii sunt tratate identic.

Pot cere o excepție dacă bundle-ul meu depășește limita? Da, există un formular dedicat. Trimiți bundle-ul minificat și metafile-ul esbuild, după ce rulezi shopify app build. Shopify analizează conținutul și poate aproba o creștere dacă greutatea rămasă este inevitabilă. Cererile sunt respinse pentru greutate evitabilă, cum ar fi biblioteci grele, dependențe duplicate sau traduceri incluse în bundle.

Ce se întâmplă dacă nu migrez la API 2026-01 până la 1 octombrie 2026? Conform sursei, pentru a rămâne deployabilă după acea dată, fiecare extensie UI existentă trebuie să folosească API versiunea 2026-01 sau mai nouă. Nu este o chestiune de performanță, ci de capacitate de a publica actualizări.

Concluzia ALLSoft Agency

AI-ul ajută concret aici: poate inventaria dependențele, poate citi un metafile esbuild și poate propune în câteva minute ce biblioteci sunt redundante, ce importuri pot fi înlocuite și ce traduceri pot fi mutate pe API-urile native. Este exact genul de muncă repetitivă și plictisitoare la care un asistent automatizează 70 la sută din efort.

Dar decizia rămâne umană. Un media buyer sau un dezvoltator senior știe ce se poate scoate fără să rupă funcționalitatea, ce trebuie păstrat pentru stabilitate și ce este cu adevărat inevitabil în bundle. Algoritmul nu simte riscul de a livra o extensie ruptă în plin sezon. Omul, da.

Pasul concret îl face ALLSoft Agency: verificăm versiunile de API, măsurăm bundle-urile, punem la punct planul de optimizare sau de excepție și ne asigurăm că deploy-ul rămâne funcțional după termenul din octombrie 2026. Dacă vrei să știi exact unde stai înainte să te lovească termenul, începe de la allsoftagency.ro.