Weboldal-fejlesztési audit Ausztriában: Optimalizálás vagy újratervezés? Döntéshozatali útmutató osztrák kkv-k számára

Probléma és tünetek

• • Hosszú betöltési idők, észrevehető késések a kattintásoknál vagy az űrlapok kitöltésekor, látható elrendezéseltolódások (a tartalom ugrál), a mobil eszközökön jelentősen csökkenő kattintási arányok: a technikai hiányosságok tipikus tünetei.

• • SEO-jelzések: az organikus láthatóság csökkenése, hibaüzenetek a Search Console-ban (indexelési hibák, A weboldalak alapvető teljesítménymutatói Figyelmeztetések).

• • Üzemeltetés/támogatás: drága javítások, kis változtatásokhoz is jelentős erőfeszítés szükséges, hiányzó tesztek/folyamatos integráció (CI) — ezek a rossz kódminőségre utalnak.
    Ellenőrzött tények: A Core Web Vitals (LCP, INP, CLS) a Google által meghatározott mutatók, amelyek a betöltési idő, az interaktivitás és a vizuális stabilitás értékelésére szolgálnak. Ezeket a mutatókat többek között a Search Console és a PageSpeed Insights is megjeleníti. (web.dev)

Mit kell mérni – és hogyan
Ellenőrzött mutatók (a legfontosabbak, közvetlenül mérhetőek)

• • LCP (Largest Contentful Paint): azt méri, mikor töltődik be a legnagyobb látható elem. Cél: Good ≤ 2,5 másodperc (75. percentilis). (web.dev)

• • INP (Interaction to Next Paint): a felhasználói interakciókra adott válaszidőt méri; a FID helyébe lép. Jó: ≤ 200 ms, Rossz: > 500 ms; az értékelés a 75. percentilis alapján történik. (developers.google.com)

• • CLS (Cumulative Layout Shift): a vizuális eltolódásokat méri. Jó: ≤ 0,1; Rossz: > 0,25. (web.dev)

Eszközök (labor és terep)

• • Feldaten (RUM): Google Search Console – Core Web Vitals jelentés; Chrome felhasználói élmény Jelentés (CrUX) / PageSpeed Insights (eredeti/oldalszintű). Ezek valós felhasználói adatokat mutatnak. (support.google.com)

• • Laboratóriumi eszközök: Lighthouse (DevTools/CI), PageSpeed Insights, WebPageTest — a diagnózisok megismételhetőségének biztosítására. (github.com)

• • Forráskód-könyvtárak: web-vitals (saját RUM-adatgyűjtéshez) vagy kereskedelmi RUM-szolgáltatók (New Relic, Datadog stb.) a részletes interakciós nyomkövetéshez. (github.com)

Konkrét eljárás

1. 1. Kezdő audit (1–2 nap): a Search Console ellenőrzése (index, CWV-jelentés), PSI/Lighthouse 5–10 reprezentatív oldal esetében, a szerver- és CDN-konfiguráció ellenőrzése.

1. 1. RUM-mérés (2–4 hét): a Web Vitals vagy a RUM-eszköz bevezetése, az LCP/INP/CLS 75. percentilisének meghatározása mobil és asztali eszközökön külön-külön.

1. 1. Laboratóriumi diagnosztika: erőforrások prioritásba rendezése (a betöltést gátló JS/CSS, nagy méretű képek, rosszul beállított betűtípusok), külső felülvizsgálat (hirdetések, nyomkövetők).
      Ellenőrzött tények: Az INP-t hivatalosan is bevezették a Core Web Vital részeként, és felváltotta a FID-et; a Google a 75. percentilis értéket javasolja értékelési alapként. (developers.google.com)

Üzleti hatások (például hogyan befolyásolják a műszaki problémák az árbevételt és a láthatóságot)

• • Láthatóság: A felhasználói élményt jelző mutatók beépülnek a Google értékelési keretrendszerébe; a Core Web Vitals ennek a felhasználói élményre épülő megközelítésnek a része. Ugyanakkor fontos megjegyezni: a relevancia és a tartalom továbbra is központi rangsorolási tényezők maradnak — a jó CWV-értékek nem garantálják a legjobb helyezést. (developers.google.com)

