Háttér

[Warner]

Hajjaj, ha ilyen ms pontosságú méréseket végzel, akkor elég sok tényezőt kihagysz, ami számít. Mi lesz pl. azzal az idővel, míg a phpstudio.hu címhez a DNS szerver megadja neked az IP címet. Súlyos ezredmásodpercek vannak itt. Csak, hogy én is hasogassam azt a bizonyos szőrszálat.
Elküldve:: 2010. Január 01.  19:03:50

Egy utolsó stat:
A témának az oldala kereken 190 kép lekérést indít, ezt átlagosan 50.3 ms alatt végzi el.
Az egész oldal betöltési ideje átlagosan 50.7 ms 291 kéréssel.

Nekem csak 55-öt. És ebbe még az avatarok és a hirdetések is benne vannak, amik nyilván nem spriteosíthatók.
Elküldve:: 2010. Január 01.  19:06:37

És akkor arról még nem is beszéltem, hogy a spontán végzett mérés szerint, ez az oldal, (cache nélkül) 25,38 mp alatt töltődött be (baromi sok...) és ennek legnagyobb részét, a csatlakozás, sorban állás, várakozás a válaszra kérések miatt várta. A leghosszabb "adatfogadási" idő mindössze 802 ms

Nekem cache nélkül 1-2 mp alatt töltődik be ez az oldal. A hiba nálad van.

[Suttogó]

Egy utolsó stat:
A témának az oldala kereken 190 kép lekérést indít, ezt átlagosan 50.3 ms alatt végzi el.
Az egész oldal betöltési ideje átlagosan 50.7 ms 291 kéréssel.

A kérések számának csökkentésével lényeges javulás érhető el, még így is, hogy az én FF-em egyszerre akár 50 szálon tölt egy oldalt. Megjegyzem hogy az IE és az FF alapbeállításon mindösszesen 5 szálon tölt 1-1 oldalt, 2Mb/s alatt pedig 1 szálon. Nos, most nem fogom áthangolni a böngészőmet, de érzékelhető, hogy pl ennek a fórumnak is rengeteget segítene egy CSS Smart-sprite

[<madbence />]

Azért nem teljesen hülye technikam kis képeknél, ikonoknál van értelme tényleg.
Amúgy szerintem mindenki mindennap találkozik ezzel a dologgal, lásd google:
http://www.google.hu/images/nav_logo7.png

[Suttogó]

A lekérések száma valóban csökken, de az adatforgalom ugyanannyi marad, legfeljebb nőni fog redundancia miatt, csökkenni biztosan nem. Márpedig az adatforgalom a domináns tényező.

Ez azért nem igaz, mert létezik: HTTP fejléc, keep-alive. Valamint az oldal feldolgozása is idő, és ha az oldallal párhuzamosan el tudja kezdeni tölteni a képet, nem csak oldal közben kezd el újabb 50 képet letölteni, akkor már érezhető a technika értelme.
És akkor arról még nem is beszéltem, hogy a spontán végzett mérés szerint, ez az oldal, (cache nélkül) 25,38 mp alatt töltődött be (baromi sok...) és ennek legnagyobb részét, a csatlakozás, sorban állás, várakozás a válaszra kérések miatt várta. A leghosszabb "adatfogadási" idő mindössze 802 ms

Ez alapján, ha a phpstudió pillanatnyi megjelenése smart-pritesokat használna, a betöltés 4,5 mp alá szorítható lenne. Megjegyzem szerintem még ennél kevesebb is lehetne.

Abban egyetértek, hogy amikor sok apró ábra van, akkor hasznos lehet ez a technika, mert rengeteg kis képet kéne betölteni. De, hogy egy oldalon most 1 vagy 5 képből áll-e össze a design, az szvsz tökmind1.

Hát azért egy design ritkán áll 5 képből. A PHP-stúdiónak ez a hozzászólás író oldala pl 181 kéréssel jön le, És ennek jelentős része kép.

[Warner]

Na ja, kis méretű és kevés színt tartalmazó ikonoknál, GIF formátumban előfordulhat, hogy az egy nagy képben spórolsz. (Megjegyzem, ez a te nagyobb méretű, sok színt tartalmazó JPG/PNG ábrádra már nem biztos, hogy igaz lenne, sőt...)
És ezek így "hamis" mérések, mert értelmes ember nem 10 képből rakta volna össze, hanem 5 ábra és 2 háttér = 7 képből. Ami szerintem még a 13KB-nél is kevesebb lenne, hisz maguk az ábrák kb. az egész gomb területének harmadát töltik ki, még kisebbek.

