Paris-Beyrouth

Plugin SPIP : « CSS imbriqués », pré-processeur de CSS

ARNO* — 2011-09-27T12:58:01Z

Voici un pré-processeur de CSS destiné aux webmestres qui manipulent sous SPIP des fichiers CSS particulièrement complexes, avec des imbrications à la chaîne.


Télécharger le plugin « CSS imbriqués »

Une des difficultés des CSS, lorsque l'on commence à entrer dans les plus petits détails de l'interface d'un site Web et que l'on veut donc créer des classes très discriminées selon les endroits, est que l'on se retrouve alors avec des listes interminables de classes aux noms de plus en plus longs.

Une idée qui circule sur le Web (par exemple sur le site de Shaun Inman) consiste à écrire ses styles selon une méthode contenant des enrichissements par rapport à la norme, puis à faire passer ces fichiers par un pré-processeur qui les transforme en fichiers CSS standards.

SPIP propose déjà quelques solutions pour aller dans ce sens :
— en passant une feuille de style par le filtre direction_css, on peut l'adapter automatiquement aux langues qui s'écrivent de droite à gauche, l'interface étant intégralement inversée ;
— avec les balises #SET et #GET, si l'on réalise ses styles sous forme de squelettes, on a un système de variables très pratique (par exemple : définir une seule fois la valeur d'une couleur puis l'utiliser dans plusieurs classes ; par la suite, pour changer la couleur de l'ensemble, il suffit d'intervenir uniquement dans la définition de la variable).

Il manque, à mon avis, une autre possibilité offerte par le pré-processeur de Shaun Inman : pouvoir écrire ses définitions de classes sous forme imbriquée (nested), pour en clarifier la lecture.

C'est l'objet du présent plugin.

Voici un court morceau de code CSS standard :

ul#principal {
border: 1px solid red;
width: 200px;
background-color: #aaaaaa;
}
ul#principal li {
color: red;
}
ul#principal li a {
color: black;
}
ul#principal li.on {
background-color: red;
color: white;
}
ul#principal li.on a {
color: #ffaaaa;
}

Télécharger

On peut considérer que ce code est artificiellement compliqué, mais en réalité, quand on entre dans les détails d'une mise en page, on se retrouve rapidement avec des systèmes d'héritages beaucoup plus complexe.

L'idée de la méthode des CSS imbriqués est de saisir une classe qui dépend d'une autre classe à l'intérieur de sa définition, sans répéter la hiérarchie des intitulés.

Ainsi le code précédent s'écrit :

ul#principal {
border: 1px solid red;
width: 200px;
background-color: #aaaaaa;
li {
color: red;
a {
color: black;
}
}
li.on {
background-color: red;
color: white;
a {
color: #ffaaaa;
}
}
}

Télécharger

Il existe une autre subtilité : la possibilité, dans une classe imbriquée, de faire précéder le nom de la classe imbriquée par un point suivi d'un espace ; cela indique que cette classe est une variante de la précédente (plus simplement : on « colle » les deux noms). Voici par exemple une manière de code a.spip_in, a.spip_out :

a {
. .spip_in {...}
. .spip_out {...}
}

Télécharger

et avec des variantes de survol :

a {
. .spip_in {
...
. :hover {...}
}
. .spip_out {
...
. :hover {...}
}
}

Télécharger

Notez bien : cette notation n'est pas standard et ne correspond pas à la norme des CSS. Il s'agit d'un système de notation qui doit être impérativement traduit de manière logicielle (par le présent plugin) pour qu'un fichier CSS standard soit envoyé au visiteur.

Remarque : l'utilisation du plugin ne vous interdit pas d'utiliser la notation d'une manière respectant la norme : le plugin admet des fichiers totalement standards, ou totalement imbriqués, ou utilisant les deux notations (la méthode imbriquée n'étant qu'une extension de la norme).

Pour que ce plugin traite votre fichier CSS, il faut l'utiliser de la même façon qu'on utilise direction_css, ou en complément de ce dernier, en passant le fichier par css_imbriques :

