Http-request vs. Bandbreedte

[b2vjfvj75gjx7]

Hallo,

Voor mijn website houd ik bij hoe vaak een bepaalde pagina / hoofdstuk is bezocht.

Die 'scores' laat ik - letterlijk - terugkomen in een score-board, dat ook inzichtelijk is voor de site-bezoeker.

Elk hoofdstuk heeft binnen de website zijn / haar eigen 'mascotte' - een soort hoofd van een persoon, waarbij de overheersende kleur van deze mascotte ook het kleur-schema van het gekoppelde hoofdstuk bepaalt.

Het score-board is een afbeelding en bestaat uit een standaard podium [met plaats voor de nummer één, twee en drie] en de hoofden van de mascottes.

Om het aantal http-requests te beperken, heb ik de acht losse afbeeldingen [zeven hoofden - voor elk hoofdstuk dus één hoofd - en het podium zelf] samengevoegd in een sprite (rode achtergrond is nep);



De scores zelf worden bijgehouden in een tekstbestandje, en via een geschreven XML-parser en een eenvoudig PHP-scriptje omgezet naar bruikbare codes. Deze codes bestaan vooral uit het dynamisch renderen van wat DIV'jes met daarin de hoofden van de drie 'winnaars'. De coördinaten van de sprite binnen het DIV'je worden weer gekoppeld aan het winnende hoofdstuk en een standaard offset op de X- en de Y-as.

In principe werkt het allemaal goed, en kan ik dus alle mogelijke 'winnaars' laten zien in alle mogelijke combinaties, met telkens dezelfde achtergrond - waarbij ik gebruik maak van slechts één afbeelding;



Doordat de hoofden echter semi-transparant zijn en ik sowieso vrijheid wil hebben qua positionering van de hoofden op het podium, heb ik er voor gekozen van de gehele sprite een .PNG afbeelding te maken.

De volledige sprite is nu echter iets van 250 kB groot [7 hoofden, 1 podium] en dus kan ik alles met slechts één http-request inladen, in plaats van acht losse.

Zou ik echter een .PNG sprite maken van alléén de hoofden [7 stuks] en een losse .JPG afbeelding van de achtergrond, dan zit ik op twee http-requests en slechts 150 kB.

De achtergrond [het podium] is als .PNG dus 100 kB zwaarder, dan als .JPG bestand [wat logisch is, gezien de codec en de honingraat-compressie van een .JPG bestand].

Wat is nu dan wijsheid? Alles als één .PNG opslaan - met als voordeel dat je maar één http-request hebt als iemand het score-board oproept? Of één .PNG voor de hoofden en één .JPG voor het podium, wat een http-request extra kost, maar wel 100 kB bespaard in bandbreedte...

Het gaat niet eens om die 100 kB - maar meer om het principe; wat is wijsheid - in deze kwestie...

[Bosmonster]

Denk dat 100KB minder redelijk opweegt tegen 1 request minder

Maar kijk ook eens wat een tool als OptiPNG doet met je PNG.

[ Voor 14% gewijzigd door Bosmonster op 23-02-2010 10:39 ]

[b2vjfvj75gjx7]

Denk dat 100KB minder redelijk opweegt tegen 1 request minder

Tja... dat dacht ik ook, maar wellicht dat de visie van anderen weer anders is - vandaar mijn vraag.

Maar de vraag is dan weer, waar leg je die grens?

En is de grens absoluut [100 kB verschil = de moeite waard], of relatief [in dit geval 200% meer downloaden, versus 1 request meer].

De tool ken ik niet; ik optimize alles default in Photoshop, dus ik ga eens snel kijken wat het scheelt - bedankt!

-- update -- Een leuk tooltje! Alleen in dit specifieke geval heb ik... 1.5% winst behaald



Alles beter dan niets - ook bandbreedte is een schaars goed waar je bewust mee om moet gaan, maar héél veel zoden aan de digitale dijk zet het in dit geval helaas niet...

[ Voor 25% gewijzigd door b2vjfvj75gjx7 op 23-02-2010 10:52 . Reden: KB = kB ... koffie! ]

