T.net/Got plaatjes/scripts optimaliseren

[Greyh0und]

De reden dat ik dit 'artikel' in Lieve Adjes plaats, is omdat het over het verbeteren van T.net/Got gaat en het misschien/waarschijnlijk wel interesant is voor de Dev's/Site Beheerders.
+ dat 'Voor al je opmerkingen en suggesties aangaande ons mooie forumpje' ik hier moet zijn volgens het forum

Als een mod toch vind dat dit ergens anders moet, verplaats het dan maar.
note: Dit is dus als een soort open brief aan de t.net FP/Forum devvers

Ik ben zelf geen website Devver, maar ik ben wel gek op websites/programma's te comprimeren/kleiner te maken (kwa bestands grootte i.e.g.)

Nu gebruikte ik al een tijd Firefox (toppie browser) en vond ik laatst de extentie 'YSlow'

voor degene die niet weten wat YSlow doet:

YSlow analyzes web pages and tells you why they're slow based on the rules for high performance web sites. YSlow is a Firefox add-on integrated with the popular Firebug web development tool. YSlow gives you:

* Performance report card
* HTTP/HTML summary
* List of components in the page
* Tools including JSLint

van http://developer.yahoo.com/yslow/

Als ik dan kijk naar de plaatjes die jullie op Got gebruiken (bovenaan de pagina, waar de tekst 'tweakers.net, myreact, FAQ, search etc in staan) blijkt dat die plaatjes nog niet geoptimaliseerd/gecomprimeerd zijn!

Als je nu iets hebt van 'waar heb je het over??' dan hieronder wat uitleg:

Veel plaatjes (en dan voornamelijk .png en .gif) kunnen geoptimaliseerd/gecomprimeerd worden!
Na het optimaliseren van 'nb-logout.gif' was het bestand 36% kleiner! Nu is dat niet zoveel (van 1131 bytes naar 726 bytes (zie ook het plaatje hieronder)
Maar als je 100.000 bezoekers per dag krijgt, is dat opeens best wel veel! (nu worden plaatjes ook wel 'gecached' (in de IE/Fx cache geplaatst) maar dan nog!)

Nu zat ik te denken dat de Devvers hier op T.net Misschien ookwel de plaatjes kunnen optimaliseren/comprimeren zodat er iets meer bandbreedte over blijft!

Voor .gif is er alleen 1 programma:
Trout's GIF Optimizer



Dit progje schrijft de bestanden gewoon over, dus zorg voor de zekerheid dat je een backup hebt. plus dit programma gebruikt dacht ik een lossy compressie, dus er gaat informatie verloren (voornamelijk kleuren die je niet gebruikt, al moet je wel kijken bij het tabblad 'optimized gid' (helemaal rechts) want soms wilt het progje kleuren weghalen die in gebruik zijn en dan krijg je plaatjes met maar 4 kleuren en dat wil je niet )

Voor Png zijn er meerdere, maar de beste die ik heb kunnen vinden is:
PngOptimizer



PngOptimizer gebruikt een lossless compressie (dan comprimeerd het programma het plaatje, maar dan blijft all data wel intact. Je kan hem dus theoretisch gewoon weer decomprimeren)
Als je PO (PngOptmizer) gebruikt heb je nooit kleur verlies, dus kan je alle png-tjes gewoon in de window gooien!
Bij dit progje worden er automatisch backups gemaakt in dezelfde map als het originele bestand.
Het originele krijgt een _ (underscore, of op zijn hollands 'lage streepje) voor de bestands naam en het gecomprimeerde bestand krijgt de naam van het originele bestand

Dus... waarom ik dit allemaal typ? Nou, omdat er hier plaatjes zijn die niet geoptimaliseerd/gecomprimeerd zijn en ik T.net/Got zo snel mogelijk wil hebben...

Ik ben trouwens nog niet klaar met typen zoals je ziet, want nu heb ik het over de plaatjes gehad, nu ga ik het hebben over YSlow en hoe je (de T.net/Got devvers) T.net/Got misschien nog iets sneller kan maken!

Om YSlow te gebruiken heb je
1. Firefox nodig (zullen de meeste T.netters al wel hebben, zo niet ga dan hier naartoe en installeer die zooi eens een keer. Als je perse een IE uiterlijk wilt hebben dan heb ik er hier een voor je
2. FireBug. Bij de link zit ook wat info over firebug
3. En natuurlijk YSlow. Klik op de link voor wat info er over en natuurlijk een download link
hier wat meer info over YSlow.

Als je alles geinstalleerd en opgestart (en zonodig geherstart hebt) heb je als het goed is onderaan een extra plaatje met de tekst 'YSlow' ernaast staan.

Als je nu naar T.net/Got gaat en je klikt op het plaatje, komt er onderaan een window bij.
Klikt hierna op 'Performance' (rood omcirkeld)

http://img120.imageshack.us/img120/1093/tnetyslowpo3.png <-- groot plaatje

hierna herlaad YSlow de webpagina waarna het cijfers geeft (van A (het hoogst) tot en met F of G (het laagst)) voor onderdelen van de website.

Dit is de lijst:

1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put CSS at the Top
6. Move Scripts to the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags

Dit krijg ik bij de FrontPage:

http://img120.imageshack....95/tnetperformanceta5.png <-- groot plaatje

Dus misschien willen de Devs kijken naar de dingen kijken die ik hier aankaart.

(en vertellen waarom ze dingen wel/niet zouden veranderen.)

Zet hints/tips/meuk maar hieronder in een post

[RM-rf]

een aantal van die 'raadgevingen' zijn nogal subjectieve ideeen over webdesign....

bv dingen als de vraag of je je javascripts nu beter in de head kunt plaatsen of ook verder in de pagina, of je nu wel of niet late 'expires-headers' moet gebruiken... of je minder verschillende DNS-lookups moet gebruiken

dat geeft eerder de subjectieve mening weer van die persoon achter de extentie ..
en mijns inziens presenteert hij dat iets tezeer als een soort van 'absolute waarheid'.

bij bv het idee dat het beter zou zijn om alle afbeeldingen van hetzelfde domein te serveren is het nu juist zo dat het een bewuste performance-keus was dat _niet_ te doen en bv plaatsjes en scripts van een compleet ander domein te laden, omdat per client het aantal http-verbindingen beperkt is en je dan mogelijk sneller een 'que' krijgt..

[ Voor 5% gewijzigd door RM-rf op 07-03-2008 13:33 ]

[Kees]

1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
6. Move Scripts to the Bottom
10. Minify JavaScript
13. Configure ETags

1. Dat kunnen we lang niet altijd reduceren ondanks het feit dat we op de FP al redelijk veel van sprites gebruik maken waar dat mogelijk is. Je blijft gewoon een aantal requests houden, zoals plaatjes, stylesheets, background images etc.
2. Doen we al, alleen niet op een manier die YSlow kan detecteren En aangezien het overgrote deel van onze bezoekers uit de benelus komt heeft het weinig zin om onze CDN geografisch te distributeren
6. Dat is volgens mij lang niet altijd mogelijk
10. Daar moeten we nog eens een goed programma voor vinden, want dat heb ik ook al eens geroepen
13. Etags staan zoveel mogelijk uit, en dat vind YSlow ook goed

In het algemeen zijn onze pagina's redelijk goed geoptimaliseeerd (ook met behulp van YSlow ). Echter het forum moet die optimalisatie ronde nog ondergaan, waarbij dit soort dingen allemaal aan bod zouden moeten komen.

Overigens zijn er wel veel meer tips die niet door YSlow gegeven worden en die je site zeker sneller maken, zoals layout-onderdelen (css, js, background images) via een lichte webserver serveren, daar keepalive op aanzetten, en 'intern' veel met caching werken, zorgen voor een goed cluster, zorgen voor een goede verdeling van het werk etc.

Anyway, we doen zeker wel wat aan performance tuning, maar sommige dingen (zoals ad-js en google-js) zijn buiten ons bereik om aan te passen, en het forum moet nog eens onder handen genomen worden.

[Greyh0und]

Kees schreef op vrijdag 07 maart 2008 @ 13:48:
[...]
10. Daar moeten we nog eens een goed programma voor vinden, want dat heb ik ook al eens geroepen

backups maken van originele bestanden
bestand openen, tekst copy, paste hem hier

duw op enter en tadaa! je krijgt een 'gecomprimeerde' tekst terug.
via google gezocht op 'optmize javascript'
of is dat niet wat jullie zoeken?

@RM-rf
Ik had al een vaag vermoeden dat er al geoptimaliseerd werd hier (het heet natuurlijk niet voor niet TWEAKERS.net ) maar ik dacht 'misschien weten ze (bepaalde) dingen nog niet op T.net

bij bv het idee dat het beter zou zijn om alle afbeeldingen van hetzelfde domein te serveren is het nu juist zo dat het een bewuste performance-keus was dat _niet_ te doen en bv plaatsjes en scripts van een compleet ander domein te laden, omdat per client het aantal http-verbindingen beperkt is en je dan mogelijk sneller een 'que' krijgt..

Jep, ik heb een tijdje geleden dat artikel gelezen dat jullie tweakimg.net (oid) hadden speciaal voor plaatjes zodat T.net nog iets sneller zou kunnen loaden

edit: maar plaatjes e.d. zouden jullie nog wel kunnen optimaliseren/comprimeren, niet?

[ Voor 3% gewijzigd door Greyh0und op 07-03-2008 14:09 ]

[BtM909]

Greyh0und schreef op vrijdag 07 maart 2008 @ 14:09:
[...]


backups maken van originele bestanden
bestand openen, tekst copy, paste hem hier

duw op enter en tadaa! je krijgt een 'gecomprimeerde' tekst terug.
via google gezocht op 'optmize javascript'
of is dat niet wat jullie zoeken?

Je moet een goede compressor hebben die geen gebruik maakt van evals en je code niet breekt. IMO is er een erg goed en dat YUI. Maar onthoudt een ding. Je kan alles mooi compressen, maar readable is het niet en icm HTTP compressie verlies je het voordeel van compressed oversturen anyway

@RM-rf
Ik had al een vaag vermoeden dat er al geoptimaliseerd werd hier (het heet natuurlijk niet voor niet TWEAKERS.net ) maar ik dacht 'misschien weten ze (bepaalde) dingen nog niet op T.net

Ik denk dat design-technisch en architectuur technisch het niveau een hele hoop grote websites voorbijstreeft

[...]

Jep, ik heb een tijdje geleden dat artikel gelezen dat jullie tweakimg.net (oid) hadden speciaal voor plaatjes zodat T.net nog iets sneller zou kunnen loaden

edit: maar plaatjes e.d. zouden jullie nog wel kunnen optimaliseren/comprimeren, niet?

Welke plaatjes zouden meer gecomprimeerd kunnen worden dan? Voor zover ik kan zien zullen een hoop plaatjes dusdanig gecomprimeerd zijn dat ze nog wel de design esthetiek uitstralen. Anders kan je alles net zo goed naar 2bits converteren

[Greyh0und]

BtM909 schreef op vrijdag 07 maart 2008 @ 14:53:
Welke plaatjes zouden meer gecomprimeerd kunnen worden dan? Voor zover ik kan zien zullen een hoop plaatjes dusdanig gecomprimeerd zijn dat ze nog wel de design esthetiek uitstralen. Anders kan je alles net zo goed naar 2bits converteren

De plaatjes boven aan (tweakers.net, myreact, FAQ, search etc)
daar kan je misschien wel een paar kb vanaf halen

maar ach. Het zijn maar een paar KB's
(met trout's gif optimizer, zover ik weet zonder kwaliteits verlies )

[crisp]

ej Greyh0und, allereerst bedankt voor het meedenken en de moeite die je hebt gedaan voor je duidelijke uitleg. Helaas vertel je ons niets nieuws

Zoals al is gezegd weten wij al van het bestaan van tools als YSlow en gebruiken we die zelf ook naast onze eigen kennis mbt optimalisaties (zowel server- als clientside). Het feit dat zowel frontpage als forum eigenlijk al vrij goed 'scoren' (zeker in vergelijking met soortgelijke websites/fora) spreekt eigenlijk al voor zich

Met betrekking tot het optimaliseren van plaatjes: dat is eigenlijk alleen effectief voor plaatjes die niet meer in 1 TCP packet passen. MTU sizes varieren meestal tussen de 1500 en 4000 bytes op het web, dus voor plaatjes kleiner dan 1KB (je moet ook rekening houden met headers) is het eigenlijk zinloos (correct me if I'm wrong).

Ik heb overigens zelf een tool (eigen geschreven GIF-implementatie in PHP en javascript) die GIF plaatjes kan optimaliseren, en blijkbaar werkt die goed want ik krijg dezelfde filesize na optimalisatie als jouw voorbeeld met nb-logout.gif Het 'probleem' met GIF is dat bij kleine plaatjes eigenlijk de color-table de meeste ruimte inneemt (die is uncompressed), en dat veel tools enkel de keuze bieden voor 2, 16 of 256 kleuren (resp 6, 48 of 768 bytes in de color-table). Als je echter een plaatje hebt die maar 100 kleuren bevat dan kan je de color-table al verkleinen naar 300 bytes en bespaar je zo dus al 468 bytes. Als je vervolgens ook nog eens de table zelf optimaliseerd (meest gebruikte kleuren een kleinere index geeft) dan win je vaak ook weer wat op de LZW-compressed data.

Maar met zo'n 28KB aan images op de GoT index lijkt me niet dat GoT topzwaar te noemen is. Leuk als je daar wat van af kan snoepen, maar het is gerommel in de marge natuurlijk.

Ik zie zelf altijd meer in het verkleinen van het aantal benodigde HTTP requests, en het gebruik van sprites in CSS helpt daarbij vaak behoorlijk. Om dat te illustreren heb ik zojuist de buttons uit het menu in een sprite-image geplaatst en de CSS daarop aangepast. Niet alleen is dat enkele plaatje maar de helft qua grootte van alle losse plaatjes bij elkaar, er hoeft nu ook nog maar 1 request voor gedaan te worden; zo pikken we toch ook weer 3 puntjes extra voor de performance grade

Verder heeft Kees al uitgebreid geantwoord op de 'issues' die YSlow nog aangeeft. Ik wil enkel nog aanvullen dat ik vind dat JS/CSS minification onnodig is. We gebruiken al HTTP compressie dus het effect van minification is dan nog maar minimaal op de filesize 'over the wire'. Daarbij vergroot het de kans op bugs (veroorzaakt door de minification zelf), bemoeilijkt het het debuggen van mogelijke problemen in de live-omgeving en maakt het het ontwikkel-naar-produktie traject complexer en trager. Nadelen die in ons geval imo niet opwegen tegen de voordelen...

[ACM]

crisp schreef op vrijdag 07 maart 2008 @ 23:02:
MTU sizes varieren meestal tussen de 1500 en 4000 bytes op het web

Ik heb altijd geleerd dat de nics doorgaans niet verder gaan dan 1500, maar dat de routering op het internet ervoor zorgt dat de MTU effectief sowieso maximaal 1500 blijft. Alles meer dan 1500 wordt vziw met 'Jumbo Frames' aangeduid en het lijkt me sterk dat dat over het Internet gerouteerd kan worden.

dus voor plaatjes kleiner dan 1KB (je moet ook rekening houden met headers) is het eigenlijk zinloos

Ik denk dat je plaatjes onder de 500-700 bytes moet beschouwen om echt aan de veilige kant te zitten. Maar dan nog kost het al gauw iets van 4 tcp-packets om de verbinding op te bouwen, de request te doen en uiteindelijk de response te krijgen, dus een extra voor nog een data-packet is relatief oninteressant tov het voorkomen van de request (dmv cache en/of sprite).

(correct me if I'm wrong).

Bij deze

Maar met zo'n 28KB aan images op de GoT index lijkt me niet dat GoT topzwaar te noemen is. Leuk als je daar wat van af kan snoepen, maar het is gerommel in de marge natuurlijk.

Ach, onnodig grote plaatjes is natuurlijk altijd zonde, maar ik ben het verder wel met je eens dat je meer winst haalt door ervoor te zorgen dat de request uberhaupt niet nodig was.

[crisp]

ACM schreef op zaterdag 08 maart 2008 @ 09:12:
[...]

Bij deze

Ik maakte die reservering al omdat ik niet precies wist hoe dat in een netwerk/internet precies zat

Bottomline is wel dat een 36% verkleining van een bestand (zoals het nb-logout.gif voorbeeld van TS) niet uiteindelijk 36% minder dataverkeer betekent voor dat bestand omdat de overhead juist op dat soort kleine bestanden een behoorlijk deel uitmaakt.

[...]

Ach, onnodig grote plaatjes is natuurlijk altijd zonde, maar ik ben het verder wel met je eens dat je meer winst haalt door ervoor te zorgen dat de request uberhaupt niet nodig was.

juist

[JHS]

→ Lieve Devvers .

[ Voor 28% gewijzigd door JHS op 09-03-2008 16:47 ]

[crisp]

heeft sowieso altijd al onze aandacht, dus overbodig