[(#CHEMIN{monstyle.css}|direction_css|css_imbriques)" type="text/css" />]

Si vous réalisez votre feuille de style sous forme de squelette (ma méthode préférée), il suffit d'ajouter, en fin de squelettes (par exemple « css.html »), la balise :

#FILTRE{css_imbriques_decouper}

Une autre méthode pour utiliser des CSS imbriqués dans une feuille de style sous forme de squelette (ici, couleur.html) consiste à l'appeler ainsi :

rel="stylesheet"
href="[(#URL_PAGE{couleur}|direction_css|css_imbriques)]"
type="text/css" />

Télécharger

Cette dernière méthode est particulièrement compatible avec la fonction de SPIP qui regroupe différents fichiers CSS dans un même fichier compacté.

Notez enfin que ces fonctions, contrairement à direction_css, ne traitent pas les @import présents à l'intérieur des fichiers CSS. Dans la version actuelle, il y a des chances que ces @import disparaissent (bug à corriger pour une prochaine version).

Pseudo-styles

La version 1.2 du plugin introduit des pseudo-styles, non standards, permettant de coder facilement des fonctionnalités des CSS (généralement qualifiées de « CSS 3 ») qui demandent habituellement plusieurs lignes de code, voire des codes très farfelus pour assurer une compatibilité maximale pour le webkit (Safari, Chrome), Mozilla, Opera et MSIE.

Ces pseudo-styles, à l'image des raccourcis propres à Mozilla (styles commençant par -moz) ou le webkit (-webkit), commencent ici par le -spip. Il permettent en une seule ligne, assez simple, de produire automatique les différents codes nécessaires à l'affichage cohérent sur les différents navigateurs.

Opacité

Voici le pseudo-style pour gérer l'opacité :

.exemple {
-spip-opacity: 0.4;
}

Télécharger

Ce -spip-opacity est ainsi transformé par le plugin :

.exemple {
-webkit-opacity:0.4;
-moz-opacity:0.4;
opacity:0.4;
-ms-filter:"progid:DXImageTransform.Microsoft.Alpha(opacity=40)";
zoom:1;
}

Télécharger

À partir d'une seule déclaration (-spip-opacity), on obtient ainsi automatiquement le code fonctionnant sous d'anciennes versions de Safari, sous Mozilla 3.5, sous Chrome et Safari, ainsi que sous Internet Explorer (notez l'utilisation d'un « filtre » MSIE et la valeur d'opacité adaptée.

Coins arrondis

Le code de base arrondi d'un coup tous les coins :

-spip-border-radius: 6px;

On peut préciser une valeur pour chacun des coins du pavé :

-spip-border-top-right-radius: 0px;
-spip-border-top-left-radius: 3px;
-spip-border-bottom-right-radius: 14px;
-spip-border-bottom-left-radius: 2px;

Télécharger

Ombre de boîte

-spip-box-shadow: 3px 2px 10px #666666;

La première valeur (3px) est le décalage de l'ombre portée vers la droite. La seconde (2px) est le décalage vers le bas. La troisième (10px) est l'intensité du floutage de l'ombre. La dernière valeur est la couleur.

En mettant les deux premières valeurs à zéro, on obtient assez classiquement un halo autour de la boîte, et non une ombre portée.

Dégradé

-spip-gradient: top, #f0f0f0, #bbbbbb;

Je n'ai pas trouvé de consensus sur la syntaxe exacte d'un dégradé de fond, aussi je me suis inspiré de ce que propose le W3C, en essayant de faire aussi simple que possible. À noter : les différents navigateurs ont de puissantes particularités, mais la méthode proposée est simple et le rendu est très proche sous Mozilla, Safari, Chrome et... Internet Explorer (même de vieilles versions !).

Le code produit est assez farfelu :

background:-webkit-gradient(linear,left top,left bottom,from(#f0f0f0),to(#bbbbbb));
background-image:-moz-linear-gradient(top,#f0f0f0,#bbbbbb);
filter:progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#f0f0f0',endColorstr='#bbbbbb');

Télécharger

La syntaxe de notre pseudo-style est la suivante :
— « top » l'orientation du dégradé (de haut en bas) ; l'autre valeur possible est « left » (de gauche à droite) ; il n'est pas possible de faire un dégradé en biais (MSIE ne sait pas le faire, et les dégradés verticaux et horizontaux représentent en pratique un bonne partie des besoins) ;
— la première couleur est la couleur de départ (ici, la couleur du haut),
— la seconde est la couleur d'arrivée (ici, en bas).

Pour assurer la compatibilité avec les navigateurs qui ne gèrent pas les dégradés, on pensera à indiquer, dans la feuille de style, la couleur de fond que l'on souhaite. Notez bien : il faut impérative indiquer cette valeur avant le dégradé, sinon on écrase le dégradé :

background: #dddddd;
-spip-gradient: top, #f0f0f0, #bbbbbb;

Télécharger

Important : les couleurs de dégradé doivent être indiquées sous forme hexadécimale « classique » à six lettres (pour la compatibilité du code pour MSIE) ; par ailleurs, l'actuel compacteur de CSS livré avec SPIP est en effet un peu trop « efficace », et transforme les codes couleurs composés de trois paires de lettres identiques (du genre #ff0066 transformé en #f06) d'une façon qui ne permet plus au dégradé MSIE de fonctionner. Si vous utilisez le compactage des CSS (et vous devriez le faire...), choisissez des couleurs qui n'ont pas d'équivalent à trois lettres (tel que #ff0066).

Fond de bloc semi-transparent

Pour réaliser des fonds de bloc colorés semi-transparents, dans les navigateurs modernes, il suffit de définir la couleur de fond en rgba (on code les 3 composantes de couleurs, suivies d'une valeur d'opacité).

Évidemment, pas sous MSIE.

Le pseudo-raccourci suivant transforme les valeurs pour qu'elles fonctionnent « normalement » en RGBA, et fabriquent le filtre approprié pour MSIE.

-spip-background-color: rgba (255, 255, 127, 0.5);

On peut aussi utiliser des pourcentages :

-spip-background-color: rgba (100%, 100%, 50%, 0.5);

Notez bien : n'insérez pas de background-color traditionnel avec ce style, sinon il écrasera l'effet de transparence sous MSIE.

Transitions

La versions 1.3 du plugin traite les transitions CSS :

-spip-transition
-spip-transition-property
-spip-transition-duration
-spip-transition-timing-function
-spip-transition-delay

Télécharger

Par exemple, pour effectuer une transition sur la couleur du fond, on peut coder ainsi :

a {
background-color: #eeeeeee;
-spip-transition-property: background-color;
-spip-transition-duration: 0.1s;
}
a:hover {
background-color: #cccccc;
}

Télécharger

Text shadow

L'ombre portée du texte se code avec -spip-text-shadow.

Son intérêt à limité à une situation (qui n'est cependant pas inutile du tout) : lorsque les décalages horizontal et vertical sont nuls, c'est qu'on souhaite réaliser un halo autour du texte.

Dans ce cas, le plugin insère un code compatible MSIE.

-spip-text-shadow: 0px 0px 3px #000000;

Compatibilité

D'après mes essais, la compatibilité est assez bonne, y compris avec MSIE. Habituellement, ces effets se dégradent bien, visuellement, lorsqu'ils ne sont pas actifs. On perd des effets de relief, mais la page n'est pas « déformée » (trucs qui dépassent partout) et le texte reste lisible.

Sous MSIE, on pourra être amené à changer l'ordre des différents styles, certains ayant tendance à en désactiver d'autres (il semble par exemple que l'opacité, placée après la dégradé, annule le dégradé).

Les deux choses à surveiller principalement sont :
— la dégradation de l'opacité ;
— la mention explicite d'une couleur de fond avant la définition d'un dégradé de fond.

Clearfix

On a souvent besoin d'être certain que les « float » sont dégagés à la fin d'un bloc (qui contient, donc des blocs flottants à gauche et/ou à droite). On souhaite éviter d'ajouter un « clear:both » à la suite de ce bloc : on veut que ce soit le bloc lui-même qui contienne l'ordre de libérer les blocs flottants à sa suite.

Pour cela, il existe la méthode dite « clearfix », qui consiste à créer une classe spécifique, .clearfix, que l'on insère dans le code HTML des blocs concernés.

Voir par exemple : http://nicolasgallagher.com/micro-c....

Le plugin CSS imbriqués propose un pseudo-style qui donne le même résultat :

-spip-float: fix;

Le gros avantage de cette méthode, c'est qu'il n'est pas nécessaire d'ajouter une classe dans le code HTML de la page : on peut avec ce pseudo-style forcer le comportement de n'importe quelle class sans modification de code HTML.

Pseudo-styles libres

En dehors des cas prévus ci-dessus, tout pseudo-style commençant par -spip- est automatiquement transformé dans les déclinaisons pour Mozilla, Webkit, MSIE, Opera et en CSS3 « simple ».

Noter que le préprocesseur ne vérifie pas que ces styles existent réellement.

Ainsi,

-spip-user-select: none;

est transformé en :

-moz-user-select: none;
-webkit-user-select: none;
-khtml-user-select: none;
-ms-user-select: none;
-o-user-select: none;
user-select: none;

Télécharger

@media

Les CSS3 introduisent la notion de @media, qui permet de définir des comportements de classes selon divers critères (support, largeur d'affichage...).

À partir de la version 1.8, le plugin CSS imbriqués est compatible avec ces pseudo-classes définissan les @media. Il introduit de plus une subtilité qui permet de définir les @media à l'intérieur d'une hiérarchie (puisqu'ici, les CSS peuvent-être imbriqués), le plugin reconstituant ensuite des classes de @media correctes (à la « racine » des déclarations), regroupant les différentes définitions d'un même média.

Cela permet de définir localement la variante d'une classe en fonction du média, le plugin regroupant ensuite toutes les variantes de classe d'un même média en fin de fichier.

Par exemple :

.colonne_texte {
background-color: white;
a { color: blue; }
@media all and (min-width: 640px) {
a { color: red; }
}
}
@media all and (min-width: 1024px) {
#fond_degrade {
width: 100%;
height: 400px;
position: absolute;
top: 0px;
left: 0px;
}
}

Télécharger

devient :

.colonne_texte {background-color: white;}
.colonne_texte a {color: blue;}
@media all and (min-width: 640px){
.colonne_texte a {color: red;}
}
@media all and (min-width: 1024px){
#fond_degrade {width: 100%;height: 400px;position: absolute;top: 0px;left: 0px;}
}

Télécharger

Mise à jour

1.0. Accepter les critères sur plusieurs lignes, du style :

a,
a.spip_in,
a.spip_out {
text-decoration: none;
color: #ff0000;
}

Télécharger

1.1. Les ereg sont remplacés par des mb_ereg (compatibilité PHP 5.3).

1.2. Introduction de pseudo-styles -spip... permettant de créer automatiquement des styles compatibles Webkit, CSS3, Mozilla et MSIE. Tous les mb_ereg sont remplacés par des preg plus classiques.

1.3. Introduction des pseudo-styles pour les transitions CSS.

1.4. Introduction du pseudo-style -spip-background-color.

1.5. Introduction de -spip-text-shadow.

1.6. Introduction de la fonction couleur_rgba($couleur, $alpha) qui permet de fabriquer une couleur RGBA à partir d'un code hexadécimal.

1.7. Introduction de -spip-float: fix; qui permet de faire adopter par n'importe quelle classe le comportement « clearfix » (sans devoir ajouter de classe dans le code HTML).

1.8. Compatibilité avec les @media queries.

1.9. Ajout du comportement PIE.htc, inséré automatiquement dans les pseudo-comportements -spip-border-radius et -spip-box-shadow. Ces deux pseudo-classes fonctionnent donc désormais sous MSIE.

À noter : dans ces deux pseudo-classes, si aucune position n'est indiquée explicitement, le plugin injecte automatiquement une position:relative;, de façon à assurer le bon fonctionnement sous Internet Explorer.

2.0. Gestion des mediaqueries imbriquées. Le plugin « inverse » la structure par la suite.

2.1. Suppression du comportement PIE.htc (et de l'ajout de « position:relative ») : résultat beaucoup trop aléatoire.

2.3. Retour de PIE.htc, mais on peut le désactiver avec :

define("_UTILISER_PIE_HTC", false);

Si on n'insère pas PIE.htc, le plugin n'insère plus les mentions de position dans les classes pseudo-classes border-radius et box-shadow.

2.4. Tous pseudo-style commençant par -spip- est transformé dans ses équivalents -moz-, -webkit-, -o-, -ms-…

3.0. Compatibilité avec SPIP 3.

3.1 Compatibilité avec les @keyframes. Par cohérence, on pourra utiliser @-spip-keyframes. Dans tous les cas, le plugin fabriquera toutes les versions avec les différents préfixes.

Et pour appeler ces keyframes, utiliser évidemment -spip-animation, qui fabriquera également les versions avec les préfixes nécessaires.

Remarque. Le minifieur de CSS intégré a SPIP n'autorise pas d'intitulé de CSS baptisé « 0% » (il le remplace par « 0 »). Ce qui bloque les keyframes qui commencent par cet intitulé. Le pré-processeur remplace donc automatiquement l'intitulé « 0% » par « from ».

Plugin « Supprimer l'enveloppe du mailto»

ARNO* — 2011-09-27T12:48:20Z

En compétition pour le titre de plugin le plus idiot...

SPIP ajoute une petite enveloppe avant tous les liens hypertextes de type mailto. C'est astucieux et pratique, puisque ça permet d'identifier les liens qui ouvrent le logiciel de mail.

Mais à chaque fois que je développe un site, « on » me demande de supprimer la petite enveloppe (les gens, tout de même...). Alors plutôt que de retrouver la ligne de CSS responsable de cet effet à chaque fois, voici un petit plugin qui ne fait que cela.

Il suffit de l'activer, et d'utiliser le #INSERT_HEAD dans ses squelettes.

Plugin « Listes d'articles complètes »

ARNO* — 2011-09-27T12:33:38Z

Ce plugin modifie la présentation des listes d'articles dans l'espace privé en ajoutant ;
le surtitre,
le soustitre,
un logo deux fois plus grand,
le nombre de visites,
la popularité de l'article.


Télécharger le plugin

Selon les droits de l'utilisateur connecté et le statut de chaque article, le plugin affiche des liens supplémentaires pour :
accéder à la page de statistiques de l'article,
modifier l'article,
afficher l'article en ligne.

Attention, le plugin surcharge les fonctions inc_afficher_articles et inc_formater_article.

Plugin « Inclure Ajaxload »

ARNO* — 2011-09-27T12:31:48Z

La fonction introduite par ce plugin est similaire au principe d'Ajax Parallel Loading introduit dans Zpip, tel que décrit ici. La méthode de fonctionnement est cependant différente, et surtout ce plugin est destiné à être utilisé dans n'importe quel jeu de squelettes (non Zpip, donc).


Plugins « Inclure Ajaxload »

Il ajoute un critère, {ajaxload}, à la balise #INCLURE, par exemple :

[(#INCLURE{fond=inc/footer}{id_rubrique}{ajaxload})]

Au lieu d'insérer dans le code source de la page le contenu de inc/footer avec la variable d'environnement id_rubrique, le critère {ajaxload} modifie complètement le fonctionnement : seul un lien hypertexte doté d'un code spécifique est inséré dans la page. À l'affichage de la page chez le visiteur, une fonction Javascript charge dynamiquement le contenu nécessaire et l'insère à l'endroit prévu.

Il est impératif d'utiliser #INSERT_HEAD dans le squelette appelant (le code Javascript nécessaire au bon fonctionnement est alors inséré dans la page).

Quelques remarques :
seuls les critères spécifiés dans l'appel #INCLURE sont passés à la page appelante ; si ces critères sont communs à plusieurs pages, on bénéficie ainsi du chargement d'éléments communs à ces pages (cache navigateur) ;
si Javascript est désactivé chez le visiteur, une version fonctionnant sans Javascript est activée ;
de manière automatique, les moteurs de recherche se voient proposer le contenu complet (identique à la version sans Javascript), ce qui leur permet d'indexer correctement les pages et de profiter de la navigation du site ;
attention, ne pas insérer dans ces morceaux chargés dynamiquement des publicités ou des compteurs de visites (notamment Google), qui « écrivent » via Javascript, ce qui généralement provoque un affichage de page blanche ; plus généralement, éviter les chargements Ajax à l'intérieur de ces éléments chargés dynamiquement, ils deviennent difficiles à maîtriser.

Méthode alternative : chargement d'un fichier statique

La version 0.7 du plugin introduit une nouvelle méthode : l'inclusion dynamique de fichiers HTML parfaitement statiques. La méthode « normale » fonctionne sur la base des « noisettes Ajax » de SPIP : les fichiers inclus sont donc bien pages SPIP dotées de toutes les caractéristiques habituelles (notamment la possibilité d'avoir du contenu dynamique).

La méthode alternative permet d'inclure non des pages SPIP, mais des petits fichiers HTML statiques, stockés (brutalement...) dans /local/cache-ajaxload.

Pour cela, le critère devient :

{ajaxload=html}

Dans ce cas, au calcul de la page, la noisette est immédiatement calculée, et son contenu est stocké « en dur » dans /local/cache-ajaxload. Au chargement de la page, c'est ce fichier HTML qui est directement inséré dans la page.

Pour les visites des robots de moteurs de recherche ou sans Javascript, ce sont ces morceaux « statiques » qui sont directement inclus.

L'avantage principal de cette méthode est que ces fichiers sont appelés « hors SPIP », et même hors PHP. Ce sont des fichiers HTML entièrement statiques. On gagne en vitesse et en charge du serveur. Il est très probable également que la visite du site par un robot de moteur de recherche soit beaucoup moins lourde pour le serveur avec cette méthode.

L'inconvénient, c'est que ces fichiers sortent totalement de SPIP :
— ils sont totalement statiques, et ne doivent donc contenir aucun élément dépendant d'une #SESSION, du statut du visiteur, ni code PHP non précalculé (tel que l'affichage de l'heure ou de l'IP du visiteur) ;
— le système n'interroge pas la durée du cache selon la méthode SPIP ; la durée de vie d'un tel fichier est fixée par défaut à 2 heures ; on peut forcer une autre durée, dans l'appel, avec un critère supplémentaire (ici : 24 heures) :

{ajaxload=html}{ttl_ajaxload=60*60*24}

L'appel du footer pourrait donc se faire, avec cette méthode, ainsi :

[(#INCLURE{fond=inc/footer}{id_rubrique}{ajaxload=html}{ttl_ajaxload=60*60*24})]

Pour les ceusses qui se la pètent en Javascript

Deux méthodes avancées sont destinées à ceux qui voudraient gérer eux-mêmes les appels Ajax (pas de chargement automatique par ce plugin, donc, mais « à la demande » selon du code développé par le webmestre lui-même). Ces méthodes retournent directement l'URL du fichier qui contient la noisette, à charge pour le créateur du site de savoir comment il souhaite les utiliser :
— {ajaxload=url} retourne l'URL de la noisette dynamique ;
— {ajaxload=url_html} retourne l'URL du fichier HTML statique.

Évolutions

Version 0.5. Les inclusions {ajax}{ajaxload} conservent désormais le fonctionnement du {ajax}. On peut donc ainsi charger des éléments paginés (la pagination Ajax fonctionne à nouveau).

Version 0.6. Meilleure gestion du , notamment dans le cas de passage des robots.

Version 0.7. Introduction de la méthode {ajaxload=html} et du critère {ttl_ajaxload=60*60*24}.

Version 0.8. Divers bugs corrigés concernant la navigation sans Javascript et sans cookies.

Version 1.0. Ajout des méthodes {ajaxload=url} et {ajaxload=url_html}.

Version 1.1. Insertion plus fine du code du , uniquement dans les pages où il est nécessaire. (En revanche, l'insertion du Javascript reste systématique, de façon à ne pas changer, d'une page à l'autre, le fichier Javascript créé par le compactage de SPIP.)

Plugin « Créer Sprites CSS »

ARNO* — 2011-09-27T12:24:13Z

Il n'est pas rare d'utiliser de nombreuses petites vignettes disséminées sur une page. Un menu de navigation dont les titres seraient des images (générées automatiquement par SPIP, tant qu'à faire) contient une floppée de petites images.

Chacune de ces images provoque un appel individuel au serveur Web, ce qui ralentit leur chargement (il vaut mieux charger une « grosse » image que la somme des « petites » images qui la composent) et augmente le travail du serveur.

Ce plugin permet, de manière aussi simple que possible, de regrouper plusieurs vignettes en une seule « grande » image (qui les contient toutes), que l'on affiche à la place de chaque petite vignette. Un style intégré au code permet d'afficher la bonne partie de la grande image (celle qui correspond exactement à la vignette).


Plugin « Créer Sprites CSS »

Par exemple, je réalise un menu de navigation sur mon site en transformant chaque titre de rubrique en image (image typographique) ; chaque titre est réalisé en deux versions : le texte en noir, et le texte en blanc (pour la rubrique active et pour le survol de toutes les rubriques). J'ai 9 rubriques principales, plus le lien « Accueil du site » ; je génère donc 20 petites images typographiques. Un visiteur charge donc 20 petits fichiers différents.

En utilisant le plugin « Créer Sprites CSS », je regroupe automatiquement ces 20 vignettes dans un seul « gros » fichier, et c'est lui que j'affiche à la place de chaque image initiale, avec un astuce CSS qui permet d'afficher exactement la partie de l'image dont j'ai besoin. Le visiteur charge désormais un unique fichier au lieu de 20.

Pour regrouper différentes images en un unique fichier, il faut les faire passer par le filtre |filtre{nomsprite.png}. nomsprite.png est choisi par le webmestre :
— en utilisant plusieurs noms, on peut ainsi fabriquer différents sprites, soit dans le corps d'une même page, soit entre pages différentes (par exemple un sprite qui changerait pour chaque article),
— la terminaison choisie pour le fichier (ici .png) détermine le format final du sprite.

Voici par exemple comment je réalise mon menu de navigation principal :

#URL_SITE_SPIP">

<:accueil_site|image_typo{police=mafonte.ttf}|sprite{navigation.png}:>

(RUBRIQUES){id_parent=0}{par titre}>

#URL_RUBRIQUE">

[(#TITRE|image_typo{police=mafonte.ttf}|sprite{navigation.png})]

Télécharger

Le principe est le même à chaque fois : je prends mon texte, je le transforme en image typographique, puis je le fais passer par |sprite{navigation.png}. Toutes ces images typographiques seront regroupées et remplacées par un seul « gros » fichier : navigation.png.

Ailleurs dans le corps de ma page, j'ai trois vignettes explicatives. Initialement, ce sont trois insérés dans mes squelettes. Pour les regrouper sous forme d'un sprite, je transforme le code ainsi :

[(#CHEMIN{images_site/fermer-addflip.png}|sprite{boutons.png})]
...
[(#CHEMIN{images_site/annonce-fullscreen-fr.png}|sprite{boutons.png})]

...

[(#CHEMIN{images_site/fullscreen.png}|sprite{boutons.png})]

Télécharger

Ces trois images sont désormais regroupées automatiquement dans un unique fichier, boutons.png.

J'effectue, enfin, la même opération pour réunir de petites vignettes de prévisualisation des documents joints de chaque article (mon site, très graphique, a souvent plus de 20 photographies associées à chaque article). De cette façon, au lieu de charger 20 (jusqu'à 100) petites vignettes, je n'en charge plus qu'une grande.

[(#LOGO_DOCUMENT|image_reduire{0,90}|sprite{vignettes-#ID_ARTICLE.jpg})]

Notez bien :
— Ce plugin est relativement rudimentaire, mais il répond parfaitement à mes besoins, et je l'utilise en production.
— Son fonctionnement est assez particulier par rapport aux habitudes des sprites CSS : il prend des images insérées dans le document, et les transforme en images « vides » (transparentes) de mêmes dimensions, et applique le sprite global en background CSS. Il n'est pas destiné à traiter des images qui seraient déjà dans des background CSS. (Mon idée étant qu'il est avant tout destiné à traiter des images générées par SPIP, et de telles images sont assez rarement utilisées dans des feuilles de style.)
— Attention : le nom que vous choisissez détermine le fichier final. Si vous utilisez plusieurs fois le même nom pour des choses différentes (sur des pages différentes), vous écraserez le fichier d'une page par l'autre. Faites attention au nom que vous choississez.
— Les images PNG transparentes deviendront des fond de CSS, que MSIE 6 gère mal (alors qu'il gère bien les PNG transparents affichés en tant qu'images).
— La méthode retenue n'est pas vraiment adaptée pour gérer des images qui changent souvent (ne serait-ce que parce que le sprite conserve son nom, même si on change son contenu).

Attention

Une particularité de SPIP fait que le calcul de l'image ne se fait que dans le cas d'un squelette inclus, où dans le cas où un administrateur connecté calcule la page au moins une fois (les boutons d'administration provoquant la fonction nécessaire).

L'usage « simple » de cette fonctionnalité fait qu'en général, cela ne pose pas de gros problème, puisqu'une fois que l'image a été calculée, il n'est plus nécessaire de la recalculer.

La difficulté viendra du cas où :
des « sprites » différents sont créés automatiquement pour chaque page du site, et qu'il n'est donc pas envisageable que l'administrateur recalcule toutes ces pages une par une ;
ces « sprites » ne sont pas calculés dans des squelettes inclus.

Dans ce cas, il est possible d'insérer

#FILTRE{creer_sprites}

dans le squelette pour provoquer correctement le calcul des sprites.

Trois plugins pour accélérer encore son site SPIP

ARNO* — 2010-10-08T13:35:24Z

J'ai déjà consacré deux articles à l'amélioration de la vitesse d'un site sous SPIP. Le premier expliquait comment mettre en place, assez simplement, la parallélisation des chargements d'images sur plusieurs sous-noms de domaine ; assez simple, mais demandant tout de même d'accéder à la configuration du serveur Apache. Le second présentait différents réglages que l'on peut effectuer (soit dans SPIP, soit dans Apache, soit dans .htaccess pour améliorer son score PageSpeed, c'est-à-dire améliorer la vitesse de chargement et de rendu de ses pages.

Ce troisième article est consacré à trois plugins de SPIP qui me permettent encore d'augmenter la réactivité d'un site. Le résultat est, dans certains cas, spectaculaire. À nouveau, j'ai testé ces solutions sur Flip-Zone, notre site de mode, qui a les caractéristiques suivantes :
— beaucoup de pages (près de 2000),
— énormément d'images (environ 50 000), et traitements sur toutes les images,
— beaucoup d'images à afficher sur chaque page du site,
— une fois publiée, une page ne changera quasiment plus jamais.

Cache cool

Le plugin Cache cool, développé par Cédric Morin, s'installe sur une version récente de SPIP (au minimum 2.1). Il nécessite l'installation du plugin Job Queue (qui n'est pas, à ma connaissance, documenté).

Une fois installé, le plugin est immédiatement effectif.

Le principe du cache de SPIP est le suivant :
— lorsque j'arrive sur une page du site, SPIP regarde s'il existe une version déjà sauvegardée de la page (un cache),
— il regarde la date de création de ce fichier ;
— si cette date est récente (par exemple, moins de deux heures), SPIP considère que ce cache est utilisable, et l'expédie tel quel au visiteur ;
— en revanche, si ce cache est trop ancien, SPIP lance un nouveau calcul de la page, sauvegarde la nouvelle version calculée en cache, et expédie le résultat au visiteur.

C'est la dernière entrée qui peut poser problème : recalculer la page peut prendre du temps. Sur Flip-Zone, quand le serveur est chargé, cela peut prendre plusieurs secondes. Pendant ce temps-là, le visiteur ne voit rigoureusement rien s'afficher.

Or, sur un site avec beaucoup de pages, cette situation n'est pas rare : il suffit de visiter une page un peu ancienne du site, donc peu visitée, pour être à peu près certain que SPIP va lancer un recalcul avant de servir la page.

C'est là qu'intervient Cache cool. Au lieu de faire attendre le visiteur (parce qu'il recalcule le cache avant d'envoyer quoi que ce soit), il va alors (généralement) envoyer directement le contenu du cache « périmé », et enregistrer le fait qu'il faut recalculer cette page. Le visiteur reçoit donc quasiment instantanément sa page (« périmée »), et le calcul du nouveau cache est renvoyé à plus tard, et cela en tâche de fond.

Sur un site comme Flip-Zone, le résultat est spectaculaire : dès l'installation du plugin, une navigation dans le site semble instantanément beaucoup plus réactive.

Le plugin n'est sans doute pas adapté :
— aux sites ayant trop peu de trafic (la liste de pages à recalculer s'allonge, sans qu'il y ait assez de visiteurs pour provoquer les calculs),
— aux sites dont le contenu de chaque page est censé être mis à jour souvent.

Inclure-Ajaxload

Le plugin Inclure-Ajaxload a été développé par Fil. Je l'ai repris récemment pour rendre son utilisation plus générique, et introduire quelques automatismes supplémentaires.

Son utilisation implique de modifier ses squelettes. Mais cela est particulièrement simple.

Cédric a décrit une utilisation du chargement Ajax en parallèle du contenu des pages dans un article du Spip Blog, technique décrite à l'origine par Facebook, que Cédric résume ainsi :

En résumé, pour ceux qui n'ont pas activé leur TOR ou ne comprennent pas l'anglais, l'auteur propose de rendre disponible les pages web dans le navigateur plus rapidement en les découpant en morceaux :
— un morceau ossature principal envoyé au plus vite au visiteur ;
— plusieurs morceaux de contenu (appelés pagelet), calculés et envoyés séparément.

La page complète est reconstituée dans le navigateur par une fonction javascript.

Ainsi, le rendu et l'interprétation des CSS et JS peuvent démarrer plus tôt dans le navigateur, et la page complète peut être construite par plusieurs processus séparés, en parallèle, sur le serveur.

Cédric a inclut cet automatisme (sous le nom d'APL) directement dans ses squelettes Zpip. Malheureusement, le code est difficilement utilisable en dehors de Zpip, car il repose largement sur la structure même des squelettes.

L'évolution de Inclure-Ajaxload est donc destinée à pouvoir adopter ces méthodes dans ses propres squelettes, sans devoir en passer par Zpip.

Le principe est le suivant.

— Dans mes squelettes, j'installe des morceaux de mes pages dans des squelettes séparés. Par exemple, le pied de page est installé dans un squelette inc/footer.html, et appelé ainsi depuis chacun de mes squelettes :

{fond=inc/footer}{id_rubrique} />

Cette forme d'inclusion est « dynamique », c'est-à-dire que le morceau de cache correspondant à ce footer (commun à de nombreuses pages) est indépendant du cache principal.

Je pourrais également l'appeler ainsi :

[(#INCLURE{fond=inc/footer}{id_rubrique})]

Dans cette inclusion (dite « statique »), le footer n'a pas de cache indépendant, et est stocké dans le cache global de la page qui l'appelle.

Pour utiliser Inclure-Ajaxload, je vais ajouter le critère {ajaxload} dans l'appel de l'inclusion statique :

[(#INCLURE{fond=inc/footer}{id_rubrique}{ajaxload})]

Le code généré est alors totalement différent. Le contenu de cette inclusion n'est plus du tout présent dans la page envoyée au visiteur. Seul un code très court (quelques caractères) est inséré.

Ensuite, dans l'entête de la page (il faut donc bien utiliser #INSERT_HEAD), un petit morceau de Javascript est inséré par le plugin. Dès le chargement de la page par le visiteur, ce Javascript va détecter le petit code très court, et demander au serveur de lui envoyer le contenu réel de l'inclusion, pour l'insérer correctement dans la page.

Ainsi, la page est envoyée en deux temps au visiteur :
— la page « allégée » de ses inclusions est envoyée ; comme elle est plus courte et plus simple que la page complète, elle s'affiche beaucoup plus rapidement ;
— dès l'affichage de la page allégée, les différents morceaux manquants sont appelés par Javascript et réinsérés (très rapidement) dans la page affichée.

Pour le visiteur, il y a une meilleure impression de réactivité : quand il arrive sur une page, quelque chose s'affiche beaucoup plus rapidement. Et l'information se complète rapidement après cet affichage initial.

Pour ma part, je n'utilise pas la technique complète (j'ai d'autres impératifs qui limitent mes possibilités de ce côté), mais je charge, en gros, ce qui apparaît à l'écran « sans scroller » ; tout ce qui est en bas de page (et qui est assez lourd) est chargé dans un second temps.

Les quelques dizièmes de seconde gagnés à l'affichage initial donnent réellement une meilleure impression de réactivité.

J'ai documenté le plugin sur Plugins.SPIP. Cette documentation indique encore quelques recommandations (difficultés avec les paginations, pas de publicités dynamiques, mutualiser le cache entre plusieurs pages, etc.).

Créer Sprites CSS

Pour ma dernière intervention sur le site, j'ai développé un plugin qui regroupe automatiquement plusieurs « petites » images en une seule grande image, selon le principe des « Sprites CSS ».

Le plugin est désormais disponible au téléchargement, et je vous invite à lire sa documentation sur Plugins.SPIP. J'ai essayé de faire une doc assez complète.

Pour résumer à l'extrême : j'ai à plusieurs endroits des pages des éléments graphiques générés par SPIP (images typographiques, vignettes de navigation des documents), qui insèrent beaucoup de petites images dans la page. Pour le visiteur, cela revient à charger en moyenne 30 petites images différentes à chaque page (c'est-à-dire autant d'interrogations du serveur). Grâce à ce plugin, avec des modifications de code minimes et simples, ces 30 petites images sont regroupées en deux « grandes » images, et le visiteur ne lance donc plus que deux interrogations du serveur.

La vitesse de chargement et d'affichage des pages est améloriée de manière spectaculaire (à noter que PageSpeed apprécie beaucoup la manip...).

Voilà, ce sont les trois techniques que j'ai utilisées dernièrement pour tenter d'améliorer la réactivité de Flip-Zone. Les deux derniers plugins sont assez expérimentaux, mais ils fonctionnent bien (sur un site en production, donc). Il est à noter que les gains sont spectaculaires, sans demander autre chose que l'installation de plugins dans SPIP et la modification (assez simple) des squelettes. Il n'y a ici ni besoin de modifier la configuration générale du serveur, ni de toucher au .htaccess.

Objectif PageSpeed 100/100 avec SPIP

ARNO* — 2010-05-24T13:07:56Z

J'ai récemment refondu l'interface graphique de notre site de mode, Flip-Zone. Outre la modernisation de la maquette et la simplification de l'ergonomie, un des buts était d'améliorer la réactivité du site : vitesse de chargement, vitesse d'affichage et vitesse des effets interactifs.

Un bon nombre de ces optimisations consiste en une amélioration « normale » du code HTML/Javascript du site (réduire le nombre d'images, de fichiers, de fichiers dynamiques...). En revanche, d'autres éléments sont plus difficiles à détecter, et j'ai donc utilisé l'extension PageSpeed fournie par Google pour Firefox.

Cette extension analyse la structure des fichiers fournis par votre site, et les interactions avec votre serveur, et vous donne une « note » globale, assortie de détails sur les différents points que vous pouvez améliorer. C'est un outil absolument épatant pour optimiser le site Web (une fois qu'on a déjà, autant que possible, optimisé son HTML « normal »).

Après optimisation, la nouvelle version de Flip-Zone atteint (avec la version 1.8 de PageSpeed), le score très honorable de 92, voire 94, sur 100, et obtient le petit « check vert » validant l'optimisation des pages. À titre de comparaison, le présent billet sur Paris-Beyrouth atteint 81/100 et un symbole rouge d'alerte ; rezo.net atteint 83/100 (alerte rouge) ; la page d'accueil de Libération plafonne à 79/100 ; celle du Monde (pourtant très récente) obtient un terrible 68/100.

Et la page d'accueil de l'extension PageSpeed sur le site de Google obtient... 83/100. Avec 92 ou 94/100, Flip-Zone bénéficie donc d'une optimisation très largement au-dessus de la moyenne.

Attaquons différents points, fournis par PageSpeed, sur lesquels je suis intervenu. Notez bien : je vous présente mon expérience personnelle, afin de vous donner des pistes. D'autres méthodes sont certainement possibles, voire préférables. N'hésitez pas à livrer votre propre expérience et vos conseils dans le forum ci-dessous.

Parallelize downloads across hostnames

J'ai déjà traité la question de la parallélisation des chargements dans un précédent billet.

Avec un filtre relativement simple, je répartis les différents appels aux images sur quatre sous-domaines qui, en réalité, pointent vers le même dossier du serveur, ce qui permet aux navigateurs de lancer plus de 2 chargements d'images en même temps.

La simplicité du code et l'économie de moyens nécessaires pour réaliser cela constituent un des points forts de SPIP.

Serve resources from a consistent URL

Le code précédent, fourni pour la parallélisation, est conçu pour que chaque fichier d'image soit toujours situé sur le même sous-nom de domaine. Si vous voyez apparaître cette alerte de PageSpeed, il est probable que vous n'ayez pas activé le passage par le filtre de parallélisation correctement (pas activé sur certains squelettes, pas activé dans certains include...).

Serve static content from a cookieless domain

PageSpeed suggère alors de « servir » les images (en fait, tous les contenus « statiques ») depuis un domaine « sans cookies ». Je dois avouer que j'ai eu beaucoup de mal à comprendre où était le problème : les fichiers statiques que sont les images étant tous passés sur des sous-noms de domaine de mon domaine principal, je les retrouvais pourtant tous signalés par PageSpeed comme utilisant un cookie.

L'explication de Google est franchement cryptique, alors que la solution est très simple. Le problème ne vient pas d'un réglage au niveau du serveur (et des sous-noms de domaine), contrairement à ce que suggère le terme « cookieless domain ».

C'est Google Analytics, sur mon site, qui posait des cookies « trop larges ». J'utilise l'ancien code (ga.js), qui pose un cookie qui vise à la fois le domaine principal et ses sous-noms de domaine. De ce fait, le script d'Analytics visait « flip-zone.com », mais aussi « img1.flip-zone.com » (et les autres), alors que ces sous-noms ne servent que des contenus statiques.

Il semble que le nouveau code d'Analytics n'ait plus ce défaut, mais si vous utilisez ga.js, la solution consiste à ajouter, dans l'appel à Analytics, le code suivant (en indiquant évidemment votre propre domaine principal :

pageTracker._setDomainName('www.flip-zone.com');

Passer dans les préférences de Firefox, virer les cookies qui correspondaient à ce domaine, et recharger. Le problème est alors « résolu » pour PageSpeed.

Leverage browser caching

Ce point concerne l'indication d'une durée de cache local du côté du client. SPIP insère cette indication lui-même dans les pages qu'il génère via les squelettes, mais il reste tous les autres types de fichiers : images, fichiers CSS et fichiers Javascript. Et ce sont bien pour ces types de fichiers que PageSpeed dénonce l'absence d'indication de cache (le fait que SPIP indique tous les headers nécessaires pour les pages HTML est déjà très appréciable).

J'ai donc modifié ma configuration d'Apache pour qu'il effectue ces opérations lui-même automatiquement. J'ai activé les modules headers et expire, en forçant l'activation de l'envoi d'une durée d'expiration longue sur les différents types de fichiers suivants :

Note. La plupart des caches sont ici fixés à une semaine. C'est le minimum recommandé par PageSpeed pour ces types de fichiers. Comme les fichiers Javascript, CSS et images passent par un traitement SPIP, ça ne devrait pas poser de difficulté en cas de modification du site, les noms des fichiers résultants changeant avec la date de création de chaque fichier.

Même si ça n'est pas l'idéal, il est parfois possible d'insérer cette configuration dans .htaccess, pour les hébergements mutualisés qui ont activé les modules d'Apache mais sans la configuration nécessaire. Je viens par exemple de le faire sur le serveur (mutualisé) qui héberge le présent site.

Après redémarrage du serveur, le problème de cache est résolu pour PageSpeed.

Combine external JavaScript, Combine external CSS

PageSpeed suggère de ne pas appeler plusieurs fichiers Javascript, mais de les regrouper en un seul fichier. Même chose pour les fichiers CSS.

Sur ce point, SPIP offre une fonction absolument épatante : il combine lui-même automatiquement les fichiers Javascript et les fichiers CSS. Il suffit d'activer ces fonctions dans l'espace privé de SPIP : Configuration > Fonctions avancées > Compactage des scripts et CSS.

Voilà un problème de PageSpeed résolu d'un clic dans SPIP !

Enable compression, Specify a Vary : Accept-Encoding header

Tous les navigateurs récents permettent d'échanger des fichiers compactés avec le serveur plutôt que les fichiers texte d'origine. C'est un aspect très important pour accélérer les transferts (surtout que les fichiers texte, tels que HTML, Javascript et CSS, gagnent énormément à être compactés).

Deux méthodes sont possibles.

Les automatismes de SPIP

SPIP livre en standard tous les outils pour réaliser la compression, avec par ailleurs une mise en cache des fichiers compressés.

Rendez-vous dans la page > Configuration > Fonctions avancées et en bas de page trouvez le pavé « Optimisations et compression ». Activez la compression pour les 3 éléments.

La compression des pages HTML est alors automatiquement gérée par SPIP. (Une bonne chose de faite.)

Le seul point difficile est, maintenant, de parvenir à servir les versions compressées des fichiers CSS et Javascript. Il faut intervenir sur la configuration d'Apache, mais ici cela peut se faire directement dans le fichier .htaccess.

Les fonctions de regroupement des fichiers CSS et Javascript, ainsi que la compression des pages Web par SPIP, stockent en cache deux versions des fichiers : le fichier non compressé, et le même fichier compressé, dont le nom est complété par la terminaison .gz. Ainsi, dans /local/cache-css, vous trouvez des couples de fichiers :

Même chose dans /local/cache-js.

Il faut donc indiquer à Apache de servir, lorsque le navigateur le permet, l'un ou l'autre de ces fichiers. J'insère le code suivant dans .htacces :

(Le début de ce code, qui définit des AddType, est assez douteux. Mais il semble fonctionner, et lorsque je le supprime, je rencontre des dysfonctionnements. Code bizarre, donc, mais qui semble bien fonctionner.)

Le problème est résolu pour PageSpeed, avec une solution « pur SPIP ». Cette solution a l'avantage de ne pas demander des droits énormes sur le serveur : si vous avez le droit d'utiliser le fichier .htaccess de votre serveur Web, vous pouvez certainement l'utiliser.

La solution mod deflate

L'autre méthode consiste à demander au serveur Apache de prendre en charge la compression de tous les fichiers à la volée. Il faut activer, sur le serveur, le module deflate, avec la configuration :

(la configuration par défaut ne prend pas en compte les CSS).

Redémarrer Apache, et le problème est résolu pour PageSpeed.

Minify CSS

PageSpeed suggère de réduire la taille des fichiers CSS. On écrit en effet la plupart du temps les fichiers CSS avec de nombreux retours à la ligne et des indentations, de façon à avoir un code très lisible (et donc facile à modifier). Mais ces indentations et ces retours-chariot ont un poids, et PageSpeed suggère de les supprimer.

Si vous activez le regroupement de fichiers CSS dans SPIP, cette fonction fabrique un fichier CSS avec la notation allégée.

Ma difficulté est que, sur Flip-Zone, je n'utilise qu'un seul et unique fichier CSS. Du coup, la fonction de compactage de SPIP ne passe pas dessus (la fonction s'active lorsqu'il y a plusieurs appels de fichiers CSS visant le même support).

Pour les fichiers CSS « faits à la main », il faut transformer la notation développée du type :

body {
background-color: white;
color: black;
}

Télécharger

par la notation très compacte :

body {background-color: white; color: black;}

Pour ma part, j'utilise systématiquement le plugin CSS imbriqués pour coder mes CSS, et ce plugin générait un code doté de retours-chariot et d'indentations. J'ai donc récemment modifié ce plugin pour qu'il génère désormais un code « minifié ». Si vous utilisez une version du plugin qui ne le fait pas encore, mettez le à jour.

À noter : les différents fichiers Javascript et CSS étant regroupés, sur chaque page du site, dans des « gros » fichiers, il convient de prendre soin à systématiquement appeler les mêmes fichiers dans chaque type de squelette. Pas de CSS appelés uniquement dans les rubriques et d'autres CSS uniquement dans les articles ; pas de fichiers Javascript uniquement pour les rubriques et d'autres pour les articles. En ayant bien les mêmes appels de CSS et de fichiers Javascript pour les différents types de squelettes, quand on navigue dans le site, on est certain de toujours recharger le même fichier CSS unique et le même fichier Javascript unique. (Cela n'est valable, évidemment, que parce qu'on regroupe automatiquement les différents fichiers externes.)

Remove unused CSS

Le fait d'avoir un gros CSS regroupant les CSS pour tous les squelettes du site peut provoquer l'alerte « Remove unused CSS » dans PageSpeed. Je l'ai vu passer, mais en naviguant un peu dans le site, il semble que PageSpeed ait compris que ces règles CSS étaient tout de même utilisées dans le site, et l'alerte a disparu.

Minify HTML

De la même façon, PageSpeed suggère de « minifier » le code HTML.

Il est notoire que SPIP a tendance à générer un code HTML avec de nombreuses lignes vides, à cause de la succession de boucles. On peut évidemment écrire ses boucles pour limiter cet aspect, mais je trouve que le code source devient alors peu lisible ; je préfère donc conserver mon code source qui génère beaucoup de lignes vides, et intervenir ailleurs.

La première solution consiste à activer le validateur XHTML intégré à SPIP (SAX, qui succède à une première implémentation basée sur tidy). Si vous ne connaissez pas cet outil, vous devriez vous y intéresser : c'est un outil vraiment épatant lors du développement de votre site.

Il s'active en indiquant, simplement,

$xhtml = true;

ou :

$xhtml = "sax";

Vous obtenez alors un bouton « XML » supplémentaire en haut de vos pages publiques, qui vous permet de « débugger » votre code HTML.

Lorsque votre page est considérée comme suffisamment valide, cette fonctionnalité transforme votre code HTML et le livre sous forme « nettoyée » et structurée : retours chariot bien placés et indentation parfaite.

PageSpeed apprécie assez largement ce nouveau code source reformaté selon la norme XML.

Mais cela ne suffit pas à PageSpeed, qui réclame encore la disparition des retours chariot surnuméraires et, surtout, des indentations.

Plutôt que de « patcher » SAX, je préfère recourir à une seconde méthode. Une fois mon HTML débuggué, je désactive SAX, et je fabrique (dans mes_fonctions.php un petit filtre en PHP :

function mini_html($texte) {
$texte = preg_replace(",\n[\t\ ]*,", "\n", $texte);
$texte = preg_replace(",\n+,", "\n", $texte);
return $texte;
}

Télécharger

Cette fonction supprime les multiples lignes vides et toutes les indentations en début de ligne. Pour la déclencher, j'insère dans mes squelettes la mention :

#FILTRE{mini_html}

Ce raccourci #FILTRE est déjà expliqué dans mon billet sur la mise en parallèle des téléchargements de fichiers externes. Puisque j'ai déjà mis en place un filtre pour la parallélisation, mes squelettes contiennent donc désormais les mentions :

#FILTRE{filtrer_images_page}
#FILTRE{mini_html}

Télécharger

Notez bien : il faut désactiver SAX (ne pas activer la variable $xhtml), qui passe après ces filtres, et réintroduirait alors les indentations.

Encore des points gagnés sous PageSpeed avec une économie de moyens remarquable.

Les images

Sur Flip-Zone, quasiment toutes mes images passent par les filtres graphiques de SPIP. De ce fait, tous les commentaires concernant les images dans PageSpeed sont « automatiquement » respectés : indiquer la taille des images, pas de redimensionnement d'images directement dans le HTML, compression correcte des fichiers...

Sur tous ces points, je n'ai pas du tout eu besoin d'intervenir pour satisfaire PageSpeed (en revanche, j'ai effectué une optimisation de mon côté pour, plus « normalement », limiter le nombre d'images différentes et leur taille autant que nécessaire).

Specify a character set early

Si vous suivez la même logique que les squelettes standards de SPIP, vous avez bien pensé à indiquer :

en début de vos entêtes. Ce qui fait plaisir à PageSpeed.

Pourquoi je n'obtiens pas 100/100

Sur Flip-Zone, j'obtiens donc 92 ou 94/100. Il me reste deux alertes, que je ne souhaite pas corriger pour l'instant.

Use efficient CSS

J'ai là des déclarations de CSS considérées comme « très inefficaces » par PageSpeed. Problème qui est accentué par le fait que j'utilise le plugin « CSS imbriqués », qui fabrique automatiquent des déclarations CSS à rallonge.

Je pourrais donc réécrire mes feuilles de style, mais je préfère conserver mes sources CSS structurées et très lisibles, qui me permettent de facilement intervenir sur le code du site.

Combine external JavaScript

J'ai déjà regroupé, sur mon site, les fichiers Javascript externes que je gère moi-même (les nombreuses extensions jQuery). Mais je suis ici bloqué par la présence des publicités, principalement les pubs AdSense, qui provoquent chacune l'appel de quatre fichiers Javascript différents.

Je ne vois pas de moyen de réellement optimiser cet aspect. C'est un point qui m'échappe totalement sur mon site, puisque je dépends là des fichiers fournis par Google.

En restant raisonnable dans les modifications du code, j'obtiens par exemple 97/100 sur Web Design News ; avant l'intervention, je plafonnais à 80/100. À noter que la désactivation pure et simple des Google Ads n'en améliore pas le score.

Qu'est-ce que ça apporte ?

Au niveau de l'expérience de l'utilisateur, c'est clair : le site est beaucoup plus rapide et donne une bien meilleure impression de fluidité que dans sa version précédente. La visite est, à mon avis, beaucoup plus agréable.

Est-ce que cela va augmenter mon nombre de pages vues (les visiteurs restant plus longtemps sur un site qui va « plus vite ») ? Est-ce que cela va augmenter le nombre de visites (les visiteurs recommandant plus facilement un site plus agréable à consulter) ? Il est trop tôt pour le dire, et il sera difficile de savoir si une augmentation ne serait pas plus liée au changement de graphisme et d'ergonomie. Pour l'instant, honnêtement, je n'ai pas le sentiment que les chiffres soient très différents. Si Google communique beaucoup sur la vitesse absolue des sites Web, je ne suis pas certain que les utilisateurs, eux, soient très sensibles à la différence de vitesse entre un site « qui va plutôt vite » et un site « qui va très vite » (surtout sur Flip-Zone, site qui ne demande pas de beaucoup naviguer entre les pages, mais bien plus de rester longtemps sur une même page présentant une collection de mode complète).

Est-ce que cela va améliorer mon référencement dans Google ? Google a récemment annoncé qu'ils allaient prendre en compte la vitesse dans le score des sites. Mais de manière très limitée, et rien n'indique que, pour Google, il y ait une grosse différence entre un score 84 dans PageSpeed et un score 94 (car implémenter PageSpeed au niveau du robot de Google me semble carrément overkill).

Est-ce que cela va réduire la charge sur mon serveur ? Côté trafic, certainement : les fichiers envoyés vers le visiteur sont moins nombreux, plus petits et offrent une meilleure gestion du cache. Comme je lance beaucoup moins de services HTTP en même temps, j'ai aussi certainement une réduction de la puissance machine utilisée. Mais cet aspect est beaucoup plus lié à l'amélioration de mes squelettes lors de la refonte.

Pour l'instant, ma conclusion est plutôt une question de respect de l'utilisateur : il s'agit de lui proposer une navigation plus fluide et plus agréable. Qu'il y soit sensible au point que cela change son comportement sur le site est très douteux. Quant à la charge du serveur, c'est largement la refonte des squelettes qui joue, bien plus que l'optimisation spécifique pour satisfaire PageSpeed.

Pas de BOM pour PHP (utf-8)

ARNO* — 2010-04-26T10:03:23Z

Le problème m'arrive régulièrement lorsque je développe mes propres fonctions dans SPIP, soit dans mes_fonctions.php et mes_options.php, soit dans un plugin :
— certains liens de l'espace privé me mènent à une page qui m'indique un « Type 302 » (login, effacer un message, changer le statut d'un article...) et me demande de cliquer pour poursuivre l'opération (et revenir à l'interface privée « normale »),
— j'obtiens un message d'erreur PHP de genre « Headers already sent »,
— je vois apparaître dans mes pages publiques des caractères bizarres, généralement la série « ï»¿ ».

Ces trois problèmes viennent généralement de la même source : un fichier PHP ou un squelette encodé en unicode (utf-8) démarrant par l'insertion d'une indication de « BOM » : « Marque d'ordre des octets ».

Ce marqueur est un caractère inséré en début de fichier unicode, automatiquement : il est utile en utf-16 et utf-32, mais pas indispensable en utf-8 (qui est le format d'encodage des caractères que l'on utilise désormais de plus en plus sur le Web - et que j'utilise désormais sytématiquement pour ne plus avoir à coder les caractères sous formes d'entités HTML du genre é).

C'est ce caractère qui est inséré en tout début de fichier provoque les erreurs :
— dans un squelette, il peut devenir un caractère « visible », et sur un site qui n'est pas lui-même en utf-8, on voit apparaître la série ï»¿ (qui est sa translittération en iso-8859-1),
— dans un fichier PHP, cela provoque l'envoi de caractères avant le démarrage du PHP, avec notamment l'interdiction d'envoyer des entêtes PHP par la suite ; dans notre cas : les entêtes qui provoquent une redirection vers une autre page.

La solution est simple :
— ouvrir le ou les fichiers fautifs avec l'éditeur et forcer la sauvegarde dans le format « UTF-8 NO BOM » ; c'est la meilleure solution ; le fichier est ainsi sauvegardé correctement en Unicode utf-8, mais sans ce caractère ; en général, il suffit de traiter mes_fonctions.php et mes_options.php pour corriger tous les dysfonctionnements ;
— si vous ne pouvez pas sauvegarde en UTF-8 NO BOM, sauvegarder le fichier en ISO-8859-1, mais en prenant soin de transformer d'abord les caractères accentués en entités HTML. Ça n'est pas la solution idéale, surtout si comme moi on fait des fonctions PHP testant des chaînes multi-bytes. Mais pour beaucoup de sites, c'est souvent très suffisant. (Mais idéalement, adoptez un éditeur de texte qui vous permet de sélectionner la sauvegarde au format UTF-8 NO BOM.)

Parallélisation des chargements avec SPIP

ARNO* — 2010-04-17T12:25:50Z

Ces derniers temps, je constatais de lourds ralentissements sur mon site Flip-Zone. La charge processeur était loin d'atteindre le maximum, et la bande passante n'était pas saturée non plus. Solution : la configuration par défaut d'Apache de la Debian est excessivement sous-dimensionnée ; en augmentant le MaxServers et le ServerLimit à nettement plus que 256, le serveur s'est remis à donner des résultats satisfaisants.

Toujours est-il que, cherchant à améliorer la réactivité du site, je me suis tourné vers l'outil PageSpeed pour Firefox. Quelque soit votre niveau, en tant que webmestre, je vous suggère de l'installer et de tester vos sites. L'outil fournit non seulement les tests, mais aussi de très intéressants conseils d'optimisation de votre site. Il y a de plus des tutoriaux pour tous niveaux sur le site du plugin.

Un point en particulier m'a intéressé : la mise en parallèle des téléchargements des éléments appelés par la page : images, feuilles de style, javascript. Le principe est que le protocole HTTP n'autorise qu'un nombre très réduit de téléchargements simultanés de fichier sur un même domaine (sans doute deux chargements). Quand la page contient beaucoup d'appels à des fichiers externes, tels que des images, le navigateur va charger ces fichiers les uns après les autres (deux par deux). On voit ainsi se charger les images les unes après les autres, de manière séquentielle. Or, avec une connexion rapide, on n'exploite pas la totalité de la bande passante disponible. Il y aurait donc moyen de charger ces images plus rapidement, en lançant plus de chargements en même temps (en parallèle).

La méthode pour réaliser cela est de fournir les images sur plusieurs adresses (noms de domaines) différents. En effet, si le navigateur ne peut charger que deux fichiers en même temps pour un nom de domaine, il peut lancer en même temps les chargements sur plusieurs domaines. C'est expliqué, par exemple, sur cette page du Yahoo User Interface Blog.

Je vous livre comment j'ai procédé pour mon site sous SPIP. Il faut, évidemment, disposer d'une machine dédiée sur laquelle on peut soit-même gérer des sous-noms de domaine, ainsi que la gestion des zones de son nom de domaine au niveau du registrat.

Le principe consiste à créer autant de sous-noms de domaine que nécessaire (pour mes essais actuels : quatre sous-noms de domaine), et à les faire pointer vers le même dossier du serveur (le dossier qui contient déjà le site sous SPIP). De cette façon, l'image qui se trouve habituellement à l'adresse :

est également accessible via les adresses :

Il s'agit, physiquement sur le serveur, du même fichier (fabriqué par les filtres graphiques de SPIP). En revanche, pour le visiteur, ce sont bien des domaines différents, ce qui permet de dépasser la limite de téléchargements simultanés. Le navigateur ne peut lancer simultanément que le chargement de deux images sur www.flip-zone.com, mais il peut lancer en même temps deux chargements sur chacun des sous-domaines. Je peux donc démarrer le chargement, ici, de huit images en même temps sur mes sous-noms de domaine.

Au niveau de la gestion du nom de domaine, il faut évidemment que je fasse pointer tous les sous-noms de domaine vers le même serveur. Plutôt que de me contenter d'une zone du style :

je fais pointer « tout » vers le serveur, grâce à l'astérisque :

Avec cette configuration, tous les sous-noms de domaine de flip-zone.com pointent vers le même serveur. C'est pratique, dans l'absolu, pour se créer des domaines à la demande (dev.flip-zone.com, test.flip-zone.com...), et pour le cas qui m'intéresse, faire directement pointer img0.flip-zone.com à img3.flip-zone.com vers le serveur.

Au niveau du serveur, il faut évidemment indiquer à Apache vers quel dossier du serveur faire pointer ces nouveaux sous-noms de domaine. C'est simple : vers le même dossier déjà utilisé pour www.flip-zone.com.

J'avais déjà une définition complète (avec la gestion des droits) pour www.flip-zone, pointant notamment vers :

www.flip-zone.com:80>
DocumentRoot /var/www/flip/zone/
...
>

Télécharger

Je modifie ce VirtualHost en indiquant qu'il sert d'alias à certains sous-domaines (merci à Fred pour le truc) :

www.flip-zone.com:80>
DocumentRoot /var/www/flip/zone/
ServerAlias img*.flip-zone.com
...
>

Télécharger

Je redémarre Apache, et voilà. Pour tester, je me rends sur mon site, j'affiche une image (qui est pour l'instant en http://www.flip-zone.com/..., et je remplace son URL par http://img0.flip-zone.com/.... Si l'image se charge à nouveau, c'est que la configuration est correcte.

Il faut maintenant que j'intervienne dans SPIP pour que mes pages lient les images non plus en relatif (donc vers www.flip-zone.com), mais avec des URL absolues réparties sur les quatre sous-noms de domaine.

Je vous livre ma méthode, très simple et qui ne demande pas beaucoup de modifications des squelettes.

D'abord, je vais faire passer le résultat des pages, en fin de compilation, par un filtre. J'insère dans chaque squelette concerné (sommaire.html, rubrique.html, article.html...) le code suivant :

Cette fonctionnalité de SPIP indique que l'intégralité du squelette, une fois compilé, doit passer par le filtre |filtrer_images_page. Elle s'applique avant la sauvegarde en cache, le résultat est donc bien géré par le cache de SPIP.

Il me faut définir cette fonction PHP. Je l'installe par exemple dans /config/mes_options.php, de façon à pouvoir en profiter dans tous mes jeux de squelettes (puisque j'ai des squelettes spécifiques pour iPad et iPod sur ce site).

La fonction est un peu rustique et on pourra sans doute aisément rendre son écriture plus élégante. Mais elle fonctionne, et j'ai besoin pour mes tests qu'elle soit simple à lire et à modifier (merci cependant à Marcimat pour le morceau de code qui rend ça beaucoup plus propre).

function filtrer_rediriger_images($reg) {
$lien = $reg[1];
if ( ! preg_match(",^http,", $lien)) {
$code = substr(md5($lien), 0, 1);
$code = hexdec($code) % 4;
$lien = "http://img$code.flip-zone.com/$lien";
}
return " src=\"$lien\"" ;
}
function filtrer_images_page($flux) {
$flux = preg_replace_callback(",[[:space:]]src=[\"\']([^\"\']*)[\"\'],", "filtrer_rediriger_images", $flux );
return $flux;
}

Télécharger

La fonction extrait toutes les chaînes du style :

C'est peu précis, mais ça ne semble pas provoquer de dégâts par ailleurs. Cela me permet de récupérer, en une passe, les liens vers des images et vers des fichiers Javascript. On peut facilement la rendre plus précise, ou lui faire également traiter les appels aux feuilles de style.

Pour ma part, j'ai tout de même un dommage collatéral sur l'appel des Javascript externes. J'ai donc modifié le script ainsi (ligne 4) pour les exclure :

if ( ! preg_match(",^http,", $lien) && !preg_match(",\.js$,", $lien)) {

Pour chaque lien ainsi récupéré, j'exclus les liens qui sont déjà en URL absolue. J'effectue un hachage md5 du lien, ce qui me donne une chaîne en hexadécimal, et je récupère le premier caractère (de 0 à 9 et de a à f). À partir de ce caractère, de manière systématique, je fabrique une valeur entre 0 et 3. Et je retourne le lien en URL absolue vers un des sous-noms de domaine en img0.flip-zone.com à img3.flip-zone.com.

La fonction ne cherche pas à répartir équitablement les liens sur les quatre sous-noms de domaine, mais applique un filtre systématique en fonction de l'URL du fichier (de toute façon, j'ai tellement d'images dans chaque page que la répartition est statistiquement équitable). C'est ce qui garantit que, d'une page à l'autre du site, une image sera toujours sur le même sous-nom de domaine. Sinon, je provoquerais des rechargements d'une image déjà chargée, parce que son URL serait sur un sous-nom de domaine différent.

Et voilà. Au recalcul de la page, les appels vers les images et les fichiers Javascript sont répartis sur les quatre sous-noms de domaine, et j'ai donc le chargement simultané d'au moins 8 fichiers par le navigateur.

À noter.

— La fonction #FILTRE ne concerne que le contenu de la page compilée. S'il y a des inclusions, il faut considérer que :

les inclusions statiques en [(#INCLURE...)] sont traitées (puisque le contenu est inséré dans la page avant le passage à #FILTRE ;
les inclusions dynamiques en ne sont pas traitées. Si l'on veut traiter ces éléments, il faut ajouter #FILTRE à l'intérieur même de ces morceaux de squelettes. Mais c'est aussi une façon d'exclure certaines parties du site.

— Les appels à Google Analytics tels que fournis par Google sont corrompus par le script. Les appels au serveur de publicité OpenX également. Il suffit de placer ces éléments dans des squelettes séparés sur lesquels on ne fait pas passer le filtre (donc appelés par ).

— Il est déconseillé de trop multiplier les sous-noms de domaine (mon script peut facilement gérer 16 sous-noms de domaine) : il faut en effet que le navigateur interroge le DNS pour chacun des sous-noms de domaine, et on perdrait trop temps avec trop de domaines différents.

— Au niveau du serveur Apache, penser à activer le fonctionnement KeepAlive, et à avoir un MaxServers suffisant (puisqu'on lance plus de connexions simultanément à chaque page).

— Comme préconisé par PageSpeed, j'ai également activé les modules expires et headers, pour que le serveur envoie automatiquement les indications de mise en cache pour les images, les fichiers CSS et les fichiers javascript. Une fois installés, j'ai ajouté la configuration suivante :

— Enfin, je répète ce que j'ai déjà indiqué dans d'autres billets : la gestion/configuration d'un serveur n'est vraiment pas mon domaine. Je bidouille. Je suis donc très preneur de conseils et commentaires de la part d'informaticiens calés sur le sujet pour améliorer cette technique.

Scroll auto sur iPhone, iPod et iPad

ARNO* — 2010-04-06T15:00:17Z

Avertissement : cette astuce n'est pas réservée à SPIP. Elle concerne n'importe quelle page HTML destinée à l'affichage sur iPhone ou iPad. (Mais personnellement, je développe jamais que du HTML avec SPIP...)

Sur Safari versions iPhone, iPad et iPad, il est très difficile d'utiliser le scroll automatique pour des éléments de hauteur fixée dotée du style :

overflow: auto;

Le comportement existe, mais est généralement inconnu des usagers : le scroll s'obtient en caressant l'engin avec deux doigts. Le scroll avec un doigt est réservé au scroll général de la page.

Si votre page est conçue comme une « application Web », ce comportement est très pénible. Je n'ai pas trouvé de solution satisfaisante pour rétablir le comportement « habituel » sur ces machines, aussi j'ai développé un petit javascript (utilisant jQuery).

Je vous le livre donc ci-dessous, tel quel.

Outre le retour du scroll à un doigt sur les éléments à overflow, le script simule l'apparition et la disparition d'une scrollbar à la façon de Safari.

Pour l'utiliser, il faut ajouter la classe scroll_auto aux éléments concernés (les éléments qui sont conçus pour la classe overflow). Par exemple :

<div id="cadredemo" class="scroll_auto">
Ceci est mon texte.
[...]
Ce contenu est suffisamment long pour déclencher le système de scroll.
</div>

Télécharger

Pour être cohérent, il faut évidemment que le cadre doté du scroll_auto soit de hauteur fixe et doté d'un overflow, par exemple :

#cadredemo {
height: 400px;
overflow: auto;
}

Télécharger

Il suffit ensuite d'appeler le fichier Javascript dans votre header, il déclenchera tout seul tout le comportement nécessaire.

Notez bien : si vous testez votre page Safari sous Mac (ou sous Windows) en modifiant son indication d'agent utilisateur, le comportement ne fonctionnera pas : les événements touchstart, touchmove et touchend ne sont intégrés qu'aux versions iPhone, iPod et iPad.

var debut_scroll_Y = false;
var debut_marginTop = 0;
var hauteur_scrollbar_auto = 100;
function fix_scroll_auto() {
if(
(navigator.userAgent.match(/iPhone|iPod|iPad/i))
) {
$(".scroll_auto").each(function() {
var contenu = $(this).html();
var start_time = 0;
var last_decal = 0;
var rapport = 1;
var hauteur_max = 100;
var hauteur_boite = 100;
if ($(this).children(".wrapper").width() > 0) {
} else {
$(this)
.html( "
"
+ "
"
+ contenu + "
"

+ "

)

.css("position", "relative")

.css("overflow", "hidden");

}

this.ontouchstart = function(evt) {

debut_scroll_Y = evt.touches[0].pageY;

var now = new Date().getTime();

start_time = parseInt(now, 10);

last_decal = 0;

debut_marginTop = parseInt($(this).children(".wrapper").css("marginTop"));

rapport = $(this).outerHeight() / $(this).children(".wrapper").outerHeight();

if (rapport < 1) {

$(this).children(".scrollbar_auto").fadeIn();

hauteur_scrollbar_auto = Math.floor(rapport * $(this).outerHeight());

$(this).children(".scrollbar_auto").height(hauteur_scrollbar_auto);

}

hauteur_max = $(this).children(".wrapper").outerHeight() - $(this).outerHeight();

hauteur_max = -1 * hauteur_max;

hauteur_boite = $(this).outerHeight();

};

this.ontouchmove = function(event) {

if (rapport > 1) return false;

var y = event.touches[0].pageY;

var decal = y - debut_scroll_Y;

last_decal = decal;

decal = decal + debut_marginTop;

if (decal > 0) decal = 0;

if (decal < hauteur_max) decal = hauteur_max;

$(this).children(".wrapper").css("marginTop", decal);

// Hack bizarre: dans certains cas, il faut ecrire quelque chose quelquepart pour que le scroll fonctionne en direct

$(this).children(".bidon").html("bidon");

var rapport_pos = (decal / hauteur_max);

var vide = Math.round( rapport_pos * (hauteur_boite - hauteur_scrollbar_auto));

$(this).children(".scrollbar_auto").css("marginTop", vide);

return false;

};

this.ontouchend = function(event) {

var now_end = new Date().getTime();

var end_time = parseInt(now_end, 10);

var duree = end_time - start_time;

var decal = Math.round(last_decal * ( 1 + 200/duree));

decal = decal + debut_marginTop;

if (hauteur_max < 0) {

if (decal > 0) decal = 0;

if (decal < hauteur_max) decal = hauteur_max;

$(this).children(".wrapper").css("marginTop", decal);

// Hack bizarre: dans certains cas, il faut ecrire quelque chose quelquepart pour que le scroll fonctionne en direct

$(this).children(".bidon").html("bidon");

}

});

}

$(document).ready(function() {

fix_scroll_auto();

});

$(document).bind("touchend touchcancel", function(){

$(".scrollbar_auto").fadeOut();

});

Télécharger

Version 0.2.

Amélioration du rendu visuel de la scrollbar.
Effet de transition du scroll : à la fin du scroll, si on a effectué un mouvement vertical rapide (« swipe »), le scroll continue un peu plus loin.

Version 0.3 Les clicks (pas de scroll) à l'intérieur du scroll provoquaient un décalage après un premier scroll (à noter : dans un simple « click », il n'y a semble-t-il pas de ontouchmove du tout).

Version 0.4 Optimiser le code, augmenter la vitesse d'exécution.