Le site qui va marcher: optimisation d’une page clé

5 (100%) 1 vote

Après mes différents articles d’introduction concernant le site qui va marcher, il est maintenant temps de rentrer dans le vif du sujet. Pour ce faire, je vais dans un premier temps me consacrer pleinement à une page bien particulière du site. J’expliquerai dans un autre article plus en détail ce que j’attend de cette page clé et aussi toutes ses caractéristiques; vous verrez que c’est fort intéressant, puisque c’est principalement grâce à elle que toute ma stratégie va commencer et que les premiers sous-sous vont tomber, dixit Mme Soleil, qui l’a annoncé ce matin sur France Zéro.

La pauvre expérience utilisateur

Avant de commencer l’optimisation, l’expérience utilisateur de cette page était un véritable désastre, semblable à une manifestation de l’union nationale des croque-morts par temps de pluie, à Saint-Jean-de-Cuculles dans l’Hérault. Voici cette vilaine chose telle que nous le sortait à l’époque l’illustre GPI (Google Page Insight):

Pagespeed Insights page désastreuse

De source sure, il parait que se rapprocher de 100% pourrait grandement améliorer les choses en terme de trafic. En bon élève de Google, c’est ce que nous allons tenter de faire. Fort heureusement, j’ai déjà levé quelques lièvres similaires dans un article précédent. Chic, un peu moins de maux de tête en perspective !

Compressez et cachez, nom d’une pipe !

« Autoriser la compression » et « exploiter la mise en cache du navigateur » sont des choses très faciles à faire en utilisant tout plein de directives incompréhensibles à mettre dans votre .htaccess. Je ne l’affiche pas ci dessous parce que c’est laid comme un phylloxéra vastatrix.

Plus c’est petit, plus c’est bon

« Réduire la taille des ressources JavaScript/CSS », est aussi simple que de boire une bonne bière pendant une grosse choucroute garnie. Il faut d’abord s’assurer que les CSS présents sur votre site sont bien utilisés, et là c’est souvent la grande surprise:

Ce résultat est obtenu en utilisant le debugger de Chrome (CTRL-ALT-I), menu Audit et Run. On y voit qu’il y a un certain nombre de feuilles de style qui ne sont carrément pas utilisées mais quand même chargées ! C’est un peu dommage, parce que comme le Sénat Français, cela ne sert à rien du tout et vous fait perdre du temps. Pour info, les CSS sur le site qui va marcher représentaient quand même 500K avant l’optimisation. Alors, n’hésitez pas: sabrez-les de votre thème.

Deux remarques toutefois:

  • Les CSS peuvent très bien être utilisés sur d’autres pages de votre site, méfiez-vous donc car vous pouvez tout casser.
  • Le debugger de Chrome vous indique les instructions qui ne sont pas utilisées et la tentation est grande de vouloir aller les supprimer directement dans le fichier source. Malheureux ! Évitez absolument de faire cela pour plein de raisons: ce qui est vrai avec votre configuration ne l’est pas forcément sur un mobile ou sur un écran plus grand. De plus, vous allez voir que c’est très chronophage avec beaucoup d’ennuis en perspective. Personnellement, après m’être acharné sur quelques malheureuses lignes pendant deux jours, j’ai renoncé: le jeu est beaucoup trop hasardeux surtout si comme moi, vous codez vos CSS comme une quiche lorraine.

Après, combinez le plus possible vos CSS, afin de réduire leur nombre. Il vous suffit juste de les concaténer. Attention, pour pleins d’autres raisons, vous pouvez encore une fois casser tout votre thème. Faites des essais en commençant par concaténer deux feuilles et continuer comme cela tout doucement.

Finalement, vous minifiez tous vos fichiers CSS et JS par la même occasion en faisant toujours bien attention à ne rien casser. GPI et GT Metrix vous proposent des versions minifiées de vos fichiers. Jouez avec une combinaison des deux car vous n’obtenez pas toujours les mêmes résultats d’un site à l’autre.

