Kaip optimizuoti WooCommerce 10 000+ produktų parduotuvę

Jei valdote didelę WooCommerce parduotuvę su dešimtimis tūkstančių produktų, tikriausiai susidūrėte su šia problema: svetainė tampa vis lėtesnė, serverio apkrova auga, o Google pozicijos krenta. Tai nėra neišsprendžiama problema – tik reikia tinkamos strategijos.

Šiame straipsnyje aptarsime visas svarbias optimizavimo sritis, nuo duomenų bazės iki CDN, ir paaiškinsime, kodėl WooCommerce optimizavimas daug produktų atveju reikalauja kitokio požiūrio nei mažose parduotuvėse.

Kodėl didelė WooCommerce parduotuvė tampa lėta?

Suprasime problemą prieš sprendžiant. WooCommerce kuria duomenų bazės lentelių struktūrą, kuri gerai veikia iki kelių tūkstančių produktų. Kai produktų daugėja, atsiranda kelios problemos:

• wp_posts lentelė – kiekvienas WooCommerce produktas yra post tipo įrašas. 10 000 produktų + variantai gali reikšti 50 000–200 000 eilučių
• wp_postmeta lentelė – produktų meta duomenys (kaina, SKU, svoris ir kt.) saugomi EAV (Entity-Attribute-Value) struktūroje – tai fundamentaliai neefektyvu didelėms parduotuvėms
• wp_options lentelė – su daugeliu įskiepių ši lentelė gali turėti tūkstančius eilučių, iš kurių dalis įkeliama su kiekvienu puslapiu
• Transients – netinkamai valdomi transients gali perpildyti duomenų bazę

Rezultatas: kiekvienas puslapio užkrovimas generuoja šimtus SQL užklausų, serveris dirba daugiau nei reikia, o skaitytojas laukia.

1. Duomenų bazės optimizavimas – pagrindas

Duomenų bazė yra didelės WooCommerce parduotuvės butelio kaklelis. Štai ką reikia daryti:

Optimizuokite wp_postmeta lentelę

WooCommerce 8.2+ pristatė naują HPOS (High Performance Order Storage) – atskiras užsakymų lenteles. Tačiau produktų meta duomenys vis dar saugomi wp_postmeta. Galite optimizuoti šią lentelę:

-- Patikrinkite lentelės dydį
SELECT table_name,
  ROUND(((data_length + index_length) / 1024 / 1024), 2) AS Dydis_MB
FROM information_schema.TABLES
WHERE table_schema = 'jusu_db_pavadinimas'
ORDER BY (data_length + index_length) DESC;

Jei wp_postmeta yra didžiausia lentelė – tai patvirtina problemą.

Šalinkite nereikalingus postmeta įrašus

Laikui bėgant susikaupia tūkstančiai našlaičių meta įrašų – meta duomenys produktų, kurie jau ištrinti. Naudokite šią SQL komandą (prieš tai padarykite backup!):

-- Rasti naslaiciai meta irasai
SELECT COUNT(*) FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL;

Reguliari lentelių optimizacija

Nustatykite savaitinę MySQL lentelių optimizaciją per WP-CLI arba cron:

wp db optimize

Su MariaDB naudokite innodb_buffer_pool_size – turėtų būti 70–80% serverio RAM.

2. WooCommerce HPOS – perjunkite jau dabar

WooCommerce High Performance Order Storage (HPOS) yra ne tik greičio gerinimas – tai nauja duomenų bazės architektūra užsakymams. Didelėse parduotuvėse tai gali sumažinti duomenų bazės apkrovą 30–50%.

Kaip įjungti: WooCommerce → Settings → Advanced → Features → Enable High Performance Order Storage.

3. Kešavimas – būtinas didelėms parduotuvėms

Kešavimas yra svarbiausias greičio gerinimo įrankis. Bet WooCommerce su daugeliu produktų turi specifinių kešavimo iššūkių.

Pilno puslapio kešavimas (Full-Page Cache)

WooCommerce produktų puslapiai ir kategorijų puslapiai gali būti kešuojami. Tačiau niekada nekešuokite:

• Krepšelio puslapio (/cart/)
• Checkout puslapio (/checkout/)
• Mano paskyros puslapio (/my-account/)
• Prisijungusių vartotojų sesijų

Rekomenduojami įskiepiai:

