Február 26-án a Google hivatalosan bejelentette, hogy 2015. április 21-től jön egy új algoritmus frissítés, amiben a mobilbarát webhely megléte még fontosabb rangsorolási tényező lesz. Emellett pedig elkezdik használni az indexelt mobil applikációkból nyert információkat is a rangsoroláshoz. Két nappal korábban, február 24-én egy indiai bloggernek sikerült elcsípnie Androidon, inkognitó módos böngészés közben, hogy a Google egy új címkét tesztel a találati listában. Ha ez globálisan elérhetővé válik, akkor a lassabb oldalak megkülönbözető, hátrányos jelölést kaphatnak és minden bizonnyal hátrább sorolódnak a találati listákban.

A sebesség eddig is jelentős rangsorolási faktor volt, mostantól azonban még tovább növekedik a szerepe. Minden webhely tulajdonosnak törekedni kell a gyors betöltésre, hiszen ez az egyik legkönnyebben mérhető és riportálható tényező. A felhasználók utálják a lassú oldalakat, a sebesség a konverziós arányra is jelentősen kihat. Az oldalak többsége átlagosan 7 másodperc alatt töltődik be, 1 másodperces lassulás a betöltési időben 11%-kal kevesebb oldalmegjelenítést, 16%-kal kevesebb vásárlói elégedettséget, 7% konverzióveszteséget okoz.

Az oldal betöltési idő hatása a konverzióra

A Walmart esetében a betöltési idő 1-ről 4 másodpercre történő növekedése a konverziók jelentős csökkenését okozta. Az e-kereskedelmi oldal állítása szerint átlagosan minden 1 másodperc betöltési idő javulás 2% konverzió növekedést okozott.

További példák a sebesség jótékony hatására:

• az Amazon esetében 0,1 mp oldal gyorsulás 1% bevétel növekedést okozott
• a Shopzillánál 6-ról 1,2 mp-ra gyorsulás 12% bevétel növekedést és 25%-kal több oldalmegtekinést eredményezett
• a Yahoo 9%-kal növelte a forgalmát minden 0,4 másodperces oldal gyorsítással
• a Mozilla 60 millióval több Firefox letöltést ért el évente azzal, hogy 2,2 másodperccel felgyorsította az oldalai betöltési idejét
• a Google esetében 0,4 mp késleltetés 0,59%-kal kevesebb keresést eredményezett felhasználónként

Javaslatok a sebesség optimalizáláshoz

HTTP kérések minimalizálása

Általában a betöltési idő 80-90%-a a front-endre megy el. Sok ideig tart letölteni és megjeleníteni az oldal összes összetevőjét, pl. a képeket, stíluslapokat, szkripteket. Az összetevők számának lecsökkentésével a HTTP kérések is minimalizálhatók, ez kulcsfontosságú a gyorsabb oldalakhoz. Minden új HTTP kérés (például kép, JS, CSS fájl letöltése) a webszerver felé plusz erőforrás és ezáltal idő növelő tényező. Kerülni kell az üres src és href tulajdonságokat, mert felesleges kéréseket generálnak. Ne legyenek a HTML kódban elérhetetlen és 404-es külső hivatkozások.

DNS lekérdezések csökkentése

A DNS lookup-ok, a névfeloldási lekérdezések keresik meg a hostnév számára az IP címet. A böngésző várakozik mindaddig amíg ez a lekérdezés tart, így ezek csökkentésével jelentős idő takarítható meg. Az egyedi hostnevek alacsony számára kell törekedni, ha lehetséges, akkor egy domain alól töltődjenek be az összetevők. Például a közösségi modulok (like boxok, megosztás gombok) és a külső oldalakról betöltött képek mind mind lassítják az oldalbetöltést. Gyakorlatilag egy-egy DNS névfeloldás 0,02-0,12 másodperc időbe kerül. Például 10 fájl különböző domainről történő betöltése közel 1 másodperces késleltetést okoz a betöltési időben. A webhely válaszidejének mérésére alkalmas eszköz a Pingdom Website Speed Test.

Átirányítások minimalizálása

