Honlap sebesség optimalizálás és tippek

A jó tartalom után, illetve az mellett a legfontosabb, hogy honlapunk gyors legyen, különben értékes látogatóktól eshetünk el. De nézzük is mitől lesz fürge az oldalunk, sok mindenre kell figyelni. Részletek a cikkben.

Képzeljük el azt a szituációt, hogy keresünk valamit a neten, pár oldalon már túlvagyunk és éppen az aktuális, reményteli oldalt nyitjuk meg és 1-2 másodpercig semmit nem látunk, csak üres, fehér lapot. Nem tűnik soknak az 1-2 másodperc, de ilyen (gyakori) helyzetekben az emberek nagy többsége bezárja az oldalt és keres másikat, nem vár. Több nagy szolgáltató is végzett méréseket, pár eredmény:

Google: "400ms késleltetés 0.59%-kal kevesebb keresést eredményezett felhasználónként."
Mozilla: "Oldalukat 2.2 másodperccel meggyorsítva 15.4%-os konverziónövekedést értek el, ami éves szinten 60 millió letöltést jelent."

Higgyük el, hogy ezek a kis százalékok nagyon sokat számítanak, a Google helyezésünket is befolyásolja, ha gyors a weblapunk, a szerverünket is tehermentesítjük és a látogatók is elégedettebbek lesznek.

Optimalizálási lehetőségek

Minimalizáljuk a http kéréseket, mert minden egyes új szál nyitása, új erőforrás (szerveroldalon is) és plusz idő költség. A CSS és Javascript fájlokat lehetőség szerint csoportosítsuk egy CSS és egy JS fájlba. A képeknél lehetőség szerint használjuk a CSS Sprite technikát.

Csökkentsük a DNS lookup-okat (névfeloldás), ha például CDN-t használunk JS-k behúzására, akkor lehetőleg egy domain alól kerjük be a szükséges fájlokat, mert egy-egy névfeloldás 20-120ms időt eredményez. Gyakorlatibb a példa, ha külső oldalakról képeket jelenítünk meg, 10 kép, 10 domainről az máris közel 1mp csúszás.

Kerüljük az üres src és href tulajdonságokat, mert felesleges szálnyitásokat generáltatunk velük a böngészőkkel.

Ne hagyjunk a kódban olyan külsőhivatkozásokat, melyek elérhetetlenek (404), mert egyrészt feleslegesek, másrészt egy letöltési szálat elpazarolunk.

Használjuk a GZip tömörítést, igaz szervertől és klienstől is függ, de mára szinte minden támogatja. 70% körüli méret csökkenést érhetünk el a szöveges fájlok terén (CSS, JS, HTML).

Használjuk a gyorsítótárat (Cache-Control), így a böngészőnek nem kell állandóan, minden külső fájlt letöltenie, azokat a saját gyorsítótárából is előszedheti. Figyeljünk arra, hogy dinamikusan változó fájloknál ez nem járható út, vagy csak minimális időzítéssel.

.htaccess példa a gyorsítótárazásra:

<ifModule mod_headers.c>
    Header set Connection keep-alive

    # 1 hetes tárazás

    <filesMatch ".(jpg|jpeg|png|gif|swf|ico|pdf|flv)$">
        Header set Cache-Control "max-age=604800, public"
    </filesMatch>

    # 4 napos tárazás
    <filesMatch ".(xml|txt|css|js)$">
        Header set Cache-Control "max-age=345600, proxy-revalidate"
    </filesMatch>

</ifModule>

A gyorsítótárazás idejét mindenki maga állapítsa meg, de ajánlott legalább 1 hetes lejáratot megadni.

Csoportosítsuk a CSS linkeket egy helyre, a HEAD tegen belülre, így nem csak átláthatóbb lesz a kódunk, de a böngészők is sokkal gyorsabban tudják az oldal renderelését végrehajtani.