[eamelink]

Bedoel je met 100kb 100 kilobit, of 100 kilobyte? Waarschijnlijk dat laatste, en dan kan je voor de duidelijkheid beter 100kB schrijven

100kB downloaden duurt met een 1 megabit verbinding al gauw een seconde. Een enkel extra http-request gaat veel sneller.

b2vjfvj75gjx7 schreef op dinsdag 23 februari 2010 @ 10:41:
Maar de vraag is dan weer, waar leg je die grens?

Tsja, dat is uiteindelijk niet zo heel erg belangrijk

En is de grens absoluut \[100 kb verschil = de moeite waard], of relatief [in dit geval 200% meer downloaden, versus 1 request meer].

Die grens is absoluut, omdat een http-request een minimale vaste hoeveelheid tijd en bandbreedte kost. Als je van twee plaatjes van 100 bytes naar één plaatje van 400 bytes kan gaan is dat zeker de moeite waard, ondanks dat het plaatje dan een stuk groter is.

[ Voor 65% gewijzigd door eamelink op 23-02-2010 10:52 ]

[b2vjfvj75gjx7]

Bedankt voor je reactie!

Met "absolute" grens, bedoelde ik overigens niet of de téchnische grens absoluut is [dus altijd het zelfde], maar meer de ethische / esthetische grens.

Dus dat je als ontwikkelaar bepaalt dat "100 kB" een reden is voor een request meer-of-minder [dus een absolute grens; je legt de lat op 100 kB].

Of dat je deze grens voor jezelf "relatief" houdt, dus meer gevoelsmatig - of de ene keer wel, en de andere keer niet, of juist "relatief" ten opzichte van de winst in kB's [bijvoorbeeld bij 25% winst doe je niets, en bij 75% winst kies je liever voor een http-request extra].

Hangt natuurlijk ook van je doelgroep af; ik werk relatief veel voor Zuid-Amerika, waar relatief weer langzame verbindingen gelden - dan is een kB'tje meer-of-minder van meer belang dan voor een doelgroep in West-Europa [om maar even te generaliseren, wat ik met de mascottes zelf ook heb gedaan...].

[crisp]

Meten is weten; het hangt zoals je zelf aangeeft behoorlijk af van de latency wat een extra roundtrip aan tijd kost ten opzichte van een grotere payload bij een request minder.

Bij grote spritemaps gaat overigens clientside rendertijd en geheugengebruik ook een rol spelen.

In dit geval zal ik, zelfs bij een lage latency, gevoelsmatig al zeggen: 2 files. Als het van dezelfde host afkomt heb je sowieso toch al voordeel van clients die pipelining ondersteunen.

[ Voor 12% gewijzigd door crisp op 23-02-2010 11:05 ]

[b2vjfvj75gjx7]

Tja, qua tijd is het handiger gewoon twee plaatjes in te laden;

Ik doe sneller 2 http-requests dan dat ik een 100 kB extra download...

Maar dat is puur objectief / technisch gestaafd; want een extra request is sneller dan dat je die 100 kB extra download [dus goed, qua tijd], maar een grotere sprit kost ook meer bandbreedte / energie [in de data-centra] en dat is weer slecht voor het milieu, etc...

Het gaat overigens niet om dit specifieke voorbeeld [100 kB is niet veel en we hebben het niet over een site die dagelijks miljoenen bezoekers heeft], maar meer in het algemeen;

Stel dat je hier als ontwikkelaar tegenaan loopt, waar kies je dan voor?

Voor tijdswinst, of belasting van het netwerk? In dit geval is het trouwens van beide één, want twee afbeeldingen is én minder kB's én sneller om te downloaden [maar je hebt dus wel een request extra].

Ik denk dat ik zelf maar kies voor die extra request; scheelt me 100 kB en het gaat sneller [en ik kan de achtergrond ook nog makkelijk aanpassen, zonder de mascottes overnieuw in te laden].

[Icelus]

b2vjfvj75gjx7 schreef op dinsdag 23 februari 2010 @ 10:41:
[...]

