A lassú oldal, ami számít, nem a kezdőlap

Összefoglaló

Amikor a főnök azt mondja, hogy lassú a weboldal, az ösztönös reakció az, hogy elkezdjük tömöríteni a képeket és bocsánatot kérni a kezdőlaptól. A hasznosabb lépés az, hogy eldöntjük, melyik oldalt érdemes először felgyorsítani. Ez a cikk egyetlen forgatókönyvet mutat be: egy kis marketingcsapat, amelynek azt mondták, „gyorsítsák fel” egy közepes méretű B2B weboldalát. Szó van benne a Core Web Vitals méréséről valós felhasználói adatokkal, a lapok üzleti hatás alapján történő kiválasztásáról, és a strukturált adatok rétegezéséről, de csak az olcsó javítások után. Az eredmény egy rövid, védhető terv, amely egy nem technikai főnök számára is érthető.

A weboldalad leglassabb oldala nem az, amelyet a PageSpeed Insights jelez. Hanem az, amelyet a főnököd soha nem nyitott meg – az, amelyik fizetett kampányhoz kötődik, vagy egy elfelejtett termékszekcióban van elásva – és ez az, ami valójában meghatározza, hogy a havi büdzsé termel-e valamit. Amikor valaki vezető beosztásban azt mondja, hogy „lassú a weboldal, javítsd meg”, akkor neki nem egy weboldal-gyorsítási projektre van szüksége. Hanem egy rangsorolási gyakorlatra.

Vegyünk egy forgatókönyvet, amelyet sokan átéltünk már. Te vagy a teljes marketingcsapat egy közepes méretű B2B szoftvercégnek. A weboldalon van egy kezdőlap, egy blog, egy súgóközpont és öt landolóoldal, amelyek konkrét hirdetési kampányokhoz kötődnek. A főnököd olvasott egy cikket a Core Web Vitalsról, vagy hallott egy ügyfélpanaszt. Az utasítás egyértelmű: gyorsítsd fel.

Az, hogy hogyan reagálsz a következő órában, eldönti, hogy a következő hónapot képek tömörítésével töltöd, vagy olyan munkával, amely megváltoztatja a számokat, amelyek számítanak.

Kezdd azzal az oldallal, amelyik pénzt hoz, nem azzal, amelyik kínos

Az elv: a gyorsítási munkának megtérülése van, és ez a megtérülés a forgalomtól és a konverziós értéktől függ. Egy alacsony forgalmú, de magas konverziós oldal fontosabb lehet a vállalkozás számára, mint a kezdőlap, még akkor is, ha lassabb.

Tehát az első lépés az, hogy az analitikából készíts listát az oldalakról, nem a webhelytérképből. Mely oldalak kapnak pénzt hirdetési kattintások formájában? Mely oldalakat nem érintették indulás óta? Ebben a forgatókönyvben a legfontosabb landolóoldal – amely mögött egy két hónapja futó fizetett keresési hirdetés van – nagy, optimalizálatlan képernyőképekkel készült. A kezdőlap ezzel szemben már egy éve optimalizálva volt egy ügynökség által.

Nem a kezdőlapot javítod meg először. Azt az oldalt javítod, amelyik pénzt hoz. Ez nem technikai döntés, hanem üzleti. Ha egy teljes technikai audit tűnik a helyes válasznak, állj ellen egy pillanatra. Az auditok listát adnak, de nem mondják meg, melyik elemmel kezdj. Egy jól körülhatárolt technikai SEO audit döntési eszköz, nem pánikreakció.

Gyakran azt találod, hogy néhány oldal generálja a forgalom és a konverziók nagy részét; a többi információs vagy maradvány jellegű. Ez nem ok arra, hogy örökre figyelmen kívül hagyd a lassú információs oldalakat. Inkább arra, hogy a bevétellel közvetlen kapcsolatban álló oldalak után sorold őket. A kezdőlap lehet a leglassabb mind közül, de ha az üzleti cél a lead, a kezdőlap látogatása csak kiindulópont – a landolóoldal az, ahol valaki valójában konvertál.

Bontsd a „gyorsat” „mértre” és „érzettre”