Csoportosítsuk a JS fájlokat a kód végére lehetőségünkhöz mérten, egyrészt, hogy ne pazaroljuk a párhuzamos letöltési szálakat láthatatlan elemekre, másrészt, a letöltött Javascriptet a böngésző le is futtatja már az oldal letöltési fázisában, így a megjelenítéstől vonunk el erőforrást. Ha a JS fájlokat a HTML kód végére tudjuk tenni, akkor csak miután a honlapunk megjelenik, fogja azokat lefuttatni.

A CSS és JS tartalmakat külső fájlként húzzuk be, mivel így azokat a böngésző a gyorsítótárból veszi elő, és nem kell minden alkalommal letölteni a HTML-vel együtt.

Minimalizáljuk (Minify) a CSS és Javascript fájlokat, ezt nagyszerűen kombinálhatjuk közös fájlba csoportosításnál, így simán 20-25%-kal kisebb méretet kapunk. Ha úgy gondoljuk a GZip miatt ez felesleges, tévedünk, átlagosan 5%-kal kisebb méretre tömöríti a GZip a minimalizált fájlokat.

Pár online tömörítő:

Kerüljük az átirányításokat, nagyon hasznosak a 301 és 302-s átirányítások, SEO-nál sokszor elengedhetetlen, de óvatosan bánjunk velük, mert egy átirányítás akár 200-300ms-ba is kerülhet. Képzeljük csak el, ha 5-6 Javascript és 4-5 CSS fájlt olyan útvonalról kérünk le (rosszul beállított), ami minden lekérésnél egy plusz átirányítást végez.

Csökkentsük az AJAX kérések tartalmát, ne előre elkészített teljes HTML oldalakat, vagy részeket töltsünk le a kérések alkalmával, lehetőleg csak a megjelenítendő adatokat kérjük le és azok megjelenítését a böngészővel végeztessük. Nagy forgalmú rendszereknél ez elengedhetetlen.

Elemek előtöltése, vagyis ha egy-egy képre, vagy külső fájlra nincs azonnal szükségünk, akkor azt Javascripttel betölthetjük miután az oldalt már a böngésző láthatóvá tette. Így szintén nem lassítjuk az oldalunk betöltését olyan elemekkel, amikre azonnal nincs szükség.

Lehetőség szerint minél kevesebb DOM elemet használjunk. Minél több elemből áll az oldalunk, a böngész annál lassabban lesz képes azt megformázni, megjeleníteni.

Minimalizáljuk a DOM hozzáférések számát, lehetőleg, ne Javascripttel javítsuk a design hibákat.

CSS behúzásra az @import helyett a <link>-t használjuk, vagy még inkább tegyük közös fájlba a CSS-ket.

Optimalizáljuk az oldalon megjelenített képeket, ha nem szükséges ne 100%-s JPG tömörítésű képeket tegyünk fel. Általában elég 85-90% körüli JPG tömörítést használni, rengeteg méretet spórolhatunk meg. Áttetsző képek esetén, ha azok 256 színnél kevesebbet használnak, akkor a GIF a nyerő, nem avult el, nem kell félni tőle. Ha viszont 256-nál több színnel kell dolgozni, akkor PNG24. A JPG képeknél pedig tömörítsünk progressive-n, így a kép bár nem azonnal lesz szép, de hamarabb kapunk eredményt a megjelenítés során. Ehhez egy kis kitérő: http://webstack.hu/cikk/kepek-optimalizalasa

Használjuk a CSS Sprites technikát, a sok kis képet (nyilak, ikonok, jelek stb…) tegyük be egy PNG-be (256 színű ikonok esetén PNG8) és a background-position-nel szépen meg tudjuk jeleníteni a kért elemeket. Így ha például 8 különböző képet kell megjeleníteni, 8 helyett, csak 1 képet kell letölttetni a böngészővel.

