Képek, PHP és egyéb sebességnövelő megoldások

Modul 6: Sebesség · Olvasási idő: 9 perc

Tanulási cél: E lecke után Ön képes lesz alkalmazni a legnagyobb fennmaradó sebességnövelő megoldásokat, és mérni azok hatását.

Kulcsfogalmak: képoptimalizálás, WebP és AVIF, lusta betöltés (lazy loading), az LCP-kép, fetchpriority, PHP-verzió, adatbázis rendbetétele (változatok, tranziens adatok, autoload), WP-Cron, valódi cron, DISABLE_WP_CRON, külső betűtípusok, Heartbeat

Dolgozzon a megfelelő sorrendben

Az oldalgyorsítótár (6.2 lecke) után ezek hozzák a legtöbb eredményt, nagyjából a ráfordított munka és a hatás arányában rendezve:

1. a képek rendbetétele;
2. egy naprakész PHP-verzió;
3. kevesebb külső elem és erőforrásigényes bővítmény;
4. egy rendbe tett adatbázis;
5. az ütemezett feladatok futtatása valódi cronon keresztül.

Mérjen minden lépés előtt és után (6.1 lecke), különben nem fogja tudni, mi segített. És egyszerre csak egy dolgot végezzen el.

Képek: a legnagyobb nyereség a böngészőben

A legtöbb oldalon a képek teszik ki a legnagyobb részét annak, amit a látogató letölt. Amit a 4.4 leckében tanult, itt térül meg:

• Megfelelő méret: ne töltsön fel nagyobb képet a szükségesnél, és engedje, hogy a WordPress a srcset segítségével kisebb méreteket is felkínáljon.
• Tömörítés és formátum: a WebP azonos minőség mellett jellemzően jóval kisebb, mint a JPEG; az AVIF gyakran még kisebb. Egy bővítmény átalakíthatja a meglévő képeket, és a kisebb verziót adhatja a böngészőknek, amelyek támogatják azt. Ellenőrizze, hogy az átalakítás az Ön saját szerverén történik-e, vagy egy külső szolgáltatásnál.
• Lusta betöltés (lazy loading), de nem mindenre. A WordPress automatikusan loading="lazy" attribútumot ad a képeknek, kivéve a legfelső nagy képet. Ez a kép gyakran az LCP-elem (6.1 lecke): a legnagyobb tartalmi elem, amelyet a látogató elsőként lát. Ha ez lustán töltődik be, a böngésző éppen ezzel vár, és az LCP-érték romlik. A WordPress ezért az LCP-jelöltnek gyakran fetchpriority="high" attribútumot ad, hogy a böngésző elsőként töltse be.

<img src="hero-1536x864.webp" width="1536" height="864"
     fetchpriority="high" alt="Műhely, sorba rendezett kerékpárokkal">
<img src="team-768x512.webp" width="768" height="512"
     loading="lazy" alt="A csapat a bolt előtt">

Egy buktató: egyes sablonok, oldalépítők és optimalizáló bővítmények a legelső képre is lusta betöltést alkalmaznak, vagy a nagy képet CSS-en keresztül háttérként töltik be (amit a böngésző csak később fedez fel). A PageSpeed Insightsban az LCP résznél láthatja, melyik elemről van szó, és hogy az lustán töltődik-e be.

PHP: ingyenes sebességnövekedés

A PHP minden új főverziója gyorsabb az előzőnél, és a WordPress-weboldalak ebből azonnal profitálnak, anélkül hogy bármit is módosítani kellene a weboldalon. Ezenkívül a régi verziók már nem kapnak biztonsági frissítést (8.4 lecke). Ha vált, ellenőrizze, hogy a bővítményei és a sablonja támogatják-e az új verziót, és lehetőleg előbb egy tesztkörnyezetben (staging) próbálja ki.

A PHP beállításainál érdemes megnézni a következőket is:

