Paris-Beyrouth

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.

Le convertisseur Office2SPIP

ARNO* — 2010-03-24T16:31:29Z

[Niveau : très avancé] Cela fait des années que je cherche un moyen de pouvoir envoyer directement un fichier Word, RTF, OpenOffice... dans l'interface de SPIP et récupérer automatiquement un article SPIP.

Voici la toute première version d'un plugin qui permet de réaliser cela. Le plugin est intitulé « Office2SPIP » et est installé sur la zone. Comme il s'agit d'une toute première version, il n'y a pas de version directement téléchargeable pour l'instant. Le plugin est fonctionnel, mais demande encore à être affiné.

La vidéo ci-dessus vous montre le plugin fonctionnant sur un de mes sites, avec un vieux fichier Word retrouvé de l'époque où je travaillais dans l'édition. Notez que je n'ai pas modifié le fichier Word, et que l'article SPIP résultant est déjà très convenable, avec ses images et ses tableaux. Quelques retouches dans l'édition de l'article sont nécessaires, mais elles sont peu importantes.

Attention : pour faire fonctionner ce plugin, il faut pouvoir installer des logiciels sur le serveur ; cela est donc réservé aux webmestres contrôlant complètement leur serveur, ou bien en demandant à votre hébergeur de réaliser l'opération.

Attention 2 : la création d'articles à partir de pages Web distantes fonctionne sans avoir à installer les logiciels sur le serveur. C'est donc une fonctionnalité que n'importe qui devrait pouvoir activer à volonté.

Le plugin ajoute une petite case dans les pages de rubriques de l'espace privé, permettant d'envoyer un fichier de traitement de texte vers le site.

Les fichiers acceptés par le plugin sont tous les formats acceptés par OpenOffice, notamment les fichiers Word (.doc et .docx) et OpenOffice (.odt).

Intérêt de l'opération

— Beaucoup de webmestres reçoivent encore (malheureusement) des fichiers Word qu'ils sont chargés de mettre en ligne. Le plugin permet de gagner énormément de temps avec de tels documents. Le fait que les images insérées dans les fichiers soient extraites et insérées dans l'article fait gagner encore plus de temps.

— De manière assez naturelle, beaucoup d'associations ont accumulé une belle base documentaire sous forme de fichiers Word (ou OpenOffice en étant optimiste). Ce plugin automatise la mise en ligne de tels documents.

— Certains rédacteurs ne veulent toujours pas (malheureusement, encore) mettre les mains dans le cambouis et recopier leurs articles eux-mêmes dans le formulaire d'édition des articles, et encore moins traiter leurs images. Le plugin leur retire l'excuse de la « technicité »...

— Je n'ai jamais utilisé de gros CMS commercial (genre Vignette), mais je suppose que la gestion de documents Word fait partie de leurs gros atouts sur les solutions libres. Maintenant, SPIP peut aussi le faire.

— Le fait que l'éditeur SPIP ne soit pas Wysiwyg présente beaucoup d'avantages. Mais, pour certains utilisateurs, c'est encore rédhibitoire. Le plugin permet de laisser l'aspect Wysiwyg aux logiciels tiers, avec lesquels les rédacteurs ont leurs habitudes et leurs automatismes, et de récupérer ces documents formatés proprement directement dans SPIP. Dans le même temps, le « nettoyage » assez violent qui intervient sur ces fichiers permet de conserver la structure du document sans introduire d'incohérence dans l'interface du site, tel que cela est le cas avec les éditeurs Wysiwyg (changements de couleurs, changements de polices...).

— Ceux qui ont l'habitude de rédiger leurs textes hors ligne (notamment dans un traitement de texte) avant de les copier-coller sur leur site gagnent énormément de temps.

— La possibilité d'indiquer l'URL d'une page Web existante et de la voir transformée en article SPIP débarassés du HTML a deux intérêts principaux :

créer rapidement une base documentaire : je repère un article intéressant sur le Web, et d'un clic je le « recopie » dans mon site,
récupérer des pages d'une ancienne version du site en automatisant énormément le travail.

