[spip-dev] optimisation : compactage head js et css

Bonjour,

je suis en train d'optimiser mon site, et à cette occasion j'ai pu me rendre compte avec plaisir que la fonction de compactage css / javascript du header des pages fonctionne bien mieux sous spip 2 qu'en 1.9 (où elle cassait beaucoup de plugins).

Cependant je me suis rendu compte qu'elle "oublie" un certain nombre de fichiers, par exemple :
- couteau suisse -> jquery.scrollto.js
- couteau suisse -> jquery.localscroll.js
- couteau suisse -> decoupe.css
- couteau suisse -> decoupe.js
- couteau suisse -> sommaire.js
- couteau suisse -> blocs.js
- thickbox2 -> thickbox.css
- crayons -> crayons.css
- crayons -> crayons.js

A noter aussi qu'elle ne compresse pas le javascript et le css inclus directement dans le head, ce qui serait pourtant souvent utile...

Une amélioration à prévoir ?

    Simon

fonction de compactage css / javascript du header
des pages fonctionne bien mieux sous spip 2 qu'en 1.9 (où elle cassait
beaucoup de plugins).

ouf :slight_smile:

Cependant je me suis rendu compte qu'elle "oublie" un certain nombre de
fichiers, par exemple :
- thickbox2 -> thickbox.css

il faut faire attention au media="..." qui doit être identique à celui
des autres pour que le compactage se fasse

- crayons -> crayons.css
- crayons -> crayons.js

ça c'est normal car les crayons ne sont pas chargés par les visiteurs
non connectés

A noter aussi qu'elle ne compresse pas le javascript et le css inclus
directement dans le head, ce qui serait pourtant souvent utile...

Non car ces valeurs peuvent être différentes sur chaque page, et on
perdrait alors l'avantage de la mise en cache

-- Fil

Fil a écrit :

Cependant je me suis rendu compte qu'elle "oublie" un certain nombre de
fichiers, par exemple :
- thickbox2 -> thickbox.css
    

il faut faire attention au media="..." qui doit être identique à celui
des autres pour que le compactage se fasse
  

En effet, j’ai corrigé dans ma copie locale, mais ça serait peut-être intéressant d’avoir plusieurs css compactés : un par set de médias.

- crayons -> crayons.css
- crayons -> crayons.js
    

ça c'est normal car les crayons ne sont pas chargés par les visiteurs
non connectés
  

Même chose que ci-cessus, pourquoi ne pas les compacter quand-même (et les stocker dans un fichier à part, bien sûr).
Ca virerait au moins les commentaires et autres caractères inutiles une fois en exploitation.

A noter aussi qu'elle ne compresse pas le javascript et le css inclus
directement dans le head, ce qui serait pourtant souvent utile...
    

Non car ces valeurs peuvent être différentes sur chaque page, et on
perdrait alors l'avantage de la mise en cache
  

Oui, mais ce que j’avais dans l’idée, c’est un compactage stocké non pas dans un cache à part mais directement dans celui du squelette calculé : le code reste déclaré là où il est (entre des balises style ou script) mais en version compactée.

Simon

il faut faire attention au media="..." qui doit être identique à celui
des autres pour que le compactage se fasse

En effet, j'ai corrigé dans ma copie locale,

pourquoi ne le commit tu pas ?

mais ça serait peut-être
intéressant d'avoir plusieurs css compactés : un par set de médias.

c'est le cas

Même chose que ci-cessus, pourquoi ne pas les compacter quand-même (et les
stocker dans un fichier à part, bien sûr).
Ca virerait au moins les commentaires et autres caractères inutiles une fois
en exploitation.

as-tu regardé le contenu ?

Oui, mais ce que j'avais dans l'idée, c'est un compactage stocké non pas
dans un cache à part mais directement dans celui du squelette calculé : le
code reste déclaré là où il est (entre des balises style ou script) mais en
version compactée.

en général il s'agit de qqs lignes, ça ne vaut pas le coup

-- Fil

il faut faire attention au media=« … » qui doit être identique à celui
des autres pour que le compactage se fasse

En effet, j’ai corrigé dans ma copie locale,

