ugrás a tartalomhoz

Mennyire terhelt a blogunk?

Török Gábor · 2007. Aug. 16. (Cs), 12.34
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.

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.
 
1

erdekes felvetes az utolso mondat...

ksgy · 2007. Aug. 16. (Cs), 13.12
..de szerintem ez is a fejlodes egy fazisa, resze. Ahogy regebben az animgifek voltak a "csillivilli, trendi" kategoria, most a JS alapu oldalak azok. Ez is le fog valoszinu tisztulni, es normalizalodni az ertelmesebb oldalakon, es talan besegit abban, hogy a bongeszofejlesztok kicsit jobban rafekudjenek a temara, szabvanyosan irjak meg az implementaciokat, stb. Szerintem most ez a lo tuloldala, ami szepen helyre fog allni idovel, es talan eljon az az ido, mikor nem kell azon gondolkozni, hogy szerveroldalon vagy kliensoldalon kell-e valamit megcsinalni, mert "fogja-e birni a bongeszo/szerver?!"...
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... :)
10

xml/json/egyeb

virág · 2007. Aug. 21. (K), 11.45
Szia,
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. :)
2

Elviselhető

Jano · 2007. Aug. 16. (Cs), 14.46
Két módon is értelmezhető ez a slowdown. Egyrészt a sok plusz hivás a hálózaton keresztül, másrészt a kliens terhelése. Nem tudom megitélni, hogy a sok kérés hatással lehet-e az internet egészére, de ha valami akkor inkább a multimédiás tartalmak azok amik a szűk keresztmetszetet jelenthetik.

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.
3

A probléma oka

Heilig Szabolcs · 2007. Aug. 16. (Cs), 14.56
Nem arról van szó a cikkben, hogy maga a kliens oldali funkcionalitás magában rossz lenne, lassú lenne. Önmagában egyikkel sincs baj, csak ha összeeresztjük őket. Mindegyik hozza magával a saját preferált JS keretrendszerét. Az egyik a jQuery-t, a másik a Prototype-ot. Sőt, esetleg ugyanannak a libnek két teljesen elrétő verzióját húzza be és futtatja az egyi meg a másik. Ugyanabban a homokozóban koszolnak ráadásul, pakolgatják az eventeket, elemzik a DOM-ot, amit a másik már kicsit átrajzolt, stb...
9

khmm

inf3rno · 2007. Aug. 21. (K), 08.41
Ja hát most ez a trendi, hogy ezer frameworköt egymásbapakolunk, aztán az alap motorban igazából nem szokott sok eltérés lenni a frameworkök terén, szóval ugyanazt szépen sokszorozzuk, ami meg eléggé ellentmond az oop elveinek. Én azt javaslom, hogy ha ennyire szükség van ezekre, akkor legalább egy frameworkre épüljön minden, aztán akkor nem lesz probléma belőle. Ha meg nincs az adott frameworkben megfelelő kiterjesztés, akkor azért fejlesztő az ember, hogy megcsinálja hozzá. (persze a lustaság nagy úr.)
(én speciel saját frameworköt használok - fejlesztek éppen)
11

kozos js fajlok

Tyrael · 2007. Szep. 20. (Cs), 13.09
ezen mar en is gondolkoztam.
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
12

Új függőség

Török Gábor · 2007. Szep. 20. (Cs), 14.29
Az elgondolás nem lenne rossz, de az effajta törekvés további problémákat vetne fel - legnagyobb probléma, hogy amit megspórolsz az egyik oldalon, most ott veszted el, hogy egy távoli szolgáltatás elérhetőségétől teszed függővé magad.

É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.
14

Jó is volna...

Wabbitseason · 2007. Szep. 20. (Cs), 15.08
É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.


Mi lehet az oka, hogy e teljesen logikus és kézenfekvő megoldást nem karolja fel sem az Opera, sem a Mozilla?
13

Van rá példa

attlad · 2007. Szep. 20. (Cs), 14.51
15

vicces latni, hogy ez a

Tyrael · 2010. Május. 27. (Cs), 13.30
vicces latni, hogy ez a kerdesem/joslatom mennyire bevalt. :)
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
4

több CSS, egy csomó JS

Hodicska Gergely · 2007. Aug. 17. (P), 00.29
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;
A 20y.hu-ról van szó? Ha igen, akkor ha megnézed akkor nem ezzel a kompresszálatlan JS-sel van gond, hanem pl. a highlightot végző JS cuccal. Kb. 11 JS fájl, mindegyik külön HTTP kérésben jön le. Ezen kívül is van még pár külön JS, ami mehetne egybe, illetve van két CSS is, amit lehetne egybe tenni. És akkor még el lehet gondolkodni a CSS Sprite-ok bevetésén, de az már munkásabb lehet.


Üdv,
Felhő
5

Syntaxhighlighter

Török Gábor · 2007. Aug. 17. (P), 07.08
Igen, 20y, de a syntaxhighlightert még azért nem vettem figyelembe, mert csak a napokba került bele, és egyelőre tesztelem, hogy beválik-e. A CSS sprite teljesen jó ötlet, amint lesz némi szabadidőm, sort is fogok rá keríteni (:

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.
6

LyteBox

Max Logan · 2007. Aug. 17. (P), 09.27
Érdemes rá vetni egy pillantást : LyteBox
7

törött link

ninja · 2007. Aug. 17. (P), 14.31
az Alex írásában link törött!
8

Javítva

Heilig Szabolcs · 2007. Aug. 17. (P), 14.47
Köszi, javítva.