Hány kilobyte legyen maximum egy letöltött web-oldal?

Web, mail, IRC, IM, hálózatok

Régebben úgy 8-10 éve az volt a szabály, hogy ne legyen több 100kbyte-nál egy oldal.
Természetesen ma már nehéz ezt tartani.
Most figyel erre valaki?

Aki igen az írja ide, hogy mennyi szerinte a maximum ami még belefér. Köszi.

  • 3090 megtekintés

( bambano | 2010. 09. 12., v – 01:40 )

ugyanezt megkérdezhetnéd a levelekkel kapcsolatban...
én szoktam figyelni mindkét dologra...

szerk: hogy legyen viszonyítás is: a hup.hu megfelel, az index.hu sok.

Igen, de a hup.hu támógatókat is igényel, az index.hu meg kitermeli az ott dolgozók bérét és ezen felül jelentős hasznot is hajt. A hup.hu nem négyzetmétert vesz a datacenterben, az index.hu igen. Más a kettő. Persze a gömb is olyan, mint a kocka, csak nyolc sarokkal kevesebb van neki.

akárhogy is olvasom, akárhányszor újraolvasom, mégiscsak az lett itt a kérdés, hány kB legyen a felső határ weboldalak méreténél.

Nem látok olyat, hogy ha datacenterben négyzetméter, akkor mennyi és ha nem, akkor amannyi... meg olyat sem, hogy 5-10 dolgozó bérét kell kitermelni, akkor mekkora legyen, illetve ha 50-150 dolgozó bérét...

a zindexnél idomított nikotinfüggő cerkófmajmok dolgoznak, Прилуки ukrán csempészcigiben kapják a fizetésüket. így könnyű volt nyereséget termelni:)
kíváncsi vagyok most mit fognak csinálni? a segg, amit lelkesen nyaltak és amely pénzt fosott nekik eltűnt és nemigen fog visszajönni :)

( Erendis42 | 2010. 09. 12., v – 01:39 )

számot bezzeg egyikőtök se írt :D

( hakosh | 2010. 09. 12., v – 05:28 )

Szerintem nincs maximum. Ma már elég sokrétű a web ahhoz, hogy ilyenről ne lehessen beszélni. Én egyszerűen csak törekedem mindent a lehető legkisebbre csinálni (tömörített css, js, képek). Ezt az addont szoktam segítségül hívni: http://code.google.com/intl/hu-HU/speed/page-speed/index.html

Legutóbbi eset: először örültem, hogy a kezdőlapot be tudtam vinni 1MB alá (sok kis kép + diavetítés). Aztán 6db képet (ami csak szöveg volt) sikerült lecserélni tisztán html+css-re. Ezen kívül itt-ott átvariáltam a dolgokat a html-ben és így lett most 760kB a kezdőlap. Még pár kB-ot le tudok faragni a kódból, mert itt-ott még mindig elég "lazán fogalmaztam". Illetve még a CSS és a JS sem tömörítve van fent. Most nem tudom megnézni, de tippre 50-60kB-ot tudok még ezzel spórolni. Ez a 760kB egyébként attól függ, hogy mennyit tartózkodik a user a főoldalon, mert nem töltődik le egyből az összes kép a diavetítéshez. Ha valaki ilyesmit csinál, akkor ez nagyon fontos. Bár ez a bekezdés nem kapcsolódik ide szorosan, azért gondoltam leírom.

Köszi!

Nálam is ez a gond. Azzal, hogy nő a userek képernyőfelbontása nő az oldal (képek) mérete is. Minden vállalkozás szeretné, ha az arculatába illene a weboldal ami normális, viszont sokszor már a kezdő oldal is 500-1000kbyte-os + flash video.
Én ezt sokallom.

Azt gondolom, hogy a net sebességének növekedését figyelembe véve, ma olyan 350-500 kbyte-nál nagyobb kezdőoldalt nem illene készíteni.

CSS Sprite-ok megvannak? http://webmania.cc/tunderi-manocskak-avagy-css-sprites/ Ez nálam sokat javított a betöltési időn, főleg lassú kapcsolatoknál.
Nekem eddig sikerült mindenkit lebeszélni a flash-ről, amit eddig akartak azt meg lehetett oldani js-ben is. Szerencsére még nem találkoztam olyannal, aki jobban tudta :)