N’oubliez pas non plus d’arranger vos fichiers HTML. Transformez par exemple:

<div>
<div>
<div>

en

<div><div><div>

A la longue, vous allez voir que cela va beaucoup plaire au « juge de paix ». Il m’est arrivé de gagner quelques pourcentages juste en éliminant des retours chariot.

Laissez-moi passer, c’est urgent

« Éliminer les codes JavaScript et CSS qui bloquent l’affichage »; pour le JS, la solution toute simple est de déférer l’exécution du script:

<script async src= »js/script.js » type= »text/javascript »>

Pour les CSS, la solution qui revient la plus souvent est d’utiliser loadCSS(). Mais dans mon cas, cela n’a pas été nécessaire puisque suite aux optimisations déjà effectuées sur les CSS, le message a disparu. De plus, le fait de charger les CSS après le corps peut parfois avoir des effets très laids votre site.

Un problème épineux sur cette problématique a été l’utilisation des polices de Google appelées par le thème du site. Il s’agit ici d’un problème récurrent que l’on retrouve aussi avec les scripts Google Analytic, Adsense, Facebook, etc. J’ai donc téléchargé toutes ces polices en local et modifié tous les CSS y faisant référence. Le travail de conversion et de génération des feuilles de style peut être entièrement automatisé grâce au génial google-font-download.

Le serveur qui rame encore

Il ne rame pas mon beau serveur de chez OVH, c’est une petite bombe qui marche très bien; mais cela ne semble pas suffisant pour l’ami Google. Alors, armé d’un petit verre de Châteauneuf-du-Pape, j’ai réfléchi au moyen de le contenter. En fait, c’est systématiquement la même chose qui pose problème: les entrées-sorties qu’il faut absolument réduire, car c’est toujours elles qui vous plombent vos performances. Voici par exemple ce qu’il ne faut absolument pas faire en PHP:

echo « Bonjour Papa »;
echo « Bonjour Maman »;
echo « Bonjour Madame la maîtresse »;

Total = 3 sorties quand même ! On réduit très facilement comme ceci:

$li = « Bonjour Papa\n »;
$li .= « Bonjour Maman\n »;
$li .= « Bonjour Madame la maîtresse\n »;
echo $li;

On gagne de cette manière un temps précieux. Ne pas oublier le « \n » dans les variables parce que sinon c’est moche comme une araignée qui tombe du plafond dans votre flan aux poireaux.

Malheureusement, cela ne suffit pas car en environnement LAMP, il y a des entrées-sorties très gourmandes en ressources. Je pense bien entendu aux accès aux bases de données:

SELECT * FROM tatable ORDER BY id DESC LIMIT 10000000000;
DELETE FROM table;

etc.

Vous me direz que l’on a pas trop le choix, car ces requêtes doivent être exécutées un moment ou un autre . C’est vrai, mais tant que ce peut, il faut éviter que ce soit l’utilisateur qui le fasse. L’idée est donc de déporter au maximum ce qui peut l’être via un cron (une tâche planifiée récurrente).

Ainsi, j’exécute toutes les 5 minutes la page clé qui va me créer un fichier texte:

*/5 * * * * /usr/bin/php /home/www.sitequivamarcher.com/creer.php >/home/cache

que j’appelle très facilement comme ceci:

$li = file_get_contents(« /home/cache »);
if(strlen($li)) echo $li;

Dans ce cas, l’appel se fait toutes les 5 minutes parce qu’il y a des mises à jour fréquentes sur cette page. Mais pour des pages statiques, on peut imaginer générer une bonne fois pour toute le cache. On mesure les gains obtenus très facilement en insérant par exemple une balise commentaire dans le cache:

$ts0 = microtime(true);
. .
. .
$ts = microtime(true) – $ts0;
$li .= « <!– « .sprintf(« %0.04f »,$ts).  » –> »;

Voici par exemple le résultat obtenu sur une des pages, exprimé en microsecondes:
<!– 0.4595 –>
<!– 0.0000 –>

