Mérje a front-endet és a szervert is reprezentatív oldalakon, távolítsa el a felesleges pluginokat és szkripteket, optimalizálja a képeket, az adatbázis-lekérdezéseket és az objektum-gyorsítótárat. A nyilvános oldalakat gyorsítótárazza, de a kosarat, a fiókot és a pénztárt megfelelően zárja ki. A változtatásokat valós katalógussal és párhuzamos rendelésekkel tesztelje.
A WooCommerce gyorsítása megköveteli a nyilvános katalógus és a személyre szabott részek megkülönböztetését. A kategóriák és a termékek gyakran gyorsítótárazhatók, a kosár, a fiók és a pénztár azonban egy konkrét vásárlóval és a munkamenet állapotával dolgozik. Egy agresszív szabály megjelenítheti más vásárló kosarát, régi árat vagy elavult készletinformációt. Ezzel szemben a gyorsítótár teljes kikapcsolása miatt a szerver újra és újra ugyanazt a tartalmat állítja össze, és csúcsidőben feleslegesen fogyasztja a kapacitást.
Az optimalizálás a valós sablonok és üzleti forgatókönyvek mérésével kezdődik. A kezdőlap nem elegendő minta; össze kell hasonlítani a kategóriaoldalt, a változatokkal rendelkező terméket, a keresést, a kosarat, a pénztárt és az adminisztrációt. Ezután a legnagyobb szűk keresztmetszetet kell kezelni, nem pluginok véletlenszerű sorozatát. Minden változtatáshoz működő regressziós teszt és visszaállítási mód szükséges.
Készítse el a webáruház teljesítményprofilját
Mérjen laboratóriumi és éles üzemi adatokat is. A böngészőben futó eszköz megmutatja a hálózati erőforrásokat, a fő szálat és a vizuális stabilitást, a szerveroldali profilozás pedig feltárja a lassú lekérdezéseket, a külső hívásokat és a PHP-függvényeket. Használjon inkognitó ablakot és több futtatást, mert az első és az ismételt látogatás eltérő gyorsítótárat használ. Rögzítse a katalógus méretét, a kiválasztott változatot, a bejelentkezési állapotot és az eszközt, hogy az eredmény reprodukálható legyen.
Határozzon meg költségkereteket a jellemző sablonokhoz, és kövesse a trendet a kiadások után. Egyetlen összesített pontszám elfedhet egy kritikus problémát, ezért olvassa a konkrét metrikákat, a szerver válaszidejét és a kérések vízesésdiagramját. Éles környezetben használjon aggregált valós felhasználói adatokat, megfelelő adatvédelemmel. A teljesítményt kapcsolja össze a hibákkal és a rendelkezésre állással; egy rendkívül gyors oldal működő fizetés nélkül értéktelen.
Állítsa be a tárhelyet, a cache-t és a dinamikus kivételeket
A szervernek támogatott runtime-verzióval, elegendő memóriával, optimalizált adatbázissal és a csúcsterheléshez mért erőforrásokkal kell rendelkeznie. A page cache csökkenti a nyilvános URL-ek kiszolgálásával járó munkát, az objektum-gyorsítótár mérsékelheti az ismétlődő adatbázis-műveleteket, a CDN pedig a látogatóhoz közelebbről szolgálja ki a statikus fájlokat. Minden rétegnek egyértelmű érvénytelenítési szabályokra van szüksége az ár, a termék vagy a tartalom változásakor. Az elavult állapotban maradó gyorsítótár üzleti problémát okoz, nem csupán technikai pontatlanságot.
Zárja ki a kosarat, a pénztárt, a fiókot, a fizetési callbackeket és a további személyre szabott endpointokat az alkalmazott megoldás dokumentációja szerint. A cache-kulcsnak figyelembe kell vennie a pénznemet, a nyelvet vagy a releváns szegmenst, különben a tartalmak összekeverednek. A WooCommerce cookie-kat üres és teli kosárral is tesztelje. A beállítás után végezzen el egy vásárlást inkognitóablakban, módosítsa a mennyiséget, és ellenőrizze az aktuális árat és készletet is. Soha ne másolja át a kivételek listáját a konkrét bővítmények ellenőrzése nélkül.
- Oldalgyorsítótár a biztonságosan nyilvános tartalomhoz
- Objektum-gyorsítótár az ismétlődő számításokhoz
- Dinamikus URL-ek és callbackek a nyilvános gyorsítótáron kívül
- Megbízható invalidálás a katalógus módosítása után
Optimalizálja a képeket, a betűtípusokat és a JavaScriptet
A termékfotókat a megjelenítésnek megfelelő méretekben generálja, és használjon modern formátumokat észszerű tömörítéssel. Biztosítson a böngésző számára reszponzív változatokat és méreteket, hogy előre lefoglalhassa a helyet. A fő termékképet ne töltse be késleltetve, ha az a legnagyobb látható elem jelöltje; az első nézeten kívüli galéria fokozatosan is betölthető. A nagyítást és a videót csak akkor aktiválja, ha valódi értéket adnak.
Korlátozza a betűcsaládok és betűváltozatok számát, a kritikus fájlokat célszerűen töltse be, és használjon észszerű tartalék tipográfiát. A marketingcímkék, csevegőablakok, hőtérképek és ajánló widgetek gyakran terhelik a fő szálat. Minden szkriptnek legyen felelőse és mérhető célja. Ha a funkció lehetővé teszi, a betöltést halassza el a hozzájárulásig vagy az interakció pillanatáig. Egy nem használt eszköz eltávolítása általában megbízhatóbb, mint egy újabb minifikálási réteg.
Javítsa az adatbázist, a lekérdezéseket és a katalógust
A lassú kategóriákat okozhatják összetett szűrők, sok változat, árújraszámítások vagy egy olyan bővítmény, amely minden termékhez külön lekérdezést futtat. Profilozza a konkrét kérést, és a kiváltó okot javítsa. A megfelelő indexek, a hatékony adat-API-k és az előre kiszámított értékek segíthetnek, de az adatbázisba történő beavatkozás fejlesztő feladata, mentéssel és teszteléssel. A táblák gépies tisztítása az adatok gazdájának ismerete nélkül károsíthatja a rendeléseket vagy az integrációkat.
A technikai naplókat és az ideiglenes adatokat az üzemeltetési igények szerint archiválja vagy korlátozza, ne vakon a rendelési előzményeket. Az ütemezett feladatokat helyezze át megbízható rendszerszintű cronra, ha a látogatások általi indítás nem elegendő, és figyelje a sor növekedését. Nagyobb katalógus esetén a keresés és a szűrők speciális indexet igényelhetnek, de előbb rendezze az attribútumokat és a duplikációkat. A rossz minőségű bemeneti adatokat nem lehet pusztán erősebb szerverrel megoldani.
- Profilozás az adatbázis módosítása előtt
- A naplók és ütemezett feladatok ellenőrzött növekedése
- Hatékony szűrők tiszta attribútumokra építve
- Biztonsági mentés és regressziós teszt minden beavatkozás után
Óvja a teljesítményt minden további módosításnál
Új plugin vagy marketingcímke telepítése előtt hasonlítsa össze a teljesítményt és a funkciókat staging környezetben. Készítsen automatikus vagy megismételhető teszteket a kategóriaoldalra, a termékoldalra, a kosárra és a pénztárra. Figyelje az adminisztrációt, az importokat és a sorfeldolgozást is, mert az ügyfeleknek szóló weboldal lehet gyors, miközben a raktár minden rendelésmódosításra vár. A változtatásokat csúcsidőn kívül vezesse be, előkészített visszaállítási lehetőséggel.
A kapacitástesztet arányosan és biztonságosan szimulálja tesztkörnyezetben vagy a tárhelyszolgáltatóval egyeztetve. Az olvasások, keresések és írások valósághű keverékére összpontosítson, ne csak több ezer kérésre egyetlen gyorsítótárazott URL-re. Az indítás után figyelje a válaszidőt, a hibákat, az erőforrások kimerülését és a legfontosabb webes mutatókat. Ha a trend romlik, a nagy kampány előtt kezelje, ne közben.
Gyakori kérdések
Segít a gyorsítótárazó bővítmény felgyorsítani a WooCommerce-t?
Jelentősen segítheti a nyilvános oldalakat, ha kompatibilis a tárhellyel, és helyesen kizárja a dinamikus részeket. Nem oldja meg a lassú lekérdezést, a túl sok szkriptet vagy a gyenge minőségű bővítményt. A beállítást mindig ellenőrizze egy tesztvásárlással.
Miért lassú a WooCommerce adminfelülete?
Az ok lehet adatbázis-lekérdezés, nagy méretű napló, külső API, ütemezett feladat, a rendelések száma vagy minden képernyőn betöltődő bővítmény. Egy konkrét lassú művelet profilozása pontosabban megmutatja a forrást, mint az általános takarítás.
Jobb az erősebb tárhely vagy az optimalizálás?
Gyakran mindkettőre szükség van, megfelelő arányban. A megfelelő infrastruktúra az alap, de a felesleges kód több erőforrást is felemészt. Először mérje fel a szűk keresztmetszetet, majd döntse el, hogy az alkalmazás, a cache, az adatbázis vagy a kapacitás módosítása hatékonyabb-e.