More

    Mit jelentenek a webes életjelek mutatói és hogyan javíthatók?

    Mielőtt belemerülne a webes Életjelekbe, legalább egy egyszerű ötletet kell kapnia arról, hogy az oldal hogyan töltődik be a böngészőben. 

    Az egyszerűsítés érdekében így működik. Amikor a felhasználó egy webhelyre megy, például egy keresőmotorból, egy másik webhely linkjén keresztül, vagy egyszerűen egyik oldalról a másikra költözik, böngészője hozzáfér a szerverhez, amelyen ez az oldal található. A szerver feldolgozza a kapott kérést, és ha a kért oldal valóban létezik, elküldi annak tartalmát. 

    A böngésző megkapja a weboldal HTML kódját, majd elkezdi külön elemekké elemezni, megpróbálva lefordítani az egyes címkéket a (DOM) Dokumentumobjektum modellbe. A HTML elemzésének folyamatában a böngésző olyan külső szkriptekkel és stílusokkal találkozik, amelyeket megpróbál betölteni. A HTML elemző továbbra is úgy fog működni, mint a CSS fájl betöltése, de blokkolja a renderelést, amíg a fájl be nem töltődik. Amikor találkozik JS fájlokkal, a renderelés is blokkolva van, de a JS fájlok előnye a defer és async attribútumok, amelyek lehetővé teszik a HTML értelmező számára, hogy továbbra is működjön, miközben a JS a háttérben fut. A CSS betöltési folyamat során egy CSSOM (CSS objektummodell) is létrejön, amely tartalmazza a webhely összes CSS-kiválasztójának térképét. 

    Mindezek után a böngésző létrehoz egy renderelő fát, amely egyesíti a CSS-t és a HTML-t. A renderelő fa minden csomópontjára kiszámítják, hogy hol található az oldalon. Ezután a böngésző végigmegy ezen a fán, és kiírja az oldalt. 

    Ha sok különálló fájl csatlakozik a folyamathoz, vagy egy nagy DOM fát használnak, vagy a szerver által küldött fájlok elég nagyok, vagy maga a szerver “gyenge” stb. ez azt eredményezi, hogy az oldal nagyon hosszú időt vehet igénybe a készülék betöltéséhez. 

    Senki sem szereti, ha egy oldal hosszú időt vesz igénybe a betöltéshez, ezért a felhasználók elhagyhatják a webhelyet anélkül, hogy várnák a betöltését. Ez az egyik oka annak, hogy a keresőmotorok megpróbálnak “bónuszt” adni a jobb betöltési sebességgel rendelkező webhelyek rangsorolásában. 

    Ezenkívül 2020 májusában a Google bevezette a webes életjeleket-a webhely fontos mutatóit, amelyeket 2021.június közepétől használnak a rangsorban. 

    Fontos megérteni, hogy ez csak egy a további rangsorolási tényezők közül. A keresőmotor promóció területén továbbra is fontos a kiváló minőségű tartalom, a helyes webhely-indexelés, a kereskedelmi, viselkedési és egyéb tényezők. 

    Vagyis, ha tökéletes webes vitális mutatókat készítünk, de a webhely oldalai nem válaszolnak a felhasználói kérésekre, ez nem vezet a csúcsra. 

    Ezeknek a paramétereknek a prioritását helyesen kell értékelni az összes többihez képest. Azonban minden más dolog egyenlő, a legjobb internetes Vitals mutatókkal rendelkező webhely magasabb helyet kap a keresési eredményekben, mint a hasonló webhelyek. 

    Jelenleg a webhelyeknek csak mintegy 20% – A felel meg az ajánlott Google értékeknek (az adatok szerint https://corewebvitals.iprospect.com/).

    показатели Web Vitals1

    Szeretném hozzátenni, hogy számos élet hack, hogyan kell csalni,” javítani ” a mutatók. Ebben a cikkben nincsenek ilyen megoldások, mivel érdemes megjegyezni, hogy a minőségi megoldások megkerülésére szolgáló trükkök javítják a keresőmotorok mennyiségi mutatóit, de rontják a webhelygel való kölcsönhatás felhasználói élményét, és végül meglehetősen negatívan befolyásolják. 

    Az alábbiakban megpróbálom részletesebben elmondani az egyes mutatókról, nevezetesen, hogy az egyes mutatókat a lehető legegyszerűbben elmagyarázzam, és hogyan lehet minőségileg befolyásolni. Részletesebben feltárom a “webhely betöltési sebesség mutatóinak javítása” általános ajánlást is, hogy konkrétumokat adjak hozzá: “hol kell keresni/mit kell szerkeszteni”. 

    Tartalom

    Legnagyobb Contentful festék (LCP)

    • Hogyan lehet javítani az LCP-t 
    • LCP fejlesztés
    • Ajánlások

    Első bemeneti késleltetés (FID)     

    • Hogyan javítható a FID
    • A FID (TBT)
    • Ajánlások

    Halmozott Elrendezéseltolódás (CLS)    

    • Hogyan lehet javítani a CLS-t
    • A CLS kidolgozása
    • Ajánlások

    Következtetések 

    Először is, néhány szimbólum, hogy fog történni a cikkben: 

    LCP (legnagyobb Contentful Paint) – megmutatja, hogy mennyi ideig húzódott a legnagyobb tartalom a felhasználó látható részében (az első képernyőn). 

    FID (első bemeneti késleltetés) – felhalmozott adatok, amelyek a böngésző átlagos válaszidejét mutatják az első felhasználói művelethez. 

    TBT (teljes blokkolási idő) – teljes blokkolási idő. 

    CLS (kumulatív Elrendezéseltolódás) – kumulatív elrendezés váltás. 

    FCP az első renderelés a tartalom (nem tévesztendő össze LCP!). 

    TTI – az interaktivitás ideje. 

    Laboratóriumi adatok – adatok a telephely betöltési sebességének egyetlen méréséhez. 

    Mező vagy felhalmozott adatok – egy adatkészlet átlagos értékei a felhasználók által egy adott oldal letöltéseinek száma alapján. 

    A viewport a felhasználó képernyőjének logikai felbontása. 

    Mindezek a mutatók láthatók PageSpeed Insights. 

    Nézzük meg a webhely példáját https://alliancesales.ru/. a nézetablak ebben az esetben az értékek jobb oldalán található képernyő képernyőképe. 

    показатели Web Vitals2

    A fő mutatók, amelyeket a Google meg fog nézni, a következők: 

    1. Legnagyobb Contentful festék (LCP) 

    Az LCP megmutatja, hogy mennyi ideig tartott a legnagyobb tartalom megjelenítése a felhasználó látható részében (az első képernyőn). Például a főoldalon https://alliancesales.ru / a legnagyobb tartalom a banner. 

    показатели Web Vitals3

    Egy jó mutató a felhasználók 75% – ánál akár 2,5 másodpercnek is tekinthető. 

    LCP4

    Az aktuális mutatót a Google Page Speed szolgáltatásban tekintheti meg. Ez a szolgáltatás mind a laboratóriumi adatokat biztosítja egy adott teszthez, mind a felhalmozott statisztikai adatokat. 

    Például itt vannak az oldal mutatói https://alliancesales.ru / mobil eszközök esetén (fontos, hogy mind mobil, mind PC-n megfeleljen): 

    Показатели Web Vitals5

    Láthatjuk, hogy a felhalmozott adatok azt jelzik, hogy a fő látható tartalom átlagos megjelenítési ideje 3 másodperc. A felhasználók 65% – ánál-kevesebb, mint 2 másodperc, de a felhasználók 13% – ánál ez a mutató a “piros” zónában van. 

    A laboratóriumi adatok szerint a mutató sokkal rosszabb, 14,9 másodperc. 

    Milyen elemeket tartalmaz az LCP, amikor kiszámítják: 

    • < img > (mint a példánkban), 
    • < image > elemek belül < svg > (tartalmazhat), 
    • < videó > (tartalmazhat), 
    • elemek egy háttérkép töltött CSS, 
    • blokkszintű elemek, amelyek szöveges csomópontokat vagy a beépített szint más gyermekszövegelemeit tartalmazzák(például egy bevágás a szöveg belsejében, az alábbi képernyőképen). 

    LCP6

    Ha azonban egy elem kilép a nézetablakból, ha egy elemet levágnak vagy láthatatlan túlcsordulással rendelkeznek (például a szöveg egy része spoiler vagy görgetés alatt van elrejtve), akkor ezeket a részeket nem veszik figyelembe az elem méretében. 

    Példák a jobb megértéshez

    Példa 1. 

    Показатели Web Vitals7

    Ebben az esetben a megjelenítés első pillanatában (FCP – 1.lépés) a logó alatt található tartalom-ez a legnagyobb tartalom. 

    2-4. lépés-van egy szöveges blokk a logó alatt, amely a képernyő nagy területét foglalja el. Az első képernyő betöltésének utolsó szakaszában ( 5. lépés) megjelent egy kép, amely a legnagyobb tartalom lett. A kép megjelenítéséig eltelt idő mutatja az LCP jelzőt. 

    Példa 2.

    Показатель LCP8

    Ebben az esetben a tartalom első megjelenítésekor (FCP-1.lépés) egy szöveges blokk jelenik meg a webhelyen, amely a képernyő legnagyobb részét foglalja el. A második lépésben a miniatűrök betöltődtek, de a legnagyobb tartalom változatlan maradt. A harmadik lépésben további tartalom volt, ami az előző legnagyobb tartalom lefelé történő eltolódásához vezetett, a legnagyobb tartalom pedig egy másik szövegblokk volt. A negyedik lépés csak kissé eltolta az alábbi tartalmat. De az ötödik lépésben, az első képernyő betöltésének utolsó szakaszának pillanatában ismét megjelent a kép, amely a megtekintési terület legnagyobb tartalmává vált. 

    A fenti példákban a legnagyobb elem A tartalom betöltésekor változik. Az első példában új tartalom kerül hozzáadásra a DOM-hoz,egy másik elem pedig a legnagyobb. A második példában az elrendezés megváltozik, a korábban a legnagyobb tartalmat pedig eltávolítják a nézetablakból. 

    OLVASS TOVÁBB:  Hogyan készíthetünk és helyezhetünk el történeteket a weboldalon a Flyvi segítségével

    Még néhány példa:

    LCP9

    LCP10

    Az első példában az Instagram logó viszonylag korán betöltődik, továbbra is a legnagyobb elem, még akkor is, ha más tartalom fokozatosan jelenik meg. 

    A példában Google keresési eredmények oldal, a legnagyobb elem egy bekezdés a szöveg, amely megjelenik, mielőtt bármelyik kép befejezni betöltése. Mivel az összes egyes kép kisebb, mint ez a bekezdés, továbbra is a legnagyobb elem a betöltési folyamat során. 

    Figyelem! Az LCP indikátor különbözik a különböző típusú oldalak és az azonos típusú különböző oldalak esetében. 

    Hogyan lehet javítani az LCP-t 

    Az LCP-t elsősorban négy tényező befolyásolja: 

    • Lassú szerver válaszidő (például az adatbázis sebessége; a szkriptek kiszolgálón történő végrehajtásának sebessége; minden, ami a hátoldalon történik; valamint a szerver távolsága a felhasználótól, az Internet sebessége). 
    • JavaScript és CSS a renderelés blokkolásával (először csak a kritikus CSS-t és JS-t helyezze be a kódba, a többit később lehet betölteni, hogy a fő szál ne legyen blokkolva (lusta terhelés használata)). 
    • Erőforrás betöltési idő (csökkentenie kell az átvitt fájlok méretét). 
    • Ügyfél rendering (releváns SPA). 
    OLVASS TOVÁBB:  Milyen a clickbait és milyen

    Az LCP javításával kapcsolatos további információkért lásd az LCP optimalizálást (ez az információ relevánsabb a programozók számára, mint a SEO szakemberek számára, de meg kell értenünk, hogy miről szól, és hol található). 

    Azt is tanácsos tudni, hogy a fő helyszínen teljesítmény javítása technikák, amelyek javíthatják LCP: 

    • Prpl alkalmazása (előtöltés, gyorsulás, gyorsítótárazás, lusta terhelés). 
    • Optimalizálja a renderelési / renderelési folyamatot (például használjon progresszív oldalvisszaadást JS fájlok betöltésével, ha szükséges). 
    • CSS optimalizálás(például, hogy CSS betöltése aszinkron betöltésével fájlokat js). 
    • Képoptimalizálás (használjon modern képformátumokat, használjon progresszív képtömörítést stb.).
    • Optimalizálja a webes betűtípusokat (például kerülje a láthatatlan szöveget, csökkentse a betűméretet/engedélyezze a tömörítést). 
    • JavaScript optimalizálás az ügyféloldali kijelzővel rendelkező webhelyek számára-SPA oldalak, JS-keretrendszerek (például úgy, hogy a HTML-tartalom a felhasználó böngészőjében js használatával, nem pedig a szerveren generálódjon). 

    LCP fejlesztés 

    Az összes problémás oldal adatai megtalálhatók a Google Search Console-ban (engedély szükséges) https://search.google.com/u/1/search-console/core-web-vitals. ez csak azokra a webhelyekre vonatkozik, ahol elegendő “mezőadat”van. Ha nincsenek “mező” adatok, és nincsenek hibák a GSC-ben, akkor a Google Page Speed segítségével ellenőrizze a főoldaltípusokat, hogy felmérje a mező-és laboratóriumi LCP-adatok rendelkezésre állását. 

    Показатель LCP11

    Ezután meg kell találnia az ilyen alacsony LCP értékek okait. Emlékeztetem Önöket, hogy a mutató rosszabb, mint 4 másodperc, rossznak tekinthető. Kívánatos egy 2,5 másodperc alatti mutató elérése. 

    Показатель LCP12

    Nézzük meg a példa oldalt https://alliancesales.ru/. a Google Oldalsebessége szerint az LCP 14,9 másodperc (lab). 

    Показатели Web Vitals13

    A szolgáltatáson keresztül nézve https://gtmetrix.com / LCP csak 4,7 másodperc hosszú. 

    Показатель LCP14

    A Google Chrome böngészőfelügyelőn keresztül történő megtekintéskor (F12 gomb, majd lépjen a Teljesítmény fülre, kapcsolja be a képernyőképeket, váltson mobil eszközökre (például iPhone X)):

    Показатели Web Vitals15

    Ezután futtassa a Ctrl Shift E ellenőrzést (Windows rendszerben). Látjuk, hogy van egy LCP blokk az időzítések szakaszban. 

    Показатели Web Vitals16

    Az LCP 5,9 másodperc. Látjuk a kapcsolódó blokkot is, amelyet csak az ügyfél hatókörében a legnagyobbnak tekintünk (amikor a div felett lebeg, látjuk, hogy melyik elemet tekintik a legnagyobbnak a képernyőn). 

    Показатели Web Vitals17

    Összesen három különböző eszköz mutatott nekünk 3 különböző mutatót: Google Oldalsebesség-14,9 másodperc; GTmetrix-4,7 másodperc; böngésző ellenőr-5,9 másodperc. 

    Ne felejtsük el, hogy az LCP időt befolyásolja a szerver válaszideje, amely folyamatosan változhat, valamint közvetlenül függ a szerver távolságától, valamint a csomópontok számától a csatlakozási láncban. 

    Ajánlások 

    1. Meg kell növelni a szerver teljesítményét a válaszidő csökkentése érdekében. 
    2. Mivel termékképünk a legnagyobb tartalom az oldalon, az első termék képéhez előterhelést használhat. 
    3. CDN hozzáadása. 
    4. Egyéb ajánlások a “Hogyan javítható az LCP”szakaszból. 

    2. Első bemeneti késleltetés (FID) 

    FID-ideje a webhely interaktivitásának. 

    FID18 

    A FID azt az időt méri, amikor a felhasználó először kölcsönhatásba lép egy oldallal (azaz amikor rákattint egy linkre, rákattint egy gombra, vagy egyéni JavaScript-alapú vezérlést használ), amikor a böngésző ténylegesen elkezdheti az események feldolgozását az adott interakcióra válaszul. Egy jó mutató a felhasználók 75% – ának legfeljebb 100 milliszekundumnak tekinthető. 

    Fontos! A FID csak az eseményfeldolgozás” késleltetését ” méri. Nem méri sem az esemény feldolgozási idejét, sem azt az időt, amíg a böngésző frissíti a felhasználói felületet az eseménykezelők indítása után. 

    Próbáljuk megérteni, mi az, egy egyszerű példa segítségével. 

    FID19

    Szimbólumok és szimbólumok: 

    FCP az első renderelés a tartalom (nem tévesztendő össze LCP!). 

    TTI – az interaktivitás ideje. 

    Szürke blokkok az erőforrás kérések (többnyire CSS és JS). 

    Sárga blokkok azok az időszakok, amikor a főoldal megjelenítési áramlása a böngészőben egy ideig elfoglalt. 

    A függőleges fekete vonal mellett a piros nyíl jelzi a felhasználói interakció pillanatát. 

    Ebben a példában a felhasználó véletlenül kölcsönhatásba lépett az oldallal a fő szál legnagyobb terhelésének időszakában (lásd a képernyőt-a nyíl jelzi). Ha a felhasználó egy pillanattal korábban (üresjárati időszakban) kapcsolatba lépett az oldallal, a böngésző azonnal reagálhatott volna. Mivel a bemenet akkor fordul elő, amikor a böngésző egy feladat elvégzésének folyamatában van, meg kell várnia, amíg a feladat befejeződik, mielőtt válaszolhat a bemenetre. Az időtúllépés a felhasználó FID értéke ezen az oldalon. 

    Bár bármely bemenet késleltetése rossz felhasználói interakcióhoz vezethet, érdemes az első bemenet késleltetésére összpontosítani. 

    A FID egy olyan mutató, amely a betöltés során méri az oldal válaszadási sebességét. Tehát csak a műveletek bemeneti eseményeire összpontosít, például kattintásokra, érintésekre és billentyűleütésekre. 

    Fontos megérteni azt is, hogy nem minden felhasználó fog kölcsönhatásba lépni a webhelyen minden alkalommal, amikor meglátogatja. Ezenkívül egyes felhasználók első interakciói előfordulhatnak a patak betöltésekor (sárga blokkok), valamint olyan esetekben is előfordulhatnak, amikor a főáram tétlen. 

    Sajnos a FID nem mérhető laboratóriumi körülmények között, mivel valódi felhasználóra van szükség. A teljes blokkidő metrikus (TBT) (feladat végrehajtási idő egy 50 ms-ot meghaladó menetben) azonban mérhető a laboratóriumban, és jól korrelál a FID-vel. Vagyis a TBT javításának javítania kell a FID-t is. 

    Például nézzük meg az oldal mutatóit https://alliancesales.ru/.

    Показатель FID20

    Látjuk, hogy a terepi mérések átlagos értéke 91 milliszekundum. A felhasználók 75%-ánál kevesebb, mint 100 milliszekundum volt a FID. A felhasználók 13% – ánál a FID több mint 300 milliszekundum. A TBT laboratóriumi adatai 4050 milliszekundum volt. Vagyis a böngésző fő szálát különböző feladatok blokkolták valamivel több mint 4 másodpercig. 

    Hogyan javítható a FID 

    Bár a FID egy terepi mutató, a FID javítására vonatkozó ajánlások megegyeznek a laboratóriumi teljes blokkolási idő (TBT) mutatójának javításával. 

    Néhány olyan ajánlás, amely javíthatja a FID pontszámot: 

    • Csökkentse a harmadik féltől származó kód hatását (távolítsa el vagy csökkentse a kódot harmadik féltől származó webhelyekről/alkalmazásokról). 
    • Csökkentse a JavaScript végrehajtási idejét (például rövidítse vagy tömörítse a kódot, törölje a nem használt kódot, aszinkron betöltést használjon). 
    • Csökkentse a fő munkafolyamatot (például kerülje a nagy és összetett elrendezéseket, minimalizálja a CSS-t, távolítsa el a fel nem használt kódot stb.). 
    • Tartsa alacsonyan a kérelmek számát, valamint az átutalások méretét (a legegyszerűbb módja a nagy fájlok méretének csökkentése az átvitel során). 
    OLVASS TOVÁBB:  Milyen a clickbait és milyen

    A FID (TBT) 

    Az összes problémás oldalon található adatok megtalálhatók a Google Search Console-ban (engedély szükséges), ez csak azokra a webhelyekre vonatkozik, ahol elegendő “mezőadat”van. Ha nincsenek “mező” adatok, és nincsenek hibák a GSC-ben, akkor érdemes megnézni a főoldaltípusokat a Google Oldalsebességén keresztül, hogy felmérje a FID mezőadatok és a TBT laboratóriumi adatok rendelkezésre állását. 

    Показатель FID21

    Emlékeztetem Önöket, hogy a 300 milliszekundumnál rosszabb mutatót rossznak tekintik. Kívánatos 100 milliszekundum alatti érték elérése. 

    Показатель FID22

    A jelentés által a Google Keresőkonzolban található oldalak listájából ki kell választania a legrosszabb mutatókkal rendelkező fő sablonoldalakat. Például vegye be https://alliancesales.ru/. 

    Ellenőrizheti a FID (TBT) mutatókat a Google Oldalsebességében. A részletesebb megközelítéshez használhatja a böngésző ellenőrét. 

    A Google Chrome browser inspector (F12 gomb) menüben lépjen a világítótorony fülre, válassza a mobil eszközök és a teljesítmény lehetőséget, majd kattintson a jelentés létrehozása gombra. 

    Показатель FID23

    A következő képet kapjuk. 

    Показатель FID24 

    Figyelem! Figyelmeztetések jelenhetnek meg, ezért végezze el ezeket a műveleteket egy “tiszta” böngészőben. 

    Показатель FID25

    Látjuk, hogy a TBT mutató 3,0 másodperc volt. 

    A TWT arány csökkentése érdekében részletes elemzést kell végezni az összes összetevőről, és meg kell határozni, hogy az ajánlott 50 milliszekundumot meghaladó hosszú feladatok hol találhatók. A leggyakoribb okok a következők: 

    • A JavaScript felesleges betöltése vagy végrehajtása. Ez akkor történik, amikor a fő szál olyan munkát végez, amelyre nincs szükség az oldal betöltéséhez. A JavaScript terhelés csökkentése a kód felosztásával, a fel nem használt kód eltávolításával vagy a harmadik féltől származó JavaScript hatékony betöltésével javíthatja a TBT pontszámát. 
    • Nem hatékony JavaScript nyilatkozatok. Például a kód elemzése után megjelenik egy dokumentumhívás.querySelectorAll (“a”) (az oldal összes hivatkozásának kiválasztása), amely 2000 csomópontot ad vissza. Ebben az esetben meg kell refactor a kódot, hogy egy konkrét választó, amely visszatér csak 10 csomópontok, ami javítja a TBT pontszámot. 
    OLVASS TOVÁBB:  Hogyan készítsünk videohirdetéseket a Mail.ru Narrator alkalmazásban

    Ajánlások

    Nézzük meg az oldal példáját https://tomdom.ru/vladivostok/komplekti-shtor/. 

    A Google Chrome böngésző ellenőrét (F12) használjuk. Lépjen a világítótorony fülre, állítsa be a mobil eszközök Teljesítménykategóriáját. Kattintson a” Jelentés létrehozása ” gombra (hasonló adatokat kaphat a Google Oldalsebességén keresztül, de gyakran ellenőriznie kell valamit a robotok számára zárt tesztkiszolgálón, ezért DevTools-t használunk). 

    Проверка FID26

    Az optimalizáláshoz a következő adatokat, lehetséges ajánlásokat kapjuk. 

    Показатель FID27

    A nyilak jelzik a fő gyakori okokat, amelyek befolyásolhatják a TBT-t, ennek eredményeként a FID-t. Nézzük meg őket részletesebben, és próbáljuk megérteni általánosságban, hogy mit tehetünk ellene. 

    Fel nem használt JS / CSS kód

    A lényeg az, hogy nem minden JS vagy CSS kód szükséges egy adott oldalon, ezért javasoljuk, hogy ezeket a fájlokat csak azokon az oldalakon töltse be, ahol közvetlenül használják őket. Ez azonban a teljes webhelykód teljes refaktorálásához vezethet. 

    Egy rendszeres webhelyen meglehetősen nehéz újrafényképezni az összes kódot úgy, hogy a szükséges kód csak a kívánt oldalon legyen betöltve. Általában ez lehetetlen, vagy hatalmas időt vesz igénybe, mivel meg kell változtatnia a frontend architektúráját a webhelyen. Nem minden projekt rendelkezik erőforrásokkal ehhez. De a SPA elveire épülő helyszíneken ez a megközelítés lehetséges. Használhatja például az összetevők JS kódjának aszinkron betöltését. 

    Az alábbi képernyőkép azt mutatja, hogy hány JS fájlt töltöttek be, amelyek mindegyike felelős az oldal saját összetevőjéért vagy az oldal egészének kódjáért. 

    Показатель FID28

    De amint egy másik oldalra lép, látni fogjuk (a következő képernyőképet), hogy egy másik JS betöltődött, csak az, amely az új oldalhoz szükséges. 

    Показатель FID29

    Ez a megközelítés lehetővé teszi számunkra, hogy felgyorsítsuk a betöltést, amikor a felhasználó először meglátogatja az oldalt, nem pedig felesleges erőforrásokkal tölti be. 

    Távolítsa el a kijelzőt blokkoló erőforrásokat 

    Ezt a paramétert befolyásolja a JS és CSS futási ideje, valamint az oldalhoz való csatlakozásuk módja. Ideális esetben minden JS-nek aszinkron módon kell csatlakoznia, de ezt nem lehet mindenhol megtenni. Óvatosnak kell lennie a CSS-vel, különben kiderül, hogy az összes CSS aszinkron módon van betöltve, majd a felhasználó egy “csupasz” HTML oldalt fog látni formázás nélkül a betöltés során. A helyükön lévő összes elem “elrendezése” csak a CSS betöltése után következik be. 

    By the way, ezzel a megközelítéssel az elrendezés eltolódik, amelyet az alábbiakban ismertetünk. Csak ehhez be kell vonni a kritikus CSS-t a HTML-be, vagyis a főbe, hogy a Felhasználó legalább egy valahogy megtervezett oldalt láthasson az első másodpercekben, majd csatlakoztassa a többi CSS-t. De nem minden projekt esetében ez a CSS kód kezdeti architektúrája miatt lehetséges. Itt vagy refactor (ami néha még több időt vehet igénybe, mint az eredeti írás), vagy ne érintse meg. 

    A harmadik féltől származó kódex hatásának csökkentése 

    Itt minden egyszerű. Ezt a paramétert általában túlbecsülik, ha számos különböző harmadik féltől származó szkript, például a Yandex.A Metrica és a Google Analytics az oldalon kerül megvalósításra. Ezért nagyon fontos betölteni őket, hogy ne blokkolják a fő renderelési áramlást. 

    Például Yandex. A Metrica alapértelmezés szerint elindította az” aszinkron ” számlálót az utolsó frissítésben. Más külső szkriptek csatlakoztathatók az async vagy defer attribútumok segítségével. 

    3. Halmozott Elrendezéseltolódás (CLS) 

    A CLS az elrendezés stabilitásának mutatója, Vagyis “kumulatív elrendezéseltolódás”. 

    CLS30

    Hogyan néz ki nagyjából https://www.webit.ru/images/layout-instability2.mp4 .

    A videóban a felhasználó a “Nem” gombra akar kattintani, de az elrendezés eltolódik, a kattintás pedig az “igen, küldje el a rendelést”gombra esik. Ezután több kattintás látható a Mégse gombra:). 

    Vagyis a webhelyen vagyunk, de a webhely betöltésével a Tartalom részben eltolódik. A CLS méri az összes egyedi elrendezéseltolódás-becslés teljes összegét minden olyan váratlan elrendezéseltolódás esetén, amely a teljes oldal betöltési ideje alatt történik. 

    Az elrendezés eltolódása minden alkalommal megtörténik, amikor egy látható elem megváltoztatja helyzetét az egyik renderelt keretről a másikra. A jó CLS a webhely felhasználóinak 75% – ánál nem haladja meg az 0.1 értéket. 

    A CLS mérhető mind a terepen, mind a laboratóriumban. Például a kutatási oldal termékprofil oldalán https://alliancesales.ru/catalog/perchatki/perchatki_nitrilovye/perchatki_nitrilovye_benovy_dental_formula_chernye_50_par_up / shift elrendezés mobil eszközök: 

    CLS31 

    A “mező” adatok átlaga 0,39. A CLS-felhasználóknak csak 46% – A kevesebb, mint 0,1. 

    A laboratóriumi adatok 0,475 CLS-t mutatnak, ami azt jelenti, hogy az elrendezést az ajánlott értékekben nem szereplő összeg eltolja. 

    Hogyan lehet javítani a CLS-t 

    A legtöbb webhely esetében elkerülheti az elrendezés minden váratlan eltolódását néhány elv betartásával:

    • Mindig szerepeljen méretjellemzők a képekben és a videó elemekben, vagy más módon foglalja le a szükséges helyet. Ez a megközelítés biztosítja, hogy a böngésző megfelelő mennyiségű helyet foglaljon el a dokumentumban a kép betöltésekor. 
    • Soha ne helyezzen be tartalmat a meglévő tartalom tetejére, kivéve a felhasználói interakcióra adott válaszként.  
    • Az átmeneteket olyan módon animálja, amely kontextust és folytonosságot biztosít államról államra. 

    A CLS javításával kapcsolatos további információkért lásd az optimalizálási útmutatót. 

    A CLS kidolgozása 

    Az összes problémás oldal adatai megtalálhatók a Google Search Console-ban (engedély szükséges. Ez csak azokra a webhelyekre vonatkozik, ahol elegendő “mezőadat”van. Ha nincsenek “mező” adatok, és nincsenek hibák a GSC-ben, akkor a FŐOLDALTÍPUSOKAT a Google Oldalsebességén keresztül is ellenőriznie kell, hogy értékelje a CLS indikátor laboratóriumi adatait. 

    A webhely példáján https://tomdom.ru:

    Friss cikkek

    Kapcsolódó történetek

    HOZZÁSZÓLOK A CIKKHEZ

    Kérjük, írja be véleményét!
    írja be ide nevét

    Maradjon op - Ge a napi híreket a postaládájában