Activer le HTTP/2 push sur WordPress

Si votre serveur est déjà http2 que ce soit parce que vous avez upgradé Apache à une version >= à la 2.4.17 ou parce que vous passez par un service comme Cloudflare, alors il est possible d’accélérer encore un peu plus votre site en utilisant le push http/2.

Les gains en temps de chargement sont en général assez conséquent. En plus du gain déjà  apporté par le multiplexage des streams avec http/2 qui permet aussi d’éviter l’inlining, le domain sharing et la concaténation, on va pouvoir accélérer encore les choses en envoyant des données au client avant même qu’il ne les ait demandé !

Le gain de performance sera plus particulièrement perceptible sur les connections à faible bande passante ou haute latence.

Si on souhaitait le faire manuellement on ajouterait ces lignes dans le header.php du theme. C’est exactement comme pour le prefetch en HTTP1 les deux sont donc parfaitement compatibles. Si on ajoute le rel= »preload », les données seront pushées si http/2 est actif et preloadées si on est en http/1.x

Il faudrait ensuite faire en sorte que les données déjà mises en cache par l’utilisateur ne soient pas inutilement repoussées à chaque fois.

Ces fonctionnalités ne sont pas encore supportées directement par WordPress mais il existe bien sûr un plugin pour ça :

http2 server push plugin wordpress

C’est extrêmement simple, il suffit de l’installer puis de l’activer, aucune configuration. Par contre il n’a pas l’air d’être compatible avec WordPress 5 pour l’instant (2019_04_02). 4.9.10 max.

On peut ensuite vérifier que les données soient bien pushées à l’aide de ce site : https://http2-push.io/

Ou tout simplement dans l’inspecteur de Chrome, Firefox ou Safari dans l’onglet network puis dans la colonne Initiator :

http2 push vérification dans chrome outils dévelopeur onglet réseau colonne initiator

Gatsby, le générateur de site statique basé sur React et GraphQL

Gatsby est un générateur de site statique (SSG) basé sur React. Il s’agit d’un projet openSource (GitHub) né en en mai 2015 auquel ont contribués plus de 1350 développeurs en 7000 commits à ce jour. Debut 2018 Kyle Mathews crée Gatbsy Inc pour soutenir le développement du projet. L’entreprise à levé 3,8 millions de dollars de seed money en mai 2018.

Les données peuvent provenir de nombreuse et diverses sources : fichiers Markdown, CMS Headless, API WordPress, fichiers Google docs, etc. grâce à de nombreux plugins.s

Plugins

L’écosystème Gatsby est déjà riche de plus de 500 plugins. Il y’en pour tous les goûts, que ce soit pour afficher un feed Instagram, configurer Google Analytics ou se connecter sur un CMS headless.

Parmi eux certains sont quasiment indispensables et on les retrouvera dans la plupart des projets.

Gatsby images

Le plugin gatsby-image est un composant clef de Gatsby qui simplifie l’experience dévelopeur pour servir des images optimisées.

Utilisation d’images WebP pour les navigateurs le supportant

Réservation l’emplacement des images pour éviter les saccades lorsque les images sont chargées

Chargement de l’image optimale en fonction de la taille d’écran et de la résolution.

srcset

Génération de multiples version d’une image automatiquement grace à srcset. La taille adéquate est utilisée automatiquement par le navigateur en fonction de la taille de l’écran.

Lazy loading

Le lazy loading est intégré dans gatsby-image par défaut, il n’y a rien a configurer, ca fonctionne. Les images ne sont pas requêtées par le navigateur au chargement de la page mais uniquement lorsqu’on scroll vers le bas. Et ça améliore aussi grandement la performance d’un site.

Blur-up ou tracedSVG en un fragment.

Les fragments ce sont des briques de GraphQL qu’on peut créer et réutiliser par la suite, Blur up reprend une idée popularisée par la plateforme de blogging Medium et consiste à généré des versions floues et donc très légères des images affichées sur un site. Au chargement de la page c’est d’abord les images floutées qui seront afiichées enattendant que les images originales soient téléchargées. Le rendu est beaucoup plus agréable même si on ne distingue pas le contenu de l’image, on sait au moins qu’il y’a une image, le contenu ne sautera au moment du chargement puisque l’image est déjà en lace. Rien de révolutionnaire mais c’est tellement à mettre en place avec Gatsby qu’il serait dommage de s’en priver. TracedSVG fonctionne sur le même principe sauf qu’a la pace d’une version floutée de l’image on va cette fois la remplacer par une version vectorisée à l’aide du programme open source Potrace, automatiquement. Et le résultat est magnifique.

Un article très intéressant sur le préchargement et l’optimisation et des images : How to use SVG as a Placeholder, and Other Image Loading Techniques

TracedSVG placeholder Gatsby image optimisation

 