• • Konverzió és felhasználói élmény: a lassú vagy megbízhatatlan interakció csökkenti a felhasználói elégedettséget, és gátolhatja a közvetlen foglalásokat/vásárlásokat; a technikai akadályok pedig növelik az ügyfélszolgálati terhelést és a javítások költségeit.

• • Üzemeltetési költségek: egy nehezen karbantartható webhely hosszú távon magasabb fejlesztési és biztonsági költségeket eredményez (pl. moduláris felépítés hiánya vagy elavult könyvtárak esetén).

Hátteret az osztrák kkv-k számára
Ellenőrzött tények: Ausztriában szinte minden vállalkozás kkv: a legfrissebb adatok szerint a kkv-k az osztrák vállalkozások több mint 99%-át teszik ki (konkrét nemzeti jelentések/monitoring-kiadványok). Az EU-s KKV-definíció: <250 alkalmazott, és vagy ≤ 50 millió euró éves forgalom, vagy ≤ 43 millió euró mérlegfőösszeg (ez releváns a támogatási kritériumok és programok szempontjából). (bmwet.gv.at)

Prioritások — Most / Következő lépések / Később
Ajánlások (gyakorlati prioritás)

• • Most (0–4 hét)
    • • Sürgősségi javítások: a kritikus JavaScript-blokkok eltávolítása, a képek késleltetett betöltése (lazy loading), a böngésző gyorsítótárának beállítása, a HTTPS használatának kikényszerítése.

     

    • • Search Console: Hibaelhárítás (indexelési és mobilhasználhatósági figyelmeztetések); a CWV-jelentés megtekintése.

     

    • • Biztonsági mentés és biztonság: TLS/HTTPS, rendszeres biztonsági mentések, aktív tűzfal/forgalmi korlátozások. (Biztonsági szabványok: az OWASP-irányelvek iránymutatásként). (support.google.com)

     

     

• • Következő lépések (1–3 hónap)
    • • A RUM-mérés teljes körű bevezetése; a tesztelési lefedettség növelése a Lighthouse CI segítségével; a kritikus sablonok/oldalak (termékoldalak, foglalás) optimalizálása.

     

    • • Tartalom-audit: A tartalmak átvizsgálása a keresési szándék és az E-E-A-T-jelek szempontjából; strukturált adatok beépítése ott, ahol indokolt.

     

    • • Harmadik felek: A címkék és a harmadik felek szolgáltatásainak ellenőrzése (Analytics, Ads) — gyakran jelentős teljesítménybeli és adatvédelmi kockázatokat hordoznak.

     

     

• • Később (3–12 hónap)
    • • Építészeti áttekintés: CMS-frissítések, CI/CD, komponens-tesztek.

     

    • • Döntés az újratervezésről: ha 3 hónapos mérhető optimalizálás után a legfontosabb üzleti oldalak nem érik el stabilan a «Jó» (75. percentilis) szintet, vagy a karbantartási költségek túl magasak, akkor új rendszer kiépítését kell tervezni.

     

     

Döntési szempontok: optimalizálás vagy újratervezés
Ajánlások (konkrét döntési kérdések)

• • Kódminőség és karbantarthatóság: Vannak-e tesztek, verziókezelés, egyértelmű elválasztás a frontend és a backend között? Ha nem → inkább újra kell építeni.

• • Mérhető befolyásoló tényezők: Célzott intézkedésekkel 1–3 hónapon belül jelentős javulást érhet el (pl. az LCP/INP/CLS 75. percentilisét a «Good» kategóriába emelni)? Ha igen → Optimalizálja.

• • Üzleti függőség: Az alapvető folyamatok (könyvelés, pénztár, CRM-integráció) az architektúra hiányosságai miatt hibára hajlamosak-e? Ha az alapvető folyamatok instabilak → inkább új rendszer kiépítése szükséges.

• • Költségek kontra haszon: Becsülje meg mindkét lehetőség bevezetési és karbantartási költségeit; ha a kódbázis magas fix költségeket generál, az újratervezés gyakran középtávon megtérül.

• • Idő és erőforrások: Rendelkeznek-e fejlesztői vagy ügynökségi kapacitással ahhoz, hogy átfogó refaktorálási munkákat végezzenek? Ha nem, akkor hosszú távon költséghatékonyabb egy modern architektúrájú, automatizált tesztekkel ellátott új rendszer felépítése.