Étape 1 : conversion en HTML

Le fichier est converti en HTML (assez salement) par un utilitaire nommé unoconv. Lequel utilise une version « sans interface » de OpenOffice.

Sur mon serveur sous Debian, j'ai installé les éléments ainsi :

apt-get install unoconv
apt-get install openoffice.org
apt-get install openoffice.org-headless
apt-get install openoffice.org-writer

Télécharger

Ne me demandez pas plus de précisions sur l'installation, ni sur Debian ni sur aucun autre système : je suis une véritable bille de ce côté.

Le fichier de traitement texte est donc transformé en fichier HTML, et les images qu'il contient sont sauvegardées sur le serveur.

Étape 2 : convertir vers SPIP

Une fois le fichier HTML obtenu, je le fais passer par une moulinette dérivée de la fonction sale() (une vieille fonction tirée de rezo.net jamais réellement finalisée), pour transformer le code HTML en code SPIP, puis je fabrique un article et j'y insère les images.

Notez bien : c'est une toute première version d'un plugin peu finalisé. Son usage n'est pas évident, et il est réservé aux webmestres qui peuvent et savent installer des logiciels (non PHP) sur leur serveur.

Modifications

0.2. On peut demander au plugin de créer un document PDF à partir du document d'origine et de le joindre à l'article SPIP.
0.3. On peut décider de conserver le document d'origine et de le joindre en tant que « document joint » à l'article SPIP. Uniquement pour les formats gérés par SPIP.
0.4. Possibilité d'indiquer l'URL d'un fichier (notamment page Web) distant. Le plugin rapatrie le document et effectue le traitement.
0.5. Repérer l'encodage d'un fichier HTML distant (par son meta) et convertir en utf-8 si nécessaire.
0.6. Corriger les liens hypertextuels relatifs (les liens vers l'intérieur du site de l'article original deviennent des liens absolus vers ces articles).
0.7
- Les images des pages web distantes sont rapatriées et installées en documents joints. Le raccourci devient pour faciliter la correction des éventuels titres d'images.
- Ce faisant, la création de fichier PDF à partir d'une page Web distante est grandement améliorée.
0.8
- Quand une image est un lien hypertexte direct vers une autre image, on considère qu'il s'agit d'une vignette prévisualisant une « grande » image. On rapatrie alors l'image cible et on l'installe dans le portfolio de l'article SPIP.
- Suppression des caractères Unicode de césure discrète dans le code source, parce que (1) SPIP les remettra lui-même si on le désire, (2) ça doit certainement largement améliorer le fonctionnement du moteur de recherche, (3) l'édition de texte dotés de caractères Unicode invisibles est pénible.

To do

Les éléments ~~barrés~~ sont désormais intégrés dans le plugin.