A második lépés az, hogy elválaszd, mit mondanak a teljesítménytesztek az oldaladról attól, amit a valódi felhasználók tapasztalnak. A Google Core Web Vitals dokumentációja három mérőszámot nevez meg, amelyek beleszámítanak a keresési rangsorolásba: Largest Contentful Paint (betöltés), Interaction to Next Paint (reagálóképesség), és Cumulative Layout Shift (vizuális stabilitás). Azért fontosak, mert olyan pillanatokat követnek, amelyek befolyásolják, hogy valaki ténylegesen tudja-e használni az oldalt.

A forgatókönyvben megnyitod a landolóoldalt egy teljesítménytesztelőben, és elfogadható pontszámot kapsz. De amikor ezt összeveted a Google Search Console-ból származó valós adatokkal – amelyek a látogatók valós élményeit tükrözik –, kiderül, hogy az oldal gyakran lassú. Ez az a jel, ami számít. A laboratóriumi tesztek továbbra is hasznosak egy változtatás után, az előtte-utána összehasonlításhoz. De a valós felhasználói adatok az igazság alapja azok számára, akik különböző eszközökről és kapcsolatokról kattintottak a hirdetésedre.

Ehelyett	Ezzel kezdd	Miért
PageSpeed pontszám egyetlen számként	Core Web Vitals valós adatok	A valós adatok valódi felhasználóktól származnak, nem teszt szerverről
„A weboldal lassú”	Mely oldalak támogatják az üzleti célokat	A gyors haszontalan oldalak nem termelnek leadeket
A CMS újraépítése	Képek tömörítése és szkriptek tisztítása	Az alacsony kockázatú javítások hozzák a haszon nagy részét

Ha később mélyebb referenciára vágysz, egy Core Web Vitals útmutató végigvezet az egyes mérőszámokon. De egyelőre csak annyira van szükséged, amennyi a terv elkészítéséhez kell. A kulcs az, hogy megnevezd, a három mérőszám közül melyik okozza valójában a problémát az adott oldalon. Ha a szöveg későn jelenik meg, nézd a képeket és a szerver válaszidejét. Ha a gombok akadoznak, nézd a hosszú JavaScript-feladatokat. Ha az elrendezés ugrál, nézd a hirdetéseknek és beágyazásoknak fenntartott helyeket. Ez a különbségtétel választja el a célzott javítást a véletlenszerű optimalizálástól.

Javítsd az olcsó dolgokat a drágák előtt

A harmadik elv: ne hagyd, hogy egy teljesítményprojekt újratervezéssé dagadjon. A legtöbb fejlesztés, amely valójában javítja a felhasználói élményt, nem látványos és olcsó.

Nézd meg a landolóoldalt, és nevezd meg a nyilvánvaló bűnösöket. A képek teljes felbontású képernyőképek. Van egy harmadik féltől származó szkript az oldalon, amelyet már senki sem tud azonosítani. Egy webes betűtípus blokkolja a szöveg megjelenítését. Ezek ismerős problémák.

Tökéletes világban egy hetet töltenél az oldal újraírásával egy modern keretrendszerrel. A gyakorlatban fél napos feladatokkal kezdesz: tömörítsd a képeket, halaszd el a nem használt szkriptet, töltsd előre a hős képet. Ezeket a változtatásokat egy délután alatt tesztelheted, és nem igényelnek jóváhagyó bizottságot.

Figyelmeztetés: a sebesség nem mindig ilyen egyszerű. Egyes oldalak azért lassúak, mert a szerver, az adatbázis vagy egy harmadik féltől származó függőség, amelyet nem ellenőrzöl, okozza. De ha nem ellenőrizted az olcsó javításokat, még nem indokolhatod a drágát. Sok csapat költ pénzt újraépítésre, mert soha nem tömörítette a képernyőképeket. Van itt egy alázat, amelyet érdemes megőrizni: a teljesítménypontszám tünet, nem diagnózis. Az olcsó javítások önmagukban is diagnosztikai jellegűek. Miután tömörítetted a képeket, megtudod, hogy a szűk keresztmetszet a tartalmad vagy az infrastruktúrád volt-e.

