Weblabor

Török Gábor küldött be blogmarkot a Google Page Speedről. Ennek kapcsán szépen sorjában végigmentem az ajánlásokon és néhány helyen az eddigi szemlélettel – amit mindenki „kőbe vésett szentírásnak” vett – homlokegyenest ellenkező javaslatot olvastam. Emiatt gondoltam, hogy a számomra kérdéses dolgokat összegyűjtöm. Nézzük hát egyenként ezeket a pontokat.

Avoid CSS expressions

Egyetértek, hiszen ha nincs a JavaScript futtatása engedélyezve, akkor amúgy sem fognak lefutni a CSS expressionjeink, ráadásul egy-egy expressiont akár minden pixelnyi egérmozgatáskor újra és újra lefuttathatja a böngésző, ami feleslegesen terheli a kliens gépét.

Ahogy írják is, egyszerűbb és jobb megoldás, ha diszkrét JavaScriptet használunk az expressionök kiváltására.

Combine external CSS

Jó meglátás, hiszen eleve törekedni kell a lehető legkevesebb request számra, másrészt – ahogy később ajánlják is –, a böngészők egy időben ugyanarról a hosztról párhuzamos csak 2–6 fájlt töltenek.

Ugyanakkor ez ellentmond annak a megállapításuknak, miszerint minél kevesebb felesleges CSS szabályt szolgáljunk ki. Hiszen ha egyetlen CSS állományunk van, akkor a következő oldalnál megspóroljuk azt az időt, amit a böngésző az állomány letöltésére fordítana, cserébe persze a megnövekedett CSS méret miatt a render picivel lassabb lehet, de véleményem szerint még mindig elenyésző a HTTP kéréshez képest.

Combine external JavaScript

Teljesen egyetértek, nincs nagyon mit rajta boncolgatni. Talán annyi hozzáfűzni való lehet, hogy a Yahoo! YSlow ajánlásban az áll, hogy a body legvégére rakjuk a script elemeinket, mivel így nem fogják megakasztani a renderelést a feldolgozásukkal. Ezzel szemben a Google a példáiban előszeretettel a headbe rakja őket.

Defer loading of JavaScript

Sajnos még nem sikerült olyan oldalt létrehozzak, ahol a masszív tömegű JavaScript alkalmazása – természetesen csakis diszkréten! –, lehetővé tette volna, hogy „defer” betöltést alkalmazzak:

• ha pl. bármilyen JS könyvtárat is használunk, annak betöltését már nem tehetjük deferre, mivel az összes többi fájlunk rajta alapszik;
  
• ha az oldal specifikus JS állományunk tartalmaz load vagy domready handlert, akkor a defer betöltési mód megakadályozhatja azok lefutását.
  

Persze amennyiben YSlow ajánlás szerint a scripteket a tartalom után helyezzük el, nem lesz szükségünk load handlerekre, mivel a scriptek lefutásakor már minden elemünk létezni fog a DOM-ban, azokra hivatkozhatunk bátran. Ugyanakkor ezen esetekben nem is lesz szükségünk a defer használatára, mert az oldal renderelését már nem fogják megakasztani a scriptjeink feldolgozása.

Enable gzip compression

A tanácsuk megfontolandó, miszerint – azon túl, ahogy a címben is szerepel, minden szöveges tartalmat gzippelve szolgáljunk ki – a CSS szabályokon belül a tulajdonságokat és a HTML tageken belül az attribútumokat is ábécérendbe írjuk, ezzel is növelve a gzip hatékonyságát. Erre megoldás lehet, ha a publikáló scriptünket felkészítjük ennek a lekezelésére, így a fejlesztés alatt ezzel nem kell törődnünk. Ugyanakkor ebben a scriptben figyelnünk kell arra, hogy CSS hackek alkalmazásakor már nem mindegy a tulajdonságok sorrendje a szabályainkban, így azokat saját jelöléssel ellátva lehet megjelölni:Így a !+ kezdetű és a -! közötti megjegyzés blokkot érintetlenül hagyhatja, és mondjuk a szabály legvégére sorolhatja, míg a többi szabályt ábécé szerint rendezheti.

Fontos a gzip használatakor tisztában lenni azzal is, hogy Internet Explorer 6 alatt a Flash applet a betöltött gzippelt szöveges tartalmat nem képes feldolgozni, így azokat nem lehet például tömörítve kiszolgálni.

Leverage browser caching

A statikus állományokat Expire vagy Cache-Control fejléccel ellátva nagy sávszélességet és — ami még fontosabb — felhasználói időt spórolhatunk meg. Mindig is gyorsabb lesz kiszolgálni egy fájlt a helyi lemezről, mint hálózatról. Ugyanakkor ez magában hordozza azt a veszélyt, hogy ha a lejárati idő előtt módosítjuk a tartalmat, az a felhasználónál nem fog frissülni. Ennek kiküszöbölésére alkalmazható a kiszolgált fájlok verziózása, ami annyit tesz, hogy az állományokra hivatkozáskor a query stringben elhelyezünk egy, az adott fájlra érvényes verziószámot, ami lehet például az SVN revision száma:Vagy magában a fájlnévben:

Serve resources from a consistent URL

Egyértelmű, ha más domainről szolgáljuk ki ugyanazt, újra be kell gyorsítótáraznia, egyértelműen kerüljük.

Specify image dimensions

Azzal kapcsolatban egyetértek, hogy a beszúrt képek méretét határozzuk meg, így könnyítve a megjelenítést.

Azzal viszont nem, hogy ne ugyanazt a (tartalmi) képet használjuk fel, ha két különböző méretben akarjuk megjeleníteni, például avatarok esetében. Ez akkor természetesen igaz, ha – vegyük például a Flickrt – a fotók listázásakor nem a teljes felbontású képet használjuk fel.

Use efficient CSS selectors

Logikailag teljesen helytállóak, ellenben ha azt vesszük, a HTML csak jelölésre szolgál, a megjelenésért kifejezetten a CSS a felelős. Legalábbis ezt szajkózták anno, most…

…eddig?

Ráadásul az újrafelhasználása a kódnak is macerás lehet, illetve az ajánlást követve megnövekedik a HTML. Nem rajongok az ötletért! És vajon egy összetettebb oldal esetében is mennyivel növekedhet meg a renderelés ideje? 10-100 ms? És akkor szerintem sokról beszélünk. Bár tény, hogy a YSlow prezentációban megmutatták, hogy egyes szolgáltatások forgalma mennyivel csökkenne ilyen mértékű oldalbetöltődési idő növekedés esetén. Valószínűsítem, ez szolgáltatásfüggő.

Avoid the :hover pseudo-selector for non-anchor elements

Viszont ami miatt igazán ez a bejegyzés született, az nem más, mint hogy a következőt olvashatjuk ebben a pontban:


Na most vajon nem pont az lenne a lényeg, hogy JavaScript nélkül is elérhető legyen minden lényegi funkció? Ezt az utolsó gondolatot inkább vitaindítónak szánom, sem mint, hogy én magyarázzam meg. Biztos maga a helyzet az – ebben egyetértek –, ami meghatározza a létjogosultságát a „teljes” JS nélküli funkcionalitásnak, de nem érdemes erre törekedni mindig?