-- update -- Een leuk tooltje! Alleen in dit specifieke geval heb ik... 1.5% winst behaald

[afbeelding]

Komt omdat het een 32-bits afbeelding is. Is het mogelijk om 8-bits (palet) afbeelding te maken, of ziet het er dan niet meer uit?

[MBV]

als ze semi-transparant zijn gaat dat natuurlijk niet werken. De hoofden apart maakt dat al een stuk makkelijker.

[Bosmonster]

Icelus schreef op dinsdag 23 februari 2010 @ 13:59:
[...]
Komt omdat het een 32-bits afbeelding is. Is het mogelijk om 8-bits (palet) afbeelding te maken, of ziet het er dan niet meer uit?

Dat maakt niet zoveel uit. OptiPNG verwijdert alle zinloze meta-data uit een PNG. Photoshop is daar gelukkig redelijk schoon in, maar bij veel andere pakketten is er behoorlijk wat winst te halen door de PNG's op te schonen. (Fireworks is hier een extreem voorbeeld van)

8bit maken lijkt me redelijk zinloos. Daarvoor zul je de afbeeldingen los moeten trekken van elkaar en dan kun je er dus net zo goed een JPG van maken.

[ Voor 3% gewijzigd door Bosmonster op 23-02-2010 14:34 ]

[Wolfboy]

Bosmonster schreef op dinsdag 23 februari 2010 @ 14:33:
[...]


Dat maakt niet zoveel uit. OptiPNG verwijdert alle zinloze meta-data uit een PNG. Photoshop is daar gelukkig redelijk schoon in, maar bij veel andere pakketten is er behoorlijk wat winst te halen door de PNG's op te schonen. (Fireworks is hier een extreem voorbeeld van)

Niet helemaal waar. Fireworks gebruikt als zijn standaard formaat PNG met een hele stapel extensies waar je zelfs animatie en vector afbeeldingen in kan opslaan. Dit formaat is dan ook niet bedoeld voor webpagina's maar echt alleen om te editten. Vergelijk het met het online zetten van je PSD bestand, dat doe je ook niet

Als je met Fireworks een bestand wil maken om online te zetten dan moet je export gebruiken, daarna zal OptiPNG weinig meer kunnen verwijderen.

[b2vjfvj75gjx7]

Tja, de hoofden zijn inderdaad semi-transparant, dus met een gradientieel alpha-channel.

De hoofden zijn niet óf doorzichtig, óf zichtbaar, er zitten tussenstappen in, waardoor je de achtergrond [de blauwe lucht, delen van het podium, een dropshadow óp het podium] inderdaad half er door ziet komen.

Als dit geen vereiste was, had ik wel gewoon transparante .GIFjes genomen. Maar die kan weer niet anti-aliased transparancy aan [nog los van de 256 kleuren beperking].

Qua techniek / functionaliteit / vorm is voor de hoofdjes dus een .PNG een vereiste - de achtergrond is vrijer, vandaar mijn vraag. En JPG met Quality 70 [ongeveer] is 50 kB, vs. 150 kB als PNG.

Dus dat scheelt wel - ik heb dus maar gekozen voor een PNG sprite met 7 hoofdjes naast elkaar en een JPG background als solide achtergrond. Samen 2x een http-request, maar wel een besparing van 100 kB.

Altijd beter dan alle mogelijke scores als losse plaatjes op de server te gooien Zit je al snel op 7 tot de macht 7 combinaties... [wiskunde is niet mijn ding].

[Bosmonster]

Wolfboy schreef op dinsdag 23 februari 2010 @ 15:11:
[...]
Niet helemaal waar. Fireworks gebruikt als zijn standaard formaat PNG met een hele stapel extensies waar je zelfs animatie en vector afbeeldingen in kan opslaan. Dit formaat is dan ook niet bedoeld voor webpagina's maar echt alleen om te editten. Vergelijk het met het online zetten van je PSD bestand, dat doe je ook niet

Als je met Fireworks een bestand wil maken om online te zetten dan moet je export gebruiken, daarna zal OptiPNG weinig meer kunnen verwijderen.

