Webshop s 10.000+ proizvoda: zašto usporava

Kad rast kataloga postane tehnički problem, ne kozmetički

Ukratko: veliki katalog ne usporava webshop sam po sebi — usporavaju ga četiri konkretna, imenovana uzroka: neindeksirana baza podataka, relacijsko filtriranje bez dedicated pretrage, cache bez precizne invalidacije i neoptimizirane slike. Svaki ima poznato, dokumentirano rješenje, redom od najjeftinijeg prema najskupljem.

Webshop koji je bio brz sa 500 proizvoda ne mora ostati brz na 10.000. Ne zato što je platforma loša, nego zato što se određene operacije ponašaju linearno ili gore s brojem proizvoda, dok je infrastruktura ispod njih projektirana za manji obujam. Ovo je vodič kroz te uzroke i redoslijed kojim ih vrijedi rješavati, kao nastavak šireg pregleda u izradi webshopa u Hrvatskoj 2026.

Baza podataka nosi najveći teret prva

Kod WooCommercea, svaki proizvod, varijacija, atribut i meta-podatak (cijena, zaliha, SKU) tradicionalno se čuva u zajedničkim WordPress tablicama wp_posts i wp_postmeta — istim tablicama koje dijele stranice, blog postovi i narudžbe. Na malom katalogu to ne smeta. Na tisućama proizvoda s desecima meta-polja po proizvodu, tablica wp_postmeta naraste na milijune redaka, a upiti koji filtriraju po cijeni, zalihi ili atributu moraju pretraživati taj cijeli, nedovoljno indeksiran prostor.

WooCommerce ovo rješava premještanjem narudžbi u posebne, namjenski indeksirane tablice — značajka koja se zove High-Performance Order Storage (HPOS), zadana za nove instalacije od verzije 8.2 (službena dokumentacija HPOS-a). To rješava polovicu problema — narudžbe. Proizvodni katalog i dalje sjedi u wp_postmeta, pa na velikim katalozima ostaje na razvojnom timu da doda ciljane indekse ili premjesti kritične atribute (cijena, zaliha) u posebne, indeksirane tablice.

Kod custom/headless arhitekture ovaj problem se rješava drugačije od početka — shema baze se projektira za katalog, ne nasljeđuje iz općeg CMS-a. To je jedan od praktičnih razloga zašto veći katalozi češće završe na headless rješenju, ne stilski nego strukturno.

Filtriranje i pretraga pucaju prvi, prije nego korisnik primijeti sporost stranice

Faceted pretraga — filtriranje po više atributa istovremeno (kategorija + veličina + boja + raspon cijene) — na relacijskoj bazi znači kombinatorni upit preko više tablica odjednom. Na 500 proizvoda to je trenutno. Na 10.000+ proizvoda s desecima atributa, isti upit počinje trošiti stotine milisekundi po zahtjevu, a s više istovremenih posjetitelja koji filtriraju, opterećenje baze raste brže od broja proizvoda.

Ovo je točka gdje standardni plugin filtar (WooCommerce, Shopify built-in search) prestaje biti dovoljan i tim počinje razmatrati dedicated search infrastrukturu — Algolia, Meilisearch ili Elasticsearch — koja indeksira katalog odvojeno od transakcijske baze i odgovara na filtriranje u milisekundama neovisno o broju atributa. Ovo nije nadogradnja koju svaki webshop treba; ima smisla kad se filtriranje po atributima stvarno koristi i kad je katalog dovoljno velik da relacijski upit postane mjerljivo spor za korisnika.

Generiranje stranica na skali — zašto SSR/ISR nije samo "headless trend"

Standardna platforma generira stranicu proizvoda ili kategorije iznova pri svakom zahtjevu (server-side rendering na zahtjev) ili je servira iz cachea koji plugin mora sam upravljati. Na tisućama stranica proizvoda, cache invalidation postaje vlastiti problem — kad se promijeni cijena ili zaliha jednog proizvoda, sustav mora znati točno koje generirane stranice osvježiti, a ne cijeli katalog.

Next.js ovo rješava mehanizmom koji sam dokumentira kao Incremental Static Regeneration — stranice se predrenderiraju unaprijed, a osvježavaju u pozadini bez ponovne izgradnje cijele stranice (Next.js dokumentacija o ISR-u). Za katalog od 10.000 proizvoda to znači da posjetitelj gotovo uvijek dobiva već generiranu stranicu. Osvježavanje pojedinačnih stranica događa se u pozadini kad se podatak promijeni — ne pri svakom zahtjevu.

Shopify ima drugačiji strop od WooCommercea, ne isti problem

Shopify ne pati od istog problema s relacijskom bazom jer je katalog upravljan na platformskoj infrastrukturi, ne na serveru trgovca. Ali ima svoj strop: dugo je vrijedilo ograničenje od 100 varijanti po proizvodu, koje je Shopify tijekom 2025./2026. povećao na 2.048 (službeni Shopify changelog). Veći limit ne rješava sve automatski — teme i dalje ograničavaju Liquid objekt product.variants na manji broj unosa radi performansi, a aplikacije za pretragu, pretplate, recenzije ili feedove mogu se slomiti ili usporiti kad se pređe stari prag od 100 varijanti, jer nisu sve ažurirane za novi limit.

