Lassú a WordPress weboldalad?



Sok-sok bejegyzés születik a témában, mindenki a webes elemző programok és azok magyarázatáról értekezik. Hogyan lehet 1KB-ot spórolni a png képen, és hogyan lehet telpíteni az egyik gyorsítótár bővítményt. Ebben a bejegyzésben szerver oldalról közelítjük meg a dolgot, ahogy egy tárhely szolgáltató látja.

 

Lassan megjelenő weboldal több tényező miatt lehet lassú
1. Szerver oldali generálási idő
2. Kliens oldali (böngésző) megjelenítési idő

Általában mindenki a másodikról ír, a mérőprogramok nagy része is csak 1-1 pontban foglalkozik az első ponttal, pedig nagyon fontos eleme a weboldalnak a szerver oldal válaszidő, vagy generálási idő.

 

Mi a válaszidő?
Válaszidő alatt általában azt értjük, amennyi idő alatt valamilyen választ ad a szerver

 

Mit jelent a szerver oldali generálási idő?
Ez a teljes weboldal generálási ideje, amennyi idő amíg pl. a WordPress a főoldal HTML forrását legenerálja a látogatónak, és visszaadja.

WordPress sebesség szempontjából a szerver oldali generálási időt kell nézni, mert a válaszidővel trükközhet a szolgáltató.

 

Hogyan lehet trükközni?
Pl. a PHP-nál van egy olyan paraméter, hogy output_buffering, ami azt csinálja, hogy ha ki van kapcsolva akkor képes darabokban küldeni a HTML tartalmat.

 

Miért jó ha trükközik a szolgáltató?
Az egyes mérőprogramokban „gyorsabbnak” látszódhat, mert TTFB -t mérnek, vagy Time To First Byte -ot mérnek, így az első pár bájt, pl. egy header információ, vagy bármilyen egyéb adat amit a böngészőnek küldenek.