• OPcache: a legtöbb szolgáltatónál alapértelmezetten be van kapcsolva. Ennek következménye: egy módosított PHP-fájl esetén eltarthat egy ideig, amíg a PHP az új verziót kezdi használni.
• memory_limit: ha túl alacsony, hibákat okoz erőforrásigényes oldalaknál; ha nagyon magas, attól a weboldal nem lesz gyorsabb.

Külső elemek és erőforrásigényes bővítmények

Minden más fél által biztosított elem egy plusz kapcsolatot és plusz várakozási időt jelent: egy külső szolgáltatás betűtípusai, egy beágyazott videó, egy chat widget, mérőkódok, közösségimédia-gombok, egy térkép. Elemenként érdemes feltenni a kérdést:

• Szükséges ez? Egy videót, amelyet szinte senki nem indít el, helyettesíthet egy kép és egy hivatkozás is.
• Lehet helyi? A betűtípusokat általában elhelyezheti a saját szerverén (egy bővítménnyel vagy blokk sablon esetén a theme.json fájlon keresztül). Ez megspórol egy kapcsolatot, és jót tesz az adatvédelemnek is (9.3 lecke).
• Lehet később? Egy chat widget vagy videó betöltődhet csak egy kattintás után is.

A bővítmények méréséhez segít az X-Ray (CloudLinux alapú tárhely esetén), vagy egy olyan bővítmény, mint a Query Monitor (ideiglenesen bekapcsolva, csak az adminisztrátorok számára látható). Ezek megmutatják, melyik bővítmény fogyasztja a legtöbb adatbázis-lekérdezést vagy időt.

Az adatbázis rendbetétele

Az adatbázis olyan dolgokkal is növekszik, amelyeket Ön nem lát:

• Változatok (4.1 lecke): minden oldal minden mentett verziója. Korlátozza ezeket a WP_POST_REVISIONS segítségével, és tisztítsa meg a régieket.
• Spam- és kukába dobott hozzászólások, valamint a kukában lévő bejegyzések.
• Tranziens adatok (transients): a bővítmények ideiglenes adatai a wp_options táblában, amelyeket néha nem takarítanak el.
• Autoload: a wp_options táblában lévő, autoload bekapcsolt beállításokat minden kéréskor egyszerre betölti a rendszer. A régen eltávolított bővítmények néha nagy mennyiségű adatot hagynak ott. A Webhely Egészség (5.4 lecke) figyelmeztet, ha az autoload-adatok nagyon nagyok.
• Napló táblák bővítményektől (statisztikák, biztonsági naplók, e-mail naplók), amelyeket soha nem ürítenek ki.

A rendbetétel elvégezhető egy rendbetevő bővítménnyel, a WP-CLI használatával (wp transient delete --expired, wp post delete $(wp post list --post_type=revision --format=ids) --force), vagy a phpMyAdmin táblaoptimalizáló funkciójával. Mindig készítsen előbb biztonsági mentést. Ne távolítson el semmit, amiről nem tudja, mi az.

Ütemezett feladatok: WP-Cron

A WordPressnek vannak olyan feladatai, amelyeknek egy adott időpontban kell lefutniuk: egy ütemezett bejegyzés közzététele, a frissítések ellenőrzése, egy biztonsági mentés bővítmény működtetése. Ezt nevezik WP-Cronnak. Alapértelmezés szerint a WP-Cron nem egy óra szerint fut, hanem látogatáskor: minden oldalkérésnél a WordPress megnézi, van-e éppen esedékes feladat. Két hátránya van:

• Kevés látogató esetén a feladatok túl későn futnak le (egy ütemezett bejegyzés csak az azutáni első látogatáskor jelenik meg).
• Sok látogató esetén nagyon gyakran megtörténik az ellenőrzés, és egy erőforrásigényes feladat éppen egy látogató oldalát lassíthatja le.

Jobb megoldás: kapcsolja ki a WP-Cront látogatáskor, és futtassa egy valódi szerveroldali cronjob tíz vagy öt percenként. A wp-config.php fájlban (a "ne szerkessze tovább" sor fölött):

define( 'DISABLE_WP_CRON', true );