Vous pouvez également observer de véritables placeholder SVG dans leur habitat naturel sur ce site que j’ai réalisé pour découvrir Gatsby : https://waterscap.es. Très inspiré de gatsby-starter-gcn. Plus d’infos ici : Waterscap.es un site statique réalisé avec Gatsby.

Themes

Il y’a bien évidement beaucoup moins de thèmes que pour les gros CMS et ils ont moins de fonctionnalités mais on commence cependant à en voir apparaitre quelques un intéressant.

Gatsby JS themes

Showcase

Gatsby a beau être jeune, nombreux sont ceux qui l’utilisent déjà en production, parmi eux :

Gatsby sites Showcase

Déploiement en un clic

Pour deployer son site, la commande gatsby serve s’en charge. Le site est envoyé directement chez l’hébergeur, Netlify ou Github pages par exemple et si le site est sur un repo Git il est aussi possible de configurer des webhooks qui déclencheront une compilation à chaque commit. Les webhooks peuvent aussi être configurés lors de la modification du contenu si celui ci est hébergé sur un CMS headless le supportant comme Contentful ou DatoCMS.

Performance

Sans aucune optimisation, même pas la moindre directive cache-control, la plupart des sites développés avec Gatsby se chargeront incroyablement plus rapidement qu’un site équivalent (qui affiche la meme chose) développé avec WordPress. D’autant plus que la plupart des hébergeurs de sites statiques fournissent le HTTPS, HTTP2 et le CDN par défaut. Et tout cela gratuitement. Etant statique, un site Gatsby n’aura aucun soucis à supporter une montée en charge due à un plus grand nombre de visiteurs.

GraphQL

GraphQL et Gatsby fonctionnent quasiment main dans la main même si il reste possible d’utiliser ce que Gatsby appel des données déstructurées. L’utilisation de GraphQL est un vrai bonheur pour le développement, on demande l’information que l’on souhaite et le serveur nous la renvoi. Si vous utilisez Gatsby vous passerez surement pas mal de temps dans GraphiQL (prononcé Graphiqeule), la web app de GraphQL qui permet de tester une requête ou une mutation avec la possibilité d’utiliser des variables et même avec de l’autocomplétion sur les champs disponibles !

SEO

Gatsby est SEO friendly. Rien que le fait qu’un site static se charge rapidement boost sa position dans les SERP. Côté lecture par les robots, puisque les pages du site sont crées au build avant le déploiement du site, on ne retrouve pas les problèmes des SPA puisque tout est là, aisément lisible dans un seul fichiers par page. Et pour les metadata ? C’est l’indispensable plugin gatsby-plugin-react-helmet qui s’en charge.

Multiplatformes ?

Un site Gatsby est avant tout un site React et ça peut être bien pratique dans le cas où l’on souhaite developper une application qui reprend certaines fonctionnalités du site (ou vice versa). Grâce au concepts de React où tout est « componentisé », il va être possible de récupérer ces composants pour les réutiliser dans une app (Gatsby for Apps). Et c’est encore plus vrai et plus simple si on utilise GraphQL pour récupérer des données à partir d’une API. Ca commence à devenir vraiment très multi-platformes :)

Installer et configurer Redis pour WordPress en 5 minutes

Introduction

Redis est une base de données clé-valeur open-source développé par Salvatore Sanfilippo qui est sponsorisé par VMWare. Il est utilisé par des sites tels que Twitter, GitHub, Pinterest, Snapchat, Craigslist, Digg, StackOverflow et Flickr. Redis permet de garder en mémoire les requêtes mySQL. C’est un système de mise en cache extrêmement simple à mettre en oeuvre et qui peut apporter d’importants gains de performance. Bien que tous les sites soient différents et ne réagiront pas de la même façon, il n’est ainsi pas rare de voir le temps de chargement d’une page divisé par deux grâce à l’utilisation de Redis.

Memcached est un équivalent de Redis. Si vous vous demandez lequel utiliser, il vaut mieux opter pour Redis. Pour plus d’infos, voir cette réponse extrêmement détaillée sur StackOverflow.

Comment ça marche ?

A chaque fois qu’une page est chargée sur votre site lors d’une visite, une requête vers la base de données MySQL est effectuée. Redis retient ces requêtes, on dit qu’il les met en cache. Par la suite, si un autre visiteur charge la même page, la requête vers la base de données étant la même, le résultat de la requête est donné par Redis directement depuis la mémoire sans interroger la base de données. Le temps de chargement s’en trouve considérablement réduit et les ressources du serveurs sont moins solicitées. Si une valeur est mise à jour dans la base de données (un nouvel article est crée par exemple), la valeur pour cette requête est invalidée puis mise à jour.

Note

Avant d’installer Redis, il est recommandé de backuper Wordrpess ou d’essayer d’abord sur un serveur de test.

Installer Redis

Rien de plus simple, sur Ubuntu :

