1

Objectif PageSpeed 100/100 avec SPIP

24 mai 2010

par ARNO*

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 :

ExpiresActive on

ExpiresByType text/html A7200

ExpiresByType text/css A604800
ExpiresByType application/x-javascript A604800
ExpiresByType application/javascript A604800
ExpiresByType text/javascript A604800

ExpiresByType image/jpeg A604800
ExpiresByType image/png A604800
ExpiresByType image/gif A604800

ExpiresByType application/x-shockwave-flash A604800
ExpiresByTYpe text/xml A604800

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 :

07c71327f8a0d62d77f91af0a65f7dc7.css
07c71327f8a0d62d77f91af0a65f7dc7.css.gz

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 :

<files *.js.gz>
AddType "text/javascript" .gz
AddEncoding gzip .gz
Header set Vary "Accept-Encoding"
</files>
<files *.css.gz>
AddType "text/css" .gz
AddEncoding gzip .gz
Header set Vary "Accept-Encoding"
</files>

#Check to see if browser can accept gzip files.
ReWriteCond %{HTTP:accept-encoding} gzip
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]

(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 :

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript

(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;
}

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;
}

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}

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 :

<meta http-equiv="content-type" content="text/html; charset=#CHARSET" />

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.

Fil

Mai 2010

Non, Google n’implémente pas pagespeed au niveau de son moteur d’indexation, mais il le fait à travers sa toolbar, qui moucharde le temps réel chez le vrai visiteur (tu vois ça dans webmaster tools).
paolo

Mai 2010

Merci, Arnaud ! Ce sont des conseils/explications très utiles.

Chez nous j’ai ajouté le code pour « Enable compression » dans mon .htaccess. Pourtant PageSpeed réclame toujours d’enclencher la compression. Par ex. sur la page http://www.taize.fr/fr

As-tu une idée de ce qui pourrait me manquer ?
ARNO*

Mai 2010

Bonjour Paolo,

Je vois que tu as activé le compactage des fichiers JS et CSS par SPIP, je peux également accéder à la version .gz. Le souci est donc du côté du htaccess. Est-ce que tu as bien intégré le code avec les Rewriterule conditionnel que je fournis, dans le .htaccess, pour que les clients chargent la version .gz plutôt que la version « normale » ? Sinon, ça signifie que tes droits sur les RewriteRule dans le .htacces sont restreints au niveau du serveur.
Sylvain

Mai 2010

Merci pour le tuto, c’est bien intéressant !

Si je peux essayer d’apporter mes deux sous :

Pour être un poil plus propre en cas de changement de serveur (si le nouveau n’a pas les modules activés, je crois que ça risquerait de faire des erreurs), je mets des IfModule :
<IfModule mod_expires.c> ExpiresActive On # le html maintenant ExpiresByType text/html A1 # les css et js apres deux semaines dans le cache du client # une semaine = A604800 ExpiresByType text/css A1209600 ExpiresByType application/javascript A1209600 ExpiresByType text/javascript A1209600 # les images, videos et flash apres 2 mois dans le cache du client ExpiresByType image/* A5184000 ExpiresByType video/x-flv A5184000 ExpiresByType application/x-shockwave-flash A5184000 </IfModule>
Pour faire compresser par Apache à la volée, j’utilise les lignes suivantes (je crois qu’elles viennent de la doc Apache) :
<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain text/html text/css text/xml application/rss+xml application/javascript text/javascript # gestion des navigateurs buggés # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine # BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48 # the above regex won't work. You can use the following # workaround to get the desired effect: BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html # gestion des proxy caches Header append Vary User-Agent </IfModule>
Et il y a un truc de plus que les pagespeed et yslow recommandent :
# desactivation des Etag FileETag none
Sylvain

Mai 2010

Et pour minifier le html, on peut le faire en une seule passe :

$texte = preg_replace(array(",\n[\t|\ ]*,",",\n+,"), "\n", $texte);

Je me demande si ce n’est pas plus rapide ?
paolo

Mai 2010

Merci de ta réponse, Arno*,

Je crois avoir trouvé la source du problème : j’avais mis les lignes que tu indiques trop bas dans le fichier .htaccess, notamment après la section fournie par SPIP

# Si le fichier ou repertoire demande existe # ignorer toutes les regles qui suivent

J’ai maintenant placé tes lignes plus haut et cela a l’air de marcher !
ARNO*

Mai 2010

Merci pour tes précisions, Sylvain.
paolo

Mai 2010

Encore une idée : je lis ici qu’il est bien de charger les CSS avant les JS. Sur la première page de Flipzone, je vois que tu fais le contraire.
ARNO*

Mai 2010