WordPress esetén ha az Output Buffering be van kapcsolva, akkor az egyes header duplikációk nem okoznak hibát, míg kikapcsolt állapotban előfordulhat esetleg hasonló figyelemeztetés:
„Warning: Cannot modify header information - headers already sent by (output started at”


Mi, a szolgáltatók által kínosnak tartott szerver oldali generálási időt fogjuk boncolgatni, hogy mit hogyan lehet nézni, mi miért van.

Böngészőben megjeleníthető szerver oldali valós sebesség


Szerver oldalra várakozás
Request sent – kérés küldése a szervernek
Waiting (TTFB) – várakozás a szerverre, amíg a tartalmat legenerálja
Content Download – tartalom letöltésének ideje

Request sent és Content Download első sorban a kliens oldali infrastruktúrán múlik, vagyis a kliens eszköz teljesítményétől, és a hálózati kapcsolatától. Ritkábban a webtárhely szolgáltatón is, hogy hol van a szervere, milyen hálózati kapcsolatai vannak.

A Waiting a szerver oldali teljesítménytől, rendelkezésre álló erőforrásoktól függ.

 

Szerver teljesítménye
WordPress esetén a szerver oldali sebesség a CPU-tól, SSD/HDD-ktől, terheltségtől függ. Ha a szolgáltató nagyon sok weboldalt enged elhelyezni egy szerverre, akkor annak aránylag normális működéséhez korlátozásokat kell bevezetnie. Ilyen korlátozás lehet: inode, IOPS, IO, CPU, RAM, hálózat, stb.

inode: fáj és könyvtár darabszám
IOPS: másodpercenkénti fájl műveletek száma, amibe beletartozik a PHP fájlok megnyitása, statikus fájlok (css, js, png, jpg, stb.) kiszolgálása
IO: másodpercenként mennyi adatot kezelhet a disk, általában MB/s
CPU: a cPanel, vagy egyéb hasonló tárhelykezelők az adott hozzáférésre tartalmaznak egy CPU korlátot, ami lehet 1 mag, 2 mag, stb. Ezek természetesen nem dedikált processzor magok, hanem jelentős mértékben túlértékesített, vagyis ha a szerveren a sok elhelyezett Ügyfél leterheli, akkor az kihatással van a saját oldaladra is. Hozzá kell tenni, hogy marketingben pl. 4 magos szerver esetén úgynevezett Hyper-Threading -es Intel CPU-knál pl. 8 szálat, vagy még jobban megtévesztő módon 8 magot szoktak írni. Ez azért rossz elgondolás, mert a második feldolgozó szál az adott CPU magnál csak akkor tud doglozni, ha a főszál épp várakozik valamire. Ha az nem várakozik, akkor nem tud dolgozni, várakozik.
RAM: A maximium memória korlátozásával az egyidejű kiszolgálható lekérések számát korlátozzák, a fájl cache-nek használható memróia minimálisra csökken emiatt.
Hálózat: A hálózat korlátozásával az egyidejű kapcsoaltok számát, valamint az elérhető maximális sávszélességet illetve az adatforgalmi keretet tartalmazhatja. Szerencsére ezt ritkábban használják a szolgáltatók.

Egy alap WP installálásnál 7db statikus tartalom kerül kiszolgálásra, vagyis leegyszerűsítve 7 műveletet jelent és 270KB-os hálózati forgalmat gzip tömörítéssel. Mivel nincs képi tartalom az alap WP-n, így a 270KB egy jól tömörített tartalom.

Ahhoz, hogy megkapjuk a HTML tartalom generálásához szükséges fájlműveleteket, és egyéb értékes információhoz jussunk, bekapcsoltuk szerver oldalon a debug módot. Fontos tudni, hogy ilyen esetben a PHP kód, így a WP is jelentősen lassabban fut, vagyis arányait kell nézni mindig a futási időnek.

 

 

Alap WP install-ban pár szerver oldali adat
PHP hívások száma: 48279db
Szerver oldali generálási idő: 0.2851s (debug módban, élesben ez 0.04s körül van)
Felhasznált memória: 3 104 040B, vagyis 3MB
Megnyitott PHP fájlok száma: 248db
Megnyitott PHP fájlok mérete összesen: 5753301B, vagyis 5.7MB

A szerver oldali kiszolgálást lehet javítani, ha Opcache van használva, ekkor nem teljesen 1-1 -ben kell számolni.

Ha csak a 3MB/s IO limit van beállítva egy cPanel-es szolgáltatáson, akkor ez azt jelenti, hogy kb. 1.5s -el növelheti a szerver oldali generálási időt, és a teljes oldalkiszolgálást 2s -el növelheti, feltételezve hogy egyszerre csak egy oldallekérés történik.
Ha IOPS és CPU korlát is van a szolgáltatáson, akkor az további lassítást jelenthet, de főleg akkor, ha több lekérés érkezik a weboldalhoz.
Korlátozásokkal teli tárhelynél ezt a terhelést úgy lehet csökkenteni WP esetén, hogy statikus cache-t generáltatunk a szerverrel, és ha beérkezik a kérés, és rendelkezik már korábban generált de még érvényes kész HTML-el, akkor azt tölti be, így spórol a fenti alapoldalból kb. 247 fájlmegnyitást, 3MB memóriát, és 5.6MB-nyi olvasást a tárhelyről.
Vannak olyan oldalak amiket nem lehet ilyen módon gyorsító tárazni, ilyen pl. az admin felülete, a kosár, és a pénztár oldalak. Vagyis ahol nem szabad ugyanazt a tartalmat mutatni mindenkinek.
A statikus gyorsítótár generálása plusz erőforrást igényel, de gyengébb tárhelyeknél jó megoldás a WordPress gyorsítására. Arra kell ügyfelni az ilyen beállításoknál, hogyha lehet, akkor soha le nem járó cache-t kell használni, és csak akkor dobja el, ha az adott rész tartalma módosul. Ilyen fajta cache-t bemutatkozó oldalaknál a legegyszerűbb megcsinálni. Ezeknek a gyorsítótára moduloknak a bemutatása külön téma, és érdemes sokat foglalkozni velük, mert nem mindegy melyiket mikor és mire használjuk. Eltérés van a működésükben, funkcionalitásukban, és használhatóságukban. Vannak olyan modulok, amik feltérképezik az oldalt, és előre legeneráltatják az összes aloldalnak a HTML-jét, de ezzel az a gond, hogy a szerver saját magát hívva oldalszámtól függően akár végtelen hívást is tartalmazhat, így nagyon sok erőforrást is igényelhet. Ha pl. másodpercenként 2-3 oldallekérést indít, akkor az a fenti példában bemutatott korlátos tárhelynél jelentős problémát okozhat.
Vannak olyan gyorsítótárak, amik statikus tartalom visszaadására is PHP-t használnak, vannak amik pl. .htaccess -ből vezérlik azt, és így szinte nulla erőforrás használattal a PHP -t kihagyva tudja kiszolgálni az oldallekérést.

 

 

Egy normál működő WordPress webáruháznak a főoldalánál a példában feltüntetett értékek
PHP hívások száma: 3238824db
Szerver oldali generálási idő: 14.4s (debug módban, élesben ez 0.7s körül van)
Felhasznált memória: 48 034 016B, vagyis 48MB
Megnyitott PHP fájlok száma: 2039db
Megnyitott PHP fájlok mérete összesen: 23762296B, vagyis 23.7MB

WordPress szerver oldali elemzést 

 

Szerveren futtatott elemzés a bővítmények futási idejéről

breeze: 0.2128 s
ac-addon-woocommerce: 0.0002 s
admin-columns-pro: 0.0002 s
atum-stock-manager-for-woocommerce: 0.1636 s
barion-woocommerce-status: 0.0004 s
cf7-conditional-fields: 0.0044 s
classic-editor: 0.0018 s
code-snippets: 0.0175 s
contact-form-7-dynamic-text-extension: 0.0006 s
contact-form-7: 0.0323 s
contactsheets-refund-request: 0.0062 s
criteoonetag: 0.0034 s
custom-fixed-quantity: 0.0212 s
customwoosheets: 0.0009 s
duplicate-page: 0.0011 s
english-wp-admin: 0.5008 s
finale-woocommerce-deal-pages: 0.0605 s
finale-woocommerce-sales-countdown-timer-discount-plugin: 2.2861 s
import-tracking: 0.0024 s
js_composer: 0.0688 s
kadence-woocommerce-email-designer: 0.0096 s
kirki: 0.6252 s
loco-translate: 0.8123 s
pay-via-barion-for-woocommerce: 0.0124 s
payment-gateway-via-paylike-for-woocommerce: 0.005 s
pixelyoursite-pro: 0.1056 s
pixelyoursite-super-pack: 0.0064 s
reamaze: 0.0101 s
simple-css: 0.0005 s
tracking-code-manager: 0.0862 s
unero-vc-addons: 0.0377 s
utm-leads-tracker-lite: 0.0034 s
variation-swatches-for-woocommerce: 0.0022 s
vp-woo-product-user-guide: 0.0042 s
wc-pont: 0.0025 s
wonderpush-web-push-notifications: 0.0206 s
woo-billingo-plus: 0.0054 s
woo-checkout-field-editor-pro: 0.0024 s
woo-mailerlite: 0.012 s
woo-order-export-lite: 0.0005 s
woo-phone-input-plugin: 0.0033 s
woo-photo-reviews: 0.021 s
woo-product-feed-pro: 0.0156 s
woocomerce-sendpulse2-extended: 0.2088 s
woocommerce-dynamic-pricing: 0.139 s
woocommerce-fixed-quantity: 0.0639 s
woocommerce-gateway-paypal-express-checkout: 0.0331 s
woocommerce-max-quantity: 0.0046 s
woocommerce-notification: 0.0175 s
woocommerce-order-status-manager: 0.0256 s
woocommerce-pdf-invoices-packing-slips: 0.0281 s
woocommerce: 7.817 s
woofunnels-aero-checkout-order-forms: 0.0009 s
woofunnels-aero-checkout: 0.2699 s
woofunnels-order-bump: 0.0237 s
woofunnels-upstroke-dynamic-shipping: 0.0014 s
woofunnels-upstroke-multiple-products: 0.0023 s
woofunnels-upstroke-one-click-upsell: 0.2115 s
woofunnels-upstroke-subscriptions: 0.0066 s
woosheets: 0.0022 s
woosms-sms-module-for-woocommerce: 0.0115 s
wp-all-export-pro: 0.228 s
wp-carousel-pro: 0.0551 s
wp-cron-status-checker: 0.032 s
wp-file-manager: 0.006 s
wp-mail-smtp: 0.021 s
xl-woocommerce-sales-triggers: 0.0477 s

 

Ha ez egy erősen korlátozott tárhelyen van, akkor Opcache mellett is jelentős lassulást jelent a működése. Az erőforrás korlátok, és az általános célú szerverek okozzák a lassú WordPress működést.

Webáruházak esetén sokan tapasztalják azt, hogy a weboldal gyorsan betöltődik, de az admin felület illetve a kosár és pénztár rész már sokkal lassabb. Ez a jelenség is a korlátozott erőforrásokra, és a nem megfelelő szerverekre vezethető vissza.

A korlátozások általában 30%-ot, a túlterhelt szerverek 20-30%-ot jelentenek a weboldal szerver oldali generálási idejében.

 

Mikor kell gyanakodni, hogy a tárhely a lassú

  • Ha szerinted lehetne gyorsabb is a webáruházad, weboldalad
  • A szolgáltató nem tudja megmondani, hogy miért lassú a weboldal
  • A WordPress admin felület lassan válaszol
  • A kosár és a pénztár oldalak lassúak
  • Kosárba helyezésre sokat kell várni
  • Resource limit reached hibaüzenet jelenik meg
  • A szolgáltató a sok látogatót DDoS-nak mondja

 

Próbálja ki díjmentesen a gyors WordPress webtárhelyet!

 

Ha szeretné megtudni, hogy a WordPress weboldalának melyik eleme a lassú, vagy ki szeretne próbálni egy gyors WordPress-nek megfelelő tárhelyet, akkor keressen minket az info@elin.hu email címen.

 

A gyors webtárhelyről a Webtárhely -> ASA webtárhely menüpontban találhat több információt.

 

Ha már kinőtte az osztott tárhelyet, vagy már saját szervert bérel, akkor ajánljuk figyelmébe Webtárhely -> VIP webtárhely szolgáltatásunkat.

HÍVJON MINKET : +36 70 297 4811