Installer une config qui permettrait :
- de modifier le chemin d'appel à unoconv,
- de faire fonctionner uniquement la partie « rapatrier une page Web », puisque celle-ci ne nécessite pas unoconv.
~~Joindre le document d'origine à l'article créé.~~
~~Créer un document PDF à partir du document d'origine et le joindre à l'article créé.~~
Pouvoir installer un document à partir du dossier /tmp/upload.
Pouvoir traiter en batch tout le contenu d'un dossier de /tmp/upload et créer autant d'articles que nécessaire.
@Fil : pouvoir downloader un fichier Word de l'article et pouvoir réuploader une nouvelle version (de façon à pouvoir faire réaliser des modifs directement par un échange de fichiers Word).
@Fil : créer une version client-serveur pour ceux qui ne peuvent installer unoconv. Remarques : (1) c'est très intrusif, puisque le contenu complet serait envoyé à un serveur externe, (2) il faut un serveur puissant, parce que le traitement est relativement lourd, (3) une difficulté est que le système extrait aussi les images et les intègre à l'article, le traitement client-serveur est donc plus complexe que pour le traitement TeX.
~~Pourvoir envoyer un fichier HTML.~~ (Ça semble fonctionner d'office.)
~~Pourvoir indiquer une URL sur le Web pour en faire un article.~~
~~Traiter les images des documents HTML distants.~~
~~Traiter spécifiquement les images qui mènent vers des images (documents joints).~~
Analyser les liens hypertexte : quand le lien est un fichier et non une page Web (genre PDF, Word..), rapatrier le document et l'installer en pièce jointe.
~~Supprimer les indications de césures discrètes.~~
Vérifier les apostrophes.
Rétablir les ancres internes (notamment notes de bas de page).

Afficher les messages Twitter qui pointent vers un site

ARNO* — 2010-02-07T11:25:33Z

[Niveau : facile] Il est désormais assez fréquent pour un webmestre d'afficher sur son site Web les derniers messages qu'il a posté sur Twitter (le compte Twitter qui, donc, « complète » son site Web). Je vous expliquais il y a quelques semaines que c'était très facile à réaliser avec les flux RSS de SPIP.

Maintenant, ce même webmestre voudrait afficher non pas les messages de son propre compte Twitter, mais tous les messages postés par n'importe qui sur Twitter et qui parlent de son site. Un pavé du style : « On cause de nous sur Twitter ».

On a ici deux difficultés :
— Twitter ne livre pas (à ma connaissance) de flux RSS portant sur une recherche, ce qui fait qu'on ne peut pas synchroniser son site avec un tel flux RSS ;
— surtout, on ne peut pas rechercher de liens vers son propre site dans Twitter en cherchant directement l'URL du site, parce que la plupart des messages utilisent des adresse raccourcies (de type bit.ly, ow.ly, etc.).

Il existe cependant un service gratuit qui résout ces difficultés : Backtweets.

Il suffit que j'indique l'URL de mon site dans le champ de recherche :

et j'obtiens immédiatement les derniers messages qui concernent mon site, même lorsque ces messages sont codées sous forme d'URL raccourcies :

Déjà, rien que pour savoir qui pointe vers vous sur Twitter, effectuer cette recherche manuelle est fort pratique. Il y a même la possibilité de se faire envoyer un mail automatiquement chaque fois qu'un nouveau message parle de votre site.

Mais le service qui nous intéresse ici, c'est la possibilité de récupérer un flux RSS de cette recherche. En haut de la liste des résultats, il y a un bouton « RSS » :

Et voilà, j'ai donc un flux RSS qui contient les derniers messages qui pointent vers mon site. Je recopie l'adresse de ce flux, ce qui donne dans mon cas :

Je vais donc dans l'interface privée de mon site sous SPIP, et je fabrique un nouveau « site syndiqué », selon la procédure habituelle (pour ceux qui n'ont pas l'habitude, c'est expliqué dans cet article.

Dans le même article, je vous donnais le code qui permettait de compléter sommaire.html pour afficher des flux tirés de Twitter. Complétons ce code pour afficher, de manière séparée, mon nouveau flux :

>
On parle de nous sur Twitter
(SITES){url_syndic==^http://backtweets\.com}>
>
(SYNDIC_ARTICLES) {id_syndic} >

#URL_ARTICLE">#LESAUTEURS –

[(#DESCRIPTIF|propre|ptobr)]

Télécharger

Le code complet devient :

>
On parle de nous sur Twitter
(SITES){url_syndic==^http://backtweets\.com}>
>
(SYNDIC_ARTICLES) {id_syndic} >

#URL_ARTICLE">#LESAUTEURS –

[(#DESCRIPTIF|propre|ptobr)]

Sur Twitter

(SYNDIC_ARTICLES) {age<180} {par date}{inverse} {0,6} {url==^http://twitter\.com}>

#URL_ARTICLE">#NOM_SITE –

[(#TITRE|replace{^.*\:}|propre|ptobr)]

[(#REM) Sur le Web ]

<:nouveautes_web:>

(SYNDIC_ARTICLES) {age<180} {par date}{inverse} {0,6} {url!==^http://twitter\.com}>

[(#DATE|affdate_jourcourt) – ]#URL_ARTICLE"[ title="(#NOM_SITE|attribut_html|couper{80})"] class="spip_out">#TITRE

Télécharger

Ce qui donne sur la page d'accueil du site :

Du texte mouvant qui habille une image fixe

ARNO* — 2009-12-21T15:43:22Z

J'ai développé, pour Blog-Mode.info, un effet que je crois inédit en HTML : il s'agit de faire circuler le texte autour d'une image (en jargon typographique : « habiller l'image avec le texte »), cette image étant fixe dans la page, et le texte conservant ses possibilités de déplacement vertical (scroll).

Comme c'est assez difficile à décrire, autant aller voir à quoi cela ressemble sur cette page.

Tout se passe dans la partie en bas à droite de la page : on a un mannequin, qui se détache sur le fond vert, et le texte s'affiche en suivant les limites de l'image (et non, comme c'est habituellement le cas en HTML, suivant le rectangle du fichier image). Pour réaliser l'habillage, j'utilise le script pour SPIP que j'ai développé en mars 2006, qui fabrique automatiquement le code HTML à partir du fichier image. Ce script a, depuis, été transformé en plugin pour SPIP, et c'est cette version que j'utilise sur Blog-Mode (j'en ai profité, au passage, pour l'améliorer).

Mais, ici, ça n'est pas l'habillage irrégulier (développé en 2006) qui est original : c'est le fait que l'image est fixée en bas à droite de l'écran. Si on fait défiler le texte verticalement, l'image ne « bouge » pas à l'écran, et le texte se déplace en continuant à respecter la forme irrégulière de l'habillage.

Et ça, c'est à ma connaissance totalement inédit.

Commençons par créer le contenu et la structure de notre page.

<html>
<head>
</head>
<body>
<div id="contenu">
<div id="elastique"></div>
<div id="image"><img src="image.png" alt="" width="236" height="300" /></div>
<div id="pave_texte">
<h1>Le titre</h1>
<div class="texte">
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In luctus, sapien vel feugiat hendrerit, ante felis mollis nunc, eget rutrum sapien arcu et turpis. Proin blandit sapien quis ante ullamcorper eget malesuada mi facilisis. Aenean risus velit, eleifend vitae lacinia nec, varius nec lorem. Aenean nisi urna, faucibus et lacinia a, dictum at erat. Maecenas laoreet eros nec felis tempor ac tempus felis lacinia. Vivamus aliquet semper ullamcorper. Donec ligula nisi, pellentesque non aliquet eget, malesuada nec sem. Sed ultricies arcu ut mauris eleifend pretium. Integer mattis, diam quis ultrices faucibus, lectus diam laoreet lectus, eu rutrum nunc lacus eu enim. Suspendisse potenti. Vestibulum hendrerit dolor a eros fermentum nec consectetur massa congue. Proin ornare rutrum arcu non tempor. Aliquam fermentum nulla et justo porttitor sit amet tristique dolor commodo. Fusce turpis sem, suscipit porttitor euismod eleifend, vehicula vestibulum nisl.</p>
<p>Cras dui erat, vulputate nec dictum vel, commodo id ante. Fusce bibendum varius fermentum. Maecenas lacinia egestas mi vel ultrices. In augue sapien, gravida quis vestibulum porttitor, congue et enim. Aenean condimentum tempus nisi, at vehicula magna luctus non. Nam ultricies urna in purus facilisis non venenatis ligula tincidunt. Quisque porta varius lectus, vitae vestibulum leo commodo nec. Morbi justo neque, ultrices in egestas ut, consectetur sed neque. Maecenas egestas malesuada gravida. Cras eleifend quam accumsan leo sodales viverra. Aliquam erat volutpat. Morbi nec sapien vel orci commodo volutpat nec ut ipsum.</p>
<p>Vivamus nec rutrum est. Curabitur lectus turpis, adipiscing et commodo a, blandit eu nisi. Nulla eget mi id mauris interdum accumsan vel et quam. Morbi sed neque felis. Duis sit amet dolor neque, nec tincidunt magna. Duis iaculis elementum lacus, nec elementum metus vehicula eu. Aenean sed tortor at erat blandit consectetur et vel lectus. Sed ligula nisl, posuere et pretium nec, facilisis ut nisl. Vivamus ultrices suscipit feugiat. Pellentesque eleifend varius lectus et iaculis. In gravida nisl id elit facilisis tempor. Sed eros dolor, fermentum quis aliquet id, ornare bibendum enim. Pellentesque fringilla pharetra sem, vitae interdum tellus varius quis. Sed tempor dignissim risus, vitae mattis quam aliquam in. Mauris facilisis magna a urna ultricies suscipit. Integer semper gravida nibh sed luctus. In hac habitasse platea dictumst. Nulla facilisi. Vivamus ac purus accumsan magna hendrerit ornare.</p>
<p>Praesent porta egestas orci, hendrerit consequat mi posuere non. Donec egestas posuere sapien, nec cursus elit sodales vel. Donec hendrerit mi non tellus luctus ullamcorper. Etiam eget magna et ante convallis pellentesque ut id augue. Curabitur tincidunt, velit a hendrerit aliquam, quam est fringilla purus, non scelerisque velit purus auctor est. Proin elit neque, venenatis quis iaculis et, cursus id dui. Quisque vehicula dignissim egestas. Nam viverra tincidunt eros porta sollicitudin. Cras porta mauris mollis ante bibendum id condimentum leo posuere. Maecenas lacinia pretium vehicula. Nam non metus tortor, quis dictum risus. Vivamus facilisis adipiscing arcu a commodo. Nulla consequat pulvinar risus, eu varius diam gravida sed. In hac habitasse platea dictumst. Etiam eget risus dolor, semper aliquam nisi. In hac habitasse platea dictumst. Aenean elementum hendrerit lacus eu luctus.</p>
<p>Suspendisse porttitor condimentum enim vitae aliquam. Fusce ultricies tristique sem, vel pellentesque mi consequat id. Nunc vulputate vehicula lorem, non gravida dui vulputate a. Nulla euismod ligula et sem luctus fermentum. Mauris sodales est id magna rhoncus molestie. Praesent non felis in ipsum dapibus feugiat. Nulla eget sem a urna dictum interdum. Proin eu metus sed nisl pellentesque eleifend at vel lectus. Mauris bibendum eros et nulla pretium lobortis. Aenean blandit lacus non nulla mollis mollis. Maecenas non ultricies ligula.</p>
</div>
</div>
</div>
</body>
</html>

Télécharger

La structure est très simple :
un div #contenu contenant la partie qui nous intéresse ici (on pourra ajouter, évidemment, un #header, un #footer par ailleurs) ;
un premer div #elastique qui, pour l'instant, ne sert à rien ;
un div #image qui contient l'image que nous allons chercher à afficher en bas à droite de notre document ;
un #pave_texte qui contient le texte du document (titre et texte libre).

Commençons par donner un style à ces différents éléments :

Paris-Beyrouth

Objectif PageSpeed 100/100 avec SPIP

Parallelize downloads across hostnames

Serve resources from a consistent URL

Serve static content from a cookieless domain

Leverage browser caching

Combine external JavaScript, Combine external CSS

Enable compression, Specify a Vary : Accept-Encoding header

Minify CSS

Remove unused CSS

Minify HTML

Les images

Specify a character set early

Pourquoi je n'obtiens pas 100/100

Qu'est-ce que ça apporte ?

Pas de BOM pour PHP (utf-8)

Parallélisation des chargements avec SPIP

Scroll auto sur iPhone, iPod et iPad

Le convertisseur Office2SPIP

Intérêt de l'opération

Étape 1 : conversion en HTML

Étape 2 : convertir vers SPIP

Modifications

To do

Afficher les messages Twitter qui pointent vers un site

On parle de nous sur Twitter

On parle de nous sur Twitter

Sur Twitter

<:nouveautes_web:>

Du texte mouvant qui habille une image fixe