Minden redirect új HTTP kérést generál, így csak azokat az átirányításokat szabad megtartani, amelyek mindenképpen szükségesek, például egy URL végleges elköltözése esetén. Kerülni kell az átirányítási hurkokat, közvetlenül a végső URL-re kell redirectelni a közbülső átirányítások mellőzésével. A belső linkelés során ügyelni kell a frissített URL-ek használatára. Figyelembe kell venni, hogy egy átirányítás 0,2-0,3 másodpercbe is kerülhet. Gyakorlatilag, ha 10 Javascript és CSS fájl rossz elérési útról kerül lekérdezésre, az több másodperc késlekedést is okozhat.

Példa a PHP-val történő 301-es átirányításra:

GZip tömörítés használata

A GZip tömörítés használata szervertől és klienstől is függ, de nagyfokú támogatásnak örvend, gyorsítja a válaszidőt a HTTP átvitel során. Szöveges fájlok (HTML, CSS, JS) esetében akár 70%-os fájlméret csökkenést lehet elérni vele. GZip compressor/decompressor eszköz.

Apache webszerveren mod_deflate használat

Példa a tömörítés bekapcsolására a .htaccess fájlban:

PHP-ban is használható:

GZip tömörítést ellenőrző eszköz

Gyorsítótárazás

A gyorsítótárazás segítségével a böngésző nem tölti le állandóan a webszerverről a külső fájlokat, hanem a gyorsítótárból tölti be azokat. A látogatók 40-60%-a üres cache-sel tekintik meg az oldalakat, ezért kritikus számukra is megfelelő sebességgel betölteni azokat.

Példa a .htaccess fájlban a JPG és JPEG képek egy hetes gyorsítótárazására:

Fontos megemlíteni, hogy nem szabad túlzásba vinni a gyorsítótárazást, mert a látogatókat frusztrálhatja akár egy e-kereskedelmi oldal esetén, ha már elévült információkkal találkozik például a kosarában. Sok látogató nem tudja, hogy a CTRL+F5 billentyűkombinációval tudja frissíteni a gyorsítótárat.

Minél kevesebb DOM elem használata

Amikor egy oldal betöltődik, akkor a böngésző elkészíti a Dokumentum Objektum Modellt (Document Object Model). Ha kevesebb elemből áll az oldal, akkor a böngésző gyorsabban megformázza és megjeleníti.

Minimalizálni kell a szükségtelen elemek számát a DOM-ban. Ahol lehetséges, ott a tartalom inkább szöveges formában jelenjen meg a kép helyett. Fontos, hogy a layout elrendezés formázására, igazítására ne Javascript legyen használva hanem CSS. A böngésző konzolban az alábbi sorral lehet lekérdezni az elemek számát a legkönnyebben:

Képek optimalizálása

Képek tömörítése

A webhelyeken ne legyenek tömörítetlen képek. A JPEG formátum esetében például beállítható a tömörítés mértéke (Adobe PhotoShopban pl. "Save for web" opcióval lehet tetszőlegesen tömörítve elmenteni a képeket). A progresszív tömörítés lehetővé teszi a kép pixeles, de azonnali megjelenítését, amely a kép teljes betöltődésével folyamatosan javul. Az áttetsző, transzparens képek megjelenítésére több megoldás is létezik. A 256-nál kevesebb színt tartalmazó képek számára a GIF formátum az előnyös. Ha ennél több színre van szükség, akkor a PNG24 a jobb választás.

Képekből képcsomag (sprite létrehozása)

A kisebb méretű képek (például logók, ikonok, jelek és közösségi szimbólumok) külön-külön történő betöltése helyett a különálló képek CSS sprite-ba összefűzésével, egy HTTP kéréssel több kép tölthető be és jeleníthető meg. Ezután a kódban meg lehet határozni (CSS background-positionnal), hogy az összefűzött kép melyik szelete hol jelenjen meg. CSS sprite generátor eszköz.

Kép méret specifikáció

Legyen a HTML kódban specifikálva a kép mérete width és height attribútumok használatával. Kisebb méretű megjelenítésnél ne legyenek átméretezve a képek. A különböző képméretek, pl. a reszponzív képek kiszolgálása különböző fájlokkal történjen.

Média lekérésektől függő képbetöltés

A <picture> elem natív módon teszi lehetővé a média query-től függő képbetöltést. Ezzel a megoldással mellőzhető a CSS és Javascript általi bonyolult megvalósítás és jelentős adatforgalom spórolható meg, hiszen a kisebb kijelzőjű eszközre kisebb méretű képet lehet letölteni. A böngésző a megadott tulajdonságok alapján dönti el melyik képet jelenítse meg az adott eszközön.