sudo apt-get install redis-server php5-redis

Si le paquet et introuvable comme indiqué par ces lignes :

E: Unable to locate package redis-server
E: Unable to locate package php5-redis

Il faut updater comme suis :
apt-get update

Si ça ne fonctionne toujours pas, il faut ajouter le repository universe :
sudo add-apt-repository universe

Configurer Redis

Redis peut être utilisé comme cache mais aussi en tant que base de données NoSQL. Ici nous souhaitons l’utiliser en tant que cache et allons donc procéder à une modification de sa configuration.

sudo nano /etc/redis/redis.conf

On ajoute ces deux lignes à la fin du fichier

On peut ensuite vérifier que Redis fonctione en tappant  redis-cli puis ping  qui doit normalement répondre pong

Puis taper exit pour quitter redis-cli

Editer wp-config.php

Il faut ensuite ajouter une ligne dans le fichier wp-config.php qui se trouve à la racine du site WordPress. Dans /var/www/monsite par exemple.

nano /var/www/monsite/wp-config.php

Après define('NONCE_SALT', 'xxxxxxxxxxxx'); on ajoute cette ligne  define('WP_CACHE_KEY_SALT', 'monsite.com');

Il est possible de remplacer monsite.com par n’importe quel texte mais mettre l’URL du site est une pratique courante. L’important étant d’avoir une CACHE_KEY différente pour chaque site, au cas ou vous auriez plusieurs WordPress sur le même serveur.

Il faut également ajouter cette ligne  define('WP_CACHE', true); si elle n’est pas déjà présente dans wp-config.php, ce qui est fort probable si un plugin de cache est déjà installé. Il l’aura alors lui-même écrite dans wp-config.php.

On va ensuite relancer Redis et Apache :

 

Installer le plugin Redis pour WordPress

Il faut ensuite installer à plugin qui va permettre à WordPress d’utiliser Redis. Pas la peine de passer trop de temps à chercher, le choix se porte sur le plus populaire, il y’en à d’autres mais celui fonctionne très bien.

Après l’installation il n’y a plus qu’à activer le plugin puis se rendre dans ses réglages et cliquer sur « Enable Object Cache ». Voici à quoi ressemble l’écran de configuration du plugin après l’activation du Object Cache :

Configuration Redis et WordPress avec le plugin Redis Object Cache

Vérifier que l’installation fonctionne

Pour être sur que les requêtes sont bien mises en cache, on va utiliser cette commande  redis-cli monitor et charger une page du site ne la visitant depuis un navigateur. Redis-cli devrait afficher quelque chose comme ça :

 

Conclusion

C’est tout ! Redis est installé et configuré. Il ne reste plus qu’à faire un test de temps de chargement à l’aide de Lighthouse, GTmetrix, Pingdom, webpagetest.org ou votre outil de mesure préféré pour observer le gain sur le temps de chargement du site.

 

Et si besoin de vider le cache de Redis, la commande est  redis-cli flushall

Comment optimiser le temps de chargement d’un site web

La vitesse de chargement d’un site internet est devenu un élément clef du référencement depuis la mise à jour du moteur de recherche de Google de juillet 2018. Ca faisait un moment que Google insistait sur ce point et que les performance des sites étaient prises en compte mais cette mise à jour de juillet 2018, souvent appelée « The Speed Update » officialise encore un peu plus l’importance du temps de chargement pour le positionnement dans les résultat de recherche. Cette mise à jour se concentre principalement sur le temp de chargement sur mobile.
Mais au delà du simple référencement, des études menées par des entreprises comme Walmart et Amazon montrent qu’un utilisateur abandonne très vite un site qui met trop de temps à se charger. Voici quelques exemples :

Impact sur les recettes / ventes

  • 1 seconde de retard de chargement coûterait chaque année à Amazon 1,6 milliard.
  • Si un site de commerce électronique génère 100 000 dollars par jour, un retard d’une page par seconde pourrait lui coûter 2,5 millions de dollars en pertes de ventes chaque année.

Impact sur l’attitude et le comportement des utilisateurs

  • 47% s’attendent à ce qu’une page se charge en 2 secondes ou moins.
  • 40% des utilisateurs abandonneront une page web si le chargement prend plus de 3 secondes.
  • 79% des acheteurs insatisfaits des performances du site sont moins susceptibles d’acheter à nouveau sur le même site.
  • 52% des acheteurs en ligne déclarent que le chargement rapide des pages est important pour la fidélité de leur site.

Plus de chiffres et de sources par ici : https://medium.com/@vikigreen/impact-of-slow-page-load-time-on-website-performance-40d5c9ce568a

Métrologie