Oui, Paolo, j’ai vu ça. Mais comme ça passe par le compacteur de SPIP, j’ignore si j’ai directement la main là-dessus, où si c’est le compacteur qui le fait à sa sauce. Il faudrait faire des essais.
paolo

Mai 2010

Je viens de changer l’ordre dans mon squelette pour charger :
1. CSS externe
2. JS externe
3. JS inline

Et en regardant la source de la page produite je vois que le compacteur de SPIP suit l’ordre que j’ai mis dans le squelette.
deor

Juillet 2010

Quand je demande http://www.paris-beyrouth.org/local/cache-js/5e917fe88c6fc4021c04ad6893de3246.js , d’après Firebug, dans l’onglet réseau, il me sert effectivement le js et ne redirige pas vers la version .js.gz.

Pourtant, toujours d’après firebug, la requête envoyée comporte effectivement un Accept-Encoding : gzip, deflate.

(par contre, effectivement, Pagespeed n’indique pas que la compression manque...)

Tout ça parce que de mon côté, je n’arrive pas à servir la version gz (pourtant, bien d’autres RedirectRule/Cond fonctionne tout à fait correctement).
Tom

Septembre 2010

Moi non plus je n’arrives pas à servir la version gz ...
Alesk\o_

Avril 2011

chez moi #FILTREmini_html, que j’ai mis en debut de squelette article.html pour le test avec la fonction bien mise dans mes_fonctions ne fait strictement rien, je suis en SPIP 2.1.0

Y’a t’il des choses qui ont changées depuis ?
ARNO*

Avril 2011

Alesko : récemment, j’ai eu besoin de prendre en compte les \r, et pas seulement les \n, sur un serveur spécifique. C’est peut-être ce qui vous arrive.

Voici la fonction modifiée :
function mini_html($texte) { $texte = preg_replace(array(",[\n\r][\t\ ]*,",",\n+,"), "\n", $texte); return $texte; }
Leccux

Avril 2011

Bonjour,

Merci pour ce papier. Lorsque je modifie le .htaccess de mon agrégateur http://autoentrepreneur.micro.entreprise.eu.com/ en joutant AddType "text/javascript" .gz AddEncoding gzip .gz Header set Vary "Accept-Encoding" AddType "text/css" .gz AddEncoding gzip .gz Header set Vary "Accept-Encoding"

#Check to see if browser can accept gzip files. ReWriteCond %HTTP:accept-encoding gzip #make sure there’s no trailing .gz on the url ReWriteCond %REQUEST_FILENAME !^.+\.gz$ #check to see if a .gz version of the file exists. RewriteCond %REQUEST_FILENAME.gz -f #All conditions met so add .gz to URL filename (invisibly) RewriteRule ^(.+) $1.gz [QSA,L]

j’ai une erreur 500. Je suis sous Spip2.1.

Merci
kent1

Mai 2011

Il serait facile de faire un petit plugin de minification du source html en passant par le pipeline recuperer_fond par exemple car je crois qu’il faut mettre la balise #FILTRE dans toutes les inclusions non ?

donc un truc du genre :

/** * Insertion dans le pipeline recuperer_fond (SPIP) * On minifie le code source en passant par mini_html qui est dans le fichier d'options options * * @param array $flux */ function plugin_recuperer_fond($flux){ $flux['data']['texte'] = aksioma_mini_html($flux['data']['texte']); return $flux; }
fekart

Octobre 2011

Bonjour,

Un tuto très interessant ! J’ai essayé le mod-pagespeed sur mon serveur mais j’obtiens des résultats moins interssants qu’avec le fichier.htaccess. Perso je pense que ce module n’est pas encore optimisé lui même pour pouvoir optimiser un serveur, et en plus avec ce mod on consome plus de ressources.

Avec le .htccess j’obtien 99/100 le seul prob c’est le cache du fichier google ga.js...

https://developers.google.com/pagespeed/#url=http_3A_2F_2Fwww.imageenmarche.fr&mobile=false

Bonne journée à tous,

Brahim www.imageenmarche.fr
Reg

Décembre 2011

Bravo pour ce tuto en français !

J’aurais bien aimé 1 explication pour : Différer l’analyse du code JavaScript

car pas évident (pour moi) à mettre en place. Merci.
N

Mars 2012

Objectif atteint... partiellement.

Bonjour, tout d’abord merci pour ce site, que je viens de découvrir et d’explorer durant ces quelques dernières heures.

J’ai donc lu tous vos tutos sur SPIP , télécharger tous les plugins préconisés (dont page speed via firefox).

Le score de 22 est passé à 31. Croissance importante en valeur relative certes , mais nous sommes encore loin du 100 %.