Konkrét ellenőrzőlista (rövid, az audit során felhasználható)

• • Mérés és nyomon követés
    • • Search Console: A Core Web Vitals-jelentés ellenőrzése (support.google.com)

     

    • • PageSpeed Insights / Lighthouse: 5–10 reprezentatív oldal tesztelése. (github.com)

     

    • • RUM: web-vitals vagy kereskedelmi RUM-ügynök implementálva. (github.com)

     

     

• • Teljesítmény – Gyors eredmények
    • • Képek optimalizálása (WebP/AVIF, reszponzív srcset), CDN engedélyezése.

     

    • • JS/CSS: a kritikus CSS-kódot inline módon, a nem kritikusakat aszinkron módon tölti be; hosszú feladatok elemzése.

     

    • • Betűtípusok: ellenőrizze a „font-display: swap” és a „preload” beállításokat.

     

     

• • Felhasználói élmény és konverzió
    • • Ellenőrizze a „Mobile-First” tervezést; egyszerűsítse az űrlapokat; a cselekvésre ösztönző gombok (CTA-k) legyenek jól láthatóak, és ne legyenek kitéve az elrendezés-eltolódások hatásának.

     

    • • A konverziós tölcsérből való kilépési pontok mérése az Analytics segítségével.

     

     

• • SEO és mesterséges intelligencia – láthatóság
    • • A strukturált adatok helyes és szerveroldali megadása; a tartalom minőségének ellenőrzése (lásd a Google AI-keresés-optimalizálási útmutatóját). (developers.google.com)

     

    • • Az indexelési problémák kijavítása; a feltérképezési keret ellenőrzése.

     

     

• • Biztonság és üzemeltetés
    • • HTTPS használata kötelező; a szerver aktuális TLS-beállításai; rendszeres biztonsági mentések.

     

    • • Végig kell menni az OWASP legfőbb kockázatai elleni alapelvi biztonsági ellenőrzőlistán. (owasptopten.org)

     

     

• • Üzleti csekkek
    • • A kulcsoldalak (termékek/szolgáltatások/pénztár) az LCP/INP/CLS mutatók 75. percentilisében a «Jó» kategóriába tartoznak?

     

    • • A kritikus problémák 50–80 %-a megoldható-e 3 hónapon belül a rendelkezésre álló erőforrások felhasználásával?

     

     

Záróajánlás (rövid)
Először végezzen el egy rövid, mérhető és megismételhető auditot (1–2 hét munka). Ha az auditból kiderül, hogy a főbb problémák konfigurációs és frontend-javításokkal megoldhatók, kezdjen el egy prioritások szerint rendezett optimalizálási tervet kidolgozni. Ha viszont a kódbázis széttagolt, bizonytalan vagy karbantarthatatlan, és ez a legfontosabb üzleti folyamatokat is érinti, akkor tervezzen meg egy ellenőrzött újjáépítést, egyértelmű migrációs lépésekkel és mérhető célokkal.

Fontos hivatkozások (forrásválogatás)

• • Google: Az INP / Core Web Vitals bevezetése; Útmutató a felhasználói élményhez; A Search Console Core Web Vitals funkciója. (developers.google.com)

• • web.dev: technikai útmutatók az LCP-ről, az INP-ről, a CLS-ről és az optimalizálási lépésekről. (web.dev)

• • Lighthouse / Google Chrome projektek (Lighthouse dokumentáció). (github.com)

• • Google: Útmutató a generatív mesterséges intelligencia-eredmények (AI Search) optimalizálásához. (developers.google.com)

• • Osztrák források / KKV-adatok és az EU KKV-meghatározása (bmwet.gv.at)

• • OWASP: Biztonsági ajánlások és legfőbb kockázatok. (owasptopten.org)

Ha szeretné, készíthetek Önnek egy rövid audit-sablont (kérdések, eszközök, prioritások), amelyet átadhat a fejlesztőjének vagy az ügynökségének — így 7–14 napon belül konkrét mérési eredményeket kap, amelyek objektív alapot nyújtanak a „optimalizálás vagy újratervezés” közötti döntéshez.