La lecture du cache est tellement rapide que le script n’a même pas eu le temps de calculer un différentiel de temps ! Bien entendu, cette manière de faire peut parfois compliquer la mise en oeuvre du site, mais sur des pages complexes avec plein d’appels à des bases pouvant comporter des tables comprenant des millions d’enregistrements, le jeu en vaut largement la chandelle.

Mais rassurez-moi, vous pensiez réellement que Google construit ses SERPS en interrogeant en direct ses milliards de données ?

Vous allez détester les images

Après plusieurs optimisations réussies, j’ai acquis l’intime conviction que les problèmes avec les images sont la principale source des mauvais scores obtenus avec GPI. Il faut quand même dire que ce même GPI peut parfois vous proposer des optimisations vous permettant d’économiser jusqu’à 90% des ressources. Ce qui en terme de pondération est quand même spéctaculaire.

La page clé contient beaucoup d’images, alors un soin tout particulier doit être apporté à leur utilisation et leur gestion.

Il y a d’abord le format: comme préconisé, je maximise l’utilisation du PNG, quitte à convertir les JPEG en batch par exemple. Mais bien entendu, ce n’est pas toujours facile, surtout si vous avez des GIF montrant votre grand-mère maternelle poussant la chansonnette dans une guinguette en bord de Saone.

Après, les images doivent être systématiquement optimisées. Lorsque vous utilisez WordPress, ceci peut être fait à la volée via le plugin EWWW. Mais dans mon cas, n’ayant pas opté pour le génial CMS, je le fais avec des outils en ligne de commande que j’appelle sous forme de batch.

Je recommande Optipng pour les PNG et Jpegoptim pour les JPEG. Pour obtenir strictement les mêmes résultats que GPI, vous les utilisez de la manière suivante:

optipng -o7 -strip all cassouletdecanard.png
jpegoptim –strip-all -m85 -o -p tarteaupomme.jpeg

Sur les JPEG, Google a récemment abaissé son niveau d’exigence de qualité au profit d’une compression plus importante; donc vous pouvez vous permettre d’avoir des images de qualité moindre. De toutes les manières, cela ne se voit même pas à l’oeil nu, tranquilisez-vous donc: on verra toujours très nettement la photo du très beau bouquet de pavots que vous avez offert à la tante Hildegarde.

L’autre optimisation très importante à effectuer concerne la taille: si votre image est en 2000 par 2000 pixels et que vous l’utilisez en 200 par 200 pixels, au moyen des paramètres Height et Width, c’est un peu dommage parce que vous êtes 90% trop gourmand en terme de performances. Dans ce cas et si c’est possible, vous la taillez au couteau au moyen d’un outil de redimmensionement, comme par exemple Mogrify. Voici comment je faire pour faire maigrir ses vilaines bêtes:

mogrify -resize 200×200 imagetropgrosse.jpeg

Je ne peux que vous conseiller de passer beaucoup de temps sur ce sujet, c’est absolument primordial pour une bonne optimisation de votre site.

Après le désastre

Voici donc le résultat obtenu en appliquant toutes ces modifications. C’est beau, non ?

Il m’est néanmoins très difficile d’obtenir une meilleur note sans endommager sérieusement le thème du site, ce que je préfère éviter à tout prix. Après 85 est une note tout à fait correcte, surtout que l’on revient quand même de loin. Je ne peux que vous recommander de bien lire les diagnostiques de excellentissime GT Metrix qui fourmille de bonnes informations et vous fait franchement réfléchir et évoluer votre site vers une très bonne expérience utilisateur.

Voilà, nous allons désormais laisser un peu de temps au temps et voir si ces optimisations contribuent à améliorer notre trafic sur la page clé.

2 commentaires sur “Le site qui va marcher: optimisation d’une page clé

  1. Sacré gain de vitesse, c’est une bien belle optimisation et un très bon boulot : bravo (j’attaque bientôt la même opération).

  2. Merci pour ces précieuses informations.

    Le plugin WP Rocket n’est-il pas suffisant pour améliorer le score en combinaison avec imagify.

Laisser un commentaire