Bonjour,
En essayant d'accélérer un peu les pages avec l'aide de l'article d'Arno* (http://www.paris-beyrouth.org/tutoriaux-spip/article/objectif-pagespeed-100-100-avec) et PageSpeed, je lis ici:
http://code.google.com/speed/page-speed/docs/rtt.html#PutStylesBeforeScripts
qu'il est bien de charger les css avant le js.
Peut-être SPIP pourrait les charger dans cette ordre lorsque l'option de compression est choisie dans l'espace privé ?
Paolo
C'est en principe le cas :
Le js concatene est insere a la place du premier script qui en fait partie,
Et idem pour les css concatenee, qui devrait être habillage.css et arriver avant #INSERT_HEAD
Cela peut donc ne pas produire le bon résultat si ton habillage.css n'est pas au bon endroit, ou si elle n'est pas inclue dans la css concatenee.
Sur ce sujet, Spip 2.1 introduit #INSERT_HEAD_CSS
Pour permettre aux plugins d'ajouter leurs css avant leur js et optimiser le tout.
Mais il faut l'ajouter dans ton squelette, et tous les plugins ne gerent pas encore cette insertion séparée.
Cédric
Cela dit, si je ne me trompes pas:
- puisqu'on se base sur jQuery, les scripts ne sont déclenchés qu'à la fin du «load» (document.ready), donc normalement les CSS sont chargés quand on lance les éventuels calculs de jQuery qui prennent dépendent des dimensions des éléments de la page; les Javascript qui bloquent l'affichage de la page avec un document.write, ça n'est plus très fréquent, et c'est plutôt installé «inline» dans le corps du texte (genre bandeau de pub ou compteur mal fichu);
- comme ce sont les deux premiers fichiers appelés dans le head, et que désormais on n'a plus 20 javascript et 30 CSS (que la page d'accueil du Monde) mais seulement un JS et un CSS, les chargements des deux fichiers, .js et .css sont lancés en même temps par le brouteur. Je ne suis pas certain que l'inversion des ordres d'appel changerait grand chose (à moins que 200Kb de données textuelles dans le head séparent les deux appels, ce qui ne doit pas être bien fréquent).
ARNO*
Si justement.
Dès que les navigateurs rencontrent un js, tout autre chargement est bloqué pendant le chargement de ce js, car il est susceptible de faire un document.write()
Donc il ne se passe jamais rien d'autre pendant tout le temps que le navigateur charge et interprète un js.
La simple observation d'une cascade de chargement dans firebug, ou équivalent te permettra de le constater de visu.
Au passage, ce problème, assez pénible, est la raison pour laquelle il peut être préconisé de placer les chargements de js non pas dans le head mais dans le pied de la page.
Cela dit, c'est une préco réalisable sur un site, mais difficilement généralisable car il faudrait ramasser tous les scripts de la page et les executer à la fin.
J'y pense depuis un moment, Renato a fait une tentative, mais on a pas de solution propre, simple, robuste et convaincante automatisable pour le moment.
Cédric