Elhiszem, csak kétséges az értelme...Talán bombanő jelezte, hogy szerinte az index.hu az lassan töltődik...hát szerintem meg teljesen elfogadhatóan...és azon minimum 30 villogó, csattogó, pörgő és forgó izé van, ami nem kicsi. A szélessáv korában nem lehet gond 70 kis kép letöltése az oldalhoz, maximum akkor, ha a kiszolgáló oldal tohonya....akkor meg hiába a fenti trükk, lassú lesz a szekér. Persze, lehet, hogy nincs igazam és a megoldásnak van értelme...mindenesetre tetszetős megoldás, tehát kapjon 8 pontot. :)

Pont az index.hu és a hasonló, nagy forgalmú oldalaknál van különösen értelme. Töredékére lehet csökkenteni a szerveren a terhelést a lekérések számának csökkentésével, nem beszélve arról, hogy a letöltött adatmennyiség is kisebb. Hiába van ims get meg pipeline-ing, az egy kérés akkor is egy kérés, szemben az esetleges 10-20-al.

Én mostanában csapdosom a fejemet a falba, hogy anno leszavaztam ezt a megoldást egy oldalnál, mondván hogy úgyis statikusak ezek a képek és keselve lesznek. Picivel több munka, viszont nagyon sokat dob egy olyan oldalon, ami sok kis képecskét rakosgat... és a miénk épp olyan.

Először is nem bomba, hanem bamba. Másodszor nem azt jeleztem, hogy az index.hu lassan töltődik, nekem itthon 80-90 Mbps között tolja a digi, gyakorlatilag mindegy.

Csak én még dolgoztam 2400 bit/sec-es x.25-ön is kermittel, és én még mindig nem felejtettem el, hogy régen takarékoskodtunk a nettel. Most meg azt látom, hogy teljesen mindegy, milyen drótot veszel, az user gáznemű, kitölti a rendelkezésére álló sávszélességet. Pedig a régi szép időkben már a 4+ soros aláírásokért is figyelmeztetés járt, meg tudta az ember fejből az időzónákat, mert illett helyi idő szerint éjjel tölteni az ftp szerverekről stb. stb. meg elsunnyogni a rákba, mikor megjött az x.25 forgalomról a számla:P

Én 1200 bpi sebességgel is toltam a telixet, de ez hogy jön ide?! Most egy ilyen szir-szar 5 megabites adsl-em van és ezen elég jól lejön a példaként említett index.hu, tehát nem klikkelek el. Ez a lényeg. Ne menjünk vissza a rovásírás korába, mert akkor egy hello world! oldal is lassan készült el. :D

A fles vektoros. Tehát mindegy neki a felbontás, ugyanannyi adat kell neki az 10x10 pixeles oldalhoz, mint a 1000x1000 pixeleshez.

Jahogy a grafikusok nem értenek a fleshez/animációhoz/vektorgrafikához? Mert az nem hiszem, hogy az oldal embed videóval kezdene. Ha meg ilyen oldalt találok, akkor általában azonnal ki is szúrom a szemét, pláne ha még üvölt a zene is belőle-róla.

A kezdőoldalnak amúgy szerintem még ma is gyorsnak kell lennie. Olyasmi rémlik, hogy ha valaki az oldalra téved, akkor nagyon kevesen kattintanak (még) egyet ahhoz, hogy információt szerezzenek. Pláne akkor, ha maga az első oldal is nehézkesen jelent meg.

A másik ami az eszembe jutott, hogy mi a célközönség? Budapesten nagyon sok helyen több tíz megabites vonalakkal dobálóznak a szolgáltatók, otthon, vidéken 1-2 vel (se). Nekem konkrétan mobilnetem van otthon, ami sok mindenről híres, csak épp a betont feltépő sebességéről nem.

Személy szerint gyűlöm a splash screen-t, amit kitesznek a weboladak elé, és gyakorlatilag semmi hasznos információ nincs rajta.

Viszont ha a megrendelő dögnagy, csicsás, flesses oldalt akar, akkor kapjon azt. El lehet neki mondani, hogy ennek mi a hátránya (esetleg ha van előnye, azt is), és majd ő dönt.

