A több, mint 2,5 éves tapasztalatokkal rendelkezem a Google PageSpeed Insights terén. Arra gondoltam segítek a webfejlesztőnek, hogy gyorsítsa fel a weboldalait és ez alapján jókat értékeljen a Google, mert csak így szépen indexelni fog a találati listában. Nemcsak ez, hanem a látogató viselkedése szempontból nagyon fontos, hogy valamelyiknél probléma miatt nagyobb eséllyel vissza fognak lépni, azaz visszafordulási aránya növelni fog, ezt mindenképpen el kell kerülni, csak akkor, ha szépen sebességet optimalizálva vannak.
Megjegyzés: ez csak 2018 június végéig annak a verziója érvényes volt, ezért 1. rész. Mert azóta, azaz 2018 július óta megváltozott.
Lassú mobil hálózaton(3G) általában 3mp jó (bár ezt Google elvárja, de szerintem elfogadható, ha kb 5-15 mp, mert különben gyenge felhasználói élmény miatt több lesz visszafordulási arányok száma). 4G vagy otthoni kábel /wifi internet esetén jó, ha hamarabb mint 3 mp és igen megvalósítható.
Én bár 100/100 pontot tudtam teljesíteni, de 1-2 okokból csak minimum 90/100 -ot voltam hajlandóan teljesíteni. Hogy miért? (A lenti Analytics és Render blocking CSS/JS címsor alá található a részletek) Itt meg lehet nézni a képen az eredményt, adatvédelmi okokból cenzúráztam a webcímet.
Összegyüjtöttem a legfontosabb teendők és megosztom mindenkivel:
Képek optimalizálása
A képeket optimalizálással minél több felesleges bájtokat felszabadítani, hogy minél gyorsabban töltsön fel az oldalt:
- Többféle formátumok vannak, de sorrend szerint támogatom: 1. SVG (jelenleg egyelőre logókra, később terjeszkedni fog), JPG. Nagyon ellenzem a PNG-t, mert nagyon sok bájtot fogyaszt, aminek köszönhetően lassan tölti be az oldalt. Ezért lehetőség szerint PNG-ről JPG-re konvertáljuk.
- Átméterezni szükséges, megfelelő méretekre. Mondok egy példát: egyik boxra lett helyezkedve a képméret szerint szélessége 2000px, ez nagyon sok, hisz desktopon 4db, tableten 2db, mobilon pedig 1db box tartózkodik, ezért javaslom átméretezni, mondjuk 400px legyen, ezalatt több bájtot felszabadíthatja.
- Pucoljuk ki a felesleges minőségeket és meta adatokat.
- Kit érdekel a földrajzi adatok és a fényképező adatokról? Törölni szükséges.
- Kódolni kell a képminőséget, hogy kevesebb legyen mobiladat forgalom és gyorsabb legyen, interneten van sok képek compress online vannak kint, tessék használni.
- Javaslom használni width=”” és height=”” tulajdonságot, mert enélkül a böngészőn felesleges egy plusz lépéssel számolgatni, hogy mennyi a szélessége/magassága.
- Nagy képeknél, például slidereknél javaslom CSS Sprite-t használni, mert azzal gyorsabban lehetne.
Fájlok csoportosítása 1-1 fájlba
Több helyett egy léptetés érdekében össze kell csoportosítani 1-1 fájlba, tehát lehetőleg összesen 1db CSS és 1db JS fájl legyen, mert azzal spórolni lehet a HTTP kéréseket, tehát egyes új szál nyitása, új erőforrás és plusz idő töltődés. CSS, JS és HTML tömörítése
Interneten nagyon sok jó online compressor generátorok vannak, érdemes használni.
Szükséges, mert segít kiszedni a felesleges tabokat, a sortöréseket és az enter ütéseket, ráadásul kiszedni a kommenteket, végén akkor több százalékot felszabadíthatja és gyorsabb lesz.
Nem támogatom a CDN-t
Bár a cacholáshoz (gyorsítótárazáshoz) jó, gyors, hisz ez segítségével nem kell újra letölteni a látogatónak a fájlokat, mert másik weboldalakról, ahol ugyanazon CDN-es url-val be van húzva, ilyenkor le van mentve a böngésző gyorsítótárában. De ha bármi történik a szerverrel, akkor elérhetetlen lesz, ami azt jelenti, hogy nem fog jól megjeleníteni az oldal.
Másik meg CDN-t használatakor CSS-t vagy JS-t általában 20-200ms több időt igényel, ezért jó ha saján domain alá helyezni.
CSS fájlban nem szabad használni import-ot
Nem javaslom használni a CSS fájlban külső CSS fájlt behúzni, mert újabb egy lépéssel tölti be az oldalt, emiatt egy lépéssel lassabb lesz a sebessége.
Betűtípusok optimalizálása
Ne használjon sok betűtípust, helyett inkább elég 1-2-őt.
Google Web Fonts-nál megadhatjuk paraméternek a használni kívánt betűtípusokat, így nem kell két elem miatt több száz betűtípust letölteni.
Vagy egyszerűbb javaslom használni, mert azzal aszinkron-nal tölti be: Webfont Loader. Előtte érdemes olyan betűtípust választani, hogy jól nézzen ki a Google Fonts kikapcsolás esetén, mert Webfont Loader-hez JS szükséges és azzal késlelteti a betöltésére, hogy teljes tartalom jelenjen meg, csak azután a kiválasztott Google Fonts betűtípust jelenik meg.
Ikonok optimalizálása
Több helyett egy db ikon katalógust használni. Találkoztam már azzal, ahol egy weboldalon többféle css fájlt használtak, azaz egyszerre például: font awesome, flaticon, iconfont.
Ennek van hátránya, hogy egyszerre együtt több fájt(woff, woff2, svg, stb) csatolva lettek és ennek köszönhetően több időt töltödik és több léptetés. Ezért javaslom elég csak egyik katalógust használjuk és belül úgyis több ikon választék van, amiben biztos vagyok benne, megtalálhatja amit szeretne látni.
Belső linkek átirányítása helyett javítása
Amikor történik a menü átnevezés vagy áthelyezés vagy törlés, ilyenkor mindenképpen a weboldalon ki kell javítani a belső linkeket. Bár htaccess-ban mindenképpen redirect-elni kell az új url-re, de arra való, hogy akinél le van mentve vagy marad a Google listában régi url, ott tudjanak használni, különben 404 oldalt kap.
Miért ne legyenek már ennyire lusták a belső linkek javítása, mert gondolják elég htaccess-ra rakni egy redirect-elés? Mert ott annyi gond van, hogy általában akár 100-300ms időbe is kerülhet, ezért mindenképpen jár a belső linkek módosítás.
htaccess - gzip és gyorsítótárazás (cache)
Érdemes használni a GZip tömörítést, mert segít fájlokat tömöríteni a szerveren és gyorsabb lesz. A gyorsítótárazásnál pedig inkább arra való, hogy a visszatérő látogatóknak a böngészőjük alatt nem kell állandóan újra betölteni, így gyorsabb lesz. Én ilyenkor csak a fontos fájloknak adom meg 1 évet a gyorsítótárazásra: js, css, képek és fonts. Csak arra kell figyelni, hogy például: történt az egyik helyen képcsere, de más-más alakzat van rajta, ilyenkor érdemes más fájlnevet megadni, mert nehogy ragadjon be a cache, hisz látogatók nem tudják mi a teendő, amikor beragadt a cache.
Analytics, Social, Salesmanago, és egyéb külsős/más féltől származó JavaScriptek
Ilyen fájlokat érdemes lementeni és beletenni a saját domain tárhely alá és cron használatával létre kell hozni a php fájt és oda beletenni a valódi javascript behúzást és akkor PageSpeed jót pontozni fog.
Itt van részletes útmutató: http://themefreak.net/blog/how-to-cache-google-analytics-code/
Hátránya: Bár az én szívem szerint nem javaslom, kihagynám, hogy Google rinyáljon, mert local-ként be kell tenni JS fájlt és ezzel van gondom, hogy amikor külső nál Analytics fejlesztők módosítanak valami aprót és akkor nem fog jól megjeleníteni a mérésen.
Render blocking CSS/JS (A megjelenítést gátló JavaScript és CSS kizárása a hajtás feletti tartalomban)
Itt van részletes útmutató: https://www.sitelocity.com/critical-path-css-generator
Hátránya: mivel head tag közé be kell tenni a kritikus CSS megjelenítés inline style használatával és body záró tag fölé helyezkedni aszinkron js-vel késleltetni CSS fájlt. Itt az a gond, hogy kritikus CSS-nál csak az a jó, ha adott oldalhoz tartozik. Amikor a böngészőben ki van kapcsolva JS, ez esetén a másik oldalon már nem fog jól megjeleníteni a design CSS tulajdonságok, mert hiányoznak a kritikus válogatások miatt. Ezért azt is kihagynám.
0 Megjegyzések