O pagină de produs WooCommerce se încarcă de obicei acceptabil. Pagina magazinului, listele de categorii și rezultatele căutării adesea nu, iar proprietarii de magazine sunt frecvent surprinși, fiindcă produsele luate separat par în regulă. Diferența este aritmetică. O pagină de produs arată o imagine principală. O pagină de categorie cu douăzeci și patru de produse arată cel puțin douăzeci și patru, și frecvent dublul, odată numărate efectele la trecerea cursorului și previzualizările de galerie.

Această înmulțire explică de ce paginile de catalog sunt de regulă cel mai lent lucru dintr-un magazin și de ce sunt totodată paginile care contează cel mai mult comercial. Ele stau între un vizitator care ajunge și un vizitator care găsește ceva de cumpărat.

Tiparul din spatele majorității cataloagelor lente: tema cere o dimensiune de miniatură pe care WordPress nu a generat-o niciodată, așa că browserul descarcă fișierul încărcat la dimensiune completă și îl micșorează în pagină. Douăzeci și patru de produse, fiecare trimițând o fotografie de doi megaocteți ca să o afișeze la trei sute de pixeli, dau o pagină de categorie de cincizeci de megaocteți care obține un scor prost indiferent câtă memorie cache adaugi.

De ce paginile de catalog se comportă altfel

Pe o pagină de listă se cumulează trei lucruri care nu apar pe o pagină de produs.

Volumul. Fiecare produs din grilă adaugă cel puțin o cerere de imagine. Setările implicite WooCommerce arată adesea șaisprezece sau douăzeci și patru pe pagină, iar magazinele mai mari cresc numărul ca să reducă paginarea.

Imagini la trecerea cursorului și de galerie. Multe teme preîncarcă o a doua imagine per produs pentru schimbul la hover. Asta dublează în tăcere numărul de imagini al paginii, iar fiindcă a doua imagine nu este niciodată vizibilă până la interacțiune, nu contribuie cu nimic la randarea inițială, deși costă aceeași lățime de bandă.

Instabilitatea layoutului. Grilele care nu rezervă spațiu pentru imagini se deplasează pe măsură ce fiecare imagine sosește. Pe o pagină de produs, o singură deplasare se suportă. Pe o grilă de douăzeci și patru, mișcarea cumulată produce un scor Cumulative Layout Shift slab și se simte ca o pagină care sare în timp ce încerci să dai clic.

Consecința este că paginile de catalog pică la Core Web Vitals din motive pe care o pagină de produs nu le are, iar optimizarea șablonului de produs nu face nimic pentru ele.

Nepotrivirea de dimensiune care cauzează cea mai mare parte

WordPress generează un set de dimensiuni de imagine la încărcare. WooCommerce înregistrează propriile dimensiuni peste acestea. Temele mai înregistrează altele. Ce primește browserul de fapt depinde de care dintre aceste dimensiuni o cere șablonul și dacă acea dimensiune există.

Modul de eșec este tăcut. Dacă o temă cere o dimensiune înregistrată după încărcarea produselor tale, WordPress nu a generat-o niciodată, așa că revine la originalul complet. Pagina arată în continuare corect, fiindcă browserul micșorează imaginea ca să încapă. Doar că mută mai mulți megaocteți ca să afișeze o miniatură.

Poți observa asta fără niciun instrument. Deschide o pagină de categorie, deschide panoul de rețea și sortează cererile de imagini după dimensiune. Dacă dimensiunile transferate sunt apropiate de greutatea fișierelor originale în loc să fie o fracțiune din ele, se servește dimensiunea greșită. Compară dimensiunile intrinseci ale unei imagini încărcate cu spațiul pe care îl ocupă pe ecran. O fotografie care sosește la două mii de pixeli lățime ca să umple o dală de trei sute de pixeli este toată problema într-o singură observație.

Soluția este fie regenerarea miniaturilor astfel încât dimensiunile cerute să existe, fie servirea dimensiunii corecte la livrare, ca întrebarea să nu se pună deloc.

Încărcarea întârziată și unde o ia razna

WordPress încarcă imaginile întârziat în mod implicit, ceea ce ajută paginile de catalog mai mult decât aproape orice alt tip de pagină, fiindcă cea mai mare parte a unei grile lungi se află sub linia de plutire.

Două greșeli anulează beneficiul.

Întârzierea primului rând. Imaginile vizibile la sosire ar trebui să se încarce imediat. Dacă cea mai mare este întârziată, browserul o descoperă târziu, iar fiindcă de obicei este elementul Largest Contentful Paint, măsurătoarea are direct de suferit. Majoritatea temelor greșesc aici, aplicând încărcarea întârziată uniform fiecărei dale de produs.

Pluginuri de încărcare întârziată care se luptă cu implementarea nativă. Rularea unui plugin care adaugă propria încărcare întârziată peste cea a browserului produce imagini care nu se încarcă niciodată, se încarcă de două ori sau pâlpâie. Dacă ai un plugin de performanță instalat, verifică dacă nu dublează ceva ce browserul face deja.

Livrarea: partea care scalează

Regenerarea miniaturilor repară catalogul de azi. Nu îl repară pe cel de luna viitoare, când un furnizor nou trimite fotografii cu alt raport de aspect sau când schimbi tema și dimensiunile necesare se schimbă din nou.