Attól függ. Nekem 15mbit-es netem van, ezen egy pármegás oldal hamar leugrik, szóval akár 2-3M is lehet.

Otthon eret vágnék, ha ekkora oldalt kell letöltenem, ott a 100K sokkal szimpatikusabb.

Tehát minél kisebb annál jobb, a megrendelő dönti el.

Ha te vagy a megrendelő, akkor döntsd el, hogy gyors oldal kell vagy csilivili. Bár a kettő nem mindig zárja ki egymást.

Én törekednék a minél kisebb oldalméretre, de a mai sávszélességek mellett sok lehetőség van a kompromisszumra.

Amúgy a céges oldal, ahogy most összeszámoltam 250k-val indul (aztán ami változik az csak pár kilobyte lehet). Ez nekem mobilnetről már kényelmetlenül sok, csinálnom kéne valamit, hogy az egyik háttérképet hamar töltse be, mert így fehér alapon fehér betűk vannak akár 1-2 másodpercig is, ami zavaró és gagyisztikus.

Áh, majdnem, egy div-nek kell átállítani a hátterét. Ezzel eredetileg az volt a baj, hogy a háttér átlátszó png volt, így a háttérnek is átlátszónak kellett lennie, de - amennyire rémlik - méretgondok miatt jpg lett belőle, viszont a háttér maradt semmilyen.

Most már jó lesz .D

( djsilas | 2010. 09. 12., v – 13:02 )

A már mások által is említett CSS "hack" valóban jópofa dolog. Kb 1 éve az új oldalakat már így csináljuk régebbinél is előfordult, hogy átvariáltuk, ha megérte. Tényleg nagyon hasznos dolog, érezhető a javulás.

Másik gondolatom: index.php -m legyen mondjuk 3k. De mire betölt, lehet, hogy egy 2MB -os oldal lesz belőle. Sokszor egy lassú db szerver és/vagy lassú IO nagyobb gond lehet. Azt hiszem az említett 100kb valóban "elavult".

Én nem szoktam annyira figyelni az oldalak méretére. Elég csak a SEO -ra gondolni, amihez azért nem árt, ha van tartalom is (alt, title, stb dolgokról meg ne is beszéljünk, akkor fog ám hízni az oldalunk). Ha crossbrowser + w3c valid kódot akarsz, akkor az néha megint csak növeli az oldal méretét. Ami kell, az kell! Én inkább olyanokra szoktam figyelni, hogy ahol lehet optimalizálok, tömörítek (deflate, gzip).

A korábban említett toolon kívül asszem a Yahoonak van még egy hasonló cucca, hasznos javaslatokkal.

( uid_4263 v | 2010. 09. 12., v – 21:06 )

Ma már nem nagyon izgalmas a dolog. Szinte mindenhol szélessáv van. Azért illik maximum 1-2 mbyte -os limitet tartani.

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

( hzsolt94 v | 2010. 09. 12., v – 23:28 )

Még mindig sok a 2-3 Mbites ADSL, egy weboldalra 1mp-nél többet nem szeretnénk várni. 2Mb/s kapcsolaton 256Kbyte = 1mp

Grafika mellett ez ugye nagyon-nagyon kicsi szám, tehát mondjuk az első oldalt olyan 500, de max 700Kbyte, de a cache mellett a többi oldal már ne legyen ennyi!.
(Gondoljunk bele hogy 700Kbyte környékén vannak akik már 3 mp-et fognak várni az oldalunkra. Rohanó világunkban az nagyonsok.)

Most nem kötözködésképpen, de senkit nem érdekel az, hogy te mennyit akarsz várni...a célközönséget mérik és nem te vagy az, ez tisztán látszik. A célközönség meg hajlandó várni a nagy hírportálok betöltődésére, a faszbúk, iwiw oldalak szánalmas akadozásaira. Ezért mindegy, hogy te mennyit akarsz várni vagy nem várni.

Rossz értelmezés. Ha a célközönség a pörgő, forgó, csillogó, villanó szarokat részesíti előnyben és ezért a lassabb betöltődés nem zavarja őket, akkor bezony ilyen lesz és legfeljebb elveszítelek téged, ami egy a sokból, de megmarad a sok, amiből meg meg lehet élni. Ilyen dolog a piac. Az oldal akadása az más tészta. Az oldal akadása nem egyenlő a lassabb betöltődéssel.

