YSLow plugin voor Firebug

[Juup]

De mannen van yahoo hebben een uitbreiding op Firebug gemaakt: YSlow

YSlow geeft op 13 punten aan hoe je je website sneller kan maken. Er staan echt handige dingen in.

Volgens YSlow scoort t.net niet zo goed: ze krijgen een F (ze gebruiken het Amerikaanse "puntensysteem": A zeer goed en F is zeer slecht.

Misschien kan dit topic gebruikt worden voor discussie over YSLow en hoe je je site zo snel mogelijk kan krijgen.

[disjfa]

Vroeger konden web developers zelf denken. Tegenwoordig moeten ze gewoon zoveel plugins instaleren voordat ze zelf kunnen nadenken.

Ik vind het leuk dat er plugins komen voor dit soort zaken, maar wat heeft het voor meerwaarde aan een algemene developer?

[Juup]

disjfa schreef op donderdag 02 augustus 2007 @ 01:29:
Ik vind het leuk dat er plugins komen voor dit soort zaken, maar wat heeft het voor meerwaarde aan een algemene developer?

Nou de meeste sites die ik bezoek kunnen nog redelijk wat sneller gemaakt worden dus misschien geldt wat jij zegt niet voor alle developers.

[RobIII]

Juup schreef op donderdag 02 augustus 2007 @ 01:32:
Nou de meeste sites die ik bezoek kunnen nog redelijk wat sneller gemaakt worden dus misschien geldt wat jij zegt niet voor alle developers.

Je kunt je tijd beter besteden aan useability en functionele aanpassingen dan aan dit soort micro-optimalisaties denk ik. Ja, een gifje minder is een DNS request minder en een paar bytes minder en blablabla. Maar ik heb liever een site die goed werkt en bruikbaar is (en dat kost meestal wat overhead) en die laadt in 0.8 sec dan een site die er in 0.4 seconden staat en compleet gestript is van alles en nogwat om het laden maar zo snel mogelijk te krijgen.
Daarmee schrijf ik overigens geen 'vrijbrief' voor devvers om dan maar lekker lomp met bandbreedte e.d. om te springen; punt dat ik wil maken is dat een beetje devver zelf die 'meting' prima kan doen (desnoods op 'gut feeling') en zelf prima weet waar er nog winst te halen is en of het dan ook nog rendabel is om dat te doen.

[ Voor 18% gewijzigd door RobIII op 02-08-2007 02:26 ]

[crisp]

Juup schreef op donderdag 02 augustus 2007 @ 01:25:
Volgens YSlow scoort t.net niet zo goed: ze krijgen een F (ze gebruiken het Amerikaanse "puntensysteem": A zeer goed en F is zeer slecht.

Performance Grade: D (69)

Waarbij ook eea op een aantal punten aangemerkt kan worden:

2 (Use a CDN) - leuk voor hele grote sites, voor ons nog niet echt noodzakelijk
6 (Move scripts to the bottom) - doen we al voor een aantal scripts (met name externe scripts voor de bannering), voor de rest is dat niet goed mogelijk
10 (Minify JS) - geeft relatief weinig winst aangezien we al HTTP compressie gebruiken, daarbij bemoeilijkt het onderhoud en bughunting
13 (Configure ETags) - geen issue, static files krijgen bij ons dezelfde ETag ongeacht van welke webserver ze geserveerd worden.

Eigenlijk is alleen punt 1 van belang (Make fewer HTTP requests) en dat is iets wat bij ons sowieso al aandacht heeft. Verder heeft deze tool niet echt veel meerwaarde boven de optie 'View speed report' van de webdeveloper toolbar of de 'Net' optie van Firebug.

[Juup]

Inderdaad die CDN die slaat nergens op. Minifying en merging van JS helpt echter wel heel goed. Dat doe je natuurlijk niet met je dev scripts, maar stop je in je build-to-production proces.

[crisp]

Juup schreef op donderdag 02 augustus 2007 @ 17:18:
Inderdaad die CDN die slaat nergens op. Minifying en merging van JS helpt echter wel heel goed. Dat doe je natuurlijk niet met je dev scripts, maar stop je in je build-to-production proces.

Ja, en vervolgens moet je weer in het hele scala browsers gaan testen of er geen bugs geintroduceerd zijn door het minifyen zelf... Het blijft verder rommelen in de marge als je al HTTP compressie gebruikt, misschien de moeite waard voor een Yahoo of een Google maar voor een normale website levert het meer potentiele problemen op dan winst.

[Juup]

crisp schreef op donderdag 02 augustus 2007 @ 18:35:
Ja, en vervolgens moet je weer in het hele scala browsers gaan testen of er geen bugs geintroduceerd zijn door het minifyen zelf... Het blijft verder rommelen in de marge als je al HTTP compressie gebruikt, misschien de moeite waard voor een Yahoo of een Google maar voor een normale website levert het meer potentiele problemen op dan winst.

Het gaat niet alleen om het compressen maar vooral om het aantal http requests te minimaliseren. Test maar eens als je 10 losse js files merged tot 1 en dan het verschil meten.
Zelfs bij HTTP/1.1 (waar de verbinding wordt hegebruikt) scheelt dat echt.

[crisp]

Juup schreef op donderdag 02 augustus 2007 @ 19:02:
[...]
Het gaat niet alleen om het compressen maar vooral om het aantal http requests te minimaliseren. Test maar eens als je 10 losse js files merged tot 1 en dan het verschil meten.
Zelfs bij HTTP/1.1 (waar de verbinding wordt hegebruikt) scheelt dat echt.

Ook dat is niet een kwestie van: stop alles maar in 1 js file, want daarmee maak je juist weer de 'first hit' onnodig zwaar. Het is een afweging van welke scripts je bijna altijd wel nodig hebt, en welke maar in heel specifieke situaties. De eerste voeg je sowieso samen in 1 bestand, de rest kan je toch beter gewoon los serveren. Een systeem waarbij dat serverside alsnog (als ware het modulair) samengevoegd wordt resulteert weer in meer data die gecached moet worden en minder cache-hits op de client.

[Juup]

crisp schreef op donderdag 02 augustus 2007 @ 20:06:
Ook dat is niet een kwestie van: stop alles maar in 1 js file, want daarmee maak je juist weer de 'first hit' onnodig zwaar. Het is een afweging van welke scripts je bijna altijd wel nodig hebt, en welke maar in heel specifieke situaties. De eerste voeg je sowieso samen in 1 bestand, de rest kan je toch beter gewoon los serveren. Een systeem waarbij dat serverside alsnog (als ware het modulair) samengevoegd wordt resulteert weer in meer data die gecached moet worden en minder cache-hits op de client.

Oh dat klopt zeker. Ik ging er even van uit dat alle pagina's alle scripts nodig hadden.
Ik snap trouwens niet dat YSlow t.net zo'n rating geeft:

code:

Performance Grade: F (58)
F   1. Make fewer HTTP requests
  This page has 11 external JavaScript files.
  This page has 3 external StyleSheets.
  This page has 36 CSS background images.
F   2. Use a CDN
F   3. Add an Expires header
A   4. Gzip components
A   5. Put CSS at the top
D   6. Move scripts to the bottom
A   7. Avoid CSS expressions
A   9. Reduce DNS lookups
D   10. Minify JS
A   11. Avoid redirects
A   12. Remove duplicate scripts
F   13. Configure ETags

Ik zou eerder het gemiddelde nemen en er dus een c van maken ofzo...

[crisp]

Juup schreef op vrijdag 03 augustus 2007 @ 11:24:
[...]

Oh dat klopt zeker. Ik ging er even van uit dat alle pagina's alle scripts nodig hadden.
Ik snap trouwens niet dat YSlow t.net zo'n rating geeft:

Ik meen dat je de wegingsfactoren zelf kan aanpassen (dus dan weet je ook meteen welke waarde je kan hechten aan de score die eruit komt )

Overigens zie ik dat de slechte score voor 1) en 3) grootendeels door de banners komt