Érkezett egy felkérés, hogy egy autó szerviz oldalára szeretnének egy blogot. Mondtam, hogy persze semmi akadálya, de először szeretném felmérni az oldalt. Meg is kaptam a hozzáférést a tárhelyhez. Első körben nem is a tárhelyet néztem meg, hanem magát az oldalt. Kíváncsi voltam, hogy milyen állapotban van függetlenül attól, hogy milyen technológiával van összeállítva az oldal. Tanulságos történet következik az optimalizálás fontosságáról.
TLDR;
- Használjunk loading="lazy" tag-et a képeken!
- Használjunk WebP-s képeket!
- Méretezzük eszköznek megfelelően a képeket!
- Optimalizáljuk a Youtube videók betöltődését! Kerüljük a direktbe beágyazásukat az oldalakon!
- Kerüljük a direktbe beágyazott Google Térképet!
- Használjuk a h1 taget!
- Legyen kitöltött meta="description"!
- Kerüljük a meta="keywords" használatát! 2009 óta deprecated a Google számára.
- Ami jó, azt tartsuk meg!
Az oldalt megnyitva böngészőben, majd a Chrome DevTools/ Network fül felnyitásakor már elszörnyülködtem. Minden, az oldalon lévő kép egyből betöltődött, és némelyik kép 3MB-os PNG volt. A főoldal megnyitásának teljes adatforgalma 30MB volt.
Lehetne erre legyinteni, amikor olyan világot élünk, hogy a 60GB-os játékfrissítésekre már fel se szisszenünk, mikor az okosórákra 1,5GB-os frissítés érkezik, és már kezd eléggé elterjedni a korlátlan mobilinternet-hozzáférés is. Azonban én úgy gondolom, hogy az egyik legfontosabb szabályt mindig tartsuk be fejlesztőként: ne bántsuk a felhasználót! Különösen akkor ne, ha egyébként technológiailag könnyen elkerülhető. Több megoldás együttes használatával éltem végül, mindegyik natívan támogatott a böngészők által.
Lassan tölts tovább élsz
A képekre tettem egy loading="lazy" tag-et, így a böngésző végzi el azok betöltését. A loading="lazy"-ről 3 éve még azt írtam, hogy ráérünk még annak bevezetésére, de 3 év alatt annyira elterjedt a támogatottsága, hogy kb csak a régi Internet Explorer-ek nem támogatják már csak, azt meg mobilon nem használják, desktopon meg korlátlan a sávszélesség szóval ott nem jelent problémát. Így bátran lehet alkalmazni, és már nem szükséges mindenféle Javascriptes Intersection Observer megoldással trükközni.
Mi az a lazyload?
Ha még sose hallottál erről a nagyszerű funkcióról, akkor röviden bemutatnám neked, hogy miről is van szó.
Amikor egy weboldalt megnyitunk – normál esetben – az összes létező tartalom egyszerre töltődik be. Még az is, ami nincs a képernyőn, nincs a látóterünkben. Ez hatalmas optimalizálatlanság, hiszen arra kényszerítjük a klienst, hogy olyan dolgok letöltésére pazarolja az erőforrásokat, amik lehet, hogy nem is kerülnek kirajzolásra a képernyőn.
Okostelefonokon különösen problémás, ha mindent egyszerre akarunk betölteni, hiszen ezzel felesleges adatforgalmat generálunk, ezzel csökkentve a mobiltulajdonos felhasználható mobilinternet keretét. Ezért találták ki az úgynevezett lazyload-ot, ami csak azt tölti be, ami a képernyőre kirajzolásra is fog kerülni. A gyakorlatban ez úgy néz ki, hogy amikor a felhasználó görget az oldalon, a görgetés hatására bizonyos számú elemet előtöltünk az oldalon. Így mire a felhasználó oda ér a görgetésben, addigra már betöltésre kerüljön az adott elem.
Ez azért is jó, mert előfordulhat, hogy a felhasználó nem fogja végig görgetni a teljes oldalt, és ilyenkor teljesen felesleges betölteni a képernyőn kívüli képeket.
WebP: Gyorsaság és minőség kompromisszumok nélkül
Optimalizálást azzal értem még el, hogy átalakítottam WebP-re a képeket és természetesen a PNG-s képeket is optimalizáltam JPG-re. A WebP is eléggé elterjedt formátum manapság, sőt már mondhatni őskövületnek számít, hiszen már itt az AVIF képformátum, ami éppen feltörekvőben van.
Mi a WebP? A WebP egy képformátum, amelyet a Google fejlesztett ki, és a JPEG, PNG és GIF formátumok alternatívája. A WebP célja, hogy kisebb fájlméretben tárolja a képeket a weboldalakon, miközben megtartja a képek minőségét, vagy akár javítja is. Nagyjából röviden ennyi, a technikai részének is utána lehet olvasni, a lényeg: hogy azonos képminőség mellett kisebb méretű képet eredményez. Ez mindenképp örvendetes
A WebP-nél azonban felmerült, hogy legyen egy fallback JPG verzió is, ha esetleg valamiért mégsem lenne támogatott a böngészőben, de mint a lenti képen látszik azért eléggé széles körben támogatott. Kicsi az esély rá, de ebben az esetben úgy gondoltam, hogy főbb az óvatosság. Elvégre az nagyon rossz, ha nem töltenek be a képek egy oldalon valamilyen okból kifolyólag.
Ehhez pedig a picture HTML tag-et használtam, ami egy nagyon sokoldalú elem, és egyből két felhasználását is meg tudom mutatni nektek.
Ha felhasználó böngészőjében támogatott a WebP formátum, akkor betöltjük, ellenkező esetben marad a JPG verzió:
<picture>
<source type="image/webp" srcset="[WEBPKÉPURL]">
<img src="[JPGKÉPURL]"
alt="[KÉPLEÍRÁS]"
loading="lazy">
</picture>
Ilyenkor a böngésző automatikusan betölti a source-ból a megfelelő képet, és mindezt úgy, hogy az img tagen lévő attribútumok megmaradnak, tehát lazy loadinggal a megfelelő alt leírással és CSS szabályokkal.
A másik lehetőség, hogy ha szeretnénk mobilon és desktopon eltérő méretű képeket megjeleníteni. Például hero bannernél vagy galériánál mobilon felesleges betölteni az eredeti, akár 2000x3000 pixeles képet, viszont desktopon meg nem nézne ki jól egy 300x300-as méretű pixeles kép felnagyítva. Ezért lehetőség van breakpointokat beállítani, és az annak megfelelően betöltendő képet meghatározni.
<picture>
<source type="image/webp" srcset="[DESKTOPOSNAGYKÉPURL]" media="(min-width: 600px)">
<source type="image/webp" srcset="[MOBILOSKISKÉPURL]" media="(max-width: 600px)">
<source type="image/jpg" srcset="[DESKTOPOSNAGYKÉPURL]" media="(min-width: 600px)">
<source type="image/jpg" srcset="[MOBILOSKISKÉPURL]" media="(max-width: 600px)">
<img src="[JPGKÉPURL]" alt="[KÉPLEÍRÁS]" loading="lazy">
</picture>
Mint látható 600px képernyő szélesség alatt a mobilos kisképet (media="(max-width: 600px)"), míg felette a nagy képet töltöm be. Ezt kétszer kellett eljátszanom, hiszen van JPG és WebP verzió is. Ez most egy egyszerűbb megoldás, még egymillióféleképpen lehet ezt optimalizálni más-más breakpointokat alkalmazva, de már ez is sokkal jobb, mint korábban volt.
Mit sikerült elérnem ezekkel a megoldásokkal?
A főoldal, ami eddig 30MB-ot evett, most már teljesen betöltve 3,5MB-ot eszik, ami 88,4%-os adatforgalom csökkenést jelent.
Mint látható eddig semmilyen különösebb eszközt nem használtam, csak a böngészőt és a böngészők által támogatott HTML tag-eket, attribútumokat és képformátumokat.
Komolyabb ellenőrzésre a Google PageSpeed oldalt használom, amely bár eléggé szigorú és sok javaslatot nem is szoktam feltétlenül megfogadni, de azért ami piros, az eléggé problémás, és azzal foglalkozni szoktam. Az alábbi képen látszik az eredeti állapot:
Az egyetlen pozitívum, hogy a Cumulative Layout Shift 0 értéken van, tehát nem csúszkál az oldal betöltődés közben. Innen is nagy gratula 👏👏👏 az előző fejlesztőnek, ez tényleg szép eredmény, mindenféle irónia nélkül mondom ezt.
A többi mérőszám viszont eléggé lehangoló volt, 12,9mp-es FCP, 88,3mp LCP. Igaz ezek szigorúan vett, rossz 4G-s hálózatot, és egy lassú készüléket szimuláló feltételek mellett teljesülnek, azért a 41 pont mobilos teljesítménynél elég gyatra. Én nem vagyok annyira szigorú, és nem hajszolom a 100 pontokat, 90 ponttal megelégszem, de ez még az általam elvártnak is kevesebb, mint a fele volt. 🤯
Itt az elsődleges probléma az volt, hogy több külső bővítmény is megpróbált betöltődni. A főoldalon volt egy beágyazott Youtube videó, egy Google térkép és még a reCaptcha is be volt ide húzva.
A beágyazott Youtube videók árnyoldala
A Youtube videó oldalba történő direktbe beágyazását érdemes kerülni, mivel borzasztóan rányomja a bélyegét a mérésekre. Ezért inkább itt is használjunk lazy load megoldásokat.
Ezen az oldalon egy galéria lett volna eredetileg, ahol vegyesen lehet képeket és videókat feltölteni, végül gondolom teljesítménybeli problémák miatt lekerültek a képek és ez az egy videó árválkodott ebben a szekcióban. Mivel itt elegendő volt, csak a képet megjeleníteni és kattintásra nyílik fel egy galéria ahol elindítható a videó, ezért a következő megoldást használtam:
<img src="https://img.youtube.com/vi/[YYVIDEOID]/hqdefault.jpg" alt="[KÉPLEÍRÁS]" loading="lazy">
Ami itt trükkös volt az a YTVIDEOID meghatározása. A Youtube, Megosztás gombra kattintva kimásolható egy URL. Ezt kell az admin felületen egy input mezőbe bemásolni, a többi pedig regexekkel megoldható.
Így gyakorlatilag bármelyik videó borítóképéhez hozzáférhettek, ami nagyon jól jön, ha nem akarjátok a teljes videót megjeleníteni.
A Villamosbalesetek Miskolcon oldalon pedig egy ilyen megoldást alkalmaztam:
<iframe
class="youtube-video"
src="https://www.youtube.com/embed/LGyf0w4H860?si=q3lxBnU2NkBlBXtJ&autoplay=1"
srcdoc="<style>*{padding:0;margin:0;overflow:hidden}html,body{height:100%}img,span{position:absolute;width:100%;top:0;bottom:0;margin:auto}span{height:1.5em;text-align:center;font:48px/1.5 sans-serif;color:white;text-shadow:0 0 0.5em black}</style><a href=https://www.youtube.com/embed/LGyf0w4H860?autoplay=1><img src=https://img.youtube.com/vi/LGyf0w4H860/hqdefault.jpg alt='Borsod24.hu Podcast: Villamosbalesetek - Mi okozza a tömeges ütközéseket Miskolcon? (S02E03)'><span>▶</span></a>"
frameborder="0"
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen
title="Borsod24.hu Podcast: Villamosbalesetek - Mi okozza a tömeges ütközéseket Miskolcon? (S02E03)"
></iframe>
Ez már egy fokkal bonyolultabb, de lényegében arról van szó, hogy megjelenít egy képet rajta egy lejátszó nyilacskával. Amikor rákattintunk akkor tölt be a videó. Elméletileg az autoplay kapcsolóval el kellene automatikusan indulnia betöltést követően, gyakorlatban ez nem történik meg. Így a felhasználó kénytelen még egyet kattintani, ha el akarja indítani a videót, viszont az oldal teljesítményében nem okoz fennakadást, hogy 3 videó is be van ágyazva az oldalba.
A beágyazott Google Térkép mellékhatása
A beágyazott Google térképet először meghagytam az oldalon, mivel úgy gondoltam, hogy az túl sok vizet nem zavarhat. Nagyobbat nem is tévedhettem volna.
Bár a hibalista többi elemét sikerült a korábban említett képoptimalizálással orvosolni, mobilon az LCP (Largest Contentful Paint) értéke nem akart 75 pont fölé menni, ahogy az alábbi képen is látjátok. A riport szerint a hero banneren lévő első kép okozott problémát, túl nagy volt a megjelenítési késleltetése (render delay). Mivel nem volt egyértelmű, hogy mi okozza a problémát először a szolgáltatóra gondoltam, de azért elkezdtem debuggolni.
Miután több lehetséges megoldási javaslatot is végigpróbáltam (kép és CSS-ek előtöltése pl.) úgy gondoltam, hogy a riportban nagyon sok problémát jelzett a bent hagyott Google Térképpel kapcsolatban a PageSpeed. Végülis egy próbát megért - gondoltam magamban - és kiszedtem inkább az oldalról. Aztán futtattam egy mérést, és teljes döbbenet. Mobilon 98 pont a teljesítmény.
Így hát inkább lecseréltem a beágyazott Google Térképet egy fotóra, amire tettem egy linket, és természetesen a korábban említett optimalizálásokat is elvégeztem rajta.
Kereső optimalizálás
A teljesítmény problémák megoldása természetesen szintén a SEO része, ez a technikai SEO, de ez még kevés. Az ún. on-site SEO-t is érdemes rendbe tenni, ha szeretnénk, hogy az oldalunk jó helyezést érjen el a Google-ben.
A SEO ellenőrzésre többféle eszköz is rendelkezésre áll, én leggyakrabban a Seobility-t és az ahref-et használom. Előbbit kisebb projektekhez, mivel korlátozott az egy napon elvégezhető lekérdezések száma. Utóbbit pedig ha nagyobb projektek hosszú távon történő nyomon követésére szoktam alkalmazni.
Az alábbi képen a régi oldal Seobility értékelését láthatjátok.
Az 59% nem olyan rossz, nem olyan jó. Vannak ennél rosszabb pontszámmal rendelkező oldalak is, amelyek rendre a Google 1-2. helyén vannak bizonyos kulcskifejezésekre. A hibalista viszont eléggé ledöbbentett:
- nincs h1 az oldalon, ami pedig minimum lenne. A h1 legalább van olyan fontos, mint hogy az oldal megfelelően működjön.
- Nincs megfelelően átirányítva az oldal. Ez akkor szokott előfordulni, ha a www és nem www verzió nincsenek megfelelően átirányítva. Ilyenkor tartalom duplikáció miatt kannibalizálhatják egymást a keresőben.
- nincs meta description az oldalon, ami szintén elég nagy probléma. A keresők számára nagyon hasznos információkat és kulcsszavakat tudunk elrejteni ide.
Apropó, kulcsszó. Tudtátok, hogy meta="keywords" tag használatának már 2009(!!) óta nincs semmi értelme? 2009... amikor én még csak ismerkedtem a weboldal fejlesztéssel és mindenhonnan az jött, hogy ez a tag "fúúú te, hát ez nagyon fontos, ha ez nincs az oldaladon a Google-re sose fogsz felkerülni!".
A kis kitérő után a legfontosabb teendő tehát az volt, hogy minden oldalra kerüljön h1 tag, meta description. A képeknél nálam már alap, hogy mindegyik kap alt tag-et, valamilyen szöveggel. Ebbe is rengeteg kulcsszót el lehet rejteni, így természetes, hogy használjuk. Valamint a 301 redirectet is orvosoltam, én ezt a kódot szoktam bemásolni a .htaccess fájlomba, de cPanelen vagy a tárhely admin felületén is biztosan van erre megfelelő mód.
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{HTTPS} on
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
A Page structure résznél volt még említve egy hiba, hogy kevés a belső link, ezt egy kis átszervezéssel tudtam orvosolni. Létrehozásra került egy szolgáltatás lista oldal, valamint tartalmi oldal, ahol részletesebben, akár árlistával ellátva tudják ismertetni a szolgáltatásokat. Breadcrumb-ok kerültek elhelyezésre, így az ismertető oldal visszalinkel a lista oldalra, ezáltal erősítik egymást.
Továbbá az azonos kategóriájú bejegyzések aljára elhelyeztem, egy előző és következő posztra mutató linket, ezáltal a közöttük lévő kapcsolatot tudtam erősíteni.
A végeredményt pedig az alábbi képen láthatjátok:
Az oldallal egyébként voltak egyéb problémák is, például a mobilos legördülő menü csak a főoldalon működött, ami azért elég kellemetlen. A Kapcsolati űrlapon hiába volt reCAPTCHA nem működött megfelelően, és a modalos megjelenítése eléggé fura volt. Ezért egy külön oldal alá raktam, kapott némi validációs védelmet és honey pot fieldet, amivel azért nagyszerűen, különösebb erőforrás nélkül megfoghatók a botok.
A régi jó dolgokból nem marad semmi?
Az oldallal bár számos probléma volt, egyetlen egy dologhoz mégsem nyúltam, ez pedig az oldal megjelenése. Megítélésem szerint teljesen rendben volt, és teljesen reszponzívan működött, aminek 2025-ben nem kellene újdonságnak lennie, ám még mindig vannak olyan oldalak, ahol ez nem jellemző. Sok átalakítást végeztem az oldalon, sőt kompletten új alapokra helyeztem, ennek ellenére a designhoz nem nyúltam. Annak ellenére, hogy TailwindCSS volt használva, amit eddig nem ismertem, mert én inkább a Bootstrap-et preferálom. Első gondolatom persze az volt, hogy nyilván átírom az egészet Bootstrapesre, de inkább szántam egy kis időt a Tailwind megismerésére, és végül a megtartása mellett maradtam. Úgy gondolom, fontos felismerni egy oldal értékeit, és azokat megtartani.
A bejegyzés eredetileg a hydroxy.hu blogon jelent meg 2025.05.29.-én.
Top comments (0)