Praktična posljedica za veći katalog na Shopifyju: prije nego povećate broj varijanti po proizvodu, provjerite koje su aplikacije u vašem stacku testirane za rad iznad 100 varijanti — inače dobivate novi limit, ali stare greške.

Slike i medijska imovina rastu brže od kataloga

Svaki proizvod obično nosi 3-8 slika u više veličina za responzivni prikaz. Na katalogu od 10.000 proizvoda to je, samo kao ilustracija te računice, već 30.000-80.000 datoteka. Ako se slike serviraju izravno sa servera aplikacije, umjesto s CDN-a s automatskom optimizacijom formata (WebP/AVIF) i veličine po uređaju, to je problem. Svaka stranica kategorije s 40+ proizvoda tada povlači desetke nekomprimiranih zahtjeva odjednom. Ovo je često najjeftiniji problem za riješiti — CDN sloj s automatskom transformacijom slika — i najčešće zanemaren jer ne izgleda kao "arhitektonski" problem dok se katalog ne uveća.

Kako izmjeriti gdje kašnjenje stvarno nastaje, prije nego trošite na rješenje

Prije bilo kakve investicije vrijedi točno utvrditi gdje se vrijeme gubi, umjesto nagađanja. Nekoliko provjera koje ne traže poseban alat: usporedite Lighthouse ocjenu stranice proizvoda naspram stranice kategorije s 40+ artikala — ako je razlika velika, problem je u renderiranju liste, ne u pojedinačnom proizvodu. Na WooCommerceu, plugin Query Monitor pokazuje točan broj i trajanje SQL upita po stranici — ako jedna stranica kategorije generira stotine upita, problem je u bazi, ne u hostingu. Na Shopifyju, Theme Inspector u temi pokazuje koliko vremena Liquid renderiranje troši po sekciji, što razdvaja "spora tema" od "prevelik broj varijanti po proizvodu".

Ova dijagnostika obično traje sat-dva i sprječava najskuplju grešku: kupnju veće infrastrukture (search servis, migracija platforme) za problem koji je zapravo jedan nedostajući indeks ili jedan neoptimiziran plugin.

B2B i veleprodajni katalozi osjete ovo prije nego B2C

Veleprodajni webshopovi obično prije udare u ove granice od standardnih B2C trgovina istog broja proizvoda, jer se na isti katalog dodaje sloj cjenika po kupcu, minimalnih količina i različitih uvjeta dostave — svaki dodatni sloj filtriranja ili logike po korisniku množi opterećenje na bazu koje smo opisali gore. Ovo je jedan od praktičnih razloga zašto B2B webshopovi s rastućim katalogom češće ranije razmatraju custom arhitekturu — detaljnije u tekstu o izradi B2B webshopa u Hrvatskoj.

Simptom → vjerojatan uzrok

Prije nego uložite u veću infrastrukturu, vrijedi točno locirati gdje usporavanje nastaje:

Kad zakrpa više nije dovoljna

Indeksiranje baze, CDN za slike i bolji cache rješavaju veliku većinu slučajeva bez promjene platforme. Vrijedi razmotriti dedicated search infrastrukturu ili prelazak na custom/headless arhitekturu tek kad se javi kombinacija sljedećih signala:

Ako prepoznajete više od jednog signala, vrijedi pogledati i širi kontekst u tekstu o 7 signala da webshopu treba redizajn, jer se veliki katalog često poklapa i s drugim razlozima za arhitektonsku promjenu, ne samo tehničkim.

Redoslijed kojim vrijedi rješavati, ne sve odjednom

Najčešća greška kod rasta kataloga nije prekasna reakcija, nego pogrešan redoslijed — trgovci često prvo razmatraju potpuni prelazak platforme dok bi indeksiranje baze i CDN za slike riješili većinu mjerljivog usporavanja uz djelić troška. Praktičan redoslijed: prvo izmjerite gdje stvarno nastaje kašnjenje (admin, filtriranje, stranica proizvoda ili checkout), zatim riješite bazu i slike jer su najjeftiniji i najmjerljiviji, tek onda razmatrajte dedicated search ili arhitektonsku promjenu ako simptomi ostanu. Isti princip vrijedi kod integracije s ERP-om ili sustavom dostave na velikom katalogu — o tome pišemo u tekstu o integraciji webshopa s dostavom, plaćanjem i ERP-om.

Zaključak

Usporavanje na velikom katalogu ima konkretne, imenovane uzroke — neindeksiranu bazu, relacijsko filtriranje bez dedicated pretrage, cache bez precizne invalidacije, neoptimizirane slike — ne "platforma je stara" ili "treba nam headless". Rješavanje istim redoslijedom kojim nastaju štedi i vrijeme i budžet: baza i slike prve, dedicated search i arhitektonska promjena tek kad signali to stvarno opravdaju.

U FIN STUDIU radimo i optimizaciju postojećih webshopova na velikom katalogu i custom arhitekturu od nule kad rast to opravda. Javite nam se za provjeru gdje točno vaš katalog usporava i što se stvarno isplati riješiti prvo.