Mijn ervaring is dat zelfs na export OptiPNG wonderen kan verrichten op Fireworks PNG's.

[Soultaker]

Laat een request 1KB aan header data meesturen, dan kan een reductie van 100KB payload ten koste van één extra request zonder meer uit, zeker aangezien die requests waarschijnlijk toch al gepipelined worden. Het maakt dan weinig uit of de browser op één of op twéé plaatjes moet wachten. (Overigens is het verschil wel dat bij een request er zowel headers van de client naar de server worden gestuurd als vice versa, terwijl bij een groter plaatje alleen extra data naar de client wordt gestuurd.)

CSS sprites zijn vooral zinnig als je tientallen kleine icoontjes hebt. Je kunt je dan tientallen kleine requests (met allemaal een hoop header data, als je pech hebt) in één request proppen. Als de bestanden afzonderlijk al groter dan pak-em-beet 50KB zijn, heeft die optimalisatie mijns inziens nauwelijks zin.

In dit geval is je achtergrond niet alleen groot genoeg om 'm los te versturen, maar je wint er aanzienlijke ruimte mee door 'm te hercomprimeren als JPEG. In dat geval zou ik 'm dan zeker los sturen.

Bosmonster schreef op dinsdag 23 februari 2010 @ 16:56:
Mijn ervaring is dat zelfs na export OptiPNG wonderen kan verrichten op Fireworks PNG's.

Sowieso kunnen PNG optimizers twee verschillende dingen doen. Het ene is het verwijderen van overbodige/onbekende chunks (metadata e.d.). Het tweede is de image data hercomprimeren met alternatieve filtercombinaties en compressieparameters. Het is inderdaad best mogelijk dat met de tweede stap nog enige winst te behalen is, ook al is alle niet-image-data al uit de PNG verwijderd.

[ Voor 46% gewijzigd door Soultaker op 23-02-2010 17:56 ]

[MBV]

het gaat bij meerdere plaatjes toch vooral om de round-trip-time? Als een request 300ms round-trip duurt (UMTS bijv) dan is het al snel zinvol om alles te combineren.

[Bosmonster]

Soultaker schreef op dinsdag 23 februari 2010 @ 17:51:
Sowieso kunnen PNG optimizers twee verschillende dingen doen. Het ene is het verwijderen van overbodige/onbekende chunks (metadata e.d.). Het tweede is de image data hercomprimeren met alternatieve filtercombinaties en compressieparameters. Het is inderdaad best mogelijk dat met de tweede stap nog enige winst te behalen is, ook al is alle niet-image-data al uit de PNG verwijderd.

En dat is precies m'n punt. Even een testje met een flinke PNG levert mij bij Fireworks export een 2,5MB groter bestand op dan hetzelfde bestand opgeslagen via Photoshop Save for web.

Na OptiPNG zijn de bestanden precies even groot.

Fireworks doet dus iets erg inefficients met PNG's exporteren en voegt zelfs in die 'export' feature nog een hoop zinloze informatie toe. (of gebruikt een stuk minder efficiente compressie in vergelijking met z'n broertje natuurlijk, maar resultaat blijft hetzelfde)

[ Voor 10% gewijzigd door Bosmonster op 23-02-2010 18:17 ]

[Soultaker]

MBV schreef op dinsdag 23 februari 2010 @ 18:00:
het gaat bij meerdere plaatjes toch vooral om de round-trip-time? Als een request 300ms round-trip duurt (UMTS bijv) dan is het al snel zinvol om alles te combineren.

Met pure HTTP 1.0 wel, maar met HTTP 1.1 in de praktijk niet meer, aangezien vrijwel alle browsers en servers tegenwoordig HTTP pipelining supporten. Daarbij parset de webbrowser binnenkomende HTML/stylesheets en wordt voor elke externe resource (plaatjes, externe stylesheets, externe scripts, et cetera) direct een request in een open verbinding gegooid. Daarbij wacht de client dus niet tot eerdere requests afgehandeld zijn.

