Er zijn heel veel factoren die invloed hebben op de snelheid waarmee een webpagina wordt afgebeeld. Zaken zoals het aantal requests per pagina, het wel of niet gebruik maken van een Content Delivery Network, het instellen van gzip voor bepaalde type content en een juiste plaatsing van scripts en stylesheets in de pagina, dragen allemaal bij aan de ervaring die de gebruiker heeft als hij de pagina opvraagt. Als de ontwikkelaar te veel van deze zaken fout aanpakt, dan zal hij de woede van de gebruiker op zijn hals halen en wellicht hevig bloedend ergens in een greppel treurig aan zijn einde komen.
Er zijn twee lekker pragmatische en niet te dikke boeken over deze onderwerpen geschreven die ik even wil aanstippen: “High Performance Web Sites” en “Even Faster Web Sites”, beide van Steve Souders (http://stevesouders.com/hpws/rules.php). Beide boeken zijn binnen ISAAC in ieder geval verplichte kost voor alle web develeopers.
In deze blogpost wil ik een van de technieken uit het tweede boek kort introduceren: “JavaScript laden zonder de browser te blokkeren”. Het probleem dat hier speelt is dat scripts die worden geladen m.b.v. een SCRIPT tag tot gevolg hebben dat de browser helemaal niets anders zal downloaden tijdens het laden en interpreteren van deze code. Dit alles kan resulteren in een significante verlenging van de laadtijd en dus tot een tragere pagina. Zonde, want browsers kunnen in theorie meerdere bestanden parallel downloaden.
De reden dat de browser niets anders downloadt is dat de JavaScript die op dat moment wordt gedownload de rest van de pagina kan wijzigen na executie. Het aantal en de volgorde van de andere resources kan afwijken van wat er in de oorspronkelijke HTML is gespecificeerd (bv met de document.write(…) constructie). Dit wijzigen van de HTML is in het overgrote deel van de gevallen helemaal niet aan de orde en resulteert dus in een onnodig lange laadtijd. Daarnaast is de volgorde waarin externe JavaScript bestanden zijn gedefinieerd in de HTML tevens de volgorde waarin ze moeten worden geëxecuteerd door de browser. Deze executievolgorde is eigenlijk niet van belang voor de volgorde waarin de scripts worden gedownload, iets dat tot nu toe alleen de ontwikkelaars van IE8, Safari 4 en Chrome 2 hebben begrepen: deze browsers ondersteunen het parallel downloaden van scripts wel. Andere resources worden echter wel nog steeds geblokkeerd.
In “Even Faster Web Sites” worden een aantal technieken geïntroduceerd die dit probleem (ten dele) oplossen. Ik zal deze hier kort introduceren. Voor de details verwijs ik echter door naar het boek zelf.
XHR Eval.
In deze techniek worden de scripts met een XMLHttpRequest gedownload en vervolgens met een aanroep van eval() geïnterpreteerd. Dit werkt: de browsers blokkeren het downloaden van de andere resultaten niet. Het grote probleem is echter dat je op deze manier alleen scripts kan laden die van hetzelfde domein komen als de pagina zelf.
XHR Injection
Deze methode lijkt enigszins op de voorgaande: het script wordt geladen mb.v. de XMLHttpRequest functie, maar wordt geëxecuteerd door een SCRIPT tag in de DOM te creëren en de gedownloade code daarin te injecteren. Deze methode is soms iets sneller dan het gebruik van eval(), maar lijdt onder dezelfde beperkingen.
Script in Iframe
Iframes worden parallel geladen met andere componenten op een pagina. Door in iframe’s HTML pagina’s te laden die verwijzen naar de gewenste scripts, worden deze scripts dus parallel gedownload. Ook deze techniek is beperkt tot scripts die op hetzelfde domein staan als de hoofdpagina zelf. Bovendien moet de code worden aangepast om een verbinding tussen de hoofd- en de iframepagina te leggen.
Script DOM Element
Als alternatief voor het initieel opnemen van een SCRIPT tag in de HTML, kan er ook een on-the-fly worden gecreëerd m.b.v. document.createElement(…). Deze tag wordt dan dynamisch voorzien van een src attribuut en vervolgens in de HTML geïnjecteerd. Deze methode is geschikt voor scripts die komen van een andere domein dan het domein van de pagina zelf.
Script defer
IE ondersteunt het DEFER attribuut bij de SCRIPT tag. Defer is een indicatie aan IE dat het gerefereerde script geen DOM wijzigingen zal uitvoeren en dat het niet meteen hoeft te worden gedownload. Dit heeft tot gevolg dat IE andere bestanden parallel met dit script zal downloaden. Het werkt echter alleen in IE en enkele nieuwe browsers.
Document.write Script tag
In deze techniek wordt net als bij de “Script DOM Element” methode een SCRIPT tag dynamisch aan de HTML toegevoegd, dit keer echter met een document.write() constructie. Het verschil is dat deze techniek alleen resulteert in het parallel downloaden van andere scripts, alle andere bestanden worden toch geblokkeerd.
Conclusie
Na het lezen van de technieken lijkt het redelijk simpel: kies altijd voor de “Script DOM Element” methode. De realiteit is echter niet zo eenvoudig. De keuze hangt af van het gewenste gedrag van de “busy indicators” in de browser (de visuele hints die aangeven dat er iets wordt gedownload) en van de wens om de download- en executievolgorde af te dwingen. Voor meer details over wanneer je nou precies wat moet kiezen verwijs ik je graag door naar hoofdstuk 4 van “Even Faster Web Sites”.