pourquoi ne le commit tu pas ?

Je teste d’abord si tout va bien, ensuite il faudra que je trouve le temps de me documenter sur comment faire (j’ai très peu d’expérience sur les systèmes de gestion de versions genre SVN, donc ça va me prendre du temps pour comprendre comment ça marche sans faire de grosse bêtise).

mais ça serait peut-être
intéressant d’avoir plusieurs css compactés : un par set de médias.

c’est le cas

Ben justement, j’ai des media=« all » qui sont bien compactés ensemble, mais mon thickbox. css qui est en media=« projection, screen, tv », lui, n’est pas compacté (encore plein de commentaires).

Même chose que ci-cessus, pourquoi ne pas les compacter quand-même (et les
stocker dans un fichier à part, bien sûr).
Ca virerait au moins les commentaires et autres caractères inutiles une fois
en exploitation.

as-tu regardé le contenu ?

Oui, il est tout ce qu’il y a de plus normal, indenté, commenté, etc. tout sauf compacté.
C’est le cas aussi des js et css du couteau suisse.

Oui, mais ce que j’avais dans l’idée, c’est un compactage stocké non pas
dans un cache à part mais directement dans celui du squelette calculé : le
code reste déclaré là où il est (entre des balises style ou script) mais en
version compactée.

en général il s’agit de qqs lignes, ça ne vaut pas le coup

Du coup, en en regardant mieux, la plupart ont l’air bien compactés, mais il y a des gains possible, notamment en rassemblant tout dans un seul conteneur pour js et pour css, en gardant l’ordre d’affichage, bien sûr.
Mine de trien on arrive rapidement à des petits paquets de lignes si on a quelques plugins installés + des lames du couteau suisse + du code perso…

à bientôt
Simon

il faut faire attention au media=« … » qui doit être identique à celui
des autres pour que le compactage se fasse

En effet, j’ai corrigé dans ma copie locale,

pourquoi ne le commit tu pas ?

Je teste d’abord si tout va bien, ensuite il faudra que je trouve le temps de me documenter sur comment faire (j’ai très peu d’expérience sur les systèmes de gestion de versions genre SVN, donc ça va me prendre du temps pour comprendre comment ça marche sans faire de grosse bêtise).

mais ça serait peut-être
intéressant d’avoir plusieurs css compactés : un par set de médias.

c’est le cas

Ben justement, j’ai des media=« all » qui sont bien compactés ensemble, mais mon thickbox. css qui est en media=« projection, screen, tv », lui, n’est pas compacté (encore plein de commentaires).

lorsqu’il y a un seul fichier statique pour un jeu de media, on ne compacte pas et on sert direct le fichier d’origine, car la compression ne vaut pas vraiment le coup dans ce cas.

Même chose que ci-cessus, pourquoi ne pas les compacter quand-même (et les
stocker dans un fichier à part, bien sûr).
Ca virerait au moins les commentaires et autres caractères inutiles une fois
en exploitation.

as-tu regardé le contenu ?

Oui, il est tout ce qu’il y a de plus normal, indenté, commenté, etc. tout sauf compacté.
C’est le cas aussi des js et css du couteau suisse.

les crayons concernent les administrateurs du site, donc, sauf cas particulier, un volume de trafic faible qui ne justifierait pas la mise en place de la compression en terme de performance (je rappelle que les navigateurs mettent en cache les js et css, donc les admins d’un site les ont toujours en cache…)

Oui, mais ce que j’avais dans l’idée, c’est un compactage stocké non pas
dans un cache à part mais directement dans celui du squelette calculé : le
code reste déclaré là où il est (entre des balises style ou script) mais en
version compactée.

en général il s’agit de qqs lignes, ça ne vaut pas le coup

Du coup, en en regardant mieux, la plupart ont l’air bien compactés, mais il y a des gains possible, notamment en rassemblant tout dans un seul conteneur pour js et pour css, en gardant l’ordre d’affichage, bien sûr.

Non. Enfin ce n’est pas possible en garantissant que ça marche dans 100% des cas. En particulier lorsque du js inline est lié à un script chargé. Il faudrait donc des règlages compliqués pour que chacun puisse adapter le compresseur en fonction de son cas.
En vertu de la règle « 80% du résultat optimal avec 20% des efforts », je me suis donc arrêté là.