És a tárhelykezelő felület cron képernyőjén egy feladat, 10 percenként:

*/10 * * * *  /usr/local/bin/php /home/felhasznalo/domains/example.com/public_html/wp-cron.php >/dev/null 2>&1

A PHP és a weboldal elérési útja szolgáltatónként eltérő; nézze meg a kezelőfelület dokumentációjában. Vagy használja a WP-CLI-t: wp cron event run --due-now. Utólag ellenőrizze a Webhely Egészségben, hogy nincsenek-e lemaradt ütemezett feladatok.

Heartbeat és az admin felület

A WordPress admin felülete, amíg nyitva van, 15 és 60 másodperc között folyamatosan kommunikál a szerverrel (a Heartbeat): az automatikus mentéshez, hogy jelezze, ha valaki más szerkeszti ugyanazt a bejegyzést, és az értesítésekhez. Ha tíz böngészőlapot nyitva hagy az admin felülettel egész nap, az több ezer kérést jelent. Zárja be a lapokat, amelyeket nem használ. Egyes gyorsítótár bővítmények lelassíthatják a Heartbeatet; a teljes kikapcsolása nem szükséges, és megszakítja az automatikus mentést.

Összefoglalás

• Az oldalgyorsítótár után: képek, PHP-verzió, külső elemek és bővítmények, adatbázis, cron. Mérjen előtte és utána, egyszerre csak egy lépést végezzen el.
• Lusta betöltés mindenre, kivéve a legfelső nagy képet; az inkább fetchpriority="high" attribútumot kapjon.
• Egy újabb PHP-verzió ingyenes sebességnövekedést jelent, feltéve, hogy a bővítmények kompatibilisek.
• Tisztítsa meg a változatokat, a tranziens adatokat, a spamet és a nagy autoload-adatokat, mindig biztonsági mentéssel.
• Állítsa a WP-Cront valódi cronjobra a DISABLE_WP_CRON segítségével és egy feladattal a kezelőfelületen.

Kvíz

Feladat

A6.3 feladat: Lusta betöltés és méretek a kezdőlapon. Adja meg a weboldala címét. A program beolvassa a kezdőlapot, és megvizsgálja a képeket: nincs-e az első nagy képen loading="lazy" (és lehetőleg van-e rajta fetchpriority="high"), van-e lusta betöltés a lejjebb lévő képeken, és a képek mekkora része WebP vagy AVIF formátumú?

D6.3 feladat: Előtte és utána. Mérje meg weboldala egy oldalát háromszor a PageSpeed Insightsban (mobil nézetben), és jegyezze fel a középső LCP, INP (vagy a labor-adat Total Blocking Time értéket, ha nincs mezőadat), CLS és az A6.1 feladatból a TTFB értékeket. Ezután hajtson végre egy fejlesztést e leckéből (képek, PHP-verzió, egy külső elem eltávolítása, adatbázis rendbetétele vagy valódi cron). Mérjen újra háromszor, és jegyezze fel az új értékeket. Írja le, mit tett, és hogy a különbség nagyobb-e, mint a mérések közötti szokásos ingadozás.

További olvasnivaló

Ezek a cikkek a WebOké kezelőfelületein végrehajtandó lépéseket írják le; más kezelőfelületeken hasonlóan működnek.

• DirectAdmin útmutató 14.1: A PHP-verzió kiválasztása (Select PHP version)
• DirectAdmin útmutató 12.7: Adatbázis ellenőrzése, javítása és optimalizálása
• DirectAdmin útmutató 15.1: Időzített feladatok: feladatok automatikus futtatása
• Cronjob vagy ütemezett feladat létrehozása (és mi a teendő, ha nem fut le)
• DirectAdmin útmutató 17.4: X-Ray: lassú oldalak felderítése
• A WP-Cron összekapcsolása a rendszer cronjával (developer.wordpress.org, angol nyelven): https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/
• Lusta betöltés és LCP (web.dev, angol nyelven): https://web.dev/articles/lcp-lazy-loading