
Napjainkban, főleg az EU határain belül központi kérdéssé vált a személyes adatok védelme. Ez a mesterséges intelligencia térhódításával egyre inkább így lesz. Egyrészt azért, mert ma már az információ önmagában is nagy értéket képvisel, másrészt a folyamatosan fejlődő algoritmusok, számunkra érdektelen információ morzsákból olyan következtetésre jutnak, melyet nem biztos, hogy akárkivel meg szeretnénk osztani. 2024 márciusában egy új időszak kezdődött, amikor életbelépett a digitális piacokról szóló uniós jogszabály (DMA), ennek egy következménye a Google adatvédelmi hozzájárulási nyilatkozat módosítása a **Google Consent Mode v2**, mely további beállításokat tesz szükségessé. A cookieinformation.com 4000 skandináv weboldal tesztelését követően arra a következtetésre jutott, hogy 74%-uk nem jól alkalmazza a Google Consent Mode v2-t. 

## Mi a Google Consent Mode v2?
A fent említett jogszabály az interneten kapuőrként azonosított vállalalatokat azonosítja különböző paraméterek mentén és szabályozza azok adatgyűjtési és felhasználási jogköreiket. Dióhéjban a kapuőr vállalatok, azok, akiket gyakorlatilag nem lehet megkerülni, amikor valaki internetezik, ilyen pl. a Google és a Meta. Egy korábbi jogszabály értelmében a felhasználókat informálni kell arról, hogy milyen adatokat kezel a weboldal és üzemeltetője, ehhez hozzájárulást kell kérni és biztosítani kell a felhasználó számára, hogy tárolt adatait bármikor törölhesse. 

> Ha ezek nem biztosítottak az Ön weboldalán kerressen, segítek!

A Consent Mode v2 annyiban különbözik, hogy kiterjedt azon adatok és feldolgozási módok köre, mely a szabályozás hatálya alá tartozik, ezáltal külön jóváhagyást kell kérni a felhasználótól.

## Miért fontos, hogy a weboldalam jól alkalmazza?
Ha én nem vagyok kapuőr, akkor miért kell ezzel foglalkoznom? Azért mert a google nem kockáztat és csak azokat az adatokat dolgozza fel, amiről megbizonyosodott, hogy hozzájárult a felhasználó. Ez azt jelent, hogy aki nem, vagy nem jól alkalmazza a Google Consent mode v2 módosításait, az március végétől nem jut hozzá bizonyos adatokhoz, szolgáltatásokhoz, mint például a Google Ads személyreszabott hirdetések.

## Leggyakoribb hibák
Első és legfontosabb, hogy ha nincs fejlesztői kapacitás a cégénél, célszerű az egyedi megoldások helyett a megbízhatót választani. Léteznek úgynevezett ellenörzött hozzájárulást kezelő platformok (CMP), melyek kész megoldást biztosítanak a hozzájárulás-kezeléshez. Ezen megoldások, biztosan megfelelnek az előírásoknak, sokuknak van WordPress, Joomla modulja a könnyebb beépítás kedvéért, egyesek még arra is képesek, hogy megnézzék, hogy milyen sütiket használ az oldal, melyeket bekategorizálnak és a megfelelő adatkezelési szabályzat bekezdést legenerálják. Hátrányuk, hogy a legtöbb csak korlátozottan testreszabhatók és nem ingyenesek.

Ha mégis az egyedi megoldás mellett dönt, a következőkre érdemes figyelni:

### Kiinduló beállítás
A consent mód támogatásának indításakor el lehet küldeni a kiinduló beállítást, melyet alapértelmezettnek állít be a weboldal első látogatáskor. Ezt, hogy a legalitás talaján maradjunk úgy kell beállítani, hogy nem járul hozzá semmihez a felhasználó. Minden az elfogadó nyilatkozatot megelőző süti elhelyezése sérti az EU-s rendelkezéseket. Ezzel a kóddal lehet közölni a Googlellel, hogy ne helyezzen el sütit, amíg a felhasználó nem nyilatkozott.

```
gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied'
});
```

