# Lassú betöltés miatt elvesző keresési látogatók — mikor döntsön kisvállalati vezető weboldal újraépítésről? - Link: https://digiosveny.hu/lassu-betoltes-miatt-elveszo-keresesi-latogatok-mikor-dontson-kisvallalati-vezeto-weboldal-ujraepitesrol/ - Published: 2026-10-08T10:19:13+02:00 - Author: Márton ## Rövid összefoglaló   A lassú weboldal miatt elvesző keresési látogatók jelensége nem csak technikai probléma: mérhető üzleti veszteséget és romló organikus láthatóságot okozhat. A döntés — kisebb optimalizálás vagy teljes újraépítés — akkor jó, ha tényekre (felhasználói mérésekre, RUM/adatokra és auditokra) alapul, és elkülönítjük a bizonyított tényeket a szakértői javaslatoktól. Az alábbiakban gyakorlati, ellenőrizhető lépések és döntési kritériumok találhatók kisvállalati döntéshozók számára.   (Összegyűjtött, hiteles források használatával — Google Web Vitals / PageSpeed, Search Console, WebPageTest, Deloitte/Google tanulmány — dolgoztam.) (web.dev)   ---   ## A probléma és tünetek   - Mi történik: a keresőből érkező felhasználók a lassú vagy félbemaradó betöltés miatt elhagyják az oldalt, így kevesebb lesz a kontakt, lead vagy vásárlás. Ezt a viselkedést már többször igazolták különböző R&D/statisztikai vizsgálatok.( readkong.com)   - Gyakori tünetek (ezeket ellenőrizze): - magas visszafordulási arány (bounce) keresési forgalomnál; -   - rövidebb oldalon töltött idő vagy kevesebb oldal/munkamenet; -   - organikus forgalom megtartási problémái stagnáló tartalom mellett; -   - Search Console Core Web Vitals hibák vagy „Poor” URL-csoportok. (support. google.com) -   -       ---   ## Bizonyított, ellenőrizhető tények (konkrét metrikák és források)   - Core Web Vitals: a három ma releváns CWV-mutató: LCP (Largest Contentful Paint), INP (Interaction to Next Paint, az FID helyett), és CLS (Cumulative Layout Shift). A javasolt „Good” küszöbök: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 ( a Search Console szintén Good/Fair/Poor küszöböket használ). (web.dev)   - Mérések két típusa: „field” (valódi felhasználói adatok — Chrome User Experience Report / CrUX) és „lab” (szintetikus auditok, pl. Lighthouse / PageSpeed Insights). Mindkettőre szükség van: a field mutatja a valós állapotot, a lab segít hibák reprodukálásában és javításában. (developer.chrome.com)   - A teljesítmény és üzleti mutatók összefüggnek: Google által megrendelt és nonprofit elemzők által publikált vizsgálatok szerint a mobil-sebesség javítása mérhető hatással van bounce-ra, konverzióra és bevételre (pl. „Milliseconds Make Millions” / Deloitte & Google). A források megmutatják a korrelációt, de az egyedi hatás mértéke vállalatonként eltér. (readkong.com)     ---   ## Mit és hogyan érdemes mérni   - Elsődleges mérőszámok (minden üzleti landing/legfontosabb oldal 75. percentilisére mobil és asztali bontásban): - LCP (megjelenés fő tartalom szerint), INP (interakciós válaszidő), CLS( váratlan elrendezés-változások). (web.dev) -   -     - Kiegészítő műszerfal-mutatók: Total Blocking Time (TBT), Time to First Byte( TTFB), First Contentful Paint (FCP), hálózati méretek (össz. bytes), és harmadik fél szkriptek összidő. (Ezek segítenek az okok feltárásában.) (en.wikipedia. org)   - Eszközök: - PageSpeed Insights (lab + CrUX field nézet). (developers.google.com) -   - Search Console — Core Web Vitals riport (URL-csoportok „Good/Fair/Poor”).( support.google.com) -   - WebPageTest — több helyről, valós böngészővel futtatott részletes trace.( license.webpagetest.org) -   - Chrome DevTools / Lighthouse — profilozás, long tasks, main-thread szemléltetés.( en.wikipedia.org) -   -     - Módszer: gyűjtsen 14–30 napnyi RUM/field adatot (ha van forgalom), futtasson szabványosított lab-teszteket különböző helyekről és eszközökről, és hasonlítsa össze a 75. percentilis eredményeket mobilon és desktopon. (developer.chrome. com)     ---   ## Üzleti hatás (hogyan érinti a céget)   - Közvetlen: elvesztett látogatók → kevesebb lead, alacsonyabb konverzió. Több nagyobb kutatás rámutat arra, hogy a mobil-sebesség javítása növelheti a konverziót és az AOV-t (átlagos rendelési érték), de az arányok iparág- és esettanulmány- függőek. (readkong.com)   - Közvetett: rossz CWV/UX rontja a felhasználói viselkedést (magas bounce, alacsony oldalmélység), ami hosszabb távon gyengítheti az organikus teljesítményt — Google a Page Experience elemeit a rangsorolás egyik jelzésének tekinti, de nem az egyetlen és nem minden esetben döntő. (developers.google.com)     ---   ## Prioritások: most / következő / később   - Most (azonnal, alacsony költség): - Valós adatok begyűjtése: Search Console CWV, PageSpeed Insights, alap WebPageTest. (support.google.com) -   - Gyors gyógyítások: képek optimalizálása és megfelelő formátum/kompresszió, böngészőcache beállítása, kritikus CSS/JS deferral, felesleges pluginök/ third-party tag-ek letiltása vagy késleltetése. (Általános jó gyakorlat; harmadik felek különösen nagy hatással lehetnek.) (debugbear.com) -   -     - Következő (költségesebb, 2–8 hét): - Mélyprofilozás: long tasks, JS-hosszú futások, render-blocking források javítása; teljesítmény-budget kialakítása és CI tesztek. (en.wikipedia. org) -   -     - Később (rebuild mérlegelése): - Ha a CMS/architektúra vagy harmadik fél függőségek folyamatosan akadályozzák a szükséges javításokat, érdemes újraépítésben gondolkodni — lásd a döntési kritériumokat alább. (Több erőforrást igényel, de hosszú távon fenntarthatóbb lehet.) -   -       ---   ## Döntési kritériumok — mikor gondolkodjon újraépítésben (rebuild)   Ezeket a pontokat használja feltételként, nem egyszerre mindegyiket kell teljesíteni; ha több igaz, a rebuild valós alternatíva lehet:   1. a. Kulcsoldalak tartósan „Poor” státuszúak a Search Console Core Web Vitals riportban, és lab-javítások (kritikus erőforrások átszervezése, képek, cache, script deferral) nem hoznak elfogadható javulást. (support.google.com)   1. a. A jelenlegi CMS / sablon / plugin-ök strukturális korlátot jelentenek (például nem lehet lazy-loadot bevezetni, vagy a template generál túl sok render-blocking kódot), és a szállító nem tud/bárki nem akar ezt karbantartható módon javítani.( Ez technikai adósság.)   1. a. A weboldal fejlesztési és üzemeltetési költségei, illetve a folyamatos regressziók többe kerülnek, mint egy modern, egyszerűbb, teljesítményre tervezett új frameworkbe való migráció költsége a következő 2–3 évre vetítve. (Ezt költség/haszon számítással kell alátámasztani.)   1. a. Biztonsági, kompatibilitási, vagy skálázhatósági limit miatt a jelenlegi architektúra már nem felel meg (pl. elavult PHP/WordPress verzió, nincs HTTPS/HTTP2/HTTP3 támogatás, vagy a host nem képes terhelést kezelni).     A döntéshez készítsen összehasonlító TCO/ROI kalkulációt: javítási költségek + várható javulás vs. újraépítés költsége + hosszabb távú fenntarthatóság. (Ezt szakértői becsléssel és audit-eredményekkel kell alátámasztani.)   ---   ## Szakmai javaslatok (szakértői, nem kizárólag bizonyított tények)   - Ne építsen túl bonyolult frontendet, ha a weboldal egyszerű információs/vásárlási célú — a túl sok JavaScript és harmadik fél lassítja az alapélményt.   - Először „fixeljük a lehető legegyszerűbbet”: képek, cache, CDN, defer/async, majd mérjük az üzleti eredményt. Ha ezek után is akadály a technológia, jöhet a rebuild.   - Ha épít új oldalt: tervezzen be teljesítmény-költségvetet, RUM-monitorozást( sok small-business-szolgáltató ma már beépített RUM-mel dolgozik), és szerezze be a fejlesztői trace-ek birtoklását (ne legyen black-box a platform). (soapboxdigital. co.uk)     ---   ## Rövid ellenőrzőlista (gyors végrehajtáshoz)   - Van-e Search Console Core Web Vitals riportja? (igen → exportálja a problémás URL-csoportokat). (support.google.com)   - Van-e PageSpeed Insights / CrUX field adat az érintett oldalakról? Futtasson 3–5 lab-tesztet WebPageTestből több helyről. (developers.google.com)   - Elsődleges célok beállítva: mobil LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 (mérje a 75. percentilist). (web.dev)   - Harmadik felek inventory: lista minden külső scriptből, és azok betöltési idejének mérése (ha 1–2 script felel a legtöbb blokkidőért, fontolja meg késleltetést vagy alternatívát). (debugbear.com)   - Gyors nyerés bevezetve (kép-optimalizálás, cache, CDN, kritikus CSS, JS defer): mérje az üzleti KPI-ket 2–4 hét alatt.   - Ha a gyors nyerések után is több kulcsoldal „Poor” marad, kérjen részletes teljesítmény-auditot, és készítsen költség/haszon elemzést a rebuildről.     ---   Záró megjegyzés: a lassú oldal nem automatikusan indokolja a teljes újraépítést — sok esetben jelentős javulás érhető el célzott optimalizációkkal. Ugyanakkor ha a műszaki adósság és az architektúra folyamatosan gátolja a fejlődést, a rebuild előre tervezett beruházásként kifizetődő lehet. Az első lépés mindig a mérés: field adatok + reprodukálható lab-auditok. (support.google.com)   Ha szeretné, elkészítek egy rövid, oldalankénti mérési tervet (mely oldalak, mely beállításokból és milyen eszközökkel), de ehhez hozzáférés szükséges a Search Console/ analytics/Web audit eredményekhez. --- ## Nem biztos benne, hol veszít érdeklődőt a weboldala? Egy rövid, konkrét technikai átvilágítás megmutatja a legfontosabb problémákat, a keresési és konverziós akadályokat, valamint a következő lépést. Ha folyamatos, felügyelt tartalomkészítést és weboldali érdeklődő-kezelést szeretne, a rendszer külön projektként is beköthető. [Kérem az ingyenes weboldalauditot](https://digiosveny.hu/ingyenes-weboldalaudit/) Konkrét  bloggenerátor vagy chatbot projekthez: [Kitöltöm a projekt-igényfelmérést](https://digiosveny.hu/igenyfelmero-urlap/).