• WP Rocket – geriausias mokamas variantas, WooCommerce žino automatiškai nekešuoti tinkamų puslapių
• LiteSpeed Cache – nemokamas, puikiai veikia su LiteSpeed serveriais
• W3 Total Cache – lankstus, bet reikalauja detalesnės konfigūracijos

Object Cache su Redis arba Memcached

Tai kitas lygis – WooCommerce daug naudoja WordPress Object Cache. Įdiegus Redis arba Memcached, šie duomenys saugomi RAM, ne duomenų bazėje.

Konfigūracija wp-config.php:

define('WP_CACHE', true);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

Kartu naudokite Redis Object Cache įskiepį. Didelėse parduotuvėse Redis gali sumažinti duomenų bazės užklausų skaičių 60–80%.

4. Produktų katalogas ir filtrų SEO optimizavimas

Didžiausias iššūkis didelėse WooCommerce parduotuvėse – kategorijų ir filtrų puslapiai. Netinkamai sukonfigūruoti, jie gali:

• Sukurti tūkstančius dubliuotų URL (filtrų kombinacijos)
• Lėtinti kategoriją su šimtais produktų
• Sugadinti Crawl Budget

Filtrų URL valdymas

WooCommerce naudoja URL parametrus filtravimui: ?min_price=10&max_price=100&pa_spalva=raudona. Kiekviena kombinacija yra potencialiai naujas URL Google akyse.

Sprendimas: naudokite Yoast SEO arba Rank Math noindexuoti filtravimo URL, arba naudokite rel=canonical nurodantį į kategorijos puslapį.

Produktų per puslapį skaičius

Didelė klaida: rodyti 100 produktų puslapyje. Tai generuoja šimtus HTTP užklausų (nuotraukos), lėtina puslapio krovimą ir didina serverio apkrovą.

Optimali reikšmė: 20–36 produktų per puslapį su tinkamai sukonfigūruotu Lazy Loading nuotraukoms.

5. Paieška didelėje WooCommerce parduotuvėje

Numatytoji WordPress paieška yra katastrofa didelėms parduotuvėms – ji naudoja LIKE SQL užklausas, kurios yra labai lėtos su 10 000+ produktų duomenų baze.

Jei jūsų parduotuvė turi daugiau nei 5 000 produktų, investicija į specialų paieškos sprendimą atsipirks tiek greičiu, tiek konversijų padidėjimu.

6. Nuotraukų optimizavimas dideliam katalogui

10 000 produktų × vidutiniškai 3 nuotraukos = 30 000 nuotraukų. Tai rimta problema, jei jos nėra tinkamai optimizuotos. Apie WebP ir AVIF formatų naudojimą rašėme atskirame straipsnyje.

Lazy Loading

WordPress 5.5+ palaiko native lazy loading (loading="lazy"). Įsitikinkite, kad tema ir WooCommerce jį naudoja visoms produktų nuotraukoms.

CDN dideliam produktų katalogui

CDN (Content Delivery Network) yra būtinas didelei parduotuvei. Populiarūs sprendimai:

• Cloudflare – nemokamas planas veikia daugeliui, Pro planas pagerina dar labiau
• BunnyCDN – pigus, greitas, paprastas
• Cloudfront (AWS) – galingas, bet sudėtingesnis konfigūracijai

7. WP_Query optimizavimas

Jei naudojate custom temos kodą ar įskiepius, kurie kuria WP_Query, sekite šias taisykles:

Visada nurodykite posts_per_page

$args = [
  'post_type'      => 'product',
  'posts_per_page' => 20,
  'no_found_rows'  => true,
  'fields'         => 'ids',
];

8. Hostingas didelei WooCommerce parduotuvei

Tai tema, kurią daug ignoruoja – bet blogai parinktas hostingas gali sunaikinti visas kitas optimizacijas. Apie tai, kaip lėta svetainė naikina Google pozicijas, rašėme atskirame straipsnyje.

Ko reikia didelei WooCommerce parduotuvei:

• ✅ VPS arba Dedicated serveris – shared hosting nepakaks. Bent 4 CPU branduoliai, 8 GB RAM
• ✅ NVMe SSD – duomenų bazės operacijos žymiai greitesnės nei su tradiciniais SSD
• ✅ Redis arba Memcached – object cache yra būtinas
• ✅ MariaDB 10.6+ – geresnė performance nei senesnės MySQL versijos
• ✅ PHP 8.2+ – reikšmingas greičio patobulinimas lyginant su PHP 7.x
• ✅ OPcache – PHP bytecode kešavimas, sumažina PHP apdorojimo laiką