### Előre beállított válaszok
Személyes adatokat tartalmazó cookie-k beállítása nem lehet alapértelmezetten jóváhagyott állapotban a párbeszédpanelen. A weboldal használatához szükséges cokkiek elfogadása - ezek szintén nem tartalmazhatnak személyes adatokat - lehet rögzítetten elfogadott állapotban.

### Weboldalunk sütiket használ üzenet
Amennyiben az oldalon csak ennyi áll, hogy weboldalunk sütiket használ és alatta egy rendben gomb, elfogadott metódus abban az esetben ha a weboldal csak az oldal használatához szükséges, személyes adatokat nem tartalmazó cookiekat használ.

### Hozzájárulás módosításának lehetősége
Ugyancsak kötelező elem a weboldalon egy link/gomb a hozzájárulások módosítására.

### Felhasználó akadályozása
Ugyancsak gyakran elkövetett hiba, de az EU regulációkkal ellentétes, hogy a felhasználót megakadályozzuk abban, hogy használja az oldalt, elolvassa a cikket, amíg nem nyilatkozott arról, hogy hogyan rendelkezik személyes adatai kezeléséről.

### Csak a Google szolgáltatásaira vonatkozik
A Google által biztosított megoldás, csak a saját termékei viselkedését befolyásolja, nincs hatással más szolgáltatók cookie kezelésére, ezért nagyon fontos, hogy a válaszokat tároljuk és annak megfelelően kontrolláljuk más szolgáltatók mint például a Meta Pixel kódjait. Ez Google Tag Managerben könnyedén megvalósítható, egyedi megoldásoknál viszon külön feltételeket kell betenni a weboldal forráskódjába.

