WordPress optimalizálás sebességre hangolva
A látogatók szeretik a gyorsan betöltődő weboldalakat. És a Google sem lesz hálátlan… Ebben a bejegyzésben azt nézzük végig, mit tehetünk, hogy a WordPress sebességét optimalizáljuk. A bejegyzésben leírt tényezők nagy részéhez bővítmények is vannak, azok is használhatók.
WordPress optimalizálás: a tárhely
A WordPress optimalizálás alapjaiban is a jó tárhely megválasztásával kezdődik. Lehetőleg olyan helyen vásároljunk tárhelyet, ahol nincs rengeteg ügyfél a szerver megosztott erőforrásaira. A néhány száz még elfogadható, az olyan tárhelyet, ahol 1000 felhasználó is jut egy szerverre, kerüljük.
Rengetegen használnak WordPresst, a számláló szerint a legfrissebb, 4.2 verziót a bejegyzés írásának ebben a pillanatában ~11,5 millióan töltötték le. Épp a népszerűsége folytán fejlesztik gőzerővel. Valljuk be, minél több funkciót kapunk az alaprendszerrel, annál több erőforrás kell neki (is, mint minden más szoftvernek is). Ezért nem mindegy, milyen szerverkonfiguráció van alatta.
Sőt a DNS (domain név szerver) sem mindegy. Ha rosszul van konfigurálva, akkor hosszú időt igénybe vehet a név feloldása.
WordPress optimalizálás: a sablon
A sebességoptimalizálás második lépése a megfelelő sablon kiválasztása. Ezen a területen olyan sablont kell keresnünk, ami nincs „összegányolva”. Jó tanács. 🙂 Honnan tudja a laikus, hogy nincs összegányolva? Első követelmény: megbízható helyről származzon. A wordpress.org-ra például csak olyan sablon kerül, ami átmegy egy alap minőségi teszten. A különböző sablongyűjtő helyek, mint a themeforest, creativemarket szintén magas minőségi követelményeket támasztanak. Megbízhatunk a kereskedelmi sablon fejlesztésre specializálódott cégek termékeiben is, a néhány ingyenesen letölthető sablonjukkal sem szokott probléma lenni.
A sablonválasztás második szempontja, hogy ne legyen telerakva számunkra teljesen fölösleges funkciókkal. A themeforesten például rengeteg olyan sablon van, ami olyan, mint a sportleves: mindent bele. Ha nem értünk olyan szinten a sablonhoz, hogy bele merjünk nyúlni és kiszedni belőle a fontos helyeken lévő fölösleget, akkor inkább próbáljunk olyan sablont keresni, ami közelít ahhoz tudásban, ami az igényünk. Jónéhány lassító tényezőtől megszabadulhatunk ezzel már az elején.
A sablonban magunk is tudunk HTTP lekérést csökkenteni, ha ott ahol lehetőségünk van, az elérési útvonal PHP kódját lecseréljük a teljes elérési útvonalra (ilyen pl. a logó a fejlécben).
WordPress optimalizálás: bővítmények, widgetek
A WordPress sebesség optimalizálásának a harmadik szempontja: csak annyi és olyan bővítményt használjunk, ami feltétlenül szükséges. Ha sokat használunk így is sok stíluslap, javascript kerül meghívásra, ami eleve lassító tényező. Ugyanígy gondoljuk meg, hogy milyen és mennyi widgetet használunk, hiszen ez is növeli az adatbázis lekérések számát.
A két legnépszerűbb WordPress SEO bővítményről korábban írtunk.
Érdemes beüzemelni valamilyen cache bővítményt. Sok van, ki kell próbálni és azt használni, ami beválik. Általában ezekben van lehetőség a stíluslapok, javascriptek minimalizálására is, ezzel vigyázni kell, csak olyan szinten minimalizáljunk, hogy a weboldal továbbra is rendeltetésszerűen működjön.
WordPress optimalizálás: minimalizálás
Sebességnövekedés érhető el a css, javascript fájlok összevonásával, minimalizálásával is. Az összevonásnál figyeljünk arra, hogy abban a sorrendbe helyezzük egy fájlba őket, amilyen sorrendben a fejlécben meghívásra kerültek. A css fájlok összevonásánál általában nincs probléma, a javascript fájlok száma csökkenthető, de rendszerint nem lehet működőképesen egyetlen fájlban egyesíteni őket. Itt is figyelni kell arra, hogy csak olyan szinten vonjuk össze a fájlokat, olyan szinten minimalizáljunk, hogy a weboldal működőképessége fennmaradjon.
WordPress optimalizálás: képek és sebesség
A túl nagy méretű képek nagyon tudják lassítani a betöltést. Célszerű olyan méretű képeket feltölteni, amekkorára valóban szükség van. A képeket feltöltés előtt nem árt optimalizálni, tömöríteni. A webre rendszerint elég a 85%-os minőség, exif és egyéb adatok nélkül. A képek optimalizálásához természetesen segítségül hívhatunk képoptimalizáló bővítményt is, amit nem szükséges folyamatosan bekapcsolva tartani, elég a futtatás idejére aktiválni.
WordPress optimalizálás: .htaccess trükkök
Elérkeztünk ahhoz a részhez, ami a legoptimálisabb megoldásokat tudja nyújtani. A .htaccess egy fájl, amit az első permalink módosítás generál (olyan tárhelyeken, ahol engedélyezett a .htaccess). Miért optimális? Pusztán azért, mert itt olyan „funkciókat” tudunk hozzáadni a WordPresshez, amelyekhez nem lesz szükségünk külön bővítményre.
Nézzük a sebességhez kapcsolódó funkciókat.
Etags (Entity Tags). Ez egy egyedi azonosító. A HTTP protokoll része, lassú és problémás (YLSOW hibának jelöli). A fejléc lejárattal kiváltható, ezért érdemes letiltani.
Header unset ETag FileETag None
Böngésző cache, más néven fejléc lejárat megadása. Így az első látogatás után sok HTTP lekérést, azaz szerver terhelést tudunk spórolni, mivel a böngésző a lejáratig a mentett változatot tölti be.
A lejárat megadásánál vagy a nap, hét, hónap, év szerint adjuk meg (értelemszerűen angolul) vagy az óra szerinti „access plus 2500000 seconds” stílusban, de következetesen vagy egyik vagy másik, ne keverjük.
# BEGIN Expire headers ExpiresActive On ExpiresByType image/x-icon "access 1 year" ExpiresByType image/jpg "access 1 year" ExpiresByType image/jpeg "access 1 year" ExpiresByType image/gif "access 1 year" ExpiresByType image/png "access 1 year" ExpiresByType text/css "access 1 month" ExpiresByType text/html "access 1 month" ExpiresByType application/pdf "access 1 month" ExpiresByType text/css "access 1 month" ExpiresByType application/javascript "access 1 month" ExpiresByType text/x-javascript "access 1 month" ExpiresByType application/x-shockwave-flash "access 1 month" ExpiresByType application/xhtml+xml "access 1 month" ExpiresDefault "access 1 month" # END Expire headers
Amennyiben más típusú fájl lejáratára is szükségünk van, azzal egészítsük ki (pl. a sablonban lévő font esetén woff, svg, stb.).
Ezzel a statikus elemekké alakítjuk az oldalt (azaz lementi statikus fájlokként), így gyorsabban tölti be a böngésző.
Szükségünk lesz hozzá a Cache kontrollra is.
Apache szerver esetén:
# BEGIN Cache-Control Headers <filesMatch ".(ico|jpe?g|png|gif|swf)$"> Header set Cache-Control "public" <filesMatch ".(css)$"> Header set Cache-Control "public" <filesMatch ".(js)$"> Header set Cache-Control "private" <filesMatch ".(x?html?|php)$"> Header set Cache-Control "private, must-revalidate" # END Cache-Control Headers
NGINX szerver esetén:
location ~* .(jpg|png|gif|jpeg|css|js)$ {
expires 6h;
}
A példában a 6h 6 órát jelent.
Gzip tömörítés. A tömörített fájlok a HTTP reakcióidőt csökkentik. Azaz szerver sávszélessége magasabban marad és csökken az az idő, ami alatt a böngésző letölti a fájlokat.
Tömöríteni érdemes a HTML fájlokat, szkripteket, stíluslapokat és minden szöveges választ, ide értve az XML és JSOn fájlokat is.
Ne tömörítsük a kép és pdf fájlokat, mivel azok már tömörítettek.
Apache szerver esetén:
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
De a Google mindenhol jelen van. 🙂 Így ide is fejlesztett egy modult, amely a mod_pagespeed nevet kapta. Ha a szerverünk támogatja – nem minden szolgáltató támogatja -, akkor használjuk bátran a fenti helyett az alábi kódot:
ModPagespeed on ModPagespeedEnableFilters extend_cache,combine_css,combine_javascript,collapse_whitespace,move_css_to_head
Ha NGINX szervert használunk, akkor pedig ezt:
server {
gzip on;
gzip_types text/html text/css application/x-javascript text/plain text/xml image/x-icon;}
Sebességre hangolva: az adatbázis
Miután végeztünk a .htaccessben történő sebességoptimalizálással, optimalizáljuk az adatbázist is.
A WordPress egy-egy anyagunkból – főleg ha hosszabb, sokat dolgozunk vele, illetve többször módosítjuk – mérhetetlenül sok változatot ment az adatbázisba. Minél nagyobb az adatbázis, annál magasabb a válaszidő.
Ezért a wp-config.php-t egészítsük ki az alábbi kódsorral:
define('WP_POST_REVISIONS', 3 );
A 3 azt jelenti, hány változatot tároljon az adatbázis egy-egy cikkből. Tetszőlegesen változtatható, 0 vagy false esetén nincs korábbi változat.
WordPress optimalizálás: a szerveren túli világ
Gyakran használunk olyan alkalmazásokat, amelyek külső szerverről hívják meg a szükséges fájlokat. Olyanokra kell gondolni, mint Facebook Like gomb, Google font, Analytics, stb.
Ezeknél a sebesség optimalizálás nehézségbe ütközik, hiszen nem férünk hozzá a másik szerverhez.
Két dolgot tehetünk:
- aszinkron módon töltjük be a meghívott javascripteket (HTML5 sablon esetén nincs nehéz dolgunk, útmutató itt) vagy
- lementjük a meghívott fájlt és a saját szerverünkön optimalizált változatot tárolunk és ezt hívatjuk meg az alkalmazással. Ez utóbbi esetben nyomon kell követnünk az eredeti fájl változásait és a változásokat ugyanúgy optimalizálni.
Nagyvonalakban ezekről az elvégzendő feladatokról szól a WordPress sebesség optimalizálása. Még több optimalizálási teendő, útmutató olvasható a bejegyzés szerzőjének 340 oldalas könyvében, a WordPress SEO könyvben, melynek a tartalomjegyzéke ide kattintva olvasható vagy akár rögtön meg is vásárolható ezen a linken.
CDN – Content Delivery Network
Az meg mi? Röviden: maximalistáknak való további gyorsítási lehetőség. Oké. Ez így kicsit elnagyolt, de mindjárt kiderül mihez érdemes használni.
Bővebben: gyakorlatilag egy hatalmas szerverhálózat, amelynek segítségével még gyorsabban tudjuk kiszolgálni a látogatóinkat. A CDN szoftver az internetezőhöz legközelebbi szerverről küldi ki az adatokat, azaz lecsökkenti a távolságokat. Ezáltal gyorsabb lesz a kiszolgálás, nagyobb lesz a teljesítmény, miközben javul a felhasználói élmény. (Az internet technikai részleteibe, hogy hogyan kapcsolódnak a szolgáltatók fő gerinchálózathoz, milyen útvonalon jut el az adat a szervertől a felhasználóig és hasonló dolgokba most ne menjünk bele…)
CDN-t használni nagyobb leterheltségű tartalmakhoz érdemes, mint audio, videó, internetes tv, nagyobb hírportálok. Ez nem zárja ki, hogy akár egy bemutatkozó honlaphoz is használjuk, de az anyagi vonzata miatt nem biztos, hogy megéri.
Hogyan ellenőrizhetem a honlapom sebességét?
Több lehetőség is van a sebesség ellenőrzésére, pl. a Google PageSpeed Insight.
Ha mélyebb részleteket szeretnénk kapni a honlapról, mint a Google eszköze ad, használhatjuk pl. a gtmetrix.com ellenőrző eszközét, amely A-F között kategorizálja a honlapot és még a konkurencia honlapjával is összehasonlíthatjuk a sajátunkat. Az A kategória a legjobb, az F a leggyengébb.
Ha a teszt lefuttatása után valami ehhez hasonlót látunk:
akkor nagyon jól állunk sebesség tekintetében, de már 80%-tól jónak mondható az eredmény.
A fenti kép egyik ügyfelünk aktuális honlap optimalizálási projektjéről készült, ahol a képi anyagok még csak kb. 50%-ban vannak optimalizálva, a honlap szerkezetileg már rendben van.
Mobilra optimalizálás
2015. április 21. A Mobilegeddon napja, ahogy angolosan hívják. Arról van szó, hogy ettől a naptól kezdve a weboldal mobil megjelenése rangsorolási tényező lett. Igaz, csak a mobilról indított kereséseknél. Nem volt rég, és nem szólt olyan nagyot (eddig), mint ahogy a Google dörgedelmeiben ijesztgetett. De azért oda kell rá figyelni optimalizálás terén is. Korábbi cikkünkben beszámoltunk arról, mire kell kiemelten figyelni.
A korábban írtak függetlenek az eszközöktől, minden eszköz esetében ugyanúgy működik. Mobil esetén viszont valószínűleg tehetünk még néhány apróságot.
- Meg kell vizsgálni a sablon képeit, amit lehet összevonni egy sprite.png-be és ennek megfelelően módosítani a css-t.
- Ami képi elemek (sablonban lévők) a kisebb eszközökön zavaróan hatnak, elrejteni a felhasználók elől a css-ben.
- Valamint el lehet rejteni olyan funkciókat is, amelyek nem élvezhetők ezeken a kis eszközökön, pl. slider.