Adj hozzá strukturált adatokat, amíg úgyis a kódban vagy

Ez az a réteg, amely meglepi a főnököt. Miután elvégezted az olcsó javításokat, már úgyis az oldal belsejében vagy. Ez a megfelelő pillanat, hogy hozzáadj valamit, ami egyáltalán nem sebesség: a strukturált adatokat.

A strukturált adat egy olyan jelölés, amely segít a keresőmotoroknak megérteni, mit tartalmaz egy oldal. Ugyanaz a HTML, amely gazdagabb keresési találatokhoz és jobb láthatósághoz vezethet – és egyre relevánsabbá válik, ahogy a keresés az AI-generált válaszok felé tolódik. Egy kis csapat számára ez egy kihasználatlan eszköz, mert nem igényel új tartalom írását. Csak felcímkézed azt, ami már létezik.

A forgatókönyvben szolgáltatásorientált sémát adsz a landolóoldalhoz. A pontos típus attól függ, miről szól az oldal: szolgáltatásról, cikkről, termékről. Nem kell egyszerre minden típust hozzáadni. Egyet gondosan hozzáadni jobb, mint tízet hanyagul. Nincs garantált eredmény; a Google dönti el, mit jelenít meg. De a kockázat alacsony, a potenciális nyereség pedig valós. Ha mélyebbre mennél, egy strukturált adatok implementációs útmutatója lefedi a gyakorlati lépéseket.

Fordítsd le a javításokat „hozott pénzt?” kérdésre

A nehéz rész nem a technikai munka. Hanem az, ahogy bemutatod egy nem technikai főnöknek.

A főnököd egy dolgot kért: gyorsítsd fel a weboldalt. Ha azt mondod, „javítottuk a LCP-t a landolóoldalon”, lehet, hogy értetlenül néz. Helyette fordítsd le a munkát üzleti következményekre.

Ebben a forgatókönyvben a landolóoldal a fizetett kampány céloldala. Minden másodperc, amit vár, egy másodperc, amíg a látogató távozhat, mielőtt a cselekvésre hívás megjelenik. Tehát elmagyarázod: eltávolítottuk a nyilvánvaló súrlódásokat azon az oldalon, ahol pénz cserél gazdát. Nem ígérhetsz konkrét rangsorolási ugrást – aki ígér, az találgat –, de készíthetsz egy ésszerű, őszinte érvet. Ezt összekötheted a főnököd által már ismert büdzsével is. Ugyanaz a hirdetési költés hoz egy látogatást; a különbség az, hogy ennek a látogatásnak van-e esélye leaddé válni.

Egy egyszerű havi jelentés jobban működik, mint egy zsargonnal teli irányítópult. Mutass három dolgot: melyik oldalt választottad, melyik mérőszámot mérted, és mit változtattál. Ha a mérőszám javul, az visszaigazolás. Ha nem, akkor is van egy világos kísérleted az újraértékeléshez. Ne hajszolj egyetlen pontszámot hónapról hónapra; a Core Web Vitals a forgalmi összetételtől, az eszköztípusoktól, sőt a földrajzi régiótól is ingadozik. A trendet jelentsd, ne a számot.

Mit csinálj jövő hétfőn

A forgatókönyv tanulsága: nem a „weboldalt” javítod. Egy konkrét oldalt javítasz, adatok alapján, és egy ismételhető folyamattal zársz, nem egyszeri projekttel. Amikor valaki hatalmi pozícióban azt mondja, „gyorsítsd fel”, a leghasznosabb válasz egyetlen tisztázó kérdés: melyik oldalt, és kinek?

Ezután mérd a valós felhasználói adatokat, javítsd az olcsó dolgokat, adj hozzá strukturált adatokat, ha úgyis a kódban vagy, és jelents egyszerű nyelvezettel. Az eredmények nem feltétlenül drámaiak. De pontosan tudni fogod, melyik oldal lett gyorsabb, miért azt választottad, és mit csinálj legközelebb. Ez jobb eredmény, mint egy homályos projekt, amely egy sebességpontszámmal kezdődött, és egy olyan újratervezésben ért véget, amelyet senki sem értett.