A lassú WordPress-oldalt ritkán teszi rendbe egyetlen gyorsító bővítmény. Először derítsd ki, mi fogja vissza: túl nagy képek, videók, bővítmény, szerverválasz vagy a háttérben betöltődő elemek. Ha azt keresed, mit tegyél, mert lassú a WordPress-weboldalad, méréssel kezdd, ne találomra telepített gyorsítókkal.
Érthető, ha elsőre a képekre gyanakszol. Gyakran tényleg ezek lassítanak, de egy jól tömörített galéria sem oldja meg, ha közben a szerver sokáig nem válaszol, vagy egy beágyazott videó újabb kérésekkel terheli az oldalt. A Google PageSpeed Insights megmutatja a mobilos teljesítményt, a TTFB pedig azt jelzi, mennyi idő alatt érkezik meg a szerver első válasza.
A cikkben végigveszem azokat az ellenőrzéseket, amelyeket te is elvégezhetsz: átnézem a képek méretét és formátumát, a videók beágyazását, a tárhely szerepét és a Google sebességmérésének eredményeit. Azt is megmutatom, miért érdemes együtt vizsgálni a szerverválasz, az oldalméret és a hálózati kérések adatait. Így nemcsak azt látod, hogy az oldal lassú, hanem azt is, hol érdemes elkezdeni a javítást.
Ha lassú a WordPress-oldalad, először az okot keresd, ne telepíts újabb gyorsító bővítményt. A képek, a sablon, a tárhely és a bővítmények mind lassíthatják a betöltést. A WordPress-oldal betöltésekor a rendszer összeállítja az oldalt a látogató számára. A gyorsítótár csökkenti ezt a munkát azzal, hogy eltárolja az elkészült oldalváltozatot.
A WP Rocket, a W3 Total Cache és a WP Super Cache gyorsítótárazásra használható bővítmény. Válassz egyet, és ellenőrizd, hogy a tárhelyed vagy más bővítmény nem futtat-e már saját gyorsítótárazást. Két, egymással átfedő cache-bővítmény könnyen összeakad. A látogató ilyenkor akár régi tartalmat, hibás elrendezést vagy üres kosarat is láthat.
A gyorsítótár lejárati idejét igazítsd az oldal tartalmához. Egy ritkán módosuló bemutatkozó oldalon hosszabb tárolás is megfelelő lehet. Webáruháznál viszont ügyelj arra, hogy a kosár és a készletadatok ne maradjanak elavultak. Módosítás után ürítsd a gyorsítótárat, majd kijelentkezett látogatóként ellenőrizd az oldalt.
A bővítmények száma önmagában nem árulja el, mennyire lassú az oldal. Egy rosszul működő bővítmény több erőforrást használhat, mint tíz egyszerű, jól megírt bővítmény. Nézd át a telepített elemeket, és kapcsold ki, amelyekre már nincs szükséged. Ezután teszteld a főoldalt, az űrlapot és a vásárlási folyamatot.
A Marketing Amazing oldalainál is a bővítmények átnézésével kezdtem. Több prémium bővítményt kiváltottam: volt, amelyiket a saját, több oldalra szóló licencemmel, és volt, amelyiket egy egyszerű kódrészlettel. Így az ügyfél pénzt spórolt a bővítménydíjakon. Ezért javaslom, hogy minden bővítménynél kérdezd meg magadtól: valóban kell ehhez egy külön plugin?
Ha lassulást tapasztalsz, próbaként kapcsold ki a gyanús bővítményt, majd mérd meg újra ugyanazt az oldalt. Egyszerre csak egy elemet módosíts, különben nem derül ki, mi okozta a különbséget. A böngésző fejlesztői eszközei vagy a Query Monitor segíthet megtalálni az erőforrásigényes működést. Kikapcsolás után ellenőrizd a menüt, az űrlapokat és a pénztárat is.
A WordPress, a sablon és a bővítmények frissítése csökkentheti az elavult kódból eredő hibák kockázatát. Frissítés előtt készíts biztonsági mentést, majd egyszerre csak egy elemet frissíts. Így hiba esetén könnyebb beazonosítani a változtatást. Sablonváltás helyett előbb nézd meg, van-e benne felesleges funkció vagy betöltődő kód.
CDN-t akkor érdemes fontolóra venned, ha a közönséged több országból érkezik, vagy sok képet és más statikus fájlt töltesz be. Ha a látogatóid főként Magyarországról jönnek, először vizsgáld meg a szerverválaszt és az oldalméretet. A CDN díja a forgalomtól, az adatátviteltől és a választott funkcióktól függ, ezért nincs minden oldalra érvényes összeg.
Biztonsági mentés után frissítsd a WordPresst, a sablont és a bővítményeket, majd ellenőrizd a fő funkciókat. Ezután egyesével kapcsold ki a felesleges vagy gyanús bővítményeket, ürítsd a gyorsítótárat, és mérd meg újra ugyanazt az oldalt. Webáruháznál próbáld végig a kosarat és a pénztárat is.
A gyorsítótárazó és optimalizáló bővítmények elavult oldalt, hibás megjelenést vagy ütközést okozhatnak. Különösen figyelj, ha több bővítmény is módosítja a gyorsítótárat, a CSS-t vagy a JavaScriptet. Webáruházban a túl széles gyorsítótárazás a kosár működését is megzavarhatja. Minden módosítás után teszteld a fontos oldalakat.
Egy 2-3 MB-os kép önmagában is jelentősen lassíthatja az oldalt, főleg mobilhálózaton. Nézd meg a médiatárban a fájlméretet, majd azt is, mekkorában jelenik meg a kép. Egy kávézó fejlécében szereplő fotónak nem kell óriási eredeti méretben betöltődnie, ha a látogató csak kisebb képernyőn látja.
A képpontméretet igazítsd a tényleges megjelenéshez. Egy 4000×3000 pixeles fotó helyett egy 800×600 pixeles változat is elegendő lehet, ha ekkorában jelenik meg az oldalon. A WordPress-kép mérete és fájlmérete külön dolog: az előbbi a képpontokat jelenti, az utóbbi a letöltendő adatmennyiséget. Mindkettőt ellenőrizd.
Ha egy 2000×3000 pixeles képet 500×750 pixeles kártyában mutatsz, a böngésző szükségtelenül nagy fájlt tölthet le. Készíts megfelelő méretű változatot, és töltsd fel azt. Reszponzív képeknél a WordPress több méretet kínálhat a böngészőnek, így az eszköz kijelzőjéhez illő változat tölthető be. A szerkesztőben válaszd ki a kívánt képméretet, ne automatikusan az eredetit.
A tömörítés csökkenti a fájlméretet úgy, hogy a kép használható minőségű marad. Erre a TinyPNG és a ShortPixel is használható. Kézi tömörítéskor olyan beállítást válassz, amelynél a termékfotó vagy portré részletei még tisztán látszanak. WebP vagy AVIF formátummal a hagyományos PNG-nél kisebb fájlméretet érhetsz el. Formátumváltás után nézd meg a képet telefonon és számítógépen.
A képoptimalizáló bővítmény kényelmes, de feltöltés után ellenőrizd az eredményt. Először néhány képet tömöríts, majd vizsgáld meg a színeket, a feliratokat és az élek élességét. Ha a logó vagy a termékfotó elmosódik, módosíts a tömörítésen. A tárhely nem helyettesíti a megfelelő fájlméretet: egy nagy kép letöltése akkor is sokáig tarthat.
A hajtás alatti képeknél használj lusta betöltést. Ez azt jelenti, hogy a böngésző csak akkor kéri le a képet, amikor a látogató közel ér hozzá görgetés közben. A WordPress 5.5 óta alapból lusta betöltést alkalmaz a képeknél. Ellenőrizd azonban a nyitóképet is, mert a legelső képernyőn látható fő fotónak rögtön meg kell jelennie.
Frissítés után ellenőrizd, hogy a képek betöltődnek-e mobilnézetben, a galériában és a termékoldalon. Ha valamelyik kép eltűnik, nézd meg a fájlformátumot és a képoptimalizáló bővítmény beállításait. Az optimalizált kép akkor segít, ha a látogató valóban megfelelő méretben kapja meg, nem csupán egy más néven feltöltött, kisebb fájlt.
A képek optimalizálásakor BMP vagy PNG helyett WebP formátumot is használhatsz. A több megabájtos nyitókép mobilhálózaton különösen lassíthatja a betöltést.
A sebesség azért fontos, mert hatással van a felhasználói élményre, és a Google a betöltési sebességet is rangsorolási szempontként veszi figyelembe. Ez nem jelenti azt, hogy a magas PageSpeed-pontszám önmagában jobb helyezést hoz. A látogató azt érzékeli, hogy rögtön megjelenik-e a kávézó étlapja, vagy percekig üres képernyőt néz.
Jó eredménynek a 2,5 másodperc alatti LCP, a 200 ezredmásodperc alatti INP és a 0,1 alatti CLS számít. Az LCP a fő tartalom megjelenését méri, az INP az oldal reakcióidejét, a CLS pedig a váratlan elmozdulásokat. Ha az LCP 4 másodperc fölött van, javítsd; ha a gomb késve reagál, az INP-t vizsgáld.
A lassú oldal a használatot is megnehezíti. Ha egy pékség nyitvatartása csak hosszas várakozás után jelenik meg, a látogató könnyen továbbáll. Mobilon a gyenge hálózat, a nagy fájlok és a tárhely lassú válasza együtt késleltetheti a betöltést. A jó felhasználói élményt ezért ne egyetlen mérőszámmal azonosítsd.
Méréshez nyisd meg ugyanazt az oldalt a Google PageSpeed Insightsban. Teszteld legalább háromszor, mert a hálózat és a szerverterhelés változhat. Rögzítsd az eredményeket, az oldal címét, valamint azt, hogy mobilos vagy asztali mérést futtattál. Így az előtte és utána kapott értékek összevethetők.
A Lighthouse a Chrome böngésző fejlesztői eszközeiben futtatható. A vizsgálat teljesítményadatokat és javítási javaslatokat mutat, például ha egy fájl késlelteti a megjelenést. A Lighthouse eredményét útmutatásként kezeld, ne üzleti célként. Egy 30 pontos mérés 70 pontra javulva is előrelépés, ha közben az oldal ténylegesen gyorsabban használható.
Mobilon külön tesztelj, ne csak számítógépen nézd meg az oldalt. A PageSpeed Insights mobilos eredménye megmutatja, hogyan teljesít a vizsgált oldal mobilos környezetben. Próbáld ki a főoldalt, egy fontos szolgáltatási oldalt és a kapcsolatfelvételi űrlapot. Figyeld meg, hogy a szöveg, a menü és a gombok késedelem nélkül használhatók-e.
Javítás után mérd meg újra ugyanazt az URL-t, hasonló napszakban és azonos eszközprofillal. Ha egyszerre több dolgot változtatsz, nehéz megállapítani, melyik csökkentette a terhelést. Egyszerre egy dolgot módosíts, majd jegyezd fel az LCP, INP és CLS értékeit. Így az élményt javító változtatásokat követheted, nem csupán egy ingadozó pontszámot.
A WordPress-weboldalnál a stabil működés is a használati élmény része: a tempó mellett azt is érdemes szem előtt tartani, hogy az oldal megbízhatóan használható legyen. A sebesség javítása ettől még nem jelent biztos keresési előnyt, ezért a mérések mellett a látogatói élmény maradjon a mérce. Minél tovább tart a betöltés, annál nagyobb az esély, hogy a látogató kilép. A WordPress sebességét ingyenes Google PageSpeed Insights segítségével is ellenőrizheted, vagy GTmetrixben is tesztelheted. Az eredmények értelmezésénél a stabilitást és az összehasonlíthatóságot is tartsd szem előtt.
A videófájlokat általában ne közvetlenül a WordPress-tárhelyedről szolgáld ki. Egy bemutatkozó film vagy tanfolyami lecke nagy fájl lehet, amelyet a szervernek minden lejátszáskor továbbítania kell. Tárold a videót külső videómegosztón, például a YouTube-on vagy a Vimeo-n, majd ágyazd be az oldalba. Így nem a weboldalad szolgálja ki a videófájlokat.
Az ágyazás azonban nem szünteti meg az összes terhelést. A YouTube-lejátszó további fájlokat és hálózati kéréseket tölthet be még azelőtt, hogy a látogató elindítaná a videót. Egyetlen oktatóvideó esetén ez kezelhető lehet. Ha egy tanfolyami oldalon egyszerre több lejátszó jelenik meg, vizsgáld meg külön, hogyan töltenek be.
Nyisd meg az oldalt inkognitóablakban, és figyeld meg, mikor jelenik meg a lejátszó. Ha az oldal a videó körüli tartalom előtt várakozik, állítsd be, hogy a lejátszó csak kattintásra töltődjön be. Ezt késleltetett betöltésnek nevezik. Előtte telefonon is ellenőrizd, hogy a látogató könnyen el tudja-e indítani a videót.
A külső szkriptek, például a chat, a látogatottságmérés és a hőtérkép, szintén újabb kéréseket indítanak. Nézd át, melyik eszközt használod ténylegesen. Ha egy régi kampány kódjára már nincs szükséged, távolítsd el a weboldalról. A kevesebb fölösleges szkript kisebb terhelést jelenthet, és hamarabb láthatóvá teheti a fontos tartalmat.
A JavaScript olyan kód, amely például a menüt, az űrlapot vagy a felugró ablakot működteti. Ha egy külső fájl betöltése késlelteti az oldal megjelenését, állítsd későbbre vagy aszinkron betöltésre. Aszinkron betöltésnél a böngésző közben más fájlokat is feldolgozhat. Módosítás után próbáld végig a menüt, az űrlapot és a vásárlási folyamatot.
A CSS-fájlok tartalmazzák az oldal megjelenésének szabályait. A tömörítés csökkenti a fájlméretet, az összevonás vagy a késleltetés viszont hibás elrendezést is okozhat. Teszteld a főoldalt, majd egy belső oldalt, például a szolgáltatási oldalt. Ha eltűnik a menü vagy elcsúszik a szöveg, állítsd vissza az utolsó módosítást.
A betűtípusoknál távolítsd el a nem használt családokat és vastagságokat. Ha az oldal több betűcsaládot, vastagságot és dőlt változatot tölt le, a böngészőnek több fájlt kell feldolgoznia. Egy kávézó étlapján például elég lehet külön betűtípust használni a címsorokhoz és a törzsszöveghez. Betöltés után ellenőrizd, hogy nem változott-e meg a szöveg elrendezése.
Weboldalad gyorsításakor egyszerre csak egy külső elemet módosíts. Először jegyezd fel, hogyan tölt be az oldal, majd kapcsold ki a gyanús szkriptet vagy késleltesd a videólejátszót. Ezután frissítsd az oldalt, és ellenőrizd, hogy működik-e a lejátszás, a mérőkód és a kapcsolatfelvételi űrlap. Így kiderül, melyik változtatás javította a sebességet, és melyik okozott új problémát.
A PageSpeed-pontszám jelezheti, hogy van-e gond, de önmagában nem árulja el, hol keresd. A TTFB azt méri, mennyi idő telik el az oldal kérése és a szerver első válasza között. Ha ez az érték magas, a képek tömörítése önmagában nem szünteti meg a várakozást. Először azt kell kiderítened, hogy a szerver, az adatbázis vagy egy háttérben futó művelet késleltet-e.
A PageSpeed Insights segítségével vizsgáld meg az oldalad mobilos és asztali eredményét. A TTFB mellett nézd meg, mely erőforrások töltődnek be lassan. A „waterfall” nézet időrendben mutatja a kéréseket, például a szerverválaszt, a képeket, a JavaScript-fájlokat és a külső szolgáltatásokat. Így nem csak egy pontszámot látsz, hanem a betöltés menetét is.
Ugyanazt az URL-t legalább háromszor mérd meg, mert az eredményt befolyásolhatja az aktuális hálózat vagy szerverterhelés. Jegyezd fel, hogy mobilos vagy asztali profilt használtál, és mikor készült a mérés. Javítás után hasonló napszakban, ugyanazzal a profillal mérj újra. Így összehasonlíthatod a javítás előtti és utáni adatokat.
Az oldalméret azt mutatja meg, mennyi adatot kell letöltenie a böngészőnek. Egy termékoldal képei, betűkészletei és videólejátszója együtt jelentős méretet érhetnek el. Nyisd meg a böngésző fejlesztői eszközeinek Hálózat lapját, és rendezd a fájlokat méret szerint. Először a legnagyobb elemeket ellenőrizd, például a képeket, a stíluslapokat és a JavaScript-fájlokat.
HTTP-kérés minden olyan alkalommal történik, amikor a böngésző adatot kér a szervertől vagy egy külső szolgáltatástól. Egy analitikai eszköz, chatablak vagy beágyazott videó további kéréseket indíthat. A waterfall nézetben keresd az ismétlődő, elhúzódó vagy hibával végződő kéréseket. Ha egy külső eszköz nem szükséges az oldal működéséhez, próbaként kapcsold ki, majd mérj újra.
Ha a TTFB lassú, de az oldalméret mérsékelt, vizsgáld meg a szerverválaszt, az adatbázis-lekérdezéseket és a WordPress háttérfolyamatait. Ha a szerver gyorsan válaszol, de a teljes betöltés elhúzódik, keresd a nagy fájlokat és a sok hálózati kérést. A böngésző Hálózat lapján láthatod, melyik fájl késlelteti a többit. Ez segít célzottan javítani a hibát ahelyett, hogy találomra próbálkoznál.
WordPress-frissítés után is mérd meg ugyanazt az oldalt, különösen, ha a sablon vagy egy bővítmény frissült. Ha romlott az eredmény, ellenőrizd a waterfall nézetet, és keresd az újonnan megjelent fájlokat. Ne törölj képeket vagy kódot pusztán a méretük miatt. Előbb nézd meg, használja-e őket az oldal, majd ellenőrizd, hogy a módosítás után működik-e a menü, az űrlap vagy a vásárlás.
Akkor javaslom az új weboldal tervezését és kivitelezését, amikor a mérések alapján már nem elég egy-egy képet vagy bővítményt optimalizálni. A lassulás hátterében a sablon, az oldal felépítése vagy több egymásra épülő technikai probléma is állhat. Ilyenkor érdemes előbb feltárni az okokat, nem pedig újabb gyorsítókat telepíteni.
A weboldal-audit segíthet feltárni, mely részek lassítják az oldaladat, és hol érdemes beavatkozni. Ha az alapok már nem szolgálják a vállalkozásod céljait, a következő lépés lehet az újratervezés és a kivitelezés. A mérések eredményei alapján válaszd ki, milyen megoldás illik az oldalad jelenlegi állapotához.
Ha elakadtál a WordPress-oldalad gyorsításával, beszéld át velem egy díjmentes konzultáción.
A sebességet akkor is tartsd szem előtt, amikor új funkciókról döntesz. Egy chatablak, tagsági felület vagy kampányeszköz hasznosnak tűnhet, de kérdezd meg magadtól: valóban segíti a látogatót, vagy csak újabb terhet rak az oldalra?
A fontos oldalakat az üzleti szerepük szerint kezeld. Egy kapcsolatfelvételi oldalon az egyszerű űrlap és a jól látható elérhetőség többet érhet, mint egy látványos, de nehézkes megoldás. Webáruháznál a gördülékeny vásárlás legyen a döntési szempont, ne az, hogy minden új ötlet felkerüljön a kezdőlapra.
Amikor legközelebb bővíted a weboldalad, már a tervezéskor gondolj a sebességre. Így nem utólag kell kiderítened, melyik új funkció nehezítette meg a használatot. A jó weboldal nem attól hasznos, hogy mindent tud, hanem attól, hogy a látogatód könnyen eljut rajta a céljáig.
A WordPress-oldalt bővítmény, sablon, adatbázis-művelet vagy külső szolgáltatás is lassíthatja. Nem feltétlenül a bővítmények nagy száma a gond, lehet, hogy egyetlen elem működik rosszul, például egy API-várakozás vagy hibás adatbázis-lekérdezés. Ha belépés után csak az adminfelület lassú, vizsgáld meg a háttérfolyamatokat és a naplóbejegyzéseket is. Így elkülönítheted a látogatói oldal és a kezelőfelület problémáit.
Válassz az oldalad különböző feladataihoz illő tesztoldalakat: például főoldalt, termékoldalt és pénztárat. A Google PageSpeed Insightsban kapott jelentést mentsd el, és jegyezd fel, melyik oldalt vizsgáltad. Tagsági rendszer esetén külön próbáld ki a belépés előtti és utáni állapotot, mert eltérő tartalom töltődhet be. A változtatások után ugyanazokat a feladatokat ismételd meg.
Figyeld meg, mikor és hol jelentkezik a késés. Ha például sokáig vársz a „Mentés” gombra kattintás után az adminfelületen, nézd meg, fut-e ismétlődő háttérkérés az admin-ajax.php fájlhoz. Ha csak egy külső naptár vagy fizetési megoldás használatakor akad meg az oldal, teszteld külön az érintett folyamatot. A szervernapló hibái segíthetnek behatárolni az okot.
A sebesség része a Google által figyelembe vett felhasználói élménynek, de nem az egyetlen rangsorolási szempont. A Search Console Core Web Vitals-jelentése valós használati adatok alapján mutatja az oldalak teljesítményét, míg egy helyi mérés egy adott teszt eredménye. Ha a látogatók számára fontos oldalak problémásak, először azokat javítsd. Ne ronts az űrlap vagy a vásárlás működésén egy jobb pontszám kedvéért.
Akkor mérlegeld a tárhelyváltást, ha a lassulás több egyszerű oldalon is megmarad, és a szerverválasz következetesen késik. Nézd meg, elegendő-e a memória, megfelelő-e a PHP-verzió, és gyorsan működik-e az adatbázis. Ha csak egy oldal vagy funkció lassú, előbb annak kódját és bővítményeit vizsgáld meg. Tárhelyváltás akkor indokolt, ha a jelenlegi környezet korlátozza a weboldal működését.
Ha lassú a WordPress-weboldalad, és nem tudod, mit tegyél, kérj weboldal-auditot, ha a hiba több fontos funkciót érint, vagy nem tudod biztonságosan tesztelni a változtatásokat. Ez különösen fontos webáruháznál, ahol a fizetés, a készlet és a kosár dinamikusan változik. Ha a sablon vagy az oldalépítő felépítése okozza a gondot, célzott javítás, részleges újraépítés vagy új weboldal is szóba jöhet.
Nem érdemes 100 pontot célként kitűzni, mert az eredményt az oldal tartalma és a mérés körülményei is befolyásolják. Egy látogatói gépen futó külső betűtípus vagy mérőkód például akkor is szerepelhet a jelentésben, ha üzletileg hasznos. A pontszám helyett azt nézd, hogy a fontos oldalak könnyen használhatók-e, és a valós látogatói adatok javulnak-e. A tökéletes mérési eredmény nem helyettesíti a működő weboldalt.
Vezess rövid változtatási naplót: írd fel, mit módosítottál, melyik oldalon és mikor ellenőrizted. Így könnyebb visszakeresni az okot, ha egy frissítés után ismét romlik a működés. A mérési adatok mellett próbáld végig a vállalkozásod fontos folyamatait is, például az ajánlatkérést, a belépést vagy a rendelést. Ha ezek gyorsabban és hiba nélkül működnek, a javulásnak üzleti szempontból is van jelentősége.
„Olyan érzés volt, hogy nem egyedül dolgozom az oldalamon, hanem ketten együtt, két tulajdonos gondolkodik...
...abban, hogyan lehetne ezt az üzletet a legjobban beindítani, hogyan lehet ezt az oldalt a legjobban összerakni."
„Az ügyfeleink a legfontosabbak számunkra. Ezért dolgozunk a legjobbakkal...
...és ezért bízzuk a weboldalaikat Rád.'
'Webfejlesztő sok van, Rudiból csak egy.
Szerencsések vagyunk, hogy a vele való munka során olyan szakemberre bízhatjuk magunkat és az ügyfeleinket, aki ugyanúgy a tökéletes végeredményre törekszik, mint mi."
"Rudi az, akit vállalkozóként webes "kollégának" álmodtam magamnak.
Megvalósítja azt, amiről még nem is tudom, hogy szükségem lesz rá. Mindig ott van, amikor szükségem van rá. Az első pillanattól kezdve érzem, hogy egy csapat vagyunk. Imádom!"