Mine de trien on arrive rapidement à des petits paquets de lignes si on a quelques plugins installés + des lames du couteau suisse + du code perso…

Si ton site est critique en terme de performance, peut-être te faut il envisager d’utiliser quelque chose d’un peu plus taillé sur mesure que le couteau suisse, et mettre tout ce dont tu as besoin dans un js externe.

Cédric

> mais ça serait peut-être
> intéressant d'avoir plusieurs css compactés : un par set de médias.

c'est le cas

Ben justement, j'ai des media="all" qui sont bien compactés ensemble, mais mon thickbox. css qui est en media="projection, screen, tv", lui, n'est pas compacté (encore plein de commentaires).

sans doute parce qu'il est tout seul à avoir ce @media

Oui, il est tout ce qu'il y a de plus normal, indenté, commenté, etc. tout sauf compacté.
C'est le cas aussi des js et css du couteau suisse.

non, crayons.js est compacté, sauf si tu es en mode debug

en général il s'agit de qqs lignes, ça ne vaut pas le coup

Du coup, en en regardant mieux, la plupart ont l'air bien compactés, mais il y a des gains possible, notamment en rassemblant tout dans un seul conteneur <script> pour js et <style> pour css, en gardant l'ordre d'affichage, bien sûr.
Mine de trien on arrive rapidement à des petits paquets de lignes si on a quelques plugins installés + des lames du couteau suisse + du code perso...

N'hésite pas à proposer du code. Attention comme il risque de
s'exécuter souvent il faut qu'il soit rapide (si pour gagner 1ms on en
perd 10, pas la peine)

-- Fil

Le 28 août 2009 18:28, Fil <fil@rezo.net> a écrit :> mais ça serait peut-être

intéressant d’avoir plusieurs css compactés : un par set de médias.

c’est le cas

Ben justement, j’ai des media=« all » qui sont bien compactés ensemble, mais mon thickbox. css qui est en media=« projection, screen, tv », lui, n’est pas compacté (encore plein de commentaires).

lorsqu’il y a un seul fichier statique pour un jeu de media, on ne compacte pas et on sert direct le fichier d’origine, car la compression ne vaut pas vraiment le coup dans ce cas.

Ok, je comprends mieux

Même chose que ci-cessus, pourquoi ne pas les compacter quand-même (et les
stocker dans un fichier à part, bien sûr).
Ca virerait au moins les commentaires et autres caractères inutiles une fois
en exploitation.

as-tu regardé le contenu ?

Oui, il est tout ce qu’il y a de plus normal, indenté, commenté, etc. tout sauf compacté.
C’est le cas aussi des js et css du couteau suisse.

les crayons concernent les administrateurs du site, donc, sauf cas particulier, un volume de trafic faible qui ne justifierait pas la mise en place de la compression en terme de performance (je rappelle que les navigateurs mettent en cache les js et css, donc les admins d’un site les ont toujours en cache…)

Ca n’est pas le cas pour mon site, mais vu qu’il y a des sites qui utilisent les crayons pour des zones wiki comme spip-contrib, ça pourrait quand-même aider de ne pas les ignorer complètement, non ?

Oui, mais ce que j’avais dans l’idée, c’est un compactage stocké non pas
dans un cache à part mais directement dans celui du squelette calculé : le
code reste déclaré là où il est (entre des balises style ou script) mais en
version compactée.

en général il s’agit de qqs lignes, ça ne vaut pas le coup

Du coup, en en regardant mieux, la plupart ont l’air bien compactés, mais il y a des gains possible, notamment en rassemblant tout dans un seul conteneur pour js et pour css, en gardant l’ordre d’affichage, bien sûr.

Non. Enfin ce n’est pas possible en garantissant que ça marche dans 100% des cas. En particulier lorsque du js inline est lié à un script chargé. Il faudrait donc des règlages compliqués pour que chacun puisse adapter le compresseur en fonction de son cas.
En vertu de la règle « 80% du résultat optimal avec 20% des efforts », je me suis donc arrêté là.