Puisqu’on ne peut pas améliorer ce qu’on ne peut mesurer, nous allons avoir besoin d’outils. Fort heureusement il en existe plusieurs très bien fait qui indiquent en détail ce qui ralentit le temps de chargement mais aussi comment y remédier.

  • PageSpeed Insights (par Google)
  • Yslow (par Yahoo) une extension pour navigateurs
  • GTmetrix, qui utilise à la fois PageSpeed Insights et Yslow en même temps
  • Pingdom
  • WebPageTest
  • Les outils de développement de navigateurs Chrome, Firefox et Safari peuvent également apporter beaucoup d’information sur les performances d’un site.

Il en existe bien d’autres mais ceux sus-cités sont largement suffisants. Attention toutefois avec les outils de mesure, il est tout à fait possible d’obtenir un score  de 100% sur PageSpeed et Yslow pour une page qui met 15 secondes à charger.

Exemple de rapport de performance GTmetrix

Exemple de rapport de performance GTmetrix

Que mesure t on ?

Le TTFB (Time To First Byte)
C’est le temps que met le serveur à envoyer la première réponse, le premier bit de données, on pourrait le comparer au ping pour les jeux vidéos. Il peut être amélioré de plusieurs façons :

  • Changer d’hébergement pour un plus performant. C’est ce qui aura le plus gros impact sur l’amélioration du TTFB.
  • Dans une moindre mesure, utiliser un CDN peut également réduire le TTFB parce qu’il route l’utilisateur vers le serveur le proche géographiquement de l’utilisateur.

Le TTI (Time To Interactive)
C’est le moment à partir duquel la page devient utilisable par le visiteur. Quand une page à atteinte le TTI, cela signifie :

  • Qu’elle affiche des informations utiles pour l’utilisateur,
  • Que les « event handlers » sont actif pour la plupart des elements de la page.
  • La page répond aux interactions de l’utilisateur en moins de 50 millisecondes.

Réduire le poids des images

Pour réduire le poids des images on peut modifier : leurs tailles, leurs résolutions et leurs compression.
Il est bien sur possible de le faire manuellement avec photoshop, GIMP, paint ou n’importe quel autre logiciel de retouche d’image. Il faudra ensuite ré-uploader les images. Si votre site contient déjà des centaines ou des milliers d’images, ça risque d’être un peu fastidieux. Heureusement, il existe des outils pour automatiser cette tâche
Sur macOS il existe une app gratuite, ImageOptim https://imageoptim.com qui est extrêmement simple d’utilisation, il suffit de glisser/déposer l’image à optimiser sur la fenêtre d’ImageOptim qui va automatiquement créer une nouvelle version mieux compressée. Mieux compressée signifiant : le meilleur ratio poids/qualité qui donnera une image pas trop lourde mais pas non plus trop dégradée par la compression.

Si votre site utilise WordPress, alors c’est encore plus simple, il existe des plugins qui font tout le travail à notre place. Plus d’infos sur les plugins WordPress de compression d’images dans la section : Plugins WordPress

Diminuer le nombre de requêtes

Pourquoi ?
Parce que le nombre de requêtes concurrentes (qui peuvent être effectuées en même temps par un naviguateur) est limité, voici les limites pour chaque navigateurs au 6 avril 2018

Version Maximum connections
Internet Explorer® 7.0 2
Internet Explorer 8.0 and 9.0 6
Internet Explorer 10.0 8
Internet Explorer 11.0 13
Firefox® 6
Chrome™ 6
Safari® 6
Opera® 6
iOS® 6
Android™ 6

Cette limitation qui peut sembler étrange est en fait indispensable, elle permet de :

  • Améliorer le temps de réponse et diminuer la congestion
  • Ne pas dégrader les performances du naviguateur
  • Eviter au client d’être considéré par le serveur come un attaquant DoS

La limite du nombre de requêtes concurrentes est défini dans les specifications HTTP RFC2616 : https://www.ietf.org/rfc/rfc2616.txt

Ce qui signifie que si un site charge plus de de fichiers que le nombre simultané autorisé par le navigateur, alors il faudra attendre que les premiers fichiers soient téléchargés avant de pouvoir commencer à charger les suivants.

Il existe plusieurs façon de diminuer le nombre de requêtes :

Combiner les fichiers

Les différents fichiers javascript et CSS par exemple peuvent être combinés ensemble afin de ne former plus qu’un seul gros fichier javascript et un autre gros fichier CSS plut que de faire appel à 10 fichiers javascript et 7 fichiers CSS

Sur WordPress il est possible d’tiliser une extension pour combiner automatiquement les fichiers (voir section plugins WordPress)

Utiliser des sprites CSS

De la meme façon qu’on peut combiner le javascript et le CSS, on peut combiner les images grâce au sprites CSS. La méthode est simple, on crée une grosse image contenant pleins de petites images qui sont placées cote a cote, puis grace au positionnement CSS on va chosiir de n’afficher qu’ine petite partie de la grosse image, cette partie coresspondra exactement à une petite image.
(illustrer)