Példa a média lekérdezésektől függő képmegjelenítésre:

Képek kiszolgálása

Lehetőség szerint az oldalon megjelenített képek saját webszerverről legyenek kiszolgálva. Ezáltal a DNS névfeloldás (lookupok) is csökkenthetők.

A Yahoo! YSlow Smush.it egy veszteségmentes eszköz, amivel tovább csökkenthető a fájl mérete, eltávolítva a szükségtelen byte-okat.

Inline képek Data URL-ekkel

A böngészők támogatják a Data URL-eket, ahol maga az URL tartalmazza a kép megjelenítéséhez az adatokat. Ezzel a módszerrel újabb fájl letöltés nélkül jeleníthetők meg képek az oldalon. Mindez egy olyan szöveges adat, ahol a bináris adat szövegessé van alakítva base64 kódolással. Példa erre:

Data URL generátor eszköz.

CSS és JS optimalizálása

CSS elhelyezése head-be

A stylesheet a HTML kód head részébe kerüljön, így a renderelés gyorsabban tud elkészülni a böngészőkben. A stíluslapok headben történő elhelyezésével megakadályozható az oldal folyamatos újrarenderelése. A W3C szabványoknak megfelelően külön kell választani a megjelenést a tartalomtól, így a HTML kódban az inline CSS formázásokat kerülni kell, pl.:

Az inline stílusok helyett a külső CSS fájlban állíthatók be a megjelenésre vonatkozó szabályok:

A CSS fájlban a megjelenítéshez használt deklarációk lehetőség szerint csak egyszer legyenek alkalmazva.

CSS és JS fájlok külső fájlból történő betöltése

Külső fájlból legyenek betöltve a CSS és JS fájlok, így a böngésző gyorsítótárazni tudja őket, nem kell minden oldalfrissítésénél letölteni őket újra. Legyenek összevonva egy-egy fájlba és minimalizálva a CSS és a JS fájlok, így sokkal kisebb méretűek lehetnek. Eszköz a JS fájlok tömörítésére.

A külső CSS betöltésére az @import helyett a link tag használata előnyösebb, pl.:

helyett legyen:

JavaScriptek elhelyezése az oldal aljára

A JS fájlok a HTML kód végére (közvetlenül a záró tag elé) történő elhelyezésével elérhető, hogy a böngésző csak az oldal betöltése után futtassa azokat, jelentősen gyorsítva így a megjelenést.

Ha bizonyos képekre vagy külső elemekre nincs szükség az oldal betöltődése során, akkor azok Javascripttel betölthetők a teljes megjelenítés után, miután a böngésző lerenderelte az oldalt. A böngésző a Javascript kód futtatásakor leállítja a HTML tartalom letöltését és csak a JS futtatást követően folytatja azt. Az async attribútummal a Javascriptet a HTML elemzés során tölti le a böngésző és a letöltést követően a HTML elemzés leáll, majd ezt követően fut le a JS. Ez akkor előnyös, ha a szkript nem függ más (HTML) elemtől. A defer tulajdonság hozzáadásával a JS a HTML feldolgozás alatt töltődik le, majd csak a HTML teljes letöltődése után fut le. Ez akkor jobb, ha a szkript függ másik JS-től, vagy HTML elemtől.

Példák a különböző módon beltöltött Javascriptekre:

Fontos megemlíteni, hogy a böngészők általában egy webszerverről egyszerre csak néhány szálon töltenek le párhuzamosan, így nagyobb JS a HTML head részében megakadályozhatja a feldolgozást, megnövelve a betöltési időt.

CDN használat

A CDN (Content Delivery Network) tartalomszállító hálózatok leggyakoribb használata általában a JavaScript keretrendszer verziók (pl.: jQuery, MooTools, Prototype) távoli domainről történő kiszolgálására terjed ki. Ilyenkor többnyire a legfrissebb stabil verzió kerül betöltésre, egy dedikált, gyorsítótárazott, gyors válaszidejű helyről, a felhasználó számára leggyorsabban elérhető hálózatról, megkímélve így a saját oldalt kiszolgáló webszerver forgalmát. Hátrányai lehetnek a DNS feloldás ideje, vagy az adott CDN rendelkezésre állása. A Google által hosztolt keretrendszerek, pl. a legfrissebb jQuery:

Oldal sebesség tesztelő eszközök

• Google PageSpeed Insights
• GTmetrix
• Pingdom
• YSlow