En effet, je vois le genre de cas où ça pourrait péter du js inline, tu as raison.
Par contre, pour le css, si je ne m’abuse, l’ordre de priorité est toujours inline > importé, quel que soient leurs positions respectives. Après il suffit de respecter l’ordre de déclaration pour ne pas casser les styles…

Mine de trien on arrive rapidement à des petits paquets de lignes si on a quelques plugins installés + des lames du couteau suisse + du code perso…

Si ton site est critique en terme de performance, peut-être te faut il envisager d’utiliser quelque chose d’un peu plus taillé sur mesure que le couteau suisse, et mettre tout ce dont tu as besoin dans un js externe.

S’il l’était, c’est ce que je ferais aujourd’hui.
Je profite seulement d’une campagne d’optimisation que je réalise actuellement sur ce site pour partager les améliorations possibles qui pourraient profiter à tout les utilisateurs de spip.

A bientôt
Simon

cedric.morin@yterium.com a écrit :

Mine de trien on arrive rapidement à des petits paquets de lignes si on a quelques plugins installés + des lames du couteau suisse + du code perso...

Si ton site est critique en terme de performance, peut-être te faut il envisager d'utiliser quelque chose d'un peu plus taillé sur mesure que le couteau suisse, et mettre tout ce dont tu as besoin dans un js externe.

Bon, je continue à creuser, et pour info, j'ai enfin trouvé pourquoi le code du couteau suisse n'est pas compacté : en fait c'est dû à ma config locale où je redirige l'espace privé sur https mais pas le site public.
=> à la compilation des lames du couteau suisse, les appels à url_absolue() renvoient donc le domaine de l'espace privé en https comme racine, empêchant donc le compactage.
Je vais bricoler un truc en local pour que ça marche, ce n'est donc pas un manque du CS ni de spip.

A bientôt
    Simon

Simon Camerlo wrote:

c'est dû à ma config locale où je redirige l'espace privé sur https mais pas le site public.

Bonjour Simon,

J'aimerais bien savoir comment faire cela, si tu sais où se trouvent des explications pour le faire.

Paolo

Paolo a écrit :

Simon Camerlo wrote:

c'est dû à ma config locale où je redirige l'espace privé sur https mais pas le site public.

Bonjour Simon,

J'aimerais bien savoir comment faire cela, si tu sais où se trouvent des explications pour le faire.

Paolo

Alors c'est de la pure bidouille de .htaccess, je ne sais pas si c'est fiable à 100% mais voilà comment j'ai procédé.

- la première étape est bien sûr d'acheter un certificat associé à ton nom de domaine et de l'installer sur le serveur
- ensuite, avec les .htaccess activés, j'ai rajouté ces règles :

RewriteEngine On

#renvoi de toutes les pages de l'espace privé sur https
RewriteCond %{SERVER_PORT} !^443$ [NC]
RewriteCond %{REQUEST_URI} ecrire [NC]
RewriteRule ^(.*)$ https://www.mondomaine.org/$1 [QSA,NC,R=301,L]

#procédure de login en https
RewriteCond %{SERVER_PORT} !^443$ [NC]
RewriteCond %{REQUEST_URI} spip.php [NC]
RewriteCond %{QUERY_STRING} (page=login|action=cookie) [NC]
RewriteRule ^(.*)$ https://www.mondomaine.org/$1 [QSA,NC,R=301,L]

#formulaires de l'espace privé
RewriteCond %{SERVER_PORT} !^443$ [NC]
RewriteCond %{REQUEST_URI} spip.php [NC]
RewriteCond %{QUERY_STRING} ^(.*exec.*)$ [NC]
RewriteRule ^(.*)$ https://www.mondomaine.org/$1 [QSA,NC,R=301,L]

Si certains d'entre-vous voient des règles à ajouter pour éviter les trous, je suis preneur.

A bientôt
    Simon

Simon Camerlo wrote:

Si certains d'entre-vous voient des règles à ajouter pour éviter les trous, je suis preneur.

Merci pour tout cela !
Dès que je le pourrai, je vais l'essayer.
Paolo