Rekomenduojami hosting sprendimai:

9. Monitoringas ir diagnostika

Optimizavimas be matavimo yra spėliojimas. Naudokite šiuos įrankius:

• Query Monitor – nemokamas WordPress įskiepis, rodantis visas SQL užklausas ir jų trukmę
• New Relic arba Datadog – profesionalūs APM įrankiai su PHP funkcijų laiku ir atminties naudojimu
• Google Search Console – Core Web Vitals ataskaitoje rodomi realių vartotojų duomenys

Kaip sumažinti LCP WordPress svetainėje – išsamiai aprašyta mūsų straipsnyje.

10. WooCommerce įskiepiai, kurie lėtina parduotuvę

Kiekvienas WooCommerce įskiepis potencialiai prideda SQL užklausų, JavaScript ir CSS. Didelėje parduotuvėje tai kaupiasi.

Dažniausiai lėtinantys įskiepiai:

• ❌ Įskiepiai, kurie skenuoja visus produktus aktyvavimo metu
• ❌ Produktų importo įskiepiai, kurie palieka nereikalingus cron hook’us
• ❌ Analitikos įskiepiai, kurie rašo duomenis į DB su kiekvienu puslapio perkrovimu
• ❌ Socialiniai įskiepiai su išoriniais JavaScript failais
• ❌ Live chat įskiepiai be lazy loading

Kaip patikrinti: Query Monitor įskiepis parodo, kuris įskiepis generuoja daugiausiai SQL užklausų. Deaktyvuokite po vieną ir matuokite.

Veiksmų planas: nuo kur pradėti?

Visa tai atrodo daug. Štai prioritizuotas veiksmų planas:

1. ✅ Savaitė 1: Įdiekite Query Monitor, nustatykite pagrindinę problemą (DB, PHP, JS?)
2. ✅ Savaitė 1–2: Įgalinkite HPOS, optimizuokite duomenų bazę, įdiekite Redis
3. ✅ Savaitė 2–3: Konfigūruokite WP Rocket / LiteSpeed Cache su WooCommerce taisyklėmis
4. ✅ Savaitė 3–4: Konvertuokite visas nuotraukas į WebP/AVIF, įgalinkite Lazy Loading
5. ✅ Mėnuo 2: Įdiekite CDN, svarstykite Elasticsearch ar Algolia paieškai
6. ✅ Nuolatos: Monitorinkite Core Web Vitals, reguliariai optimizuokite DB

Dažniausiai užduodami klausimai

Nuo kiek produktų WooCommerce pradeda lėtėti?

Tai priklauso nuo hostingo ir konfigūracijos. Standartiniame shared hostinge problemos gali atsirasti jau nuo 1 000–2 000 produktų. Gerai sukonfigūruotame VPS su Redis ir WP Rocket parduotuvė sklandžiai veikia iki 50 000–100 000 produktų.

Ar HPOS suderinamas su visais WooCommerce įskiepiais?

Ne visais, bet suderinamumas sparčiai auga. Didžioji dalis populiarių įskiepių jau palaiko HPOS. WooCommerce pateikia suderinamumo žymėjimą įskiepių kataloguose. Galite paleisti HPOS compatibility mode, kai duomenys sinchronizuojami tarp senos ir naujos struktūros.

Ar Redis veikia su visais hosting planais?

Redis dažniausiai reikalauja VPS arba Managed WordPress hostingo. Shared hosting retai suteikia Redis prieigą. Cloudways, Kinsta, WP Engine – visi palaiko Redis. Jei negalite naudoti Redis – Memcached yra alternatyva.

Kaip greitai matosi optimizavimo rezultatai?

Techniniai pokyčiai (Redis, kešavimas) matomi iš karto. Google pozicijų pokyčiai po Core Web Vitals gerinimo – paprastai per 4–8 savaites. GSC atnaujina Core Web Vitals duomenis kas 28 dienas.

Ar verta migracija iš WooCommerce į kitą platformą su 10 000+ produktų?

Retai. WooCommerce tinkamai sukonfigūruotas puikiai tvarko ir 100 000+ produktų. Migracija į Shopify ar Magento yra didelis projektas su rimtomis SEO rizikomis (URL pokyčiai, 301 redirectai, turinio praradimas).