Ceci s’explique par 2 limites :
après qq essais (parfois des heures à comprendre comment rattraper la chose), je n’ose plus taper aucune ligne de code n’ayant jamais compris où les intégrer avec certitude.

Je ne suis pas certain de comprendre l’interface de speed page : toutes les recommandations sont-elles applicables ? Si oui comment les intégrer ? Via skeleditor ?

En tout cas merci pour ce substantiel gain de rapidité déjà acquis ! Cordialement
Raphaël

Octobre 2012

Je me suis beaucoup inspiré de ce tutoriel pour augmenter la vitesse d’un site. Mais j’ai une critique. Les solutions proposées sont utiles exclusivement du point de vue du client. Le point de vue du serveur est absent. Or certaines solutions ont un effet inverse : en demandant beaucoup de ressources au serveur, elles peuvent avoir pour conséquence de le ralentir considérablement et donc de ralentir l’envoi des pages. Cette remarque concerne le site sur lequel je travaille qui est sur un serveur dédié et reçoit plusieurs dizaines de milliers de visites quotidiennes.

La réduction du code HTML, la fusion des CSS et Javascript et la compression du tout est très efficace.

Les Sprits CSS sont très utiles pour les images récurrentes, en particulier de navigation. Je les ai utilisés pour des menus constitués de logos d’articles, mais uniquement parce que ces images étaient petites (40 pixels de large). Sinon, ce n’est pas forcément pertinent. Un ou deux articles peuvent en effet être renouvelés lors d’une nouvelle visite : si on est en Sprit CSS, il faut à nouveau charger une grosse image, alors que sinon on ne charge qu’une ou deux petites images, les autres pouvant être en cache. Par ailleurs, le plugin « Créer Sprites CSS » fonctionne parfaitement chez moi, mais ne produit pas d’images en JPG. Dans ce cas, il produit au contraire un bug, comme cela semble être le cas pour d’autres utilisateurs. En PNG, l’image est plus lourde. Au final, on a moins de hits et plus de bande passante. En utilisant cette technique, il y a donc un juste équilibre à trouver, en fonction des cas particuliers.

Le plugin « Inclure Ajaxload » est très séduisant et je l’ai beaucoup utilisé. Il est efficace du point de vue client. Mais c’est à chaque fois une nouvelle page HTML que le serveur doit produire. Dans le site en question, je l’utilisait plusieurs fois dans chaque page. J’ai réduit son utilisation, jusqu’à le retirer complètement... et mon serveur s’est mis à respirer. En n’utilisant plus Ajaxload, ce serveur est plus rapide et les utilisateurs reçoivent les pages plus rapidement. Effet inverse de celui escompté par le plugin, donc.

Je n’ai pas tenté d’utiliser l’envoie des images depuis des sous-domaines. Il est probable, là aussi, que Google Speed aurait apprécié et le serveur détesté.

Une autre action efficace a été de déplacer les fonts du serveur vers Google Fonts. Moins de hits, moins de bande passante, plus de réactivité.

Après deux semaines de changements divers, j’ai finalement pu réduire l’utilisation du serveur de manière spectaculaire. D’après Awstats, le serveur ne produit plus que 24% de documents HTML, 40% de hits et 58% de bande passante.

Le Page Speed indiqué par Google n’atteint pas les 70, mais le site est plus rapide dans son usage réel.
ARNO*

Octobre 2012

Oui, Sprite CSS est intéressant pour les images qui ne changent pas trop souvent. Ce qui dépend donc de la nature du site. Sauf erreur, le format utilisé en sortie est déterminé par le nom du sprite (par exemple « navigation.png » regroupera les vignettes dans un fichier PNG, et « navigation.jpg » dans un fichier GIF).

Sauf erreur Include Ajaxload n’a pas de rapport avec PageSpeed, mais avec l’expérience visiteur. La technique de la page vide qui ensuite charge son contenu, perso je ne suis pas convaincu non plus. Je n’utilise donc cet outil que pour charger des éléments de page communs à l’ensemble du site, et de bon poids (genre un gros footer, des menus de navigation assez conséquents).

Les images sur des sous-domaines, ça n’est plus demandé par PageSpeed, parce que les navigateurs chargent désormais beaucoup plus de fichiers en parallèle.

Un PageSpeed de 70, ça n’est quand même pas terrible aujourd’hui. Sur mon site le plus « lourd », c’est désormais à 97, sans autres techniques que celles détaillées ici.

Enfin, le truc ultime, tout de même, pour alléger à mort ton serveur : installer Varnish. Ça change la vie, surtout sur un site qui a plusieurs milliers de visites chaque jour. Et ton site a nettement moins de chances de tomber par effet Slashdot.