Szóval A technika hülye megvalósítását nem ér B technika okos megvalósításával összehasonlítani, mert az nem valós eredményt mutat :yes:
Elküldve:: 2009. December 30.  21:08:23

igen ám, de azért még vannak emberek, akiknek lassú netjük van, és fél óra, míg egy képet elkezd tölteni.

Akinek annyira lassú netje, az alapból kikapcsolja minden grafikai elem automatikus letöltését és csak azt tölti le, ami kell neki. Ez nem érv.

Hozzáteszem, egy nagy oldal esetén ha valaki csak pár funkciót használ, akkor egy csomó felesleges grafikát is letölt ezzel a CSS-spritetal, hiszen azok soha nem fognak megjelenni neki. Ez aztán nagyon "lassú-kapcsolódási-sebesség-barát" megoldás

[Semmu]

de az adatforgalom ugyanannyi marad, legfeljebb nőni fog redundancia miatt, csökkenni biztosan nem.

teszt nem ezt mutatja...

[Warner]

A lekérések száma valóban csökken, de az adatforgalom ugyanannyi marad, legfeljebb nőni fog redundancia miatt, csökkenni biztosan nem. Márpedig az adatforgalom a domináns tényező.

A linket megnéztem, igazából kicsit vicces, hogy ezzel próbálnak a példában optimalizálni tök minimálisat, miközben ha az ikonokat leválasztják a hátterükről, akkor ehhez képest sokkal nagyobb optimalizálásra lett volna lehetőség. Persze azt az egy képfájlba mindent technikával nem lehet megoldani, akkor legalább már 2 kép lenne.

Abban egyetértek, hogy amikor sok apró ábra van, akkor hasznos lehet ez a technika, mert rengeteg kis képet kéne betölteni. De, hogy egy oldalon most 1 vagy 5 képből áll-e össze a design, az szvsz tökmind1.

[Semmu]

kevesebb http lekérés.

(és akkor most jön az a reakció, hogy "de a mai világban már mindenkinek gyors a nete". és erre jön az én reakcióm: )

igen ám, de azért még vannak emberek, akiknek lassú netjük van, és fél óra, míg egy képet elkezd tölteni. meg bármikor elb_szódhat vmi a szolgáltatónál, és belassulhat a net.
pár hete én is így jártam. egyszerűen lelassult a net, oldalak is csak 20x-i frissítésre töltötte be. enyhén kiidegelt. és ilyenkor nem mindegy, hogy 20 képet vagy csak 2 képet kell betölteni
Elküldve:: 2009. December 30.  19:55:45és akkor már át is futhatod ezt is

http://css-tricks.com/css-sprites/

[Warner]

Jól van, csak én nem ismertem rá ezt a kifejezést. Mondjuk, hogy miért olyan jó ezzel megoldani, nem értem, de biztos jó xD

[Semmu]

A background-position:top right; miért is nem jó? Nem világos.

css-sprite miatt, lásd:

Ha spriteokat használsz, akkor jól tervezd meg, hogy ne legyen gubanc ebből
Vagy próbálkozz máshogy, vagy JS. Direkt erre nincs CSS tulajdonság.

js-t erre nem írok, szal ketté kell szednem a képet :S

[<madbence />]

Ha spriteokat használsz, akkor jól tervezd meg, hogy ne legyen gubanc ebből
Vagy próbálkozz máshogy, vagy JS. Direkt erre nincs CSS tulajdonság.

[Warner]

A background-position:top right; miért is nem jó? Nem világos.

[Semmu]

érdekes problémába ütköztem...:

van egy adott magasságú, de ismeretlen szélességű divem, aminek van egy háttérképe, és úgy kéne pozicionálnom azt a háttérképet, hogy az egyik megadott része pont a (változó méretű) div jobb oldalára kerüljön.
és ebben a képben más elemek is vannak, szal a "top right" meg ilyen emgoldások nem használhatóak. valahogy pixel-pontosan kéne megadni.
egyszerű lenne úgy, ha a bg-position-nak be lehetne állítani, hogy az elem melyik sarkához viszonyítson, de én nem tudok ilyenről... valakinek valami 5let? :S

[Warner]

Az logikus, hogy öröklődik. A nem logikus az, hogy nem lehet tetszőlegesen felüldefiniálni. Ez kb. olyan, mintha egy div-ben 20-as betűméretet adsz meg, akkor a tartalmazott divekben nem lehetne 20-asnál nagyobb méretű betű.

[Semmu]

vagy a háttérkép legyen áttetsző.

am sztem logikus ez a megoldás, h öröklődik.