Sinon oui, les javascripts sont une solution. Je regrette que ce soit une solution de contournement et justement pas une solution native.

si on fait un document.write dans un script en defer

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 !

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.

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).

Bah… Firefox: type= »text/javascript;e4x=1″ pour activer E4X, par exemple.