Transformarea imaginilor la livrare evită această moară. Originalul rămâne așa cum a fost încărcat, iar dimensiunea servită este decisă de URL, nu de ce s-a generat acum luni. Schimbi grila, schimbi parametrul. Nu există rulare de regenerare și niciun risc ca o dimensiune lipsă să cadă înapoi pe originalul complet.

Asta se potrivește deosebit de bine cataloagelor, fiindcă aceeași fotografie de produs apare de obicei în trei dimensiuni: o dală de grilă, o imagine de pagină de produs și o vedere cu zoom sau lightbox. Într-un model de facturare per imagine, sunt trei taxări per produs. În modelul Cloudflare sunt trei variante distincte indiferent câte produse ai, iar cererile repetate din aceeași lună nu costă nimic.

Comparația noastră între Cloudflare Image Transformations și pluginurile de imagini WordPress tratează diferențele dintre modelele de facturare și care se potrivește cărei forme de bibliotecă.

Ce să schimbi, în ordine

Parcurge aceste puncte în ordine. Fiecare este măsurabil separat, iar făcute aiurea îți e greu să spui ce a ajutat.

Începe prin a afla dacă ai nepotrivirea de dimensiune, fiindcă dacă o ai, nimic altceva nu contează până nu e rezolvată. Verifică dimensiunea transferată a imaginilor din grilă față de spațiul pe care îl ocupă.

Apoi redu câte imagini cere pagina. Oprește imaginile la trecerea cursorului dacă tema le preîncarcă și te poți lipsi de efect. Întreabă-te dacă douăzeci și patru de produse pe pagină servesc pe cineva sau dacă șaisprezece cu încărcare mai rapidă convertesc mai bine.

Apoi corectează limita încărcării întârziate, ca primul rând vizibil să se încarce imediat, iar tot ce e sub el nu.

Apoi ocupă-te de livrare, ca dimensiunile servite să corespundă celor afișate și să rămână corecte când catalogul se schimbă.

Abia după toate acestea memoria cache ajută semnificativ. Punerea în cache a unei pagini lente o face constant lentă, nu rapidă, și este pasul spre care se sare primul fiindcă e cel mai ușor de instalat.

Pentru tabloul mai larg dincolo de imagini, performanța WooCommerce tratează interogările de bază de date, supraîncărcarea pluginurilor și fragmentele necache-uite care încetinesc și ele magazinele.

Măsurat cum trebuie

Proprietarii de magazine știu de obicei că magazinul pare lent și nu știu care dintre o duzină de cauze posibile este responsabilă. Ghicitul costă scump, fiindcă soluțiile evidente sunt exact cele deja încercate.

Mecanik face audituri de performanță WordPress care măsoară anume paginile de catalog, în loc să testeze o pagină principală și să considere treaba încheiată, și se ocupă de implementare prin lucrări de dezvoltare WordPress acolo unde soluția depășește configurarea. Dacă paginile tale de categorie sunt cele care pierd vizitatori, acolo ar trebui să înceapă măsurătoarea.

Articole similare: Performanță WooCommerce: de ce magazinul tău este lent , Migrare site fără pierderi de trafic: ghid 2026 , Cloudflare Image Transformations vs pluginuri WordPress , Dezvoltare site e-commerce: Shopify vs soluție personalizată ., GEO pentru ecommerce: datele produs în răspunsurile AI

Întrebări frecvente

De ce sunt paginile de categorie WooCommerce mai lente decât cele de produs? O pagină de produs încarcă o imagine principală. O pagină de categorie încarcă una per produs, adesea dublată de imaginile la hover, deci douăzeci și patru de produse pot însemna patruzeci și opt de cereri. Aceeași tratare a imaginilor, inofensivă pe o pagină de produs, se cumulează prost pe o grilă.

Cum îmi dau seama dacă WooCommerce servește dimensiunea greșită? Deschide o pagină de categorie și panoul de rețea al browserului, apoi compară dimensiunea transferată a imaginilor din grilă cu fișierele originale. Dacă sunt similare în loc să fie o fracțiune, tema cere o dimensiune pe care WordPress nu a generat-o niciodată, iar originalul complet este micșorat în browser.

Să regenerez miniaturile sau să transform imaginile la livrare? Regenerarea repară catalogul actual, dar trebuie repetată la fiecare schimbare de dimensiuni sau de temă. Transformarea la livrare decide dimensiunea din URL, deci rămâne corectă la schimbarea temei și la încărcări noi, fără nicio rulare de regenerare.

Încărcarea întârziată ajută sau strică paginile de catalog WooCommerce? Ajută, fiindcă cea mai mare parte a unei grile lungi stă sub linia de plutire, dar primul rând vizibil ar trebui să se încarce imediat. Întârzierea celei mai mari imagini vizibile amână direct măsurătoarea Largest Contentful Paint, iar aceasta este o setare implicită frecventă a temelor.

Câte produse pe pagină sunt cele mai bune pentru performanță? Mai puține imagini înseamnă pagină mai rapidă, dar mai multă paginare înseamnă mai multe clicuri pentru navigare. Șaisprezece până la douăzeci și patru este uzual. Numărul contează mult mai puțin decât dacă fiecare imagine este dimensionată corect, fiindcă o grilă bine dimensionată de douăzeci și patru bate una supradimensionată de doisprezece.