Az hogy én személy szerint mennyit vagyok hajlandó várni az az én magánügyem (nem is 2 megabites ADSL-em van.) De az emberek 99%-a nem hajlandó várni. oké, szereti az effektes csillogó villogó szarokat, de annyira nem hogy várjon rá. (Lásd: Facebook népszerűségében nagyon sokat nyom a villámgyors ajaxos megoldás.)

Saját felmérésem szerint az átlag internetező 3 mp-nél többet nem hajlandó várni egy weboldalra, akkor sem ha lassú kapcsolathoz szokott. (5Mb/s netes könyvtári gépek elé berakott proxi időnként a végtelenségig töltő oldalt adott, átlagosan 2,5 mp után navigáltak el róla az "áldozatok")

A weblapon töltött időt szokták mérni (ami gyakran több mint 1 perc) nem pedig a weblapra várási hajlandóságot.

Mi most ugye a várási hajlandóságról beszélünk: vagyis mennyi idő után kattint máshová a user ha nem kapott tartalmat. Ez olyan 3mp körüli érték. Ezt nem lehet igazán mérni, mert (jó esetben) nem vár annyi ideig hogy elkattintson, akkor pedig nem lehet tudni hogy mennyi idő után kattintott volna el. Mérni persze lehetne ha beteszünk egy mesterséges várakoztató oldalt (olyan-mintha töltene lap) de akkor megvárjuk amíg elkattint, akkor ugye nem nézi meg a sitet, látogatókiesés. Ilyet egy nagy site nem fog bevállalni, én egy könyvtári proxyval tettem be random lapok elé ilyen várakozást, innen veszem a 3 mp-es számot.

A másik mutatott a weblapon töltött idő, vagyis hogy miután megkapta a tartalmat mennyi ideig nézi azt, mielőtt továbbnavigál, ez a tartalom értékességét mutatja. A weblap számítástechnikai méretétől független.

Ezt valahogy nehezemre esik elhinni. Ez nem lehet az átlag, legalábbis itt Mo-n tutira nem. Sok helyen jó ha 3mp múlva életjelet ad az oldal (tehát megjön a válasz az első http kérésekre). Mire abból fogyasztható tartalom lesz (szöveg, képek nélkül) már vagy 5-6 is eltelik... Nekem most 4mp alatt adott be szöveget az index.hu-ról és még csak ezután jött a többi rész (Szeged, ADSL). Még időm se volt arra gondolni, hogy "aaarrgghh... meddig tölt mááá'?". Meg minek hagyná ott 3mp után ha legalább 30mp másik oldalt keresni? Ha hazamennék, akkor ott legalább 10mp az, hogy legalább vmi szöveget lássak, szóval ahogy mondtam: ezt nehéz elhinni. Linkeld légyszi ezeket a tanulmányokat!

Atért azt is számold bele, hogy nem egyszerre indul meg minden, először HTML eleje, utána külön HTTP kérés a CSS-nek, majd annak parseolása után a képeknek. Firebug, vagy Chrome saját eszköze megmutatja ezeket szépen.

----------------
Lvl86 Troll

( saxus | 2010. 09. 13., h – 07:17 )

Teljesen mindegy. Egy átlagos (gondoljunk a 3G-sekre is, legyen 2 megabit 3G-t feltételezve*) neten legyen használható elsőre néhány (lehetőleg 1-2) másodpercen belül.

* Átlagos körülmények, vidéken puszta közepén értelem szerűen nem annyi lesz). És ezt arra értem, hogy 3G-s netkapcsolat, nem mobilrol netezés.

----------------
Lvl86 Troll

( Toth Lali | 2010. 09. 13., h – 07:37 )

hup.hu: 100.89 KB (103,314 bytes)
index.hu: 140.91 KB (144,292 bytes)
origo.hu: 91.09 KB (93,274 bytes)

( Mcsiv v | 2010. 09. 13., h – 08:40 )

