Mennyire terhelt a blogunk?
A minap hozott le a Read/WriterWeb egy érdekes cikket How JavaScript is Slowing Down the Web (And What To Do About It) címmel, amelyben a főképp blogokat jellemző JavaScript (és Flash) alapú widgetek túlburjánzását vizslatja a szerző, Alex Iskold.
Hogy a temérdek weblapba ágyazható Flickr, Twitter, Del.icio.us, Last.fm sít. kisalkalmazások valóban elengedhetetlen kellékei-e egy korszerű blognak, nem célom most ezt eldönteni, mindazonáltal a trend azt mutatja, hogy valóban sokat emelnek ezek a kiegészítő szolgáltatásók egy napló amúgy hétköznapi megjelenésén.
A probléma csírája ott kezd azonban kibontakozni, amikor a sokadik, amúgy önálló viselkedésre megírt widgetet helyezi el a blogger az oldalára; a temérdek egymásról nem tudó, és tudni nem is akaró eszköz pedig a közös platform miatt kölcsönhatásba fog kerülni egymással.
Alex írásában igyekszik feltárni a szűk technológiai keresztmetszeteket, levezetésként pedig néhány jótanáccsal szolgál, amely tehermentesítheti blogunkat a vállára nehezedő JavaScript kódtömegek súlyától.
A felvetett téma számomra abból a szempontból is érdekes, mert nemrég blogoltam arról, hogy már önmagában is egy-egy távoli szolgáltatás kiesése képes meggátolni egy webalkalmazás helyes működését, másodsorban pedig pont a napokban ötlött fel bennem, hogy miképpen tudnék blogom kiszolgálásán gyorsítani. A néhány általam használt JS kódtár áttekintését követően jutottam arra a megállapításra, hogy valójában semmi szükségem sincs a Lightbox JS-re. A kompresszálatlanul közel 10 KByte-ot követelő, minden oldal letöltéskor a megfelelő entitások után kutakodó függvénytár nem elengedhetetlen kelléke a blogomnak; felhasználói élmény tekintetében pedig az old-school új oldalon történő megjelenítés saját tapasztalataimra hagyatkozva sokszor praktikusabb is – mindazonáltal a látogatók szélesebb rétege érti.
Természetesen mindez nem azt jelenti, hogy vessük el a JavaScript alapú intelligens megoldásokat, hiszen számos esetben a szerver oldali terheltség csökkentése érdekében igenis érdemes kliens oldali implementációt választani, lásd Weblabor és a SyntaxHighlighter esete, de mindenféleképpen érdemes megfontolni, ad-e annyival több pluszt a kérdéses widget a látogatóknak, mint amennyi többlet erőforrást megkövetel a böngészőtől.
■ Hogy a temérdek weblapba ágyazható Flickr, Twitter, Del.icio.us, Last.fm sít. kisalkalmazások valóban elengedhetetlen kellékei-e egy korszerű blognak, nem célom most ezt eldönteni, mindazonáltal a trend azt mutatja, hogy valóban sokat emelnek ezek a kiegészítő szolgáltatásók egy napló amúgy hétköznapi megjelenésén.
A probléma csírája ott kezd azonban kibontakozni, amikor a sokadik, amúgy önálló viselkedésre megírt widgetet helyezi el a blogger az oldalára; a temérdek egymásról nem tudó, és tudni nem is akaró eszköz pedig a közös platform miatt kölcsönhatásba fog kerülni egymással.
There is a well-known phenomenon in physics called non-linearity: When a lot of different things interact with each other, the outcome is hard to predict.
Alex írásában igyekszik feltárni a szűk technológiai keresztmetszeteket, levezetésként pedig néhány jótanáccsal szolgál, amely tehermentesítheti blogunkat a vállára nehezedő JavaScript kódtömegek súlyától.
A felvetett téma számomra abból a szempontból is érdekes, mert nemrég blogoltam arról, hogy már önmagában is egy-egy távoli szolgáltatás kiesése képes meggátolni egy webalkalmazás helyes működését, másodsorban pedig pont a napokban ötlött fel bennem, hogy miképpen tudnék blogom kiszolgálásán gyorsítani. A néhány általam használt JS kódtár áttekintését követően jutottam arra a megállapításra, hogy valójában semmi szükségem sincs a Lightbox JS-re. A kompresszálatlanul közel 10 KByte-ot követelő, minden oldal letöltéskor a megfelelő entitások után kutakodó függvénytár nem elengedhetetlen kelléke a blogomnak; felhasználói élmény tekintetében pedig az old-school új oldalon történő megjelenítés saját tapasztalataimra hagyatkozva sokszor praktikusabb is – mindazonáltal a látogatók szélesebb rétege érti.
Természetesen mindez nem azt jelenti, hogy vessük el a JavaScript alapú intelligens megoldásokat, hiszen számos esetben a szerver oldali terheltség csökkentése érdekében igenis érdemes kliens oldali implementációt választani, lásd Weblabor és a SyntaxHighlighter esete, de mindenféleképpen érdemes megfontolni, ad-e annyival több pluszt a kérdéses widget a látogatóknak, mint amennyi többlet erőforrást megkövetel a böngészőtől.
erdekes felvetes az utolso mondat...
Az en szememben kb ugynezki egy jol felepitett dinamikus oldal, hogy a tartalmi reszeknel (pl kereses lista talalat, ami tartalmaz kepeket is, egyeb infokat - pl egy katalogusban kereses) a szerver nem html-t dob vissza, hanem xml/json/egyeb mas feldolgozhato adatot, amit kliensoldalon kezelunk le, akar tobb formaban is - igy se a szerver, se a savszelesseg nem halodik meg, es ha jol van megirva a kliensoldali resz, akkor a bongeszo sem fekszik meg ettol a felallastol... :)
xml/json/egyeb
ebben igazad van, de ez egy ugyanolyan divathullám (xml/json/egyeb) most, mint a JS túltengése... :) ennek is van ilyen és amolyan része is, de persze a hasznosságát nem vitatom! Nem egyszer láttam már olyat, amikor teljesen nem odaillő módon, indokolatlanul építettek fel egész portálokat pl. XML/XSLT alapokra, tele nyakatekert dolgokkal és későbbi hibalehetőségekkel, nyitott kapukkal és bakikkal. Mindennek megvan a helye és talán ezt a "helyet" a legnehezebb egy olyan embernek megtalálnia, akinek az alkalmazott technológiákban döntési szerepe van. :)
Elviselhető
JavaScriptnél én még nem találkoztm olyan magán oldallal, ahol annyira belassult volna a gepem, viszont rengeteg portál oldalon a rosszul megírt és egymásra halmozott flash reklám bizony be tudja indítani a hűtő ventit.
Figyelmet érdemel a dolog, de nem olyan értelemben, hogy akkor a js az ördög és pusztítsuk ki, hanem csinálják a fejlesztők jól, a böbészőgyártók pedig gyosítsanak a js feldolgozás sebességén.
A probléma oka
khmm
(én speciel saját frameworköt használok - fejlesztek éppen)
kozos js fajlok
Nekunk is van olyan, hogy ossze kell raknunk tobb alkalmazast, ami hasznalhat kulonbozo js libet, azonos feladatra, vagy akar ugyanazt mashonnan, vagy ugyanazt mas verzioban.
Ugye az mindenkinek vilagos, hogy a js fajlokat keves kiveteltol eltekintve jol cachelhetonek lehet tekinteni, es ha nem kuldesz eltero headert, akkor a bongeszok jol be is cachelik, viszont napjaba szerintem en tobb 10×, 100× szor toltom le a prototype.js-t, vagy a effects.js-t, mivel szinte minden oldal hasznalja, de mindegyik oldal a sajat szervererol.
Nem lehetne megcsinalni, hogy valaki indit egy szolgaltatast egy ultra lightweight webszerverrel, amin az osszes elterjedt js lib osszes kiadott verzioja fent van (osszes beleferne egy kozepes ramdiskbe imho), es elterjeszteni az iget, hogy az adott oldalak ne kulon kulon helyrol linkeljek a js-t, hanem innen kozpontilag.
Ennek az lenne az elonye, hogyha en pl. megnezem A oldalt, ahol prototype van behuzva, akkor onnantol kezdve az osszes kozremukodo prototypeos oldalt megnezhetem anelkul, hogy ujra le kene huznom a js-t azokrol a kiszolgalokrol is. :/
Tyrael
Új függőség
Életképesebb szerintem az a megközelítés, hogy maga a böngésző tartalmazzon egy általános JS toolkit funkcionalitásával megegyező réteget.
Jó is volna...
Mi lehet az oka, hogy e teljesen logikus és kézenfekvő megoldást nem karolja fel sem az Opera, sem a Mozilla?
Van rá példa
vicces latni, hogy ez a
mind a google-nek, mind a microsoft-nak van ingyenesen hasznalhato jquery mirrorja:
http://docs.jquery.com/Downloading_jQuery#CDN_Hosted_jQuery
ugyanigy egy csomo elterjedt js lib-hez megtalalhato ez a feature.
osszehasonlitas, tesztek itt:
http://royal.pingdom.com/2010/05/11/cdn-performance-downloading-jquery-from-google-microsoft-and-edgecast-cdns/
http://www.speedyrails.com/cdn/howfast
Tyrael
több CSS, egy csomó JS
Üdv,
Felhő
Syntaxhighlighter
Amúgy azért inkább a Lightboxot emeltem ki, mert abban egy olyan widgetre találtam, amire rájöttem, hogy teljesen felesleges a használata az én esetemben - ill. ahhoz képest, hogy mit nyújt, túl sokat kér cserébe.
LyteBox
törött link
Javítva