C’est peut être ce qui résoudrait quelques problèmes de performances : une option « fast » en javascript. Cela permettrait de déclarer qu’on n’utilise pas de document.write et ne plus bloquer le rendu du navigateur. On pourrait aussi déclarer ne pas toucher aux prototypes des objets de base pour bénéficier de meilleures optimisations de l’interpréteur.
Si les moteurs nous proposent certains options qui permettent de choisir entre fonctionnalités et performances, je suis convaincu que souvent l’option performance serait intéressante.
C’est Microsoft qui nous propose une option /fast dans son moteur Jscript .NET. On force la déclaration de toutes les variables avec le mot clef var, on interdit l’accès en écriture sur les objets de base, on interdit de redéfinir une fonction déjà existante et enfin on retire la possibilité d’accéder dynamiquement aux arguments d’une fonction avec arguments. En échange on le moteur fait des optimisations de son côté pour plus de performances.
Je n’ai pas réussi à retrouver le lien mais je me rappelle qu’une implémentation javascript ou vbscript utilise déjà des paramètres dans le type mime afin d’ajouter des options à l’interpréteur : quelque chose comme <script type="application/vbscript;perf=1">. L’astuce est probablement théoriquement réalisable sur tous les navigateurs.
Tout ceci demande bien entendu un support des navigateurs, une route spécifique dans l’interpréteur, et plus de travail pour les développeurs de l’interpréteur javascript, mais les effets peuvent être notables à moindre coût. Les contraintes imposées par l’option /fast de Jscript sont tout à fait acceptable pour une majorité de scripts.
Qu’en pensez vous ? avez-vous vu une orientation similaire pour les autres implémentations de javascript ?
« Je me rappelle qu’une implémentation javascript ou vbscript utilise déjà des paramètres dans le type mime afin d’ajouter des options à l’interpréteur »
Bah… Firefox: type= »text/javascript;e4x=1″ pour activer E4X, par exemple.
Tiens, voilà un bon exemple
L’option
deferd’Internet Explorer ne correspond-t-elle pas à ce dont tu parles ? Il me semble avoir lu que les navigateurs modernes s’orientent dans cette voix ; Webkit en particulier, mais impossible de retrouver la source.Dans tous les cas, mieux vaut placer son JavaScript en bas de page, et le charger en différé selon une des nombreuses techniques disponibles (page 27 du diaporama).
hum .. j’avoue mon ignorance sur ce qu’il se passe si on fait un document.write dans un script en defer, mais non, ce n’est pas exactement ça. Le defer va retarder l’exécution du script à la fin de la page.
Ce que j’attendais c’est une exécution « au plus tôt » mais sans bloquer le navigateur.
Webkit et IE préparent des choses très bien pour ne pas bloquer les téléchargements. Par contre au moins dans le cas de webkit, si ça ne bloque pas les téléchargements, ça bloque quand même le rendu. Ils emploient un double parser et le visiteur ne voit toujours pas sa page en attendant la fin des téléchargements et des exécutions js. Bref, c’est nettement mieux mais pas parfait.
(pour les liens j’ai mis mes sources IE et Webkit sur un des derniers billets sur le sujet : http://performance.survol.fr/2008/08/javascript-non-bloquant/ )
Les techniques de chargement dynamique correspondent bien mieux à ce que je cherche mais disons que j’aurai trouvé bien que ce genre d’option soit par défaut dans le moteur sans avoir à faire des artifices côté utilisateur.
Nonon, ce sont deux idées distinctes. J’ai d’abord parlé de
defer, et de l’idée d’avoir un système natif au navigateur, pour s’occuper du chargement des scripts. Merci d’ailleurs pour le lien, j’ai lu l’article plus tard et j’ai vu les deux liens (dont celui auquel je faisais allusion sur Webkit).La deuxième idée est qu’à défaut d’un recours natif, on va retarder l’interprétation des scripts via une des astuces du diagramme que j’ai lié.
Note : j’ai dévoré tout ton blog ; c’est agréable de trouver enfin un français qui partage la passion de la performance web !
Pour le document.write c’est juste une interogation quand j’y pense. Parce que si le document.write fonctionne correctement, le rendu est certainement bloqué (même si les téléchargement, eux, continuent).
Sinon oui, les javascripts sont une solution. Je regrette que ce soit une solution de contournement et justement pas une solution native.