Saját tapasztalat alapján, olyan 500-800k környékén van az egész oldal, amivel a mostani böngészők még gyorsan elbírnak (nem feltétlenül csak arra kell gondolni, hogy kevés a sávszél).
Ez nálam most (nem publikus site), 600k (html 12k/css-10k) képekkel, optimalizálás nélkül (nincs sprite, tömörítetlen css, 35 lekérdezés), így a főoldal a clickeléstől az onload eseményig 500-700ms alatt megvan egy 10mb-es adsl-en (ehhez hozzá járult, hogy a különböző tartalmakat különböző domainekre szétdobtam (images.domain.hu, static.domain.hu)).
Persze ha szükséges, ezzel lehet tornázni, fel le, de véleményem szerint felesleges (nincs akkora különbség töltésnél), inkább a szerverre eső terhelést célszerű nézni.

( uid_13349 | 2010. 09. 13., h – 09:06 )

Régen csináltam oldalakat, de talán nagyon nem változtak meg a dolgok.

Nem hiszem, h lehet rá számszerű választ adni, a válasz a szokásos - attól függ...
Általános elvek vannak, a konkrét igények nagymértékben befolyásolhatnak.
- a lehető legkisebb legyen (a legfontosabb :-)
- szükséges-e bele a sok csicsa (mozó képek, videók, hirdetések stb.)
- célközönség/platform (pl. kell-e mobilos elérésre figyelni?)
- egyidejűleg várható felhasználók száma

Én utálom, ha egy (kező)oldal sokáig jön be (egy ok csak a méret). A végfelhasználó vonalsebessége még ma is erősen szór, gondolom inkább a lassabb a gyakori.

Szerintem sem szabad abból kiindulni, hogy mindehol hasít a net.
Nekem a halálom a mindenféle intro, főleg, ha még ki sem lehet kerülni, a flash menü, stb.
Nem csak azért, mert a munkahelyek egy részén a flasht nem lehet megjeleníteni, hanem azért, mert sokszor túlzásba viszik.

( sj | 2010. 09. 13., h – 10:17 )

En az alabbi tesztet lattam valahol az oldal meretere: vegyel egy atlagos mennyisegu levegot, majd kattints a linkre. Ha nincs lenn az oldal, mire kapkodni kezded a levegot, akkor faragni kell meg rajta...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

( dragi v | 2010. 09. 13., h – 17:07 )

Pedig érdemes odafigyelni a méretre továbbra is, mert google már figyelembe veszi az oldal gyorsaságát is. Ad is rá ajánlást hogy gyorsítsd az oldalad letöltését (minimalizáld a méretét).

( fn26 | 2010. 09. 13., h – 17:34 )

Mar regota foglalkoztat ez a kerdes. Van egy 100N byte- s lapom, szepen indentalva, megformazva. Ha kiszedem belole a indetalo dolgokat, esetleg kommenteket, ilyesmiket, akkor kapok mondjuk 95N byte- t. Tfh. van erre egy szkriptem, tehat gyorsan megoldhato. Megeri? Gondolok itt arra, hogy mennyire szep ilyet webre kirakni (nem mintha barmit is kiraktam volna az elmult 1 evben :- ) ), mivel ez masok szamara az olvashatosagot igen csak megneheziti, bar szerintem egy ertelmezo sem dobna hatast egy ilyentol... .

En mondjuk nem tennem ezt a "tisztitast", de erdekel a velemenyetek.

Egy kiszolgalt weblap nem kell, hogy ember szamara is emesztheto forrassal rendelkezzen. Ha a forras kell valakinek, ki lehet azt tenni kulon - kommentezve, es a tobbi. Amikor felrak az ember egy kepet, akkor is a png-t rakja ki, nem az XCF-et vagy PSD-t. Ha egy oneletrajzot raksz ki, akkor is inkabb a PDF-et rakja ki az ember, mint a LaTeX forrast pl.

Igy van a HTML-el, es hasonszoru tarsaival (css, js) is: ami kikerul, az egy "leforditott" dolog, nem azt kellene forrasnak tekinteni. Igy nem is kell, hogy szep legyen. A szepseg a forras dolga, nem a "binaris"-e, ugymond.

( uid_194 | 2010. 09. 13., h – 17:43 )

