[JS] High Performance Web Sites: Rule 6 - Move Scripts to...

[Verwijderd]

Ik ben nieuw met de Yslow profilering voor een website en ik had een aantal basic/stomme vragen. (beter stomme vragen dan geen)

Ik struikel op de volgende regel:
High Performance Web Sites: Rule 6 – Move Scripts to the Bottom

Ik maak nu gebruik van Mootools + Handgeschreven class en ik ben gewend om deze scripts altijd in de head te plaatsen.

Ik heb ze nu voor de </body> neetgezet. Alles werkt prima en Yslow geeft nu een A Grade. In principe niks aan de hand, gewoon door lopen maar dat wil ik niet.

Mijn hamvragen:
1) Wanneer plaats je iets in de head en wanneer op het eind van de body?
2) Werkt (b.v. cookies) in alle browsers als de scripts in de body staan?
3) Waarom word deze regel nog steeds zo weinig toegepast? (b.v. op tweakers.net)

Ik merk verder wel dat deze regel effect heeft op het laden van de website!

[MueR]

Ik plaats zelf alles in de head, muv Analytics. Ze moeten toch inladen. Het enige nut is dat je browser niet gaat wachten op de download van het script. Dat is een van de redenen waarom Google verzoekt Analytics onderin te zetten. Dan laadt eerst de hele pagina in, dus de bezoeker ziet al content. Vziw maakt het voor de laadtijd weinig tot niks uit.

[Bosmonster]

Heel veel maakt het niet uit, zeker niet als je veel javascript gebruikt. De website heeft die scripts waarschijnlijk toch nodig om optimaal te functioneren.

Mijn voorkeur gaat derhalve uit naar het omgekeerde. Scripts zo snel mogelijk inladen en de rest van de site kan wat mij betreft dan best ff wachten. Daarna wordt het gecached, dus maakt het sowieso niks meer uit.

Scripts onderaan zetten zou suggereren dat de javascripts een lagere prioriteit hebben dan de rest en ik denk dat bij script-heavy websites deze dus juist een hoge prioriteit hebben.

Uitzonderingen zijn uiteraard externe scripts. Je wilt niet je site ophouden met het laden van scripts van andere domeinen waar je de betrouwbaarheid niet van in de hand hebt (analytics, banners, etc).

[ Voor 43% gewijzigd door Bosmonster op 10-12-2009 16:34 ]

[crisp]

Waarom word deze regel nog steeds zo weinig toegepast? (b.v. op tweakers.net)

Wij spreken al javascript functionaliteit aan binnen de markup, daarom moeten deze functies ook beschikbaar zijn. Zaken als analytics en bannerscripts plaatsen wij wel onderaan in de HTML.

[Verwijderd]

super! bedankt voor de reacties!

Ik vind het eigenlijk ook wel fijn om mijn eigen scripts in de head te hebben. Dat is ook wel zo fijn voor het overzicht.

Ik snap verder ook dat je deze regel alleen maar toepast als de JS van een externe server komt. (google/userfly etc.)

[Manuel]

Ik snap verder ook dat je deze regel alleen maar toepast als de JS van een externe server komt. (google/userfly etc.)

Als je Google CDN voor bijvoorbeeld jQuery gebruikt (noem maar iets) dan zou je dat eigenlijk ook achteraan in de body moeten zetten als ik je redenatie zo lees terwijl als je het nodig hebt het misschien wel beter is om het bovenaan te zetten

[Juup]

Nog beter dan scripts onderaan je pagina zetten is de async techniek die nu o.a. door googleanalytics wordt gebruikt:

JavaScript:

var ga = document.createElement('script');
ga.src = 'http://www.google-analytics.com/ga.js';
document.documentElement.firstChild.appendChild(ga);

Dit heft het blockinggedrag (ivm mogelijk document.write) van de javascript file op.

Edit: vanzelfsprekend kan dit alleen met javascript die je voor de onload niet nodig hebt.

[ Voor 13% gewijzigd door Juup op 10-12-2009 18:21 ]

[BtM909]

Juup schreef op donderdag 10 december 2009 @ 18:20:
Nog beter dan scripts onderaan je pagina zetten is de async techniek die nu o.a. door googleanalytics wordt gebruikt:

JavaScript:

var ga = document.createElement('script');
ga.src = 'http://www.google-analytics.com/ga.js';
document.documentElement.firstChild.appendChild(ga);

Dit heft het blockinggedrag (ivm mogelijk document.write) van de javascript file op.

Edit: vanzelfsprekend kan dit alleen met javascript die je voor de onload niet nodig hebt.

Waarbij er al een hoop problemen worden gemeld (even vanuitgaande dat die specifieke situaties voor een website gelden): http://blog.getify.com/2009/11/why-dom-ready-still-sucks/. Overigens is dat een kwestie van tijd (kan nog lang duren ) voordat browsers het gaan corrigeren EN er zijn al alternatieven bedacht: http://blog.getify.com/20...abjs-speeds-up-dom-ready/

[ Voor 11% gewijzigd door BtM909 op 10-12-2009 18:30 ]

[Juup]

BtM909 schreef op donderdag 10 december 2009 @ 18:28:
Waarbij er al een hoop problemen worden gemeld (even vanuitgaande dat die specifieke situaties voor een website gelden): http://blog.getify.com/2009/11/why-dom-ready-still-sucks/.

Deze techniek heeft niks met ondomready te maken hoor.

Overigens is dat een kwestie van tijd (kan nog lang duren ) voordat browsers het gaan corrigeren EN er zijn al alternatieven bedacht: http://blog.getify.com/20...abjs-speeds-up-dom-ready/

labjs gebruikt o.a. bovenstaande techniek. Het is dus geen alternatief maar een implementatie of framework.

[BtM909]

Wel met het mechanisme om async je js-jes te laden wat weer problemen kan opleveren met domready

[Juup]

BtM909 schreef op vrijdag 11 december 2009 @ 11:59:
Wel met het mechanisme om async je js-jes te laden wat weer problemen kan opleveren met domready

En wat voor problemen kan het dan opleveren?