A weboldal gyorsítását méréssel kezdd: külön vizsgáld a szerver válaszát, a fő tartalom megjelenését és az oldal használhatóságát. WordPressnél a gyorsítótárazás, a képek megfelelő mérete és a szükségtelen kód csökkentése is segíthet. A WP Rocket ezekhez ad eszközöket, de a beállításokat az adott webhelyen kell tesztelni. A magas pontszám önmagában nem bizonyít hibamentes működést vagy több bevételt.
Itt a korábbi videós változat. A felület és több beállítás azóta változott, ezért a frissített szöveget és a telepített verzióhoz tartozó gyártói útmutatót kövesd.
Mérési eszközök:
Kezdéshez két eszközt mutatok: a GTmetrixet és a PageSpeed Insightsot. Mindkettő adhat hasznos diagnózist, de a laboreredményt külön kell kezelni a tényleges látogatók adataitól.
GTmetrix
A GTmetrixben a helyszín, az eszköz és a kapcsolat beállítása befolyásolja az eredményt. Olyan körülményeket válassz, amelyek a saját közönségedhez illenek, és összehasonlításkor tartsd őket azonosan.
A GTmetrix Basic útmutatója jelenleg londoni és seattle-i tesztelést is leír. A választható helyszíneket a saját csomagodban ellenőrizd; London európai összehasonlításra használható, de nem azonos egy magyar mobilhálózatról érkező látogató mérésével.
Így indítsd el a sebesség tesztet:
- Írd be a weboldalad URL-jét az „Enter URL to Analyze” mezőbe,
- bejelentkezett állapotban kattints az „Analysis Options” gombra,
- a „Test URL in” legördülőben válaszd ki a kívánt várost,
- és kattints az „Analyze” gombra.
A mérési keret és az ingyenes hozzáférés feltételei változhatnak. Ezeket az aktuális fiókleírásban ellenőrizd; a korábbi heti 50 vagy 5 mérés és a korlátlan kijelentkezett tesztelés nem tekinthető mai feltételnek.
A futási idő a teszttől és a szolgáltatás terhelésétől is függ. Várd meg a teljes jelentést, mielőtt következtetsz.
Amikor ez megtörtént különféle értékeket láthatsz az oldal tetején.
A GTmetrix osztályzata és pontszámai összesített jelzések. Az A–F besorolás önmagában nem mondja meg, melyik feladatot kell javítanod, vagy mennyi időt vár minden látogató.
A Performance és Structure értéket a jelentés diagnózisaival együtt nézd. A laborpontszám és a szerkezeti ajánlások két külön nézőpontot adnak.
Kedvezőbb pontszám jelezhet javulást, de csak összehasonlítható méréseknél értelmezhető. A pontszám nem a weboldal sebességének százalékos értéke.
A Core Web Vitals jelenlegi mutatói az LCP, az INP és a CLS. A jó küszöb LCP ≤ 2,5 másodperc, INP ≤ 200 ms és CLS ≤ 0,1, a látogatások 75. percentilisén, eszköztípusonként. A laborban mért TBT nem ugyanaz, mint a valódi használatból származó INP.
Ezen kívül, ha kicsit lejjebb tekersz, akkor Summary, Performance és Structure füleken megtalálod (angol nyelven) részletezve, hogy a honlapodnak melyek azok a részei, amelyek rendben vannak sebességoptimalizálás szempontból, és melyek azok, amelyek fejlesztésre szorulnak. (A zölddel jelölt megállapítások rendben vannak, a sárga, narancs vagy piros jelölésűek viszont fejlesztésre szorulnak, minél pirosabb, annál inkább.)
A Waterfall fülön látod, hogy milyen fájloknak kellett betöltődni a weboldalad megjelenítéséhez. Ha itt kiugróan magas értéket találsz, azt érdemes megvizsgálni, tudod-e csökkenteni az elem méretét, vagy ha nem feltétlenül van rá szükség, akkor akár teljesen kivenni az oldalról.
Ha lejjebb görgetsz találhatsz angol nyelvű leírásokat, segítséget weboldalad sebességének javítására.
Google PageSpeed Insights
A PageSpeed Insights mobilos és asztali laboreredményt is mutat. Ha van elegendő adat, valós Chrome-felhasználók adatait is megjeleníti, ezért a jelentés két részét külön értelmezd.
A mobilos és asztali eredmények között a jelentés kapcsolóival válthatsz. Nézd meg azt is, hogy az adatok a konkrét URL-re vagy az egész originre, vagyis az adott protokoll–domain–port kombinációra vonatkoznak-e.
A Google sebesség mérője már nagyrészt magyar nyelvű tanácsokkal lát el weboldalad gyorsításához.
Böngészd át őket.
Milyen eredményt érdemes megcélozni WordPressnél?
A WordPress vagy egy oldalépítő használatából nem vezethető le általános 80-as GTmetrix- vagy 50-es mobilos PageSpeed-plafon. A tartalom, a tárhely, az integrációk és a megvalósítás együtt számítanak.
A használatot akadályozó hibákat és a gyenge valós látogatói mutatókat kezeld először. Ne tekints automatikusan megfelelőnek egy oldalt azért, mert átlépett egy régi cikkben megadott pontszámot.
Hogyan segíthet a WP Rocket a weboldal gyorsításában?
A gyorsítótárazás csökkentheti a szerver ismételt munkáját. Optimalizáló bővítmény választása előtt nézd meg, mit végez már a tárhely vagy egy másik eszköz, hogy ugyanazt a feladatot ne kezeld több, egymással ütköző megoldással.
A WP Rocket egy fizetős lehetőség. A gyártói funkcióleírás alapján válaszd ki a szükséges funkciókat, majd mérd vissza az eredményt; pusztán a telepítésből nem következik biztos gyorsulás.
Telepítés vagy jelentősebb átállítás előtt legyen ellenőrzött, visszaállítható mentésed. Lehetőleg elkülönített környezetben próbálj, és előre rögzítsd a visszaállítást. A WordPress adminban rendszerint a Beállítások → WP Rocket alatt találod a felületet.
Az alábbi szempontok nem minden webhelyre érvényes kapcsolólistát adnak. A régi képernyőképek történeti példák: a telepített verzió és a hivatalos dokumentáció az irányadó.
1. Gyorsítótár: szerver, böngésző és mobilos változat
A szerveroldali oldalgyorsítótár és a böngésző gyorsítótára külön réteg. A WP Rocket oldalgyorsítótára elkészített HTML-választ tárolhat, így a szervernek nem kell minden kérésnél ugyanazt a PHP- és adatbázismunkát elvégeznie.
A böngésző gyorsítótára ezzel szemben a látogató eszközén tárolhat erőforrásokat a későbbi használathoz. A böngészős cache ürítése nem ugyanaz, mint a WP Rocket oldalgyorsítótárának törlése.
A lejárat és az ürítés rétegenként külön szabályozható. Az oldaltartalom, a böngészőben tárolt fájl és egy esetleges CDN-példány frissülését is ellenőrizd; nincs egyetlen közös cache-törlési idő minden rétegre.
A régi Cache fülön szereplő lehetőségeket ma így érdemes értelmezni:
Mobilos gyorsítótár: a WP Rocket 3.16-os változásleírása szerint a Cache fül megszűnt, és a mobilos gyorsítótárazás működése is változott. Ne keress minden verzióban régi jelölőnégyzeteket; a mobilos kimenetet az aktuális működés alapján ellenőrizd.
Külön mobilos cache: a „reszponzív oldalnál mindig kapcsold ki” szabály nem általánosítható. Az oldali kimenet, az optimalizált mobilos elemek és a többi gyorsítótár együtt számítanak.
User Cache: a felhasználói gyorsítótár külön példányokat készíthet bejelentkezett felhasználóknak. Ne kapcsold be pusztán azért, mert vannak fiókok: a személyre szabott, érzékeny és dinamikus oldalak kizárásait is meg kell tervezni.
Cache Lifespan: az oldalgyorsítótár élettartamát szabályozza; az újabb felületeken az Advanced Rules résznél található. Az ürítés és az előtöltés összefügg, de az előtöltés beállítását és lefutását külön is ellenőrizd.
2. File Optimization
A CSS- és JavaScript-optimalizálás után a megjelenést és az interakciókat is tesztelni kell.
A korábbi kapcsolónevek helyett a tényleges funkciót és az aktuális felületet nézd:
Minify HTML: a gyártó már a 3.7-es kiadásnál eltávolította ezt a funkciót. A régi képernyőkép alapján ne keresd mai ajánlott kapcsolóként.
Betűtípusok: a régi Optimize Google Fonts kapcsoló kezelése megváltozott. Az aktuális Self-host Google Fonts és a betűkészlet-előtöltés külön feladat. A ténylegesen használt családokat, betűvastagságokat és a megjelenést vizsgáld, ne tölts elő minden fájlt válogatás nélkül.
Minify CSS files: a felesleges karakterek csökkentésével kisebb lehet a CSS. Ez nem ugyanaz, mint a nem használt stílusok eltávolítása; a megtakarítást és a működést vissza kell mérni.
Combine CSS files: a régi „mindig egyesítsd a fájlokat” ajánlás helyett az aktuális CSS-kiszolgálást vizsgáld. A kevesebb kérés önmagában nem bizonyít gyorsabb oldalt, és a korábbi kapcsoló nem minden verzióban érhető el.
Optimize CSS delivery: a Remove Unused CSS az adott oldalhoz szükséges stílusokat állítja elő; alternatíva lehet az aszinkron betöltés. Az előállítás nem azonnali. Az alapnézet mellett a mobilmenü, a popup és az űrlap hibaállapota is kapja meg a szükséges stílust.
jQuery és jQuery Migrate: a jQuery JavaScript-könyvtár, a Migrate pedig a régebbi jQuery-funkciókkal való kompatibilitást segíti. A Migrate eltávolítása nem a teljes jQuery törlése. Függőségi vizsgálat és működési teszt nélkül ne távolítsd el egyiket sem.
Minify JavaScript files: a kód méretét csökkentheti. Bekapcsolás után ellenőrizd a menüt, a gombokat és a teljes űrlapfolyamatot; egy kisebb fájl nem ellensúlyoz egy elromlott jelentkezést.
Combine JavaScript files: nem általános kötelező beállítás. A WP Rocket Delay JavaScript execution használatakor az egyesítés letiltódik a helyes végrehajtási sorrend védelmében.
Load JavaScript deferred: a defer beállítás a parancsfájlok végrehajtását halasztja az oldal HTML-jének feldolgozásához igazítva. Nem azonos a felhasználói interakcióra váró Delay funkcióval. A függőségek és a kivételek ellenőrzése szükséges.
Delay JavaScript execution: egyes kódok csak felhasználói interakció után indulnak. A menü, az űrlap, a consent-kezelő és a mérés működését külön ellenőrizd. A mai Delay Safe Mode és a régi Safe Mode for jQuery nem azonos beállítás.
Minden egyes beállítás megváltoztatás után érdemes letesztelned, hogy minden rendben maradt a weboldaladon. Ez ezen oldal beállításaira különösen érvényes.
Még egyszer: Fontos, hogy előtte legyen biztonsági mentésed!
3. Media
Javasolt beállítások:
A LazyLoad a később szükséges képek és beágyazások betöltését halaszthatja. Ettől kisebb lehet a kezdeti terhelés. A fő tartalmi, LCP-t adó képet azonban ne késleltesd: a Google LCP-útmutatója szerint annak korai felfedezhetősége és betöltése különösen fontos.
LazyLoad képekhez: a gyártói útmutató alapján kezeld a később látható képeket és a kizárásokat. Ellenőrizd, hogy egy másik bővítmény nem késlelteti-e ugyanazt a képet másodszor is.
LazyLoad iframe-ekhez és videókhoz: a lejjebb elhelyezett beágyazásokat érdemes lehet később betölteni. A lejátszásnak, a mobilos használatnak és a szükséges hozzájárulási feltételeknek ekkor is működniük kell.
YouTube-előnézeti kép: a teljes lejátszó későbbi betöltése csökkentheti a kezdeti terhelést. Teszteld, hogy kattintás után elindul-e a videó; ez a megoldás önmagában nem helyettesíti a szükséges consent-kezelést.
Emoji-optimalizálás: a WP Rocket dokumentációja szerint a WordPress külön emoji-szkriptjét érinti. Nem azt jelenti, hogy minden emoji eltűnik a szövegből; a böngésző saját megjelenítése megmaradhat.
WordPress-beágyazások: a beágyazás egy másik tartalom megjelenítésének módja. A kapcsolódó funkció vagy szkript korlátozása nem másolásvédelem: a tartalom ettől még lemásolható. Csak a ténylegesen használt beágyazások vizsgálata után változtass ezen.
WebP Compatibility: a már rendelkezésre álló alternatív képek és a gyorsítótár együttműködését segítheti. Nem képkonvertáló szolgáltatás. A fájl létrehozása és a megfelelő változat tényleges kiszolgálása külön ellenőrzés.
4. Preload
Preload cache: az előtöltés látogatást utánozva készíti el a gyorsítótárat. Az aktuális WP Rocket-előtöltési útmutató teljes és részleges folyamatot különböztet meg. A működéshez elérhető oldalakra és működő háttérfeladatokra is szükség van.
- a releváns beállításváltozás vagy teljes cache-ürítés teljes előtöltést indíthat;
- egy cikk módosításához részleges ürítés és előtöltés kapcsolódhat;
- az élettartam miatti ürítésnél is az aktuális előtöltési szabály érvényes.
Az előtöltés szerverterheléssel járhat. Ellenőrizd a folyamat állapotát, és ne indítsd újra ismételten csak azért, mert még nincs minden eredmény kész.
Sitemap és előtöltés: a mai folyamat támogatott SEO-bővítmények webhelytérképét is felismerheti. A régi Activate sitemap-based cache preloading jelölőnégyzet nem általános mai lépés. A privát vagy bejelentkezett tartalomra nem feltétlenül ugyanaz a működés vonatkozik.
5. CDN
A CDN tartalomszolgáltató hálózat. A működését és a bevezetés szempontjait a CDN jelentéséről szóló cikkben részletesebben is bemutatom.
A gyorsítótárazható tartalmat hálózatilag közelebbi kiszolgálóról is átadhatja. A tényleges gyorsulás az oldaltól, a kapcsolattól és a cache találati arányától is függ.
Részletesebben:
Ha a látogató távol van az eredeti kiszolgálótól, a hálózati késleltetés is hozzájárulhat a várakozáshoz. A puszta légvonalbeli kilométerből azonban nem lehet pontos betöltési időt számolni.
A CDN nem feltétlenül tárol minden fájlt vagy minden személyre szabott választ. A beállított szabályok döntik el, mi szolgálható ki a gyorsítótárból, és mihez kell elérni az eredeti szervert.
Egy európai peremkiszolgáló például közelebb lehet a magyar látogatóhoz, de a hálózati útvonal nem mindig a földrajzilag legközelebbi pontot használja. Ez szemléltetés, nem mért ügyféleredmény.
A hasznát a saját oldaladon ellenőrizd, összehasonlítható mérésekkel.
Magyar tárhely és magyar közönség mellett is lehet haszna bizonyos funkcióknak, de a CDN nem kötelező pusztán azért, hogy több optimalizálási kapcsoló legyen bekapcsolva.
A WP Rocket CDN-útmutatója alapján válaszd ki az integrációt. CNAME-alapú kiszolgálásnál CDN-nevet kell beállítani; egy másképp működő proxyhálózathoz nem feltétlenül ezt a mezőt használod.
6. Heartbeat
A Heartbeat szabályozását az adott felület működésével együtt vizsgáld. A gyártó Control Heartbeat útmutatója leírja a korlátozási lehetőségeket, de a kikapcsolás megzavarhat rá épülő funkciókat.
A WordPress Heartbeat API időszakos kérésekkel segíti a böngésző és a kiszolgáló közötti adatcserét.
Például:
- Bejegyzések automatikus mentése szerkesztés közben.
- WordPress Vezérlőpulton történő értesítés
- Zárolási információ, amikor egy másik szerkesztő épp dolgozik egy bejegyzésen.
- Valós idejű adatok megjelenítése a Vezérlőpulton (pl. webshopok esetén)
A Heartbeat admin-ajax kéréseket használhat; a WordPress leírása 15–120 másodperces ütemeket említ. Más bővítmények is használják az admin-ajax.php-t, ezért a magas terhelést nem szabad automatikusan a Heartbeatnek tulajdonítani.
A korlátozás csökkentheti a Heartbeat kéréseinek gyakoriságát, de nem általános megoldás minden szerverterhelési problémára. Előbb azonosítsd a ténylegesen terhelő műveletet.
Ha módosítod, a Control Heartbeat alatt felületenként ellenőrizd a hatását.
A következő lehetőségek közül tudsz választani szabályozás tekintetében:
- Do no limit: Ne csináljon semmit az API-val (ne szabályozza).
- Reduce activity: ritkább kérésekre állítja a Heartbeatet. A WP Rocket leírásában a percenkénti ütem kétpercenkéntire változik; az automatikus mentést és a többi érintett funkciót utána tesztelni kell.
- Disable: Kapcsolja ki teljesen. (Az API teljes kikapcsolása hatással lehet a WordPress sablonjaira és egyéb bővítményeire. Ha esetleg emellett döntesz, akkor utána mindenképp tesztelj végig mindent, hogy megfelelően működik-e.)
A Behavior on backend beállítással az admin felületen történő hívásokat, a Behavior in post editor beállítással a bejegyzés szerkesztőben történő hívásokat, a Behavior in frontend beállítással a felhasználók által is látható felületen történő hívásokat tudod szabályozni.
Még egy eszköz a weboldal sebességének javítására
A képek, videók mérete erősen befolyásolja a weboldal betöltésének sebességét.
A képet a megjelenési mérethez, a kijelző felbontásához és a kívánt minőséghez igazítsd. Nagyobb eredeti fájlból kisebb változatokat is ki lehet szolgálni.
A feleslegesen nagy fájl növeli az adatforgalmat. A tényleges megjelenési időhöz azonban a letöltési sorrend, a gyorsítótár és a böngésző munkája is hozzátartozik.
Nincs minden teljes szélességű képhez kötelező 1920 pixeles méret. A szükséges felbontás a megjelenési szélességtől és a képpontsűrűségtől is függ. Reszponzív képeknél ellenőrizd, hogy a böngésző a megfelelő változatot tölti-e le.
A mobil nézetekre érdemes lehet külön mobilra optimalizált képet használni.
Azon túl, hogy maga a kép felbontása rendben van, még úgy tudod csökkenteni magának a képfájlnak a méretét, ha tömöríted.
Nincs minden képre és formátumra érvényes 60%-os tömörítési szabály. Készíts több változatot, és a tényleges fájlméretet a látható minőséggel együtt hasonlítsd össze. Szerkesztéshez használhatsz például Photoshopot vagy Pixlrt; az exportálási skálák nem feltétlenül összehasonlíthatók.
A Pixlr online képszerkesztő; az elérhető funkciókat és az ingyenes vagy fizetős feltételeket az aktuális szolgáltatói oldalon ellenőrizd.
Mobilon csökkentheted a szükségtelen animációkat és más terhelő elemeket, de a lényegi tartalom és a szükséges funkciók maradjanak hozzáférhetők. A rejtett elem ráadásul nem feltétlenül szűnik meg letöltődni vagy futni.
Szívesen olvasnál még hasonlókról? Rendszeresen megjelenő hírleveleimben ilyen és egyéb, vállalkozással, online marketinggel, web-/landing oldal készítéssel kapcsolatos fontos tudnivalókat osztok meg. Ha szeretnéd kimaxolni a vállalkozásodban lévő potenciált, akkor iratkozz fel ezekre a hasznos levelekre itt! 👇
Végszó
A gyorsítás célja a használhatóbb oldal. A mérést ezért egészítsd ki a menü, a videók, az űrlap és az esetleges vásárlási folyamat tesztjével. A jobb sebesség segíthet, de önmagában nem bizonyít több bevételt.
Válassz egy mért problémát, módosíts célzottan, majd mérj újra azonos körülmények között. Így kiderülhet, melyik változtatás javított, és nem marad észrevétlen egy elrontott funkció.
Ha komolyabb szakértői támogatásra lenne szükséged weboldalad gyorsításához, akkor vedd fel velem a kapcsolatot itt, és megbeszéljük a részleteket, hogy pontosan hogyan tudlak támogatni téged ebben!