Ne méretezzük a képeket, ha egy 100x100px képet kell megjeleníteni, akkor az eredetileg is legyen akkora, ne egy 2-3x nagyobb képet méretezzünk be width/height segítségével. Így kisebb a letöltött kép mérete, és a böngészőnek sem kell a méretezéssel foglalkoznia.

Használjuk a képek width/height tulajdonságait, így a böngészőnek nem kell a méretezéssel törődnie.

Mindig legyen egy elérhető favicon.ico ikonod, legyen kicsi és a gyorsítótárazás legyen beállítva rá is. Jobb mintha a nem lenne és a böngésző fölöslegesen 404-be futna.

A külső elemeket (képek, js, css stb…) a lehető legkisebb méreten tartsd, gondolj a mobilos felhasználókra. A „régebbi” mobilok 25K méretnél kisebb elemeket gyorsítótáraznak csak.
(http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/)

A közösségi elemek mindig lassítják az oldalunkat, ezért csak annyit és ott használjunk belőlük, amennyi szükséges. Például egy oldalon ne legyen 5-10 lájk gomb, mert azok megjelenítés sok erőforrást, igényel. Ha ez elkerülhetetlen, akkor mindenképp aszinkron módon oldjuk meg, hogy az oldalunk letöltését ne hátráltassa.
(példa aszinkron Facebook like gomb renderelésre: http://www.dynamicart.hu/blog/facebook-like-gombok-betoltese-rejtett-divben.html)

Vitatott lehetőségek

CDN használat, pár nagyobb cég, mint a Google vagy Microsoft ingyenes tartalomszolgáltatást nyújt és a legtöbb Javascript keretrendszer verzióit tőlük is letölthetjük, így nem a saját szerverünk forgalmát terheljük ezzel. Viszont hátrányai is vannak a dolognak, mint például a névfeloldással vesztett idő, vagy a rendelkezésre állás.

Osszuk el a tartalmat domainek között, így maximalizálhatjuk a párhuzamos letöltés lehetőségét. Vigyázni kell azonban, hogy maximum 2-3 különböző domaint adjunk meg, mert különben a DNS lookup (névfeloldás) több időt vesz el, mint amennyit a gyorsabb letöltéssel nyernénk.

Használjuk a PHP Flush()-t, ha egy oldal lekérést indítunk egy szerver felé, a szervernek általában 2-500ms időbe telik mire a HTML vázat legenerálja és átadja a böngésző felé. Ezt az időt értékesen is eltöltheti a böngészőnk, nem csak várnia kell a teljes HTML kódot. Ha a <HEAD> és a <BODY> közé beteszünk egy flush(); PHP parancsot, akkor a már elkészült HEAD részt már küldi is a szerver a kliensnek, amíg a BODY-t készíti a szerver, a böngészőnk már rég a HEAD-ben található CSS és JS fájlokat kezdi behúzni. Nem minden CMS-nél használható.

Mentsük le a külső Javascript fájlokat. A külső hirdetési vagy egyéb más féltől származó Javascript fájlokat lementhetjük és a saját Javascriptjeinkkel egy fájlba csoportosítva is használhatjuk. Így csökkent a névfeloldási idő (DNS lookup), csökken a letöltési szálak mennyisége, viszont figyelni kell, ha az adott szolgáltató Javascriptje frissül vagy megváltozik, akkor nekünk is frissítenünk kell azt.

Honlap sebesség/teljesítmény teszterek

Természetesen lehetőségünk van honlapunk teljesítményét felmérni, valamint az teszterek bőséges információval is ellátnak, mit és hogyan kellene csinálunk, javítanunk.

A fent említett lehetőségeket csak ajánlások, nem garantálják az oldalad betöltési sebességének javulását!

Ha tetszett a cikk, véleményed van, kiegészítenéd vagy hibát találtál, írj a cikk alatt egy kommentet, vagy írd meg emailben.

Legnépszerűbb cikkek

Buy and Trade Bitcoin at Binance