En amondo volnek, hogy attol fugg, ki a celkozonseged, es mi az oldal profilja. Teszemazt egy jatekfejleszto ceg oldala erdemes ha itt-ott tartalmaz screenshotokat meg videot, ami igencsak megdobja a meretet.

Oszinten szolva, en nem azt neznem, hogy mekkora a meret, mert ma mar a szelessav azert lenyegesen elterjedtebb, mint 8-10 eve. Egy oldal betoltodese manapsag mar jobban fugg egyeb, merettol nem annyira fuggo dolgoktol (nyilvan van olyan eset amikor a meret a meghatarozo, pl mindenfele telefonok es egyeb vackok, de arra kulon oldalt illene tenni, direkt erre optimalizalva).

Expires headerek megfelelo hasznalata, tomoritett, minified js (lehetoleg a dokumentum vegen), css & html, css spriteok, CDN - csomo olyan dolog ami rettento sokat lendithet a betoltodesi sebessegen, es a merethez vajmi keves kozuk van.

De mégis, majd mindennek a mérethez van köze...

"tömörített, mified js" -> na ugye a méret
"css spriteok" -> kevesebb HTTP kérés (fejléc és vackok), csatlakozási idő -> kisebb méret
"oldal végén" -> Kakukktojás. Csak akkor számít csak betöltöttnek egy oldal ha ez is lejött.
(Persze ideális esetben ennél hamarabb látja a tartalmat, de az oldal még nem teljes értékű)

( egmont | 2010. 09. 13., h – 22:46 )

Konkrét számot tőlem sem fogsz hallani, de remélhetőleg pár ötletet igen :) Ez is egy legalább annyira bonyolult tudomány, mint a keresőoptimalizálás, komplett könyveket lehet kapni róla.

Ismerd a célközönségedet (milyen netük van), nem mindegy hogy Bp-i vagy tanyai embereket célzol meg, avagy Amerikába vagy Afrikába akarsz eladni, más-más netkapcsolat esetén nyilván más-más oldalméret célszerű.

Sokszor nem a teljes betöltésig eltelt idő számít, hanem addig, amikor a böngésző már használhatóan rendereli az odlalt. (Sőt, addig is, más ha látszik haladás a betöltéssel, és más ha teljes a sötétség sokáig.) Például img tag-eknek ha adsz rendes width és height értéket, akkor a böngésző már véglegesre tudja renderelni az oldalt akkor is amikor a képeket még el sem kezdte leszedni, ez sokkal gyorsabbnak tűnik, mint ha a képek leszedése során töredezné át. Hasonlóan általában a táblázatokat nem szeretik a böngészők, sokan csak a záró /table tagnél kezdik el renderelni - bár van valami css property, hogy a mezők tartalmától függetlenül találja ki az oszlopok szélességét, ez is segíthet. Akik extrém módon űzik a sportot, tudják hogy melyik böngésző pontosan milyen rész html fájlt hogyan renderel.

CSS és JS közül állítólag az egyiket előre, másikat hátra kell tenni, sose tudom hogy melyiket hova, de elvileg végiggondolható. Lehet mikrooptimalizálni olyasmiket, hogy a főoldal inline-olja a CSS-t, de később ajaxszal letölti (előre cache-eli) és a további oldalak már külső CSS-ként hivatkoznak rá. Vagy cookie-ban is tárolhatod, hogy minden bizonnyal ott van-e a user cache-ében a CSS.

Szöveges tartalom (http, css, js) mehet simán és gzip-elve is, nyilván gzip-elve akarod átküldeni a neten, nem nyersen, így ez a méret számít. Gzip szereti, ha a case sensitive-en nézve sok ismétlődést talál, így nem árt mondjuk következetesen lowercase html tag-eket és attribútumokat használni, html attribútumokat mindig adott sorrendben venni fel stb. Hülye html escape-ek (például nbsp) helyett pedig nyers utf-8-at. Van valami http chunk encoding is, ami nem igazán tudom hogy micsoda, de érdemes lehet utánanézni, hátha számít.

Főleg JS esetén szerver oldali böngésző-választás: ahelyett hogy leküldenéd az "if (ie()) do_this() else do_that()" kódot, küldd le csak azt, ami az adott böngészőnek szól. Ilyenkor persze vigyázni kell, hogy félúton valami proxy ne cache-elje be a tartalmat.