### Nem működik a beállítás
A Goolge igyekezett megkönnyíteni a dolgát az oldaltulajdonosoknak, ezért létrehozott egy külön fület a [Tag Assistantben]( https://tagassistant.google.com/) a Consent Mode beállítások ellenőrzéséhez, a funkció tesztelésére. Érdemes ezt megtenni nemcsak a modul létrehozásakor, hanem bizonyos rendszerességgel, leginkább akkor, amikor módosítás történt a weboldalon, ugyanis a böngészőben futó úgynevezett JavaScript kódok (ilyen a Google Tag is) hibás működés esetén gátolhatják egymás lefutását. Bővebben a Tag Assistan használatáról itt olvashat: [https://support.google.com/tagmanager/answer/14218557](https://support.google.com/tagmanager/answer/14218557)

### Összegzés
Bár vannak a sütikezelés hozzájárulásának kezelésére kész megoldások az interneten, olykor igény lehet arra, hogy egyedi megoldás kerüljön a weboldalra. Ez sem lehetetlen kihívás, a Google minden segítséget megad ehhez a megoldáshoz, de a fent említett pontokra érdemes külön odafigyelni, mert könnyen előfordulhat, hogy egy-egy nem engedélyezett megoldás miatt vagy kötelező elem kihagyásának következtében a weboldal nem lesz GDPR kompatibilis.



Weboldalak 74%-a nem jól alkalmazza a Google Consent Mode v2 módosításokat


Az alapvető webes vitális (Core Web Vitals) mutatók alatt olyan méréseket értünk, mely összességében a weboldal használhatóságát és a felhasználói élményt mutatják. Négy nagy témakör van: sebesség (performance), hozzáférhetőség (accessibility), legjobb fejlesztői szokások, praktikák (best practices), keresőoptimalizálás (SEO).

Ezen ajánlásoknak való egységes megfelelés adja azt a böngészési élményt a felhasználónak, ami minőségi érzést és ezzel együtt biztonságot is jelent számára. Végeredményben több kattintás, jobb konverziós ráta, több megrendelés érhető el egy olyan oldallal, ami megfelel a vitális paramétereknek, mint azzal, ami egyáltalán nem.

A jelentés nagyon szakmai, de konkrét problémákra, konkrét megoldásokat javasol, mely nagy segítség a fejlesztőknek. Szerencsére számokkal és színekkel egyértelmű visszajelzést ad ahhoz, hogy weboldal tulajdonosok is tudják ha fejleszteni kell a weboldalukon. Zöld, ha rendben van, sárga, ha fejlesztésre szorul, piros az egyáltalán nem felel meg.  Jelen írás célja az, hogy weboldal tulajdonosoknak is legyen egy fogalmi képük arról mit is láthatnak itt.

## Mérés indítása

Többféleképpen futtathatjuk le a Lighthouse reportot. Google Chrome böngészővel, a Google Measure page quality oldalon, vagy a Google [PageSpeed Insights](https://pagespeed.web.dev/) használatával (ez gyakorlatilag a lighthouse report sebesség mérése, csak kiegészítve a Google Chrome böngészők által küldött adatokkal, de egy átlag magyar céges weboldalnál ez a hozzáadott érték nem nagyon látszik, mert egy bizonyos oldalmegtekintés után egészíti ki a jelentést a Google.)

**Lighthouse report futtatása**

Google Chrome böngésző használatával, privát böngésző ablakban (CTRL+SHIFT+N) navigáljunk a mérni kívánt weboldalra, majd a mérést az F12 gomb lenyomásával és a megjelenő fejlesztői ablakon a Lighthouse tabon a “Generate report” gombra kattintva futtathatjuk.

**Google Measure page quality**

A [https://web.dev/measure/](https://web.dev/measure/) weboldalon a bevitelimezőbe be kell írni a mérni kívánt weboldal címét, majd a “run audit” gombra kattintani.

**Google** [**PageSpeed Insights**](https://pagespeed.web.dev/)

A [https://pagespeed.web.dev/](https://pagespeed.web.dev/) weboldalon a bevitelimezőbe be kell írni a mérni kívánt weboldal címét, majd a “run audit” gombra kattintani.  


## Sebesség

Erre a mérésre teljes mértékben igaz, hogy egy mérés nem mérés. A weboldal megjelenítésekor a kiszolgáló szerver vagy szerverek bizonyos program kódokat és fájlokat gyorsítótárba helyeznek, mely egyes része a memóriában, más a fizikai meghajtóban van. A gyorsító tár pár perc alatt elévül, ezért főleg ritkábban látogatott weboldalakon az első mérés közben a kiszolgáló szervereknek újra fel kell azt tölteniük, ezért a mérést érdemes 2-3 alkalommal lefuttatni kielemzés mielőtt.

Fontos továbbá kiemelni, hogy az interneten kering, hogy hány másodperces oldalbetöltésnél hány vásárlót veszít, ami részben igaz is lehet bizonyos esetekben, viszont ennél a mérésnél az oldalbetöltési sebességet 3G-s mobilinternet kapcsolattal mérik, ami ma már - főleg a vásárlóképes felhasználókat nézve - nem tekinthető átlagnak.

Az adatok vizsgálatakor 4 mérőszámra érdemes rápillantani:

**First Contentful Paint**

Ennyi idő telik el, amíg a felhasználó már valami értelmezhető szöveget lát a weboldalon.

**Time to Interactive**

Ez az az időmennyiség, ami ahhoz kell, hogy a látogató már tudja is használni az oldalt - kattinthatók a gombok.

**Largest Contentful Paint**

Ennyi időbe került, míg a legnagyobb elem az oldalon - lehet ez kép vagy szöveg - teljesen láthatóvá válik.

**Cumulative Layout Shift**

Betöltéskor és a weboldal használatakor mennyire jellemző, hogy az oldal ugrál fel, le. Nagyon fontos mérés, mert ezt a google külön nézi, amikor a weboldalakat rangsorolja.

#### Túl nagy kép kis helyen!

Lejjebb görgetve a lehetőségek felsorolásánál találkozhatunk olyan megjegyzéssel, hogy alkalmazzon helyesen méretezett képeket (Properly size images). Sok weboldal esetén itt lehet lefaragni a legtöbbet az adatforgalomból, mert gyakran előfordul, hogy egy kis dobozba egy teljes képernyő méretű kép kerül, pl blog lista oldalon a cikk főképe méretezés nélkül, de az is probléma ha mobilon az asztali gépre szánt képet jeleníti meg a weboldal.

## Hozzáférhetőség

Ami itt fontos az, hogy a háttér és a szöveg megfelelő kontraszttal különüljön el, és ha szolgáltat a weboldal képernyőolvasók számára különleges információt, akkor azt helyesen tegye. Valamint a linkeknek legyen értelmes szövege és a képek alternatív szövege.

## Legjobb szokások, praktikák

Na itt érdemes még nyitva tartani a szemet, mert olyan információk kerülnek itt napvilágra, mint például ha a weboldal tartalmaz olyan előre megírt javascript kódokat, melyek biztonsági kockázatot jelentenek és hogy van-e javascript hiba az oldalon. Ez utóbbi bizonytalan funkcionalitást vagy nem megfelelő megjelenést eredményez. Mindkettő kritikus probléma akár lehetetlenné is teheti a konverziót (kapcsolatfelvételt, megrendelést).

## SEO

Az érték, amit érdemes 100/100ra felhozni. Itt az alapvető keresőoptimalizálási megoldások meglétét ellenőrizhetjük, bővebb SEO elemzésre nem megfelelő ez az eszköz, de ezen megfelelések nélkül hiába a jó SEO stratégia.

## Összegzés

Ezeken után talán nem kérdés, hogy egy weboldal audit során, miért játszik fontos szerepet az alapvető vitális mutatók elemzése. Legyen szó új weboldal készítéséről, meglévő tovább fejlesztéséről, de nagy visszafordulási arány és a vártnál rosszabb konverziós számok esetén is érdemes erre a jelentésre ránézni. Weboldal tulajdonosként tisztán láthatja, ha valami probléma van, weboldal fejlesztője részletes tájékoztatást kap a hiba elhárításához.

Milyen a jó weboldal a Google szerint


Penge öltöny, budapesti iroda, megnyerő beszéd és egy jó designer. Ez a receptje ma egy magyarországi “média vállalatnak”, ahonnan egy nap érkezik a telefonhívás, hogy “**szuper weboldalt készítünk cégének**”. Minden megy is a maga útján még talán időben el is készül az ígért marketing csoda, de valahogy a végeredmény nem nyújtja a minőség érzését. Akár ez is lehetne az első jele annak, hogy valami baj van.

Vannak viszont **mérhető paraméterei egy weboldalnak**, melyek felfedik a valóságot. Ebben az írásban igyekszem közérthető módon átadni a legfontosabb tényezőket, amiket vizsgálok, mikor megnyitom a felületet, ami ma gyakorlatilag a vásárlóközönség számára az, ami a nőknek egy férfi cipője - ha nincs szóba sem áll vele, ha van de koszos, szakadt, akkor elmenekül.

## 1\. Nincs SSL a weboldalon

Ezt talán a legegyszerűbb ellenőrizni, hiszen a mai modern böngészők mindegyike jelzi ezt valamilyen módon a látogatók számára. Nem véletlenül, ugyanis ennek hiánya egyes esetekben **komoly biztonsági kockázat**, és ami a legfontosabb, hogy ez az, amit ma egy valamire való tárhelyszolgáltató ingyen, sőt automatikusan biztosít ügyfelei számára, tehát ha a weboldalán mégsincs ilyen, az komoly hanyagság, vagy hozzá nem értés jele.

### Hogyan látszódik ez az információ?

Egyszerűen be kell írni a böngészőbe a weboldal domain nevét www-vel, vagy anélkül és felül jelzi egy kis lakattal a böngésző az SSL meglétét és állapotát. Edge és Chrome böngészők ki is írják, hogy “Nem biztonságos”, ha baj van, a Firefox csak pirossal áthúzza a lakatot.

![nincs ssl](nossl.png#272x155)

## 2\. Nem mobilbarát az oldal

2012 óta, az **első mobilbarát weboldalak** megjelenése óta már sok víz lefolyt a Dunán, mégis találkozok a mai napig olyan weboldalakkal, melyek nem megfelelően jelennek meg mobilon, esetleg egyáltalán nem “**responsive**” (képernyő méretéhez igazodó megjelenítési forma.

Ezt egyszerűen egy mobiltelefonnal láthatjuk, ha kilógnak az elemek a képernyőből, vagy pontosan ugyanazt látjuk mint az asztali böngészőn csak épp nagyon piciben vagy csak egy részletét a teljes weboldalnak..

## 3\. Javascript hibák

A javascript az a programnyelv, melyet a böngészők maguk le tudnak futtatni bármilyen kiegészítő nélkül. Majdnem **az összes weboldalon van már hosszabb, rövidebb javascript kód** különböző céllal. Ha ezekben a kódokban hiba van, az **kihathat a teljes weboldal működésére** - vagy valami nem megfelelően jelenik meg, vagy egy vagy több funkció nem működik.

### Hogyan ellenőrizhető, hogy van-e javascript hiba az oldalon?

Régebben a böngészők ezeket a problémákat külön jelezték jól látható formában, ma már sajnos minden fejlesztéssel és az oldal technikai állapotával kapcsolatos információk elköltöztek egy rejtett részre az úgynevezett fejlesztői konzolra/eszközre. Ez is lehet egy oka annak, hogy ma olyan sok a rossz minőségű weboldal, hogy nincs azonnali, jól látható hibajelzés.

A legegyszerűbb módja a javascript hibák ellenőrzésének az, ha megnyomjuk az F12 gombot, ez minden böngészőben egységesen a **fejlesztő konzol** nyitó gombja. A megjelenő panelen jellemzően alul találunk egy olyan részt, hogy “Console”, ami tartalmazza ezeket a hibaüzeneteket. Anélkül, hogy belemennék a részletekbe, ha itt bármilyen piros színű szöveget talál baj van.

![javascript hibák](jserror.png#848x301)

## 4\. Hibás kép hivatkozás (broken image)

Ezt többféleképpen is lehet értelmezni: vagy hibás a kép, amire a weboldal kódja hivatkozik, vagy maga a hivatkozás nem jó - nincs ott a kép, elütés van a nevében vagy az elérési útvonalban. Sajnos ez sem mindig látványos hiba, mert ha például egy elem háttérképéről van szó, akkor nem jelzi külön a böngésző, hogy valami hiba lenne a megjelenítésben, és az is lehet, hogy a megjelenés is olyan, mint az előzetesen elfogadott design tervben, csak épp valamilyen előre elkészített sablonnal dolgozott a weboldal építője, amiben ott volt egy kép, de nem sikerül a kódból eltüntetni.

Ez is csak a fejlesztői eszközök ablakban ellenőrizhető (F12), akár a lenti consoleban is jelzi vagy az úgynevezett “Network” tabon, ahol a hálózati forgalom tekinthető meg, jelenik meg pirossal minden olyan elem, amit valamiért a böngésző nem tudott letölteni.

![hibás képhivatkozás](brokenimage.png#792x117)

## 5\. Túl nagy képek kis helyen, vagy fordítva

Nyilván az utóbbi eset könnyebben észrevehető, ugyanis a nagyítás következtében a kép “pixeles” (konyhanyelven kockás) lesz. Míg ez csak csúnya, addig a másik eset - amikor túl nagy kép került egy hozzá képest jóval kisebb tartalmi dobozba - nagyobb probléma a megnövekedett **felesleges hálózati adatforgalom** és ezzel együtt a **hosszabb weboldal betöltési idő** miatt. Ma már jellemzően elég nagy adatforgalomra alkalmas mobil internet csomagokat ajánlanak a mobil szolgáltatók, ettől függetlenül egy mobilos weboldal látogató nem fog örülni, ha egy 128x72 pixeles kockában egy HD kép (1920x1080) kerül 2-3 MB méretben.

Ugyancsak nyomjuk meg az F12 billentyűt és a fejlesztő eszközben a “Network” tabon látható a weboldal megjelenítéséhez szükséges adatforgalom (Transferred) és a teljes weboldal mérete (resources). Egy egészséges weboldal nem nagyobb 5MB-nál, de már ennél a méretnél is lehet gyanakodni, hogy baj van, főleg, ha nincsenek nagy média elemek a designban és nincs teletűzdelve képekkel a tartalom.

Tételesen és pontosan ezt a problémát az úgynevezett Core Web Vitals analitika mutatja meg. Bővebben a Core Web Vitals-ról, melyben kitérek a túl nagy képekre is itt írok: [Milyen a jó weboldal a Google szerint](/posts/milyen-a-jo-weboldal-a-google-szerint)

## 6\. Alapvető webes vitális pontszámok nagyon alacsonyak

A Google Core Web Vitals, vagyis alapvető vitális mutatók 2021 augusztusa óta része a google rank megállapításnak, vagyis ha ezeknek a méréseknek, **ajánlásoknak nem felel meg a webolda**l, akkor azt azzal a bünteti a **keresőmotor**, hogy **hátrébb sorolja** a találati listájában.

Ugyanakkor az, hogy nincs minden mutató a zöldben az alkalmazott technologiától (pl WordPress, Jooomla esetén külön kiegészítőkkel érhető ez el) és a fejlesztésre szánt költségkerettől is függ.

Ebben az írásban részletezem, hogy melyek azok a legfontosabb információk, amit weboldal tulajdonosként érdemes megnézni és mit jelentenek. [Milyen a jó weboldal a Google szerint](/posts/milyen-a-jo-weboldal-a-google-szerint)

## 7\. favicon nincs vagy a standard jelenik meg 

A favicon az a kis ikon, ami megjelenik a böngésző fülön az oldal címe mellett. Az elmúlt évben ez a korábbinál is nagyobb jelentőséget kapott, miután a google a kereső találati oldalon is megjeleníti azt. Alapesetben egy 16x16 pixeles képről beszélünk, nem nagy munka bármit odatenni, leginkább a hiánya, vagy a rendszer alapértelmezett favicon megjelenése mutatja a fejlesztő odaadását a minőség iránt.

Itt láthatóak az alapértelmezett faviconok, melyek érdemes azonnal cserélni:

![alap faviconok](favicons.png#60x16)

## 8\. Nem frissül automatikusan a wordpress/joomla, nem mutatta meg a fejlesztő hogyan kell frissíteni

Ezen kívül nem hívta fel a figyelmet a fejlesztő az ilyen rendszerek **biztonsági kockázat**aira, ami leginkább akkor merül fel, ha az alaprendszer vagy a moduljai **nincsenek rendszeresen frissítve**.

Szerencsére a **WordPress**, **Joomla** azonnal jelzi, ha érhető el **frissítés**, bár én már találkoztam olyannal, aki úgy adja át a rendszert, hogy kikapcsolja ezt a funkciót, egyszerűen azért, mert olyan minőségi munkát végez, ami a frissítéssel tönkremegy és erről természetesen nem tájékoztatja az ügyfelet, ami véleményem szerint kimeríti a csalás fogalmát.

## 9\. Alap cégbemutató weboldal, de tele van modullal

Ez abban az esetben fordulhat elő, ha előregyártott sablonnal dolgozott a fejlesztő, vagy hozzáértés hiánya miatt minden alapvető funkcióhoz külön modult telepített, mert önerőből nem tudta megoldani. Ez gyakorlatilag az a kategória, hogy jobb lett volna, ha a szomszéd fia csinálja meg a weboldalt sörért cserébe. Sajnos sokszor előfordul, hogy fejlesztők ezzel a módszerrel élnek, majd kiszámláznak egy akkora összeget mint azon konkurenseik, akik valóban fejlesztéssel foglalkoznak és minőségi munkát végeznek, Azért is problémás ez az eset mert minden egyes telepített modullal a WordPress, Joomla! rendszerek frissítése egyre nehezebb és a biztonsági kockázat egyre csak nő.

## 10\. Nincs analytics vagy más mérőkód az oldalon

Ma amikor már minden weboldallal foglalkozó szolgáltatónál alap hívószó, hogy ők **keresőbarát weboldalt** (**SEO weboldalt**) készítenek, de nem állítanak be látogató forgalmat és viselkedést mérő kódot az oldalba, amivel ez mérhető és optimalizálható lenne. Még akkor is, ha a weboldal tulajdonos nem érti, hogy ezen analitikákat hogyan kell értelmezni, akkor is érdemes beállítani, mert ez a további fejlesztések alapja és ez mutatja meg egy szakértőnek, hogy a weboldal készítése előtt felállított célt sikerült-e elérni, és ha nem, akkor min kell változtatni.

## +1 Adatkezelési nyilatkozat hiánya 

Bár ennek megléte alapvetően a weboldal tulajdonos felelőssége, ha a fejlesztő erre nem hívta fel a figyelmet az viszont az Ő rálátását, vagy felelős hozzáállását mutatja. 2016 április 27-e óta ugyanis nem lehet kint olyan weboldal, amin keresztül felhasználó személyes adatait gyűjtik - legyen az egy kapcsolatfelvételi űrlap, vagy Google Analytics mérés - és nincs rajta adatkezelési nyilatkozat. Ennek **hiánya komoly adatvédelmi bírságot vonhat maga után**.

10+1 jel, hogy kókler csinálta a weboldalad


Gyorsan betöltődő webhelyek, lenyűgöző felhasználói élmény és zökkenőmentes skálázhatóság - mindez elérhető a Jamstack segítségével. 

A **Jamstack weboldal**, pontosabban "weboldal architektúra tervezési minta" 2015-ben került a köztudatba a Netlify felhőszolgáltatónak köszönhetően. A következőkben azt igyekszem összegezni, hogy mi is ez a technológia, és hogy céges weboldalak esetében miért olcsóbb, gyorsabb és biztonságosabb megoldás, mint egy WordPress.

## A Jamstack felépítése
### J - JavaScript
Programnyelv, mely az internetes technologiák egyik alapja a HTML és a CSS mellett. Minden böngésző beépített javascript motorral rendelkezik és képes futtatni ezeket a kódokat.
### A - API
AlkalmazásProgramozási Interfész, ami azt jelenti, hogy ez egy olyan felület, melynek segítségével adatkommunikációt folytathatunk anélkül, hogy ismeretünk lenne a belső rendszer működéséről.
### M - Markup (leíró nyelv)
Jelen esetben ez maga a HTML. Az a kód, amit megjelenít a böngésző.

Összeolvasva egy olyan architektúráról beszélünk, melyben a megjelenítés úgy történik, hogy a szerver helyett a böngésző állítja össze a weboldal HTML kódját JavaScript programot futtatva, melyhez a megjelenítendő adatok egy vagy több API-n keresztül érkeznek és emiatt a megjelenítési idő elképesztően gyorssá válik.  

Még érthetőbben, a weboldal látogató böngészője, tehát a saját számítógépe dolgozik a szerver helyett.
## Gyorsaság
Mivel a weboldalt látogató saját gépe dolgozik a szerver helyett, az ilyen oldalak processzorigénye rendkívül alacsony - bizonyos alap weboldalaknál pontosan nulla. Minden olyan tartalom, ami nem dinamikusan változó adat (képek, stíluslap, HTML kód részletek, kód vázak) CDN-en keresztül érkezhetnek.
Aki meg akar erről bizonyosdni, kattintson párat ezen az oldalon, hiszen ez is egy Jamstack oldal.
> A CDN-ekről is tervezek írni, dióhéjban annyit érdemes tudni, hogy olyan tartalomszolgáltató hálózat, melynek egyik legnagyobb előnye, hogy sokkal gyorsabban töltődnek le róla a képek és más statikus tartalmak, mint egy átlagos tárhelyről. 

És, ha belegondolunk, mi az, ami egy céges weboldalban dinamikusan változó adat? A legtöbb esetben semmi, mert nincs benne hozzászólás funkció, nem jelenít meg tőzsdei, vagy más gyakran változó adatokat.

## SEO
A Jamstack architektúrában alkalmazott JavaScript keretrendszerek egy végletekig optimalizált HTML kódot generálnak, melyet a Google weboldal sebességellenőrzője a legmagasabb pontszámokkal jutalmaz. 
Azoknál a kulcsszavaknál, ahol nagy a konkurenciaharc, az optimalizált kód és a gyorsaság döntő szerepet játszhatnak.

## Biztonság
Tapasztalatom szerint a WordPress rendszerrel épített weboldalak egyik legnagyobb problémája az egyes modulok folyamatos frissítése, és annak elmaradása esetén a keletkezett biztonsági rések.
Alapeset, hogy valaki letölthető sablonnal dolgozik, ami feltelepít sok másik modult ahhoz, hogy működjön. A megrendelő az oldal átadását követően gyakran magára marad a frissítési kötelezettségével, egyedül kell szembenéznie olyan problémával, mint az egyes modulok és a WordPress verzióinak esetleges kompatibilitási ütközése. 

Vagy másik szerencsésebb esetben rendszeresen fizet egy informatikusnak, aki karbantartja weboldalát.
A folyamatos karbantartás vagy az elromlott, esetleg vírusos weboldal helyreállítása költséges.

Ha egy átlagosnak tekinthető céges weboldalt Jamstack metodikával építenek fel, akkor nincs mit megfertőznie a vírusoknak, ezen felül a túlterheléses támadások is olyanok, mintha a vizet ököllel ütögetnénk.

## Tárhely akár ingyen
Felhőszolgáltatások esetén lehetőségünk van olyan előfizetési csomagokat találni, mely weboldal méret vagy a legtöbb esetben forgalom alapján egy bizonyos mértékig ingyenes. 
Vegyük például a Google Firebase szolgáltatását, mely a cikk megírásakor az ingyenes csomagban 10GB tárhelyet ajánl napi 360MB adatforgalommal. Az egyedi, hogy ez mire elég, de összességében azt tudom mondani, ha már nem elég, akkor a weboldal termel annyit, hogy örömmel kifizeti bárki a nagyobb csomagot.

## Most akkor miért is érdemes váltanom Jamstackre?
Természetesen nem mindenkinek való ez a megoldás, de pár általános eset, amikor ajánlott mihamarabb lépni:
1. Önnek céges bemutatkozó oldala van (főoldal, pár aloldal, kapcsolatfelvételi lehetőség) és WordPresst használ, akkor ez a megoldás költséghatékonyabb.
2. Online jelenléte erősebb, hirdet vagy írásai jelennek meg nagyforgalmú weboldalakon.
3. Marketing landing oldala van.

Ami a legfontosabb, hogy tévhit az, hogy ha van egy WordPress weboldala egy olyan tárhelyen, ami brutto 20.000 Ft évente, akkor hátradőlhet. A karbantartás vagy annak elmaradása is költség a cégének, és lehet, hogy nem mondták Önnek, de ezek az alap tárhelycsomagok is forgalom-/teljesítménykorláttal rendelkeznek.

Ez a korlát általában akkor derül ki a weboldaltulajdonosok számára, amikor megosztják egy írását vagy megemlítik cégét egy nagyforgalmú oldalon, vagy nagyobb költségkerettel hirdet online.
Hirtelen megnő a látogatók száma, melyet a WordPress vagy más keretrendszer akkora terhelésnövekedéssel tudna kiszolgálni, hogy a tárhely egyszerűen automatán lekapcsol. 
Végeredményben a weboldala csak akkor nem lesz elérhető, amikor tényleg szüksége van rá.

## Összegezve
A Jamstack technológia kétségkívül egy újabb szint a weboldalak világában minőségben, teljesítményben, biztonságban és költséghatékonyságban egyaránt. Ezt a megoldást támogató szolgáltatások és az erre épülő megoldások ugrásszerű emelkedése mutatja, hogy a változás elindult.

Ugyanakkor ez a változás nem annyira látványos, mint annak idején a responsive webdesign volt, ezért az évek folyamán mindez csendben fog végbemenni, melynek az lesz az eredménye, hogy aki váltott, előrébb kerül a keresőmotorokban, nagyobb közönséget kap és tud kiszolgálni, ezáltal versenyelőnyhöz jut azokhoz képest, akik nem tartják a lépést.


Félegyházi Balázs

Kulcsszó

#Weboldal

Weboldalak 74%-a nem jól alkalmazza a Google Consent Mode v2 módosításokat

Milyen a jó weboldal a Google szerint

10+1 jel, hogy kókler csinálta a weboldalad

Mi az a Jamstack weboldal?