Az AI weboldal készítés ma már lehetővé teszi, hogy néhány perc alatt egy screenshotból, Figma designból vagy egyszerű szöveges leírásból látványos landing oldalt készítsünk.
Feltöltjük a tervet Claude-ba vagy egy másik AI-eszközbe, megkérjük, hogy készítse el HTML/CSS-ben, majd a kapott kódot bemásoljuk a weboldalba.
Kész.
Vagy legalábbis annak látszik.
Ez a módszer óriási lehetőség. Olyan emberek kezébe is komoly frontendképességet ad, akik korábban nem vagy csak alapszinten tudtak volna HTML-t és CSS-t írni. Prototípusok, kampányoldalak és designok első működő változatai elképesztő gyorsasággal állíthatók elő.
Van azonban egy fontos probléma: attól, hogy egy generált oldal jól néz ki a böngészőben, még nem biztos, hogy technikailag jól is van felépítve.
Különösen akkor nem, ha a generált HTML-t ellenőrzés nélkül egy már eleve összetett WordPress page builderbe illesztjük.
AI weboldal készítés: a generált HTML nem automatikusan lassú
Ez fontos kiindulópont.
Egy jól megírt statikus HTML/CSS oldal akár rendkívül gyors is lehet.
Ha kevés JavaScriptet használ, megfelelően optimalizáltak a képek és fontok, nincs fölösleges kód, és logikus a DOM-struktúra, akkor egy AI által generált oldal technikailag semmivel sem szükségszerűen rosszabb annál, amit egy fejlesztő manuálisan írt.
Akár könnyebb is lehet egy túlépített CMS-es oldalnál.
A probléma tehát nem az, hogy AI írta a kódot.
A probléma akkor kezdődik, amikor a generált eredményt azért tekintjük production-readynek, mert vizuálisan helyesen jelenik meg.
Az AI ugyanis elsősorban azt a feladatot próbálja teljesíteni, amit adtunk neki.
Ha azt kérjük:
„Készíts ebből egyetlen HTML fájlt, ami pontosan így néz ki”,
akkor jó eséllyel arra optimalizál, hogy az eredmény önmagában működjön.
Nem feltétlenül arra, hogy később WordPressben, Elementorban vagy egy másik rendszer részeként fusson a lehető legtisztábban.
Több ezer sor kód? Önmagában még semmit nem jelent
Az AI weboldal készítés során könnyű megijedni attól, hogy egy látszólag egyszerű oldal mögött több ezer sor HTML és CSS jelenik meg.
Ez lehet figyelmeztető jel.
De a kódsorok száma önmagában nem teljesítménymutató.
Egy jól strukturált 4000 soros oldal működhet jobban, mint egy kaotikus 500 soros.
A böngésző szempontjából nem az a kérdés, hogy hány sort látunk a szerkesztőben.
Sokkal fontosabb többek között:
- mekkora adatot kell letölteni,
- mennyi HTML-elemből épül fel a DOM,
- mennyi CSS-t kell feldolgozni,
- mennyi JavaScriptet kell letölteni és futtatni,
- mennyi ebből a ténylegesen használt kód,
- és milyen munkát kell elvégeznie a böngészőnek az oldal kirajzolásához.
A Chrome dokumentációja például külön figyelmeztet arra, hogy egy túlzottan nagy DOM növelheti a stíluskalkulációk és layoutműveletek idejét, illetve a memóriahasználatot. Ugyanakkor azt is hangsúlyozza, hogy önmagában egy mély DOM-fa nem automatikusan teljesítményprobléma – gyakran inkább annak a jele, hogy a struktúrában szükségtelen elemek és egymásba ágyazások vannak.
Vagyis: nem a sok kódsor lassítja az oldalt. Az számít, mennyi és milyen munkát adunk a böngészőnek.
Amikor a kép már nem külön kép, hanem az oldal kódjának része
Az AI weboldal készítés egyfájlos outputjainál előfordulhat, hogy a rendszer nem különálló assetként hivatkozik egy képre, hanem közvetlenül beágyazza azt az oldalba például base64/data URL formájában.
Fontos: ez nem azt jelenti, hogy Claude vagy bármely más AI minden feltöltött képet automatikusan így kezel.
Ez az output típusától, a prompttól és a konkrét megvalósítástól függ.
Kis asseteknél az inline megoldásnak lehet létjogosultsága: egy külön hálózati kérés megszüntetése bizonyos esetben előnyös lehet.
Nagyobb képeknél viszont könnyen az ellenkező hatást érjük el.
Az inline kép megnöveli annak a HTML-, CSS- vagy JavaScript-erőforrásnak a méretét, amelybe beágyazták, és a böngészőnek ezt az egészet együtt kell letöltenie és feldolgoznia. A web.dev szintén arra figyelmeztet, hogy nagy vagy sok kép inline beágyazásánál a megnövekedett bundle-méret, parse-idő és memóriaigény könnyen meghaladhatja a külön kérés elhagyásából származó előnyt.
Ezért egy valódi production oldalon általában érdemes külön kezelni:
- a fotókat,
- az SVG-ket,
- a háttérképeket,
- és más nagyobb médiafájlokat.
WordPressnél pedig legtöbbször annak van értelme, hogy ezek valódi médiaelemként kerüljenek a rendszerbe, és ne egy több százezer karakteres HTML-blokk belsejében éljenek.
Fontoknál még fontosabb, hogyan történik a beágyazás
A fontok különösen jó példát adnak arra, hogy miért nem mindegy, mit értünk „inline” alatt.
Egy @font-face deklaráció elhelyezése közvetlenül a HTML-ben önmagában nem probléma. Sőt, bizonyos helyzetekben segíthet abban, hogy a böngésző hamarabb felfedezze a szükséges fontot.
Egészen más azonban, amikor maga a fontfájl kerül base64-ként a CSS-be.
A web.dev ezt kifejezetten nem ajánlja. A base64 kódolás nagyobb payloadot eredményezhet, a nagy inline blokk pedig késleltetheti más kritikus erőforrások felfedezését is.
Normál esetben a font külön .woff2 fájlként kezelhető.
Ennek több előnye is lehet:
- a böngésző külön erőforrásként töltheti,
- megfelelő cache-elés állítható be,
- csak a szükséges fontvastagságokat kell kiszolgálni,
- és modern böngészőknél jellemzően elegendő a hatékonyan tömörített WOFF2 formátum.
A web.dev jelenlegi ajánlása szintén a WOFF2 használatát és a szükséges fontok, karakterkészletek tudatos optimalizálását javasolja.
Egy olyan AI-output tehát, amely négy fontvastagságot, italic variációkat és teljes fontfájlokat ágyaz közvetlenül az oldal kódjába, egészen más teljesítményprofilú lehet, mint amikor ugyanazokat a fontokat tudatosan külön erőforrásként szolgáljuk ki.
„De csak egy HTML blokkot tettem Elementorba”
Itt jelenik meg egy második, nagyon gyakori probléma.
Tegyük fel, hogy már van egy WordPress-oldalunk.
Van rajta:
- egy theme,
- egy page builder,
- különböző pluginok,
- a builder saját CSS- és JavaScript-rétege,
- esetleg globális designrendszer,
- animációk és egyéb frontendfunkciók.
Az AI weboldal készítés során kapott, önmagában komplett landing oldalt saját HTML-lel, CSS-sel és JavaScripttel fogjuk, és az egészet betesszük egy HTML widgetbe.
Ilyenkor nem helyettesítettük a meglévő frontend infrastruktúrát.
Rátettünk még egy réteget.
Ez nem jelenti azt, hogy Elementor, Divi vagy WPBakery használatával automatikusan lassú lesz egy oldal. Egy builder teljesítménye rengeteg tényezőtől függ: hogyan építették fel az oldalt, milyen widgeteket és pluginokat használunk, milyen optimalizáció működik és mennyi fölösleges erőforrást töltünk.
A probléma inkább az, ha ugyanazon az oldalon párhuzamosan létezik:
- a builder layoutstruktúrája,
- a builder CSS-e,
- a builder scriptjei,
- és mellette egy második, önálló HTML/CSS/JS alkalmazásként működő generált blokk.
Ilyenkor könnyen keletkezhet fölösleges CSS, szükségtelen JavaScript vagy extra DOM-struktúra.
A Chrome Lighthouse dokumentációja szerint a nem használt CSS eltávolítása nemcsak a szükségtelen hálózati adatforgalmat csökkentheti, hanem a render tree és a stíluskalkuláció munkáját is mérsékelheti. WordPress esetében maga a Chrome dokumentációja is arra hívja fel a figyelmet, hogy érdemes ellenőrizni azokat a pluginokat, amelyek fölösleges CSS-t töltenek be.
A jó cél ezért nem az, hogy „minél kevesebb plugin” vagy „builder soha”.
Hanem az, hogy ne töltsünk be ugyanahhoz a vizuális eredményhez több frontendréteget a szükségesnél.
Az inline CSS sem ellenség
Itt is fontos elkerülni a túlzott leegyszerűsítést.
Az inline CSS önmagában nem rossz.
A kritikus, első rendereléshez szükséges CSS közvetlen elhelyezése a dokumentumban kifejezetten bevett teljesítmény-optimalizációs technika lehet.
A Chrome Lighthouse dokumentációja is javasolja a first painthez szükséges critical CSS inline elhelyezését, miközben a nem kritikus stílusokat később lehet betölteni.
A különbség a mennyiségben és a célban van.
Egy néhány kilobájtos critical CSS nem ugyanaz, mint amikor az oldal összes reszponzív szabálya, animációja, fontja és minden szekciójának teljes stylingja egy gigantikus <style> blokkban érkezik.
Az inline nem rossz. A kontroll nélküli inline lehet rossz.
Nemcsak a letöltés számít
Egy nagy HTML dokumentum vagy túlbonyolított frontend hatása nem ér véget azzal, hogy a fájl megérkezett a böngészőbe.
A böngészőnek az oldalt fel is kell építenie.
- A HTML-ből létrejön a DOM.
- A stílusokat fel kell dolgozni.
- Ki kell számítani, hogy melyik szabály melyik elemre vonatkozik.
- El kell végezni a layoutot és a festést.
- A JavaScriptet parse-olni, fordítani és futtatni kell.
- Felhasználói interakcióknál pedig ezek egy részét újra is kell számolni.
Ezért lehet problémás például az indokolatlanul nagy DOM vagy a jelentős mennyiségű fölösleges CSS és JavaScript. A Chrome jelenlegi Performance Insights dokumentációja kifejezetten azért vizsgálja a DOM méretét, mert a nagy DOM hosszabb style calculation és layout műveletekkel, rosszabb válaszkészséggel és nagyobb memóriahasználattal járhat.
A cél tehát nem az, hogy megszállottan minden egyes bájtot és HTML-elemet levadásszunk.
Hanem az, hogy ne adjunk fölösleges munkát a böngészőnek.
És mit jelent mindez a PageSpeedre és a Core Web Vitalsre nézve?
Itt is érdemes kerülni az egyszerű képleteket.
Nem igaz az, hogy: „sok HTML = rossz PageSpeed”.
Ahogyan az sem igaz, hogy egy 100 pontos PageSpeed eredmény automatikusan jó SEO-t jelent.
Az AI weboldal készítés esetében is több összetevőből áll a teljesítmény, ezért önmagában a kód mennyiségéből nem lehet megbízható következtetést levonni.
A Google jelenlegi Core Web Vitals mutatói három fő felhasználói élményt mérnek:
LCP (Largest Contentful Paint): a betöltési teljesítményt – jó értéknek 2,5 másodpercen belüli LCP számít.
INP (Interaction to Next Paint): az interakciókra adott válaszkészséget – a cél 200 ms alatti érték.
CLS (Cumulative Layout Shift): a vizuális stabilitást – a jó érték 0,1 alatt van.
Egy túl nagy kép, rosszul kezelt webfont, renderblokkoló CSS, túl sok JavaScript vagy egy szükségtelenül komplex DOM különböző módokon hozzájárulhat ezek romlásához.
De nincs olyan szabály, hogy egy adott kódmennyiség fölött automatikusan rossz lesz a Core Web Vitals.
És SEO szempontból sem érdemes a PageSpeed 100 hajszolását önálló céllá tenni.
A Google egyértelműen leírja, hogy a Core Web Vitals része a rangsorolási rendszerek által figyelembe vett page experience jeleknek, de egy jó CWV- vagy Lighthouse-eredmény nem garantál magas Google-helyezést, és nincs egyetlen külön „page experience score”, amely eldöntené a rangsort.
A sebességet elsősorban azért érdemes rendbe tenni, mert jobb élményt ad a látogatónak.
Hogyan néz ki egy rossz AI → WordPress workflow?
Az AI weboldal készítés egyik tipikus problémás workflow-ja valahogy így néz ki:
Feltöltünk egy screenshotot vagy Figma designt az AI-nak.
Azt mondjuk:
„Készítsd el egyetlen HTML fájlban.”
Kapunk egy teljes oldalt HTML-lel, CSS-sel, JavaScripttel és esetenként inline assetekkel.
Az egészet bemásoljuk egy Elementor vagy más builder HTML widgetjébe.
A vizuális eredmény jó.
A sebesség kevésbé.
- Erre telepítünk még egy performance plugint.
- Minify.
- Delay JavaScript.
- Remove unused CSS.
- Cache.
- CDN.
És egyre több réteggel próbálunk optimalizálni egy olyan struktúrát, amelyet lehet, hogy eleve egyszerűbben kellett volna felépíteni.
A teljesítményoptimalizálásnak természetesen ezek az eszközök is fontos részei lehetnek.
De van egy még jobb optimalizáció:
az a kód, amit eleve nem kell letölteni, feldolgozni vagy futtatni.
Mi hogyan használjuk erre az AI-t?
Mi sem azért jutottunk ezekre a következtetésekre, mert kerülni szeretnénk az AI-val generált HTML-t.
Éppen ellenkezőleg.
Nálunk az AI weboldal készítés, azon belül a Claude → HTML workflow az utóbbi időszakban komoly gyorsulást hozott például Figma designok feldolgozásánál.
A különbség az, hogy a generált statikus oldalt nem feltétlenül tekintjük a végleges WordPress-struktúrának.
A Claude elkészítheti a vizuálisan pontos HTML/CSS referenciát.
Ebből azonban nálunk létrejöhet egy WordPress- és Gutenberg/GenerateBlocks-barát szerkezet, ahol:
- a szekciók valódi szerkeszthető blokkok,
- a layout logikus konténerekből épül fel,
- a képek külön Media Library elemek,
- az SVG-k külön SVG assetként maradnak,
- a fontokat normál webfontként kezeljük,
- és a későbbi WordPress-szerkesztéshez sem kell több ezer sor HTML-ben turkálni.
Az AI ebben a folyamatban óriási gyorsító.
De nem feltétlenül ő dönti el, milyen formában kerül productionbe az eredmény.
Az AI weboldal készítés során szerintünk éppen ez az egyik lényeges különbség: a gyors generálás és a productionre kész struktúra nem feltétlenül ugyanaz.
Mit érdemes ellenőrizni publikálás előtt?
Az AI weboldal készítés után, még az élesítés előtt, néhány perces technikai ellenőrzéssel meglepően sok problémát ki lehet szűrni.
- Nézzük meg a Chrome DevTools Network paneljén, mekkora maga a HTML dokumentum, és mely képek, fontok, CSS- és JS-erőforrások töltődnek.
- Keressünk rá a forrásban például a base64, data:image vagy más data: URL-ekre, és nézzük meg, valóban indokolt-e az inline asset.
- Ellenőrizzük, milyen fontfájlok és fontvastagságok töltődnek be.
- Nézzük meg a DOM méretét és azt, nincs-e indokolatlanul sok egymásba ágyazott wrapper.
- Használjuk a DevTools Coverage nézetét a jelentősebb nem használt CSS és JavaScript felderítésére.
- Futtassunk Lighthouse/PageSpeed tesztet mobilra is, de ne csak az összpontszámot nézzük.
- Ha az oldalnak már van megfelelő valós forgalma, nézzük meg a valódi felhasználói Core Web Vitals adatokat is – a laboreredmény és a field data ugyanis nem ugyanaz.
Nem kell minden oldalnak mikroszkopikusan kicsinek lennie.
A cél az, hogy értsük, mit töltünk be, és legyen oka annak, ami ott van.
Akkor rossz ötlet AI-val weboldalt készíteni?
Egyáltalán nem.
Az AI kifejezetten jó lehet:
- gyors prototípushoz,
- design proof of concepthoz,
- kampányoldal első változatához,
- statikus landinghez,
- frontend komponensek kiindulópontjához,
- vagy akár production kód elkészítéséhez is.
Az utóbbihoz azonban ugyanaz az elv érvényes, mint minden más fejlesztési munkára:
a kész eredményt ellenőrizni kell.
Ha tiszta a markup, megfelelőek az assetek, nincs szükségtelen kód, jó a reszponzív működés, megfelelő a hozzáférhetőség és rendben van a teljesítmény, akkor teljesen lényegtelen, hogy az első verziót ember írta-e vagy AI.
Az AI-generated nem egyenlő az amatőrrel.
Az ellenőrzés nélkül productionbe másolt kód viszont továbbra is kockázat – függetlenül attól, hogy ember vagy AI készítette.
Az AI lejjebb vitte a kódolás belépési küszöbét. A web technikai alapjai viszont nem változtak meg.
Ma már olyan ember is képes néhány perc alatt látványos landing oldalt létrehozni, aki korábban nem tudta volna önállóan megírni annak HTML- és CSS-kódját.
Ez hatalmas előrelépés.
De a böngésző nem tudja, hogy Claude, ChatGPT vagy egy senior frontend fejlesztő írta a kódot.
- Ugyanúgy le kell töltenie.
- Ugyanúgy fel kell dolgoznia.
- Ugyanúgy fel kell építenie a DOM-ot.
- Ugyanúgy ki kell számolnia a stílusokat.
- És ugyanúgy le kell futtatnia a JavaScriptet.
Az AI ezért nem szüntette meg a webfejlesztés technikai alapjait.
Csak elképesztően gyorssá tette a kód létrehozását.
És pontosan emiatt vált még fontosabbá egy új kérdés:
nem az, hogy képes-e az AI elkészíteni az oldalt, hanem az, hogy valaki érti-e, mi került bele.
Mi ezért nem azt mondjuk, hogy az AI weboldal készítés rossz irány lenne.
Mi is használjuk.
Inkább azt: az AI által generált kódot ne azért tekintsük kész terméknek, mert első ránézésre működik.
Használjuk arra, amiben elképesztően jó: gyors tervezésre, fejlesztésre és prototípus-készítésre.
A production oldalon pedig ugyanúgy legyen követelmény a tiszta struktúra, a megfelelő assetkezelés, a szerkeszthetőség és a mérhető teljesítmény, mint az AI-korszak előtt.
Ha szeretnéd megtudni, hogyan használható az AI weboldal készítés a saját projektedben úgy, hogy a gyorsaság mellett a technikai minőség és a későbbi szerkeszthetőség is rendben legyen, lépj velünk kapcsolatba, és nézzük meg együtt a lehetőségeket.