Általában cache paraméterek beállítása: ez a kezdőoldalon ugyan nem, de a későbbi barangolás során sokat javíthat. Ha fingerprintingezel (az url tartalmazza a fájl tartalmának checksumját), akkor a fájlt akár örökké is cache-eltetheted a böngészővel, hiszen ha változtatsz az oldalon, akkor új fájlt fog leszedni helyette. (Bizony a cache paraméterek félrekonfigurálásának nagy hátulütője, hogy valahányszor módosítasz az oldalon, vigyázni kell, hogy böngésző cache-ekben maradt régi adat miatt ne romoljon el az oldal csomó usernél.)

Minden egyes http kérés során mennek http fejlécek is fel is meg le is (tehát feltöltési sebesség is számít), sok kicsi sokra megy alapon ezen is sok múlhat. Minden beágyazott kép vagy ilyesmi esetén például ott van a Referer mezőben a hivatkozó oldal címe, így hosszú URL sokszorosan megbosszulja magát felmenő forgalomban. Hasonló a helyzet a cookie-kkal azonos domain esetén, így ha sok cookie-t tárolsz az oldalhoz, akkor a képeket/css-t/js-t érdemes más (cookie-mentes) domain-ről szolgálni.

A böngészők általában úgy vannak beállítva, hogy van egy globális maximum az egyszerre nyitott http kapcsolatok számára, meg van egy nagyon alacsony maximum az 1 gépre irányuló kérések számára (általában ez az érték 2, tehát egy szerverhez - és itt nem tudom hogy hostname vagy ip számít - max 2 kapcsolat van nyitva egy adott pillanatban). Tehát ha például sok képet kell szolgálnod, agresszívabbá teheted a letöltést ha külön ip-kre pakolod szét őket.

Image spritingot már említették. Ez nemcsak a kezdeti letöltési időn tud spórolni, de egyben talán a legjobb megoldás arra, ha onmouseover-re alternatív kép van, és azt akarod, hogy az első föléegerezés során már ott legyen a kép - nagyon idegesítő, ha csak akkor kezdi el letölteni a böngésző.

PNG képeket optipng vagy pngcrush vagy hasonló programon futtasd át (pixelre azonos képet csinál kisebb fájlmérettel). JPG képek esetén lehet a minőséggel játszani, illetve progresszívvé átkonvertálni.

html, css és js-re is nyilván léteznek mikrooptimalizálást végző progik, kiszedik a fölösleges szóközöket, idézőjeleket, #aabbcc-ből #abc-t csinálnak (színkód), stb., js-re változókat átnevezik blabla. Nyilván itt mérlegelni kell hogy mennyit tudsz nyerni, megéri-e az infrastruktúrába befektetendő időt-energiát és esetleg nehezebb debugolhatóságot, nyilván sok esetben nem.

És még sokminden ami nem jut eszembe... :)

Egy kis történelmi érdekesség: Ha jól dereng, állítólag, meg nem erősített információk szerint a Firefox 2-es verziója a JS fájlokat négyzetes időben emésztette meg (itt tehát a letöltés és a használatba vétel közt eltelt időről beszélünk, ami a user szemében a tényleges letöltési idővel egyenértékű, mit érdekli őt hogy a böngészője szöszmötöl), így ha baromi nagy JS fájlod volt, akkor azt érdemes volt több kicsivé szétdarabolni, hogy a FF gyorsabban dolgozza fel őket. A 3-asra úgy tudom javították ezt a hibát.

A chunked encoding tényleg jóság, úgy fest hogy nem célszerű manapság nélküle élni. Már csak azért sem, mert a persistent http connection (egy darab tcp csatorna felett több http kérés lebonyolítása) is növel a teljesítményen, és ha nem tudod előre hogy mekkora lesz a főoldal (a szerver dinamikusan generálja, és a már kész darabokat a gyorsaság érdekében már küldöd át a hálón, nem vársz amíg elkészül az egész) és ezt persistent kapcsolattal szeretnéd kombinálni, akkor nincs más lehetőség. Újra tanultam valami hasznosat kb. 5 mp ráfordítással :)