(Zelfs met HTTP 1.0 onderhoudt een browser in een typische situatie meerdere verbindingen met dezelfde server, waardoor requests parallel afgehandeld kunnen worden. Maar met HTTP 1.1 kan dat zelfs over een enkele verbinding.)

edit:
Volgens Wikipedia hebben de meeste browsers pipelining toch nog niet (by default) aan staan. Dan komt het parallelisme dus alleen van het openhebben van meerdere verbindingen, maar ook dat moet de latency aanzienlijk verminderen (tenzij de round trip time heel erg hoog is ten op zichte van de doorvoersnelheid).

Bosmonster schreef op dinsdag 23 februari 2010 @ 18:14:
Even een testje met een flinke PNG levert mij bij Fireworks export een 2,5MB groter bestand op dan hetzelfde bestand opgeslagen via Photoshop Save for web. [..] Na OptiPNG zijn de bestanden precies even groot.

Typisch. Kun je drie van die files (Photoshop, Fireworks, OptiPNG'ed) online gooien om te vergelijken? Of is 't allemaal classified? (Ik ben wel benieuwd waar het verschil vandaan komt.)

[ Voor 49% gewijzigd door Soultaker op 23-02-2010 18:37 ]

[Bosmonster]

Soultaker schreef op dinsdag 23 februari 2010 @ 18:17:
[...]

Typisch. Kun je drie van die files (Photoshop, Fireworks, OptiPNG'ed) online gooien om te vergelijken? Of is 't allemaal classified? (Ik ben wel benieuwd waar het verschil vandaan komt.)

Het wordt wel een beetje offtopic realiseer ik me nu, maar je kunt het makkelijk reproduceren met gewoon een flinke foto (dat deed ik ook)

[Soultaker]

Ik heb alleen Photoshop noch Fireworks ter beschikking.

[Juup]

Het ligt er ook aan hoeveel andere requests je rond hetzelfde tijdstip wil doen.
De meeste browsers hebben een limiet van 4 of 6 parallele requests per host/domain.

Als je heel weinig andere zooi (js/css/imgs) tegelijkertijd (onload) wil downloaden, dan gaat deze ene extra request (hoofden) gewoon parallel met het podium plaatsje en is die 100kB pure winst.

Je kunt eventueel gebruikmaken van een (cookie-less) static host om images te serveren, dan wordt er meer parallel gedownload. Dit wordt ook wel "Domain Sharding" genoemd.

[Wolfboy]

Bosmonster schreef op dinsdag 23 februari 2010 @ 18:14:
[...]


En dat is precies m'n punt. Even een testje met een flinke PNG levert mij bij Fireworks export een 2,5MB groter bestand op dan hetzelfde bestand opgeslagen via Photoshop Save for web.

Ik deed altijd (toegegeven, jaren geleden) m'n Fireworks exports via de export preview feature. Daarbij kan je precies specificeren wat je wel/niet wil houden en zelfs welke kleuren in het palette moeten blijven. Bij de exports heb ik na afloop weinig extra optimalisaties meer mogelijk gezien in die tijd. Tegenwoordig draai ik helemaal geen Windows meer dus Fireworks gebruik ik dus totaal niet meer

Ik ga iig zeker eens experimenteren met OptiPNG, misschien helpt het wat

[Soultaker]

Wat betreft Fireworks/Photoshop/OptiPNG was Bosmonster zo vriendelijk me zijn PNG uitvoer te sturen, waarvan ik om te beginnen de PNG structuur eens bekeken heb:

Fireworks: Type Aantal Lengte* IHDR 1 13 sBIT 1 4 pHYs 1 9 tEXt 1 50 iDAT 2527 20697930 Totaal: 20698006

Photoshop: Type Aantal Lengte* IHDR 1 13 tEXt 1 25 iDAT 2527 18688221 Totaal: 18688259

OptiPNG: Type Aantal Lengte* IHDR 1 13 tEXt 1 25 iDAT 2527 18013072 Totaal: 18013110

_{* alleen payload, geen header data}

Het verschil in metadata/loze chunks is niet groot te noemen. Die paar extra chunks van Fireworks zijn verwaarloosbaar op het totaal, en ook het feit dat Fireworks de image data in 2527 aparte chunks codeert in plaats van in één grote is niet zo'n probleem (elke PNG chunk heeft 12 bytes overhead).

Hét verschil zit 'm in de opgeslagen image data. Fireworks slaat de foto mét 8-bits alpha-channel op, wat hier overbodig is, omdat het een plaatje zonder transparantie is (dus de alpha-channel heeft overal waarde 255). Photoshop en Fireworks laten die terecht weg. Daardoor is het ongecomprimeerde plaatje in Fireworks al 37,362,000 bytes groot terwijl dat zonder alpha-channel 28,022,000 bytes is.

Kijk ik vervolgens naar de compressie van de IDAT chunks, dan zie ik dat Fireworks een lager compressieniveau (level: default) gebruikt dan Photoshop/OptiPNG (level: best/slowest), wat alleen betekenisvol is als alledrie überhaupt dezelfde compressor gebruiken, wat op zich waarschijnlijk is (vrijwel iedereen gebruikt zlib).

Tenslotte keek ik naar de gebruikte filters, maar die zijn (op enkele scan lines na) nagenoeg gelijk. Daaruit kan ik het verschil tussen Photoshop en OptiPNG dus niet verklaren. Vermoedelijk zit dat 'm toch in net wat andere compressieparameters.

De moraal van het verhaal is dus om je Fireworks PNGtjes toch maar even door OptiPNG te halen, niet zozeer om metadata weg te gooien, maar wel om nutteloze kanalen te elimineren en de image data goed te comprimeren. Het weglaten van een alpha-kanaal verkleint niet alleen de gecomprimeerde data, maar scheelt ook in geheugengebruik en rendertijd van de browser. Daar zullen je bezoekers natuurlijk ook blij mee zijn.

[b2vjfvj75gjx7]

Laat een request 1KB aan header data meesturen, dan kan een reductie van 100KB payload ten koste van één extra request zonder meer uit, zeker aangezien die requests waarschijnlijk toch al gepipelined worden.

[...]

CSS sprites zijn vooral zinnig als je tientallen kleine icoontjes hebt. Je kunt je dan tientallen kleine requests (met allemaal een hoop header data, als je pech hebt) in één request proppen

Bedankt voor je uitleg - interessant om te horen, en zeker van toepassing op de wijze waarop ik werk [liefst toch zoveel mogelijk gelijksoortige "items" in één sprite gooien - al was het maar omdat die items dan in 1x worden getoond bij het fysiek opbouwen van de pagina.

Voor de site waarover het oorspronkelijke bericht ging, heb ik bijvoorbeeld alle shadows / gradienten en glimmertjes in één sprite gezet. Die sprite wordt middels DIV-backgrounds opgesplitst in losse plaatjes en over solide kleurvlakjes gezet. Daardoor worden alle kleurvlakjes in één keer, tegelijk voorzien van de extra grafische kenmerken [shadow, kleurverloop, etc...].

Zie sprite hieronder...



...het ding ziet er niet uit, maar bevat wel alle onderdelen die van belang zijn voor de opbouw van de website.

[ Voor 1% gewijzigd door b2vjfvj75gjx7 op 24-02-2010 15:03 . Reden: sprite verkeerd gelinkt... ]

[MBV]

lol. Wat zou de wereld toch mooi kunnen zijn als browsers gewoon een dropshadow met een kleurtje konden ondersteunen. Dat je een plaatje van een oranje vlak nodig hebt om een website te bouwen is toch te gek voor woorden? background: orange...

Ik weet dat je dit soort trucs nodig hebt voor 3-col layouts enzo, maar het geeft toch wel aan hoe belachelijk slecht CSS is.

[Bosmonster]

Nou, voornamelijk IE dan. Bijna alle andere browsers ondersteunen gewoon CSS3 dropshadow, rounded-corners, gradients, etc.

[MBV]

sinds de laatste 3 jaar ja. Toen heb ik gezocht, en ook voor FF was het erg lastig om zonder achtergrondplaatje een 3-col-layout te maken.

[b2vjfvj75gjx7]

Wat zou de wereld toch mooi kunnen zijn als browsers gewoon een dropshadow met een kleurtje konden ondersteunen.

Euh.... vergeten te melden dat die oranje achtergrond nep is, net als de rode in het eerste plaatje bij deze post

Het is een transparante PNG [daar begon het hele 'probleem' mee, immers] en als je die plaatst in de layout van tweakers.net, dan zie je de tweakers achtergrond er door heen komen...

Om dit te voorkomen en om duidelijk te maken dat de boel meerdere stappen van transparantie kent, heb ik een solide achtergrondskleur gebruikt...

In het origineel zit die dus niet... Daarbij zou het sowieso niet werken, omdat de dropshadows / gradienten soms over een bruine achtergrond worden gezet, dan over een groene, een blauwe. etc... Ik gebruik dus één sprite voor álle gradienten en dropshadows in combinatie met álle achtergrondskleuren.

De kleuren komen gewoon uit een style-sheet en worden getoond in een DIV'je, waarbij deze sprite een achtergrond-image is.

En je kan natuurlijk met IE wel allemaal obscure IE.filters toepassen, maar dat werkt niet [logisch] in andere browsers en je kan het net iets minder fine-tunen dan in Photoshop [gradientverloop of centrumwaardes instellen in je style-sheet is wat lastiger dan gewoon een parameter aan je tool in Photoshop toekennen...]

[ Voor 0% gewijzigd door b2vjfvj75gjx7 op 24-02-2010 16:58 . Reden: typo's ]

[pieturp]

CSS is niet slecht. CSS-ondersteuning onder IE is slecht...

Grote bezwaar tegen sprites, zoals ook al door crisp is gemeld: render time en geheugengebruik op de client. Feitelijk wordt in jouw geval 4x dezelfde afbeelding afgebeeld en in 't geheugen geladen. Dat valt in jouw geval nog wel mee, maar dat kan natuurlijk behoorlijk oplopen. Vooral op minder bedeelde systemen kan 't dan echt traag renderen.

Nog een kleine tip: mocht je site ook cookies/sessies gebruiken, zet je static images (sprites of niet) dan op een eigen subdomein en laat je cookies daar niet voor gelden: scheelt weer een paar (k) Bytes.

[André]

pieturp schreef op donderdag 25 februari 2010 @ 00:29:
CSS is niet slecht. CSS-ondersteuning onder IE is slecht...

Nog een kleine tip: mocht je site ook cookies/sessies gebruiken, zet je static images (sprites of niet) dan op een eigen subdomein en laat je cookies daar niet voor gelden: scheelt weer een paar (k) Bytes.

Maar wat als je cookies van het hoofddomein op ".domein.nl" staan, dan zul je toch echt een extern domein moeten opzoeken

[b2vjfvj75gjx7]

Bedankt voor de cookie-tip; ik gebruik twee cookies voor de site, maar stuur die niet met de afbeeldingen mee.

Eén wordt bij elke pagina meegestuurd, omdat die bijhoudt welke pagina's de bezoeker heeft bezocht [kan natuurlijk ook op de server worden bijgehouden; maar als de bezoeker binnen acht uur terugkeert, wil ik dat de oude 'pagina-score' nog wordt getoond op de site - en dan is het makkelijjker (iig. voor mij...) om gewoon de cookies op de computer zelf te zetten en daar uit te lezen).

En de ander is ivm. een tellertje dat op de achtergrond meeloopt; maar die wordt maar één keer verzonden - zodat ik kan zien of een bezoeker een unieke bezoeker is, een terugkerende bezoeker of een bezoeker die meer dan één pagina heeft bezocht.

Ook dat laatste kan je ongetwijfeld met sessies en server-cookies doen, maar dan moet ik een hele lijst bijhouden per IP-adres om het surfgedrag van de bezoeker te analyseren, en dat wil ik niet (ivm. privacy en ivm. een net iets te grote technische stap voor de manier waarop ik zelf de statistieken bijhoudt).

Aangaande de sprites; ik ga eens kijken hoeveel er zijn en hoe ik ze kan terugbrengen [in aantal en kB's].

[Wolfboy]

b2vjfvj75gjx7 schreef op donderdag 25 februari 2010 @ 11:18:
Bedankt voor de cookie-tip; ik gebruik twee cookies voor de site, maar stuur die niet met de afbeeldingen mee.

Dat maakt niet uit. Als de plaatjes in hetzelfde cookiedomein staan dan stuurt de browser ze standaard mee.

Daarom gebruikt tweakers.net http://tweakimg.net voor de plaatjes

[Onbekend]

b2vjfvj75gjx7 schreef op donderdag 25 februari 2010 @ 11:18:
Aangaande de sprites; ik ga eens kijken hoeveel er zijn en hoe ik ze kan terugbrengen [in aantal en kB's].

Heb je al wat resultaten met het werken van sprites? Ik ben eigenlijk wel nieuwsgierig of dat een significant voordeel heeft opgeleverd.

[b2vjfvj75gjx7]

Heb je al wat resultaten met het werken van sprites? Ik ben eigenlijk wel nieuwsgierig of dat een significant voordeel heeft opgeleverd.

Hi,

Het aantal plaatjes dat ik gebruikte om de website te renderen, lag ongeveer op 35 stuks.

Deze heb ik teruggebracht naar 15 stuks [bij benadering] dus dat is in cijfers een flinke afname.

Ik heb het niet gemeten met de stopwatch er naast, maar het inladen / renderen van het scherm gaat wel veel sneller; alle afbeeldingen staan nu bijna in 1x op het scherm - waar je 'vroeger' (vorige week...) toch 35x moest wachten totdat het plaatje was aangevraagd, verzonden en getoond.

Maar wellicht dat het renderen van een sprite weer meer tijd kost, dan het renderen van een losse afbeelding - dus in seconden kan ik je het verschil niet geven. Gevoelsmatig [dus wat de gebruiker ervaart] is het wel veel sneller geworden; of dit ook resulteert in een snellere laadtijd, kan ik je helaas niet zeggen.

Voordeel is verder ook dat het makkelijker is om te onderhouden / updaten; alle gelijksoortige afbeeldingen heb ik in 1 sprite gezet, dus dat is een stuk handiger met aanpassingen;

Alle gradienten / schaduwen / etc zitten bij elkaar, alle GIF formaten zitten bij elkaar, alle PNG met gradiele transparanties zitten bij elkaar, etc... Het is nu dus meer een libary van afbeeldingen die ik veel sneller kan opzoeken, aanpassen en updaten.

Dus behalve de snelheidswinst (?) is het onderhoud sowieso veel relaxeder geworden (al betreft het puur afbeeldingen voor de interface; en die pas ik niet zo snel aan - maar het is meer een manier van werken die nu logischer aanvoelt, dan 35 losse plaatjes...).

[Gersomvg]

Bosmonster schreef op dinsdag 23 februari 2010 @ 16:56:
[...]


Mijn ervaring is dat zelfs na export OptiPNG wonderen kan verrichten op Fireworks PNG's.

Bij mij slaat Fireworks PNGtjes die maar 100 bytes zouden moeten zijn soms op als 50 kB (terwijl je ze als flattened png opslaat). Wat ik altijd doe om het bestand kleiner te krijgen is het volgende:

• opslaan als flattened png
• bestand sluiten
• flattened png opnieuw openen
• even op de afbeelding klikken en hem met de pijltjestoetsen 1 pixel omhoog en weer 1 pixel omlaag bewegen
• ctrl+s

Het is zeer waarschijnlijk dat dit vreselijk omslachtig is maar bij mij maakt het dus soms het verschil tussen 50 kB en 0,1 kB.. hij slaat er extra data bij op ofzo.. maar ik heb geen idee hoe ik dat uit moet zetten.

[MBV]

Is optipng dan niet veel makkelijker?

[Gersomvg]

MBV schreef op zaterdag 13 maart 2010 @ 19:23:
Is optipng dan niet veel makkelijker?

Misschien wel.. weet niet of die het grootteprobleem verhelpt. Ik kan het eens testen