Diminuer le nombre d’outils tierces (Facebook, Analytics, etc)

Tout les sites externes auquels un site fait appel vont également augmenter le nobre de requetes et de fichiers à chargé. Parmi les plus utilisés : Facebook qui est souvent utilisé pour gérer les commentaires et la publicité. Google Analytics pour les statistiques. Disqus pour la gestion des commentaires. Outils tierce affichant des popup d’inscription a des newsletter. Etc, il en existe des milliers.

Utiliser moins d’images

Ca paraît tout bête mais c’est un des meilleurs moyen de réduire le poids d’une page. Certaines images qui ont été utilisées pour illustrer une page par exemple ne sont peut etre pas tres utiles. Par exemple, une « stock photo » d’une banalité grotesque en header d’un article juste pour avoir une image ou des photos trop nombreuses et trop similaires qui n’apportent pas grand chose à la compréhension

Utiliser le bon format pour les images

Selon ce que représente une image, on utilisera différents formats pour l’enregistrer. Par exemple une photo comme celle ci-dessous sera mieux compressé en JPEG (compression lossy, avec perte de qualité)

Alors qu’un dessin simple avec peu de couleurs comme celui ci

pourra être enregistré en PNG (compression lossless, sans perte) tout étant plus petit que si on l’enregistrait en JPEG. A l’inverse, la photo, si on l’enregistrait en PNG serait enregistrée, sans perte, oui mais elle serait beaucoup plus lourde que son equivalent JPG sur lequel on ne remarquera même pas la compression.

Minifier

Les fichiers CSS et javascript peuvent être considérablement réduits (on appel ça « minifié ») tout en procurant exactement les mêmes fonctionnalités que dans leurs version non minifiées. Pour cela, c’est très simple, un algorithme va supprimer les espaces, les commentaires (partie du code écrite par un développer pour indiquer comment fonctionne le code), réduire le nom des variables. Toutes ces modifications n’altèrent pas l’execution du code mais seulement sa compréhension par un humain, l’ordinateur le comprendra toujours de la même façon.

Ainsi, le code javascript suivant :

function sum(num1, num2) { return num1 + num2; }

Sera minifié comme suit :

function sum(A,B){return A+B;}

Et le code CSS suivant :

span { color: DeepSkyBlue; }

Comme ceci :

span{color:#00BFFF;}

 

Pour minifier le CSS et le Javascript, il existe plusieurs solutions :

  • YUI compressor  Un utilitaire Java qui permet de minifier le CSS et le Javascript
  • Google Closure Compiler Pour minifier le Javascript seulement, il existe sous la forme d’une application Java, d’une application web ou par une API
  • Il existe aussi de nombreux plugins WordPress qui peuvent se charger de la minification (plus d’infos dans la section Plugins WordPress). Certains thèmes optimisées pour la performance proposent désormais de minifier les fichiers CSS et Javascript directement par les options de performance du thème.

La compression Gzip

La compression Gzip fonctionne de la même façon que pour les fichiers zip que nous utilisons sur nos ordinateurs. Un algorithme utilise plusieurs méthodes pour diminuer la taille d’un fichier sans en perdre les informations. Il n’est pas rare de voir la taille de certains fichiers diminuer de plus de 80% grâce à la compression gzip. La seule contrepartie étant le temps nécessaire côté client pour que le navigateur dézip le fichier mais pour les ordinateurs modernes c’est tellement rapide que c’est insignifiant. La compression Gzip est donc à utiliser sans modération.
Le seul pré-requis étant que le client et le serveur acceptent la compression gzip, ce qui ne devrait poser aucun problème puisque la majorité des navigateurs et la majorité des serveurs HTTP (ex : Apache) savent très bien manipuler la compression gzip. Il est possible de Gzipper les fichiers : Javascript, CSS et HTML.

Pour activer la compression Gzip sur un serveur Apache, il faut ajouter ces lignes au fichier apache2.conf ou .htacces :

Pour Nginx, la compression Gzip devrait être activée par défaut, si ce n’est pas le cas, il faut editer le fichier nginx.conf et y ajouter les lignes suivantes :

Et pour vérifier que la compression Gzip est bien active, il suffit de se rendre sur : https://checkgzipcompression.com
Il est aussi possible de le vérifier avec les outils de développement des navigateurs ou avec la commande curl.

La mise en cache

La meilleur façon de diminuer le temps de téléchargement d’une ressource c’est de ne pas la télécharger du tout. Bien sûr il faudra bien la télécharger au moins la première fois sinon il manquerait des éléments à la page chargée mais lors du re-chargement de la même page ou du chargement d’une autre page du même site, il est très souvent possible de réutiliser une ressource (une image par exemple) qui n’est pas modifiée fréquemment sur le serveur.
C’est ce que l’on appel la mise en cache, le navigateur peut stocker localement certaines données afin de ne pas avoir à les re-télécharger par la suite.
Pour ce faire, c’est très simple, lorsque le navigateur demande une ressource au serveur, le serveur lui renvoi la ressource à laquelle sont associés des header (Plus d’infos sur les headers par ici : https://developer.mozilla.org/fr/docs/Web/HTTP/Headers ).
1. Un header « Cache-Control: max-age=360 », qui va indiquer au navigateur pendant combien de temps il peut réutiliser la ressource sans avoir besoin de la re-télécharger
Tant que ce max-age (ici 360 secondes) n’est pas dépassé, le navigateur ne téléchargera plus la ressource depuis le serveur.
2. Un header ETag: « 24rtu89/d556u4 » qui ne veut pas dire grand chose mais il à la particularité d’être modifié dès que la ressource demandé à été modifié sur le serveur.
Donc même si le max-age est dépassé, le navigateur va redemander la ressource au serveur mais en précisant qu’il a toujours en cache la ressource avec le header Etag « 24rtu89/d556u4 ». Si la ressource n’a pas changé, autrement dis, si le ETag est le même, le serveur répondra simplement avec un « 304 Not Modified » qui indiquera au navigateur qu’il peut continuer à utiliser la même ressource. Il y’a toujours une requête mais on n’économise le temps du téléchargement

Plus d’infos sur la mise en cache HTTP par ici : https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=fr

Plugins WordPress

 

Plugins de cache

W3 Total Cache (W3TC)
C’est le plus ancien et l’un des plus poussé. Très efficace mais il nécéssite d’avoir quelques connaissances afin de le configurer correctement, ça peut vite prendre pas mal de temps.

Simple cache
Le plus simple à configurer, pas de réglages à part activé/désactivé.

WP-Rocket
Très simple à configurer. C’est le seul de cette liste qui est payant mais il vaut vraiment le coup si vous souhaitez améliorer les performances de votre site rapidement sans passer des heures à le configurer. Excellent rapport qualité/facilité/prix.

D’autres plugins permettent de générer des fichiers html statiques à partir d’un site WordPress dynamique

  • WP Fastest Cache
  • WP Super Cache
  • Cache Enabler

Quelque soit le plugins que vous choisissiez, il vaut mieux vérifier la compatibilité avec les autres options et plugins de WordPress (multisite, WPML, etc, ). Certains plugins nécessitent d’être désactivés pour effectuer les mises à jours de WordPress.

 

Plugins de Lazy loading

Le lazy loading consiste à ne charger que le contenu visible d’une page dans un premier temps, puis de charger le reste quand l’utilisateur scroll vers le bas. Cette technique n’est généralement appliquée qu’aux images.

Il existe plusieurs façon pour ajouter du lazy loading :

  • Il est peut être déjà inclus dans votre thème, il faut activer l’ption quelque part
  • Le module pagespeed pour apache et Nginx peut s’en charger
  • Ou par le biais de plugins WordPress

 

Plugins d’optimisation d’images

Deux plugins permettent de réduire très simplement le poids des images. Il peuvent optimiser les images déjà présentes dans les « Médias » de WordPress mais peuvent aussi intervenir à chaque futur upload d’image.

  • WP Smush
  • EWWW Image Optimizer

Plus d’infos sur l’optimisation des images dans la section « Réduire le poids des images »

 

Sites web statiques

C’est un phénomène qui (re-)prend de l’ampleur depuis quelque temps. Il s’agit tout simplement d’un site composé de pages qui sont envoyées par le serveur telles qu’elles y sont stockés. En général il s’agit de fichiers HTML. Ces fichiers, contrairement à ceux générés par un site dynamique qui utiliserait PHP et une base de données, sont les mêmes pour tous les utilisateurs. Ils ne sont pas modifiés en fonction du temps, de la connexion de l’utilisateur à un compte sur le site, du navigateur, etc). C’est en quelque sorte un retour aux sources du web à l’époque où tout était « pur HTML »

Ce type de site offre plusieurs avantages :

  • Securité accrue grâce à l’absence de base de données
  • Excellentes performances, que ce soit au niveau du temps de chargement ou de la charge CPU et mémoire du serveur
  • Plus fiable et plus simple à maintenir parce que moins de « pièces en mouvement », pas de PHP, pas de base de données.
  • Hébèrgement très économique, voir gratuit sur Github ou Amazon S3

Mais il ont aussi des inconvenients :

  • Impossibilité d’afficher du contenu dynamic évidemment
  • Pas de formulaires de contact ou un systèmes de commentaires sur un article bien qu’il existe des « workarounds » comme l’utilisation de services externes tel que Disqus (link) pour les commentaires.

Les sites statiques ne sont plus si statiques que ça puisqu’il existe maintenant des systèmes de gestion de contenu (CMS), à l’instar de WordPress, qui permettent de modifier un site statique à l’aide d’une interface intuitive. Après une modification, les fichiers HTML sont re-générés, une seul fois et non à la volée, à chaque requête, comme dans le cas d’un site dynamique.

 

Le serveur : Apache / Nginx

Le choix du serveur HTTP peux aussi avoir un impact sur la performance d’un site internet.
Apache est le numéro 1 des serveur HTTP, c’est le plus puissant et le plus répandu.
Nginx (prononcer hainejaïllenex (fr) ou Engine X (us)) s’est hissé en quelques années à la place de numéro 2 et est réputé plus rapide.
Mais tout dépend de l’utilisation qu’on en fait. Quelque soit le serveur HTTTP choisi, il faudra le configurer correctement. En effet on ne configurera pas de la même façon un serveur qui reçoit 100 requêtes par seconde qu’un autre qui reçoit 10 requêtes par jour.
Il est aussi possible d’utiliser les deux en même temps avec Nginx en reverse proxy. Ce faisant, on profite de la puissance d’apache alliée à la rapidité d’Nginx

Cloudflare

Cloudflare est un service très simple à configurer et qui peut apporter de nombreuses améliorations de performance au niveau de la mise en cache et du CDN
Ainsi que plusieurs outils maison comme :

  • Chargement asynchrone de JavaScript avec Rocket Loader™
  • Optimisation de réseau d’origine avec Railgun™
  • Optimisations d’images avec Polish™
  • Optimisations mobiles avec Mirage™

Pour l’utiliser, il suffit de modifier les nameservers de la zone DNS, une opération qui prend 2 minutes à réaliser.
En plus de l’amélioration des performances, Cloudflare améliore la securité du site contre les attaques DDoS par exemple.

Diminuer la quantité de javascript

On a parfois tendance à charger plus de javascript que nécessaire, charger tout une bibliotheque pour n’en utiliser que queqlues fonctions. Il existe des moyens assez simple pour diminuer la quantité de javascript à charger. jQuery par exemple porpose un « Download builder » qui permet de choisir uniquement les fonctionnalités qui nous intéressent afin de réduire la taille du fichier jquery.js.

Différer le chargement du Javascript

Le javascript peut bloquer l’affichage d’une page. En effet, le code javascript ayant la capacité de modifier le contenu d’une page, par défaut, le navigateur attend donc que le javascript soit chargé afin de savoir si il doit modifier le rendu HTML.
Il est cependant possible d’indiquer au navigateur qu’il n’a pas besoin d’attendre le chargement du Javascript avant de poursuivre l’analyse HTML et qu’il peut donc charger et executer le javascript à la fin, c’est à ça que sert l’attribut defer , il dit au navigateur : charge et affiche le HTML puis, quand tu auras fini, occupe to du javascript. La plupart du temps cela ne pose pas de problème excepté l’affichage de la page qui peut être légèrement modifié par le javascript après son chargement (insertion d’images, reflow du texte, etc). Mais si le code javascript à besoin d’interagir avec l’utilisateur avant de pouvoir afficher afficher la page, par le biais d’une alert box par exemple, les conséquences seraient plus ennuyeuses. Avec defer, l’exécution du javascript est simplement repoussée à la fin de l’analyse HTML, c’est l’équivalent de mettre le code javascript juste avant la fermeture du  </body>

L’attribut async  permet lui de dire au navigateur : charge tous les fichiers javascript nécessaire quand ça t’arrange, peut importe l’ordre, premier téléchargé, premier exécuté. C’est la méthode qui permettra le chargement le plus rapide de la page, celui qui permettra d’arriver le plus rapidement possible à l’évènement DOMContentLoaded. Mais encore fois il faut être prudent parce que certains fichiers javascript peuvent avoir besoin que d’autres fichiers soient chargés (jQuery par exemple) avant de pouvoir être exécutés. Si les fichiers nécessaires n’ont pas encore été chargés, le javascript ne sera pas exécuté ou alors exécuté avec des erreurs.

C’est une méthode qui peut grandement diminuer le temps d’affichage d’une page mais il faut être prudent car si la page à absolument besoin du Javascript pour s’afficher correctement

Eliminer le CSS bloquant le rendu

Avant d’afficher une page, le navigateur va d’abord charger tous les fichiers CSS qu’on lui à demandé de charger.
Voici quelques règles simples pour ne pas rallonger le temps de chargement des fichiers CSS

  1. Ne pas utiliser @import
    La règle @import permet d’inclure dans un fichier CSS le code d’un autre fichier CSS. Mais cette @import augmente le temps de chargement du CSS. Que ce soit le @import utilisé dans le fichier CSS ou la @import utilisé dans le HTML comme ceci :  <style>@import url('a.css');</style>En ce qui concerne les @import situé dans les fichiers CSS, il est préférable d’inclure directement le code importé, si ce n’est pas possible, il faut indiquer dans le HTML de charger plusieurs fichiers CSS. Plus d’informations et de tests de rapidité sur l’utilisation d’@import ici: https://www.stevesouders.com/blog/2009/04/09/dont-use-import/
  2. Indiquer correctement le CSS conditionnel
    Le CSS conditionnel permet de charger différents fichiers CSS en fonction de l’usage ou de la taille de l’écran par exemple.

Fichier CSS chargé dans tous les cas

<link href="style.css" rel="stylesheet">

Chargement conditionnel, le fichier CSS n’est chargé que lorsque l’on souhaite imprimer la page, il n’est donc pas nécéssaire de charger à tous les coups

<link href="print.css" rel="stylesheet" media="print">

Chargement conditionnel, le fichier CSS n’est chargé que si l’écran fait plus de 40em de large

<link href="autre.css" rel="stylesheet" media="(min-width: 40em)">

Indiquer correctement au navigateur à quoi sert chaque fichier CSS va permettre de ne télécharger que le strict minimum et donc de diminuer le temps de chargement de la page.

3. Combiner les fichiers CSS (voir la section « Combiner les fichiers »)

4. Inliner le CSS

Il s’agit simplement de placer le code CSS dans le code HTML à l’aide de la balise  <style> plutot que dans un fichier séparé. Cela permet d’économiser une requête et de télécharger d’autres ressources à la place.

 

Retirer le CSS inutile

Il s’agit de code CSS qui n’est utilisé par aucun element du site.
Par exemple le code suivant :
optgroup:empty{display:none}
N’a pas de raison d’être si il n’y aucun element HTML <optgroup>  utilisé sur le site.
Ce code prend de la place dans les fichiers CSS, 28 bytes pour le code ci-dessus, pas grand chose mais mis bout à bout ça peut représenter quelques kilobytes.
Ce code inutilisé provient la pupart du temps d’une bibliotheque CSS comme Bootstrap mais il peut très bien s’agir de code écrit spécifiquement il y’a longtemps et qui n’est aujourd’hui plus utilisé.
Pour trouver les sélecteurs CSS inutilisés il existe différents outils : des extension de navigateurs, des application en ligne (https://uncss-online.com), les outils de développeurs de Chrome ou bien des plugins pour les task runners/module bundlers tel que Webpack, Grunt ou Gulp (https://github.com/FullHuman/purgecss).
Certaines bibliotheques CSS comme bootstrap proposent un download builder qui permet de ne selectionner que les elements qui nous intéressent et d’ainsi réduire la taille d’un fichier css : https://getbootstrap.com/docs/3.3/customize/

Utiliser un theme plus léger

Certains themes pour les CMS (WordPress, Prestashop, etc) sont optimisés par leurs développeurs pour accélérer le temps de chargement. Tant qu’à faire, au moment du choix du theme, autant opter pour ce genre de theme. Pour trouver un theme optimisé, il faut regarder la description sur les sites de themes comme ThemeForest. Certains en on même fait leur argument de vente :

SSL

La mise en place d’un certificat SSL permettant de sécuriser un site augmente le temps de chargement, cela est du au « TLS handshake » initial qui permet au client et au serveur de s’identifier lors du premier contact.
Cependant étant donné les récentes evolutions, ce paramètre devient de plus en plus insignifiant. L’augmentation du temps de chargement en https sera de moins de 10ms voir même nulle et étant donnée l’amélioration considérable de la sécurité et le prix d’un certificat SSL aujourd’hui (gratuit), il serait absurde de s’en passer.
Plus d’informations à ce sujet et des tests avec/sans SSL : https://www.keycdn.com/blog/https-performance-overhead/

Mettre à jour PHP

PHP est un language en constante évolution et chaque nouvelle version apporte son lot d’améliorations qui peuvent parfois avoir un impact important sur le temps de génération d’une page. Cela est rendu possible grâce à différentes choses, voici par exemple les améliorations de la version de 7 de PHP :
  • Amélioration du Zend Engine, l’interpréteur de PHP
  • Réduction de l’utilisation de la mémoire
  • Meilleur gestion du cache opcode

HTTP/2 et SPDY

La spécification du protocol HTTP/2 a été publiée en mai 2015 et est supporté par la plupart des naviquateurs depuis fin 2015. C’est une mise à jour majeure du protocol HTTP/1.1 qui date de 1997.
Utiliser HTTP/2 peut améliorer de manière signiifcative la vitesse de chargement d’un site. Voici les 4 points clefs qui permettent au protocol HTTP/2 d’améliorer les performances :
  • Multiplexing : permet d’atablir plusieurs flux sur une seule connexion TCP
  • Priorisation : permet de en priorité certaines ressources
  • Server push : le serveur peut désormais envoyer des ressources avant même qu’elles aient été demandées par le client
  • Compression des En-têtes HTTP