Reszponzív weboldalkészítés 2017-ben - egy szép weboldal már nem elég!

Nem, nem az ellenőrzés. Persze, az is sokszor: elméletben a megjelenítésre használt keretrendszer tudja a reszponzivitást, vagy úgy írjuk meg, hogy tudja, viszont - túlzott önbizalom vagy feledékenység miatt - nem ellenőrizzük le mobilon is a weboldal összes kis szegletét. Így benne maradnak olyan megjelenítési hibák, melyek csak mobil eszközön jönnek elő, vagy esetleg kiderül egy megoldásról, hogy az nem kényelmes mobil eszközön. A weboldal ezektől függetlenül megkapja a mobilbarát weboldal minősítést a Google-től, de ettől az oldal nem, vagy rosszul működő része a felhasználókat még idegesítheti, ami végső soron oldalelhagyást, rossz esetben a márka iránti bizalomvesztést eredményezhet.

De amiről most valójában szeretnék beszélni, az a betöltési (és megjelenítési) sebesség.

Az oldalbetöltési sebesség

Ez a "mérőszám" azt jelöli, hogy milyen gyorsan tudjuk az adatot átvinni a felhasználó eszközére azt követően, hogy ő elindítja az oldallekérést (pl.: leüti az Enter billentyűt, rákattint az oldalunkra mutató linkre, stb.). Ebben többek között szerepet játszik:

• a szerverünk sebessége, ezzel szoros összefüggésben az oldalt előállító kód hatékonysága (TTFB = time to first byte),
• a szerverünk konfigurációja,
• a gyorsítótárazás,
• a gzip tömörítés,
• a megjelenítést blokkoló CSS és JS fájlok betöltési sorrendje és betöltési módja,
• a CSS és JS fájlok, a HTML kicsinyítése,
• a nem megfelelően méretezett képek használata, a kezdeti betöltéskor szükségtelenül betöltött képek betöltése.

A felsorolás példálózó jellegű, ez a téma bőven túlmutat jelen cikk keretein, de látszik, hogy nagyon sok faktort kell figyelembe venni, amikor azt mondjuk, hogy egy weboldal "gyors". Persze, gyors - de melyik része?

A fentiek optimalizálására nagyon sok leírás érhető el a neten, kifejezetten hasznos oldal a varvy.com, ahol tesztet is futtathatunk, a teszteredmények mellett pedig rögtön megjelenik a javításra tett javaslat is.

.htaccess fájl példa

Ami nagyon sokat tud dobni az oldalunk sebességén és a Google Pagespeed Insight értékelésén, az a megfelelő .htaccess fájl konfigurációja. Fontos, hogy .htaccess fájlt akkor érdemes használni, ha osztott tárhelyet használunk (shared hosting), amennyiben VPS-ünk van, érdemes lehet rendszerszinten beállítani a webszerverben ezeket a paramétereket, ezzel is teljesítményt nyerve.

Az alábbi részlet az ezen az oldalon használt konfiguráció egy részlete:

Érdemes egy próbát tennetek ezzel a konfigurációval, mert tényleg érdemi javulás érhető el vele: megoldást ad az erőforrások szerver és kliensszintű gyorsítótárazására és engedélyezi a gzip tömörítést is. A CSS, JS és HTML kicsinyítést kódszinten, illetve az éles környezet előállítása során érdemes megoldani, erre task runner használata (pl. gulp) ajánlott, illetve a tartalomkezelő olyan beállítása, hogy a HTML kimenetet minifyolja. Ezt a Craft CMS esetén a {minify} tag használatával érhetjük el.

Fontos, hogy a .htaccess fájl egy nagyon erős eszköz, de az egész weboldalt elérhetetlenné tehetitek akár 1 karakter elhibázásával is. Semmiképpen se a weboldal adminisztrációs felületén keresztül szerkesszétek - miután biztonsági másolatot készítettetek róla -, nehogy hiba esetén kizárjátok magatokat! Ha baj van, keress bizalommal!

Megjelenítési sebesség

Biztosan találkoztatok már azzal a jelenséggel, amikor a weboldal tölt, tölt, és csak akkor jelenik meg a tényleges tartalom, amikor már a teljes weboldal betöltött - minden utolsó kis Facebook és közösségi megosztó modul, az oldal alján található, jelenleg éppen láthatatlan kép, stb. Ez - főleg, ha gyorsan kell valamit megnéznünk - NAGYON dühítő tud lenni. Ennek egy lehetséges megoldása, ha a nem szükséges tartalom betöltését időben eltoljuk, és csak akkor kezdünk neki, amikor már nyugodtan böngészi az oldalt a felhasználó.

A képek on-demand betöltésére egy jó megoldás az aFarkas által fejlesztett lazysizes JavaScript plugin: érzékeli, hogy a képhez közeledik a görgetéssel a felhasználó, és elindítja a betöltést, amikor elkészült, lecseréli az addig otthagyott alacsony felbontásút a szép, jó minőségű képre. Ezt az ebben a cikkben megjelenő képek esetén láthatjátok éles működés közben is.

A szükséges JavaScript és CSS fájlok betöltésének késleltetésére is van lehetőség. A gyakori megoldás az szokott lenni, hogy a CSS-t a <head>-ben, a JS-t a </body> tag előtt/után kezdjük el letöltetni a böngészővel. Ebben az esetben viszont a CSS továbbra is blokkol, ha az oldal végére mozgatjuk, akkor viszont a CSS fájl betöltéséig az oldal dizájnja nem jelenik meg, ami nyilván nem kívánt mellékhatás. Emellett pedig a JS fájlban meghatározottak is csak a JS fájl betöltését követően használhatóak (pl. addig nem működik a mobil menü, amíg minden be nem töltött).

Ennél sokkal jobb megoldás az, ha a kezdetben mindenképpen szükséges CSS és JS fájlok részleteit inline beágyazzuk az oldalunk kódjába, ezzel párhuzamosan pedig elindítjuk a teljes fájlok külön betöltését is. Amikor azok végeznek, az inline CSS-t és JS-t a dokumentumból töröljük, hiszen azokra már nincs szükség. Ez megoldja a dizájn nélküli állapot és a betöltés befejezéséig nem működő interaktív működés (például a fentebb már említett, a betöltésig nem működő mobil menü) problémáját. Ezt a működést (a webfontokra kiterjesztve) szintén tanulmányozhatjátok ezen az oldalon. Erre Joomla és Wordpress alatt használhatjátok a JCH Optimize plugin fizetős verzióját, jól teszi a dolgát, viszont ki kell kísérletezni, hogy adott oldalon milyen beállításokkal működik jól. Jótanács: ne kapcsoljatok be mindent ész nélkül, csak szépen, fokozatosan, intenzív tesztelést követően aktiváljatok újabb és újabb beállításokat.

Ezekkel gyakorlatilag megoldottuk a fenti felsorolásból:

• a megjelenítést blokkoló CSS és JS fájlok betöltési sorrendje és betöltési módja,
• a kezdeti betöltéskor szükségtelenül betöltött képek betöltése

pontokat.

Ha eddig eljutottunk, már csak a következő pontok maradtak hátra:

• a szerverünk sebessége, ezzel szoros összefüggésben az oldalt előállító kód hatékonysága (TTFB = time to first byte),
• a nem megfelelően méretezett képek használata

A szerversebességre gyors megoldást tud adni a tartalomkezelőn belüli gyorsítótárazás engedélyezése: a költséges kódrészletek nem futnak le minden oldalbetöltésnél, azok eredménye eltárolódik, és a már kész kódot tudja szinte azonnal kiszolgálni a látogatónak. Erre rengeteg megoldás létezik, Joomla alatt a Joomla alap gyorsítótárazása jól tud működni. Wordpressen több megoldás is elterjedt, mint például a W3 Total Cache és a WP Super Cache.

Craft CMS-hez a HTML cache plugint (megkötésekkel) ajánlom, jelenleg éppen egy erős újraírás alatt van, ami remélhetőleg megoldja a jelenleg létező problémákat. Ezt követően mindenképpen teljes szívvel tudom javasolni: az eredeti 0.6-1 másodperces oldalgenerálási időt 0.002-0.005 másodpercre tudja szorítani.

A nem megfelelően méretezett képek problémájára - figyelem! - nem az a megoldás, hogy rossz minőségű, alulméretezett képeket töltünk fel. A megoldás a reszponzív képek használata. Ez webfejlesztői feladat, nem Ctrl+C - Ctrl+V, de ha valakit érdekel, akkor itt talál segítséget. Sőt, össze is lehet kombinálni aFarkas korábban említett lazysizes pluginjával, ahogyan nálam is láthatjátok.

A fentiek sok esetben kevés munkával nagy előrelépést tudnak jelenteni, viszont bizonyos esetekben nem lehet megúszni egy kisebb-nagyobb újraírást. Fontos, hogy mindig legyen legalább egy működő biztonsági mentésed a szerkesztett fájlokról, hogy szükség esetén vissza tudd állítani a működő verziót. Az viszont biztos, hogy ha ezek közül az összeset megcsinálod, elmondhatod magadról, hogy mindent megtettél az adott weboldal mobilra optimalizálása érdekében.

Elengedhetetlen látnunk és beismernünk, hogy manapság a reszponzív weboldalkészítés nem csak arról szól, hogy "mobilon is jól néz ki". Sőt, 2017-ben egy szép weboldal már nem lesz elég! Nagyon sok munka és intenzív weboldal optimalizálás szükséges a megfelelő megjelenés kialakításán túl is, amit letölthető bővítmények már nem képesek biztosítani. Legközelebb tehát amikor ajánlatot kérsz valakitől, kérdezz rá ezekre is. Jó esetben tényleg hozzáértővel akadt dolgod, de ha nem, akkor azt ajánlom, még nézelődj egy kicsit.

Bevált, esetleg meglódult az oldalad? Valamelyik része esetleg nem egyértelmű? Írd meg kommentben vagy üzenetben!

A weboldalam teljes újraírása és ezen blogbejegyzés megírása során sokat merítettem Andrew Welch blogjából és Michael Westwod ezen írásából. Köszönet nekik!

During the complete rebuild of my site and writing this particular entry I was heavily influenced by the blog of Andrew Welch and by this masterpiece of Michael Westwood.

KUDOS to them!