Parfois, il peut être déroutant d’essayer de trouver tout ce dont vous avez besoin au même endroit. Donc, aujourd’hui, nous allons partager avec vous tout ce que nous savons sur l’optimisation de WordPress, plus de 15 ans d’expérience et de dures leçons apprises. Que vous commenciez tout juste à utiliser WordPress ou que vous soyez un développeur chevronné, nous vous promettons que vous trouverez quelque chose d’utile dans ce guide!

Essayez une démo gratuite
Plus de 40,0% du Web est désormais propulsé par WordPress. Bien que ce soit génial, cela signifie également qu’il y a des milliers de thèmes, plugins et technologies différents qui doivent tous coexister. Pour l’utilisateur quotidien de WordPress, cela peut rapidement se transformer en cauchemar lorsque leur site commence à ralentir et qu’il ne sait pas pourquoi ni même par où commencer le dépannage.

Nous avons passé en revue de nombreux principes fondamentaux de la performance et comment cela peut avoir un impact énorme sur la vitesse de votre site. Mais aujourd’hui, nous allons détailler les étapes applicables que vous pouvez entreprendre dès maintenant pour voir des améliorations sur vos propres sites WordPress. Nous partagerons également certaines ressources qui nous ont été inestimables.

Types de sites WordPress: statique ou dynamique

Avant de plonger dans les optimisations de vitesse de WordPress, il est important de comprendre d’abord que tous les sites WordPress ne sont pas identiques. C’est pourquoi de nombreux utilisateurs ont des problèmes, car vous ne pouvez pas aborder tous les problèmes de la même manière. Nous attribuons toujours aux sites WordPress une classification: statique ou dynamique. Voyons donc d’abord les différences entre ces deux types de sites.

Principalement des sites statiques

Statique inclurait généralement des sites tels que des blogs, des sites de petites entreprises, des sites d’actualités à faible volume, des sites personnels, de la photographie, etc. . .

Cela devient extrêmement important car de nombreuses demandes peuvent être servies directement à partir du cache sur le serveur à des vitesses ultra-rapides! Ne t’inquiète pas; nous allons approfondir le sujet de la mise en cache ci-dessous. Cela signifie qu’ils auront moins d’appels à la base de données et moins de ressources seront nécessaires pour atteindre les performances de Google.

Sites hautement dynamiques

D’un autre côté, nous avons des sites très dynamiques. Il s’agit notamment de sites tels que le commerce électronique (WooCommerce ou Easy Digital Downloads), la communauté, l’adhésion, les forums (bbPress ou BuddyPress) et les systèmes de gestion de l’apprentissage (LMS). Par dynamique, nous entendons que les données sur ces sites WordPress changent fréquemment (les transactions serveur ont lieu toutes les quelques minutes voire toutes les secondes). Cela signifie que toutes les demandes adressées au serveur ne peuvent pas être traitées directement à partir du cache et nécessitent des ressources de serveur et des requêtes de base de données supplémentaires.

Ces sites ont également généralement un grand nombre de visiteurs et de sessions simultanés. Sur un site WordPress d’information ou d’entreprise qui est principalement statique, un visiteur peut rester cinq ou 10 minutes jusqu’à ce qu’il trouve ce dont il a besoin (et c’est un nombre élevé, les taux de rebond sont généralement beaucoup plus élevés). Sur les sites dynamiques, c’est le contraire qui se produit. Les visiteurs viennent généralement sur le site pour interagir avec quelque chose ou quelqu’un. S’ils suivent un cours en ligne, il n’est pas inhabituel pour eux de rester pendant des heures.

Vous pouvez voir où cela va. Les visiteurs simultanés connectés à votre hébergeur WordPress s’additionnent rapidement. Pour aggraver les choses, vous avez alors un grand nombre de visiteurs simultanés en plus d’un problème de «contenu inaccessible».

Choisissez un hébergement WordPress haute performance

Un hébergeur WordPress est une entreprise qui stocke toutes les données de votre site Web. Vous vous inscrivez à un plan d’hébergement, et toutes vos images, contenus, vidéos, etc., résident sur un serveur situé dans le centre de données de l’hôte. L’hébergeur WordPress vous permet d’accéder facilement aux données, de les gérer et de les acheminer vers vos visiteurs. Assez simple, non? Enfin, pas tout à fait.

Il existe trois types d’hébergeurs WordPress très différents que vous rencontrerez sur le Web. Plongeons-nous dans les avantages et les inconvénients de chacun. Il est important que vous choisissiez le bon dès le début, sinon vous vous causerez simplement des maux de tête et une perte de temps en chemin.

1. Hébergement WordPress partagé

Le premier et le plus populaire type d’hébergement WordPress est ce que nous appelons «l’hébergement partagé». Il s’agit notamment des plus grands hébergeurs du secteur, tels que les sociétés EIG comme Bluehost et HostGator, ainsi que des fournisseurs tels que Siteground, GoDaddy, Media Temple, OVH, GreenGeeks et InMotion Hosting. Ils utilisent généralement cPanel, et le client moyen paie généralement entre 3 et 25 € par mois.

Quiconque utilise ce type d’hébergement connaîtra à un moment donné de la lenteur, ce n’est qu’une question de temps. Pourquoi? Parce que les hébergeurs partagés ont tendance à surcharger leurs serveurs, ce qui à son tour peut avoir un impact sur les performances de votre site. Les suspensions de site ou les erreurs 500 fréquentes sont des choses courantes que vous rencontrerez, car elles doivent tout limiter et consolider les ressources pour survivre. Ou pire encore, les temps d’arrêt du site Web. Même si vous ne le savez pas, votre site WordPress est probablement placé sur le même serveur que plus de 200 autres personnes. Tout problème qui surgit avec d’autres sites peut se répercuter sur votre site.

Peu importe la façon dont vous faites le calcul, après les dépenses, 3 € par mois ne génèrent aucun revenu pour la société d’hébergement. Surtout quand vous ajoutez du support à cela. Un ticket d’assistance et ils sont déjà dans le rouge. La façon dont ils font la plus grosse partie de leur argent est sur la vente incitative et les frais cachés. Ces ventes incitatives incluent des choses comme les migrations, les enregistrements de domaine, les certificats SSL, etc. Une autre tactique courante consiste à offrir d’énormes réductions d’inscription. Mais une fois que le renouvellement arrive, vous recevez la vraie facture.

La plupart de ces hébergeurs proposent ce qu’ils appellent leur forfait «ressources illimitées». Vous avez probablement tous vu cela. Eh bien, il n’existe pas dans le monde réel de ressources illimitées. Ce que les hôtes font dans les coulisses, c’est ralentir les clients en utilisant une grande partie des ressources. Ceci, à son tour, finit par le départ de ces clients en colère, laissant de la place à plus de clients qui n’utilisent pas beaucoup de ressources. En fin de compte, vous avez un cercle vicieux où la société d’hébergement propose des plans bon marché et recrute des clients qui, espèrent-ils, n’utiliseront pas beaucoup de ressources et achèteront des ventes incitatives.

Le service client et le support avec l’hébergement mutualisé sont presque toujours inférieurs à la moyenne en raison du volume considérable de sites par rapport aux représentants du support.

“N’oubliez jamais que vous recevez ce pour quoi vous payez!“

2. Hébergement WordPress VPS DIY

Le deuxième type d’hébergement WordPress est DIY VPS, ou “Faites-le vous-même sur un serveur privé virtuel.” Ici c’est généralement orienté pour les utilisateurs avec un peu plus d’expérience en développement, en gestion de serveur et avec plus d’expérience WordPress. Ce sont les bricoleurs. Ces gens essaient généralement encore d’économiser de l’argent, mais ils sont également préoccupés par la performance et réalisent son importance dans le succès de leur entreprise. Les configurations communes peuvent inclure l’utilisation d’un fournisseur VPS tiers tel que Digital Ocean, Linode ou Vultr; avec un outil comme ServerPilot pour le gérer plus facilement.

Un petit VPS de DigitalOcean commence à 5 € par mois et le plan populaire de ServerPilot commence à 10 € par mois. Donc, en fonction de votre configuration, vous pourriez envisager un coût compris entre 5 et 15 € ou plus par mois. L’approche DIY peut réduire les coûts, mais cela signifie également que vous êtes responsable en cas de panne et que vous optimisez votre serveur en termes de performances.

L’approche du bricolage peut être excellente, mais elle peut également se retourner contre vous si vous ne faites pas attention. N’empruntez pas cette voie si vous n’êtes pas féru de technologie ou simplement parce que vous voulez bricoler! Votre temps vaut de l’argent et vous devriez le consacrer à la croissance de votre entreprise.

3. Hébergement WordPress géré

Le troisième type d’hébergement est l’hébergement WordPress géré. Ces types d’hôtes gèrent toutes les tâches liées au serveur principal pour vous, tout en fournissant une assistance lorsque vous en avez besoin. Ils sont généralement adaptés pour fonctionner avec WordPress et incluent généralement des fonctionnalités telles que des environnements d’installation en un clic et des sauvegardes automatiques. Leurs équipes de support seront mieux informées pour se familiariser avec le CMS, car elles se concentrent quotidiennement sur une seule plate-forme.

Si vous souhaitez gagner du temps, l’hébergement WordPress géré est la voie à suivre! 👍

Les plans d’hébergement WordPress géré vont généralement de 25 à 150 € par mois ou plus, en fonction de la taille de votre site et des besoins. De grandes entreprises comme jQuery, Intuit, Plesk, Dyn, Nginx et même la Maison Blanche utilisent toutes WordPress pour héberger leur site Web. Certains hébergeurs WordPress gérés populaires que vous connaissez probablement, ou que vous utilisez peut-être également, incluent WP Engine, Flywheel, Pressable, Media Temple, Pressidium et Pagely.

OPTIMISATIONS

PHP 7 ou supérieur pour les meilleures performances

PHP est un langage de programmation et de script open source côté serveur, principalement utilisé pour le développement Web. La majeure partie du logiciel WordPress de base est écrite en PHP, avec vos plugins et thèmes, ce qui fait de PHP un langage très important pour la communauté WordPress. Vous devez vous assurer que votre hébergeur WordPress propose au moins PHP 7 ou supérieur.

Il existe différentes versions de PHP que votre hébergeur vous fournira sur votre serveur, le plus récent PHP 7.3 offrant d’énormes améliorations de performances.

En fait, dans nos récents benchmarks PHP, si vous comparez PHP 7.3 à PHP 5.6, il peut gérer 3 fois plus de requêtes (transactions) par seconde! PHP 7.3 est également en moyenne 9% plus rapide que PHP 7.2. Cela peut également avoir un impact sur la réactivité de votre tableau de bord d’administration WordPress.

Et méfiez-vous des hébergeurs WordPress proposant HHVM comme alternative à PHP. HHVM n’est plus une solution adaptée à l’hébergement WordPress.

Choisissez un hôte qui utilise Nginx

Dans les coulisses, chaque hébergeur WordPress utilise un serveur Web pour alimenter vos sites WordPress. Les choix les plus courants sont Nginx et Apache.

Nous vous recommandons vivement d’utiliser un hôte qui utilise Nginx en raison de ses racines dans l’optimisation des performances à l’échelle. Nginx surpasse souvent les autres serveurs Web populaires dans les tests de référence, en particulier dans les situations avec un contenu statique ou des requêtes simultanées élevées, c’est pourquoi Kinsta utilise Nginx.

Nginx

Certaines entreprises de haut niveau utilisant Nginx entre autre Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple , Intel et bien d’autres.

Selon W3Techs, Apache alimente 44,0% de tous les sites Web, ce qui en fait l’option la plus utilisée. Mais si vous regardez le serveur Web le plus populaire parmi les sites Web à fort trafic (top 10 000), Nginx en alimente 41,9%, tandis qu’Apache n’en alimente que 18,1%. Il est utilisé par certains des sites les plus gourmands en ressources, notamment Netflix, la NASA et même WordPress.com.

Le réseau de votre hébergeur est important

Lorsque vous choisissez un hébergeur WordPress, vous ne pensez peut-être même pas à demander ou à rechercher le réseau qu’ils utilisent, mais vous devriez le faire. Le réseau peut avoir un impact énorme sur les performances de votre site et même sur la vivacité de votre tableau de bord WordPress. De nombreux hébergeurs laisseront cela en dehors de leur marketing car ils opteront pour le réseau le moins cher pour réduire les coûts.

Voici quelques questions que vous devriez vous poser:

Sur quels réseaux transmettez-vous des données?
La majorité est-elle sur des réseaux publics de FAI ou sur des infrastructures privées telles que Google ou Microsoft?
Ces grands fournisseurs ont des réseaux conçus et optimisés pour une faible latence et une faible vitesse. Ils ont même leurs propres câbles Internet sous l’océan!
Les réseaux que vous utilisez sont-ils redondants?
Que se passe-t-il si un câble est accidentellement coupé? Cela arrive plus souvent que vous ne le pensez.

Mise en cache avec un plugin

Si vous êtes un fournisseur d’hébergement ne fournit pas de cache, vous pouvez utiliser un plugin de mise en cache WordPress tiers. Sur la base de notre expérience, nous recommandons l’un des éléments suivants:

WP Rocket (premium)
Cache Enabler (gratuit)
Cache total W3 (gratuit)

Vous pouvez également consulter quelques options supplémentaires dans notre article détaillé sur les plugins de mise en cache WordPress.

Le meilleur de nos tests est clairement WP Rocket!

L’optimisation des images est un must

L’optimisation des images est une autre chose simple que vous pouvez faire qui a un impact significatif sur les temps de chargement de vos pages. Ce n’est pas facultatif; chaque site devrait le faire!

Les grandes images ralentissent vos pages Web, ce qui crée une expérience utilisateur moins qu’optimale. L’optimisation des images consiste à réduire la taille de leur fichier, à l’aide d’un plugin ou d’un script, ce qui accélère à son tour le temps de chargement de la page. La compression avec et sans perte sont deux méthodes couramment utilisées.

Selon HTTP Archive, en août 2019, les images représentaient en moyenne 34% du poids total d’une page Web. Donc, après les vidéos, qui sont beaucoup plus difficiles à optimiser, les images sont de loin le premier endroit où vous devriez commencer! C’est plus important que JavaScript, CSS et polices. Et ironiquement, un bon flux de travail d’optimisation d’image est l’une des choses les plus faciles à mettre en œuvre, mais de nombreux propriétaires de sites Web l’ignorent.

Trouver l’équilibre entre taille et qualité du fichier

L’objectif principal de la compression de vos images est de trouver l’équilibre entre la taille de fichier la plus faible et une qualité acceptable. Il existe plusieurs façons d’effectuer presque toutes ces optimisations. L’un des moyens les plus élémentaires consiste à les compresser avant de les télécharger sur WordPress. Habituellement, cela peut être fait dans un outil comme Adobe Photoshop ou en utilisant la nouvelle application Squoosh en ligne de Google. Cependant, ces tâches peuvent également être effectuées automatiquement à l’aide de plugins, que nous aborderons plus en détail ci-dessous.

Les deux principaux éléments à prendre en compte sont le format de fichier et le type de compression que vous utilisez. En choisissant la bonne combinaison de format de fichier et de type de compression, vous pouvez réduire la taille de votre image jusqu’à 5 fois. Vous devrez tester chaque image ou format de fichier pour voir ce qui fonctionne le mieux.

Avant de commencer à modifier vos images, assurez-vous d’avoir choisi le meilleur type de fichier. Vous pouvez utiliser plusieurs types de fichiers:

PNG – produit des images de meilleure qualité, mais a également une taille de fichier plus grande. A été créé en tant que format d’image sans perte, bien qu’il puisse également être avec perte.
JPEG – utilise l’optimisation avec et sans perte. Vous pouvez ajuster le niveau de qualité pour un bon équilibre entre la qualité et la taille du fichier.
Idéalement, vous devriez utiliser JPEG (ou JPG) pour les images avec beaucoup de couleurs et PNG pour les images simples.

Et les GIF? Les GIF animés sont toujours amusants, mais ils détruisent les performances Web. De nombreux GIF ont une taille supérieure à 1 Mo. Nous vous recommandons de les conserver pour les réseaux sociaux et Slack. S’il y en a un dont vous ne pouvez pas vous passer dans votre article de blog, découvrez comment vous pouvez compresser des GIF animés.

Optimisation avec ou sans perte

Il est également important de comprendre qu’il existe deux types de compression que vous pouvez utiliser, avec et sans perte.

La compression avec perte consiste à éliminer certaines des données de votre image. Pour cette raison, cela signifie que vous pourriez voir une dégradation (réduction de la qualité ou ce que certains appellent pixelisé). Vous devez donc faire attention à la réduction de votre image. Non seulement en raison de la qualité, mais aussi parce que vous ne pouvez pas inverser le processus. Bien entendu, l’un des grands avantages de la compression avec perte et la raison pour laquelle c’est l’une des méthodes de compression les plus populaires est que vous pouvez réduire considérablement la taille du fichier.

La compression sans perte, contrairement à la compression avec perte, ne réduit pas la qualité de l’image. Comment est-ce possible? Cela se fait généralement en supprimant les métadonnées inutiles (données générées automatiquement et produites par l’appareil qui capture l’image). Cependant, le plus gros inconvénient de cette méthode est que vous ne constaterez pas de réduction significative de la taille du fichier. En d’autres termes, cela prendra beaucoup d’espace disque au fil du temps.

Vous voudrez expérimenter ce qui fonctionne le mieux pour vous. Mais pour la majorité des utilisateurs, nous vous recommandons d’utiliser la compression avec perte car vous pouvez facilement compresser une image bien à plus de 70% (parfois même plus de 90%!) Sans trop de perte de qualité. Multipliez cela par 15 images sur une page, et cela jouera un rôle important dans la réduction du temps de chargement de votre site.

Plugins de compression d’image
La bonne nouvelle est qu’il existe d’étonnants plugins de compression d’images WordPress que vous pouvez utiliser pour automatiser l’ensemble du processus. Voici quelques plugins que nous recommandons:

Imagify (avec et sans perte – optimise les images en externe)
WP Smush (avec et sans perte – optimise les images en externe)
Optimole (avec et sans perte – optimise les images en externe)
EWWW Cloud (avec et sans perte – optimise les images en externe)
ShortPixel (avec et sans perte – optimise les images en externe)

La chose la plus importante lors du choix d’un plugin d’optimisation d’image est d’en utiliser un qui compresse et optimise les images en externe sur leurs serveurs. Ceci, à son tour, réduit la charge sur votre site. Tous ceux ci-dessus le font.

Si vous êtes curieux, nous utilisons le plugin Imagify sur le site Web de Kinsta. Il compresse automatiquement les images lorsque nous les téléchargeons dans la médiathèque WordPress. Nous n’avons donc jamais à nous soucier de quoi que ce soit. Au fil du temps, vous pouvez avoir une idée du niveau de compression d’image que vous souhaitez utiliser. Il offre Normal, Agressif et Ultra.

Nous utilisons généralement le mode Agressif et réalisons généralement des économies de 60 à 70% selon l’image.

Remarque: nous utilisons beaucoup plus de PNG que de JPEG car la plupart de nos images sont des icônes et des illustrations, pas des photos.

À quel point votre site WordPress sera-t-il plus rapide si vous utilisez la compression d’image? Tout dépend de la taille de vos images originales et de ce qu’elles sont après compression. Cependant, nous avons effectué des tests de vitesse et constaté qu’une solution de compression d’image de qualité peut réduire les temps de chargement des pages de plus de 80%!

Lazy Loading

Si vous avez beaucoup d’images, vous pouvez envisager de les charger en lazy loading. Il s’agit d’une technique d’optimisation qui charge le contenu visible mais retarde le téléchargement et le rendu du contenu qui apparaît sous la partie visible de l’écran.

Cela peut être particulièrement important sur les articles de blog avec de nombreuses icônes gravatar issues des commentaires. Google vient également de publier ses recommandations pour le chargement paresseux.

Conseils supplémentaires d’optimisation de l’image
Voici quelques derniers conseils d’optimisation d’image à suivre.

Les jours des téléchargement d’images uniquement dimensionnées à la largeur de la colonne ou DIV sont révolus. Les images responsives fonctionnent “out of the box” dans WordPress (depuis la version 4.4) et afficheront automatiquement des tailles d’image plus petites pour les utilisateurs mobiles.
Les SVG peuvent être une autre alternative intéressante à l’utilisation d’images. Les SVG sont généralement beaucoup plus petits en taille de fichier, mais pas toujours.
Utilisez des polices d’icônes au lieu de placer du texte dans les images – elles sont meilleures lorsqu’elles sont mises à l’échelle et prennent moins d’espace. Et si vous utilisez un générateur de polices, vous pouvez les optimiser encore plus.

Optimisez votre base de données

Ensuite, quelques conseils sur la façon de peaufiner votre base de données WordPress. Tout comme une voiture, votre base de données a besoin d’être entretenue, car avec le temps, elle peut devenir gonflée.

Les sites d’adhésion rendent la tâche particulièrement délicate, car ils génèrent généralement des requêtes plus complexes, ce qui ajoute une latence supplémentaire dans la récupération des informations de la base de données MySQL. Cela est dû en grande partie à toutes les pièces mobiles supplémentaires et aux grandes quantités de données de sites comme ceux-ci. Cela peut également être dû à des sites qui dépendent fortement des requêtes de recherche pour la navigation ou utilisent WP_Query.

Sans oublier que vous avez également un grand nombre d’utilisateurs simultanés qui interrogent en permanence la base de données.

Utilisez le moteur de stockage InnoDB MySQL

De nombreux sites plus anciens utilisent encore le moteur de stockage MyISAM dans leur base de données. Ces dernières années, InnoDB s’est montré plus performant et plus fiable.

Voici quelques avantages d’InnoDB par rapport à MyISAM:

InnoDB a un verrouillage au niveau des lignes. MyISAM n’a qu’un verrouillage complet au niveau de la table. Cela permet à vos requêtes d’être traitées plus rapidement.
InnoDB a ce qu’on appelle l’intégrité référentielle qui implique la prise en charge des clés étrangères (SGBDR) et des contraintes de relation, ce que MyISAM n’a pas (DMBS).
InnoDB prend en charge les transactions, ce qui signifie que vous pouvez valider et annuler. MyISAM ne le fait pas.
InnoDB est plus fiable car il utilise des journaux transactionnels pour la récupération automatique. MyISAM ne le fait pas.

Alors maintenant, vous vous demandez peut-être, utilisez-vous InnoDB ou MyISAM? Si vous utilisez un site WordPress assez récent, vous utilisez probablement déjà le moteur de stockage InnoDB MySQL. Mais avec les anciens sites WordPress, vous voudrez peut-être faire une vérification rapide. Certains sites peuvent même avoir mélangé et mis en correspondance les tables MyISAM et InnoDB, dans lesquelles vous pourriez voir des améliorations en les convertissant partout.

Suivez ces étapes simples ci-dessous pour vérifier.

Étape 1
Connectez-vous à phpMyAdmin et cliquez sur votre base de données MySQL.

Étape 2
Effectuez une analyse rapide ou triez la colonne «Type», et vous pourrez voir quels types de moteurs de stockage vos tables utilisent.

Si vous en avez trouvé qui utilisent MyISAM, il est probablement temps de les transférer vers InnoDB. Nous vous recommandons toujours de contacter votre hôte et de lui demander s’il peut le faire pour vous.

Mais vous pouvez toujours suivre un tutoriel pour convertir manuellement vos tables MyISAM en InnoDB:

Convertissez MyISAM en InnoDB avec phpMyAdmin
Convertissez MyISAM en InnoDB avec WP-CLI

Supprimer et limiter les révisions de page et de publication
Chaque fois que vous enregistrez une page ou un article dans WordPress, cela crée ce qu’on appelle une révision. Cela se produit à la fois dans les brouillons et dans les articles déjà publiés qui sont mis à jour. Les révisions peuvent être utiles au cas où vous auriez besoin de revenir à une version précédente de votre contenu.

Cependant, les révisions peuvent également nuire aux performances de votre site WordPress. Sur les grands sites, cela peut s’additionner très rapidement à des milliers de lignes dans votre base de données qui ne sont pas nécessairement nécessaires. Et plus vous avez de lignes, plus la taille de votre base de données est grande, ce qui prend de l’espace de stockage. Bien que les index aient été créés dans ce but précis, nous avons toujours vu ce problème paralyser les sites WordPress. Il y a quelques choses que vous pouvez faire.

Supprimer les anciennes révisions
Si vous avez un site WordPress plus ancien avec beaucoup de pages et d’articles, il est peut-être temps de faire un nettoyage rapide et de supprimer ces anciennes révisions. Vous pouvez le faire avec MySQL, mais avec tous les mauvais extraits de code flottant sur le Web, nous vous recommandons de faire une sauvegarde de votre site et d’utiliser un plugin gratuit comme WP-Sweep.

Un autre de nos plugins préférés, WP Rocket, dispose également d’une fonction d’optimisation de base de données pour effacer les révisions.

Si vous maîtrisez WP-CLI, vous pouvez utiliser quelques commandes pour cela.

Connectez-vous à votre serveur via SSH et exécutez la commande suivante pour obtenir et voir le nombre de révisions actuellement dans la base de données.

$ wp revisions list

Si vous obtenez une erreur, vous devrez peut-être d’abord installer le package wp-revisions-cli avec la commande suivante:

$ package wp installer trepmal / wp-revisions-cli

Vous pouvez ensuite exécuter la commande suivante pour nettoyer les révisions:

$ wp revisions clean

Limiter les révisions
Une autre bonne stratégie et celle que nous utilisons est de limiter le nombre de révisions qui peuvent être stockées par article ou page. Même en le définissant sur quelque chose comme dix, les révisions ne deviendront pas incontrôlables, surtout si vous effectuez beaucoup de mises à jour.

Pour limiter les révisions, vous pouvez ajouter le code suivant à votre fichier wp-config.php. Le code ci-dessous doit être inséré au-dessus de “ABSPATH”, sinon il ne fonctionnera pas. Vous pouvez modifier le nombre en fonction du nombre de révisions que vous souhaitez conserver dans votre base de données.

define (‘WP_POST_REVISIONS’, 10);

Nettoyez votre table wp_options et vos données chargées automatiquement
La table wp_options est souvent négligée en ce qui concerne les performances globales de WordPress et de la base de données. Surtout sur les sites plus anciens et plus volumineux, cela peut facilement être la cause de la lenteur des requêtes sur votre site en raison de données chargées automatiquement laissées par des plugins et des thèmes tiers. Fais nous confiance; nous voyons cela tous les jours!

La table wp_options contient toutes sortes de données pour votre site WordPress telles que:

URL du site, URL d’accueil, e-mail de l’administrateur, catégorie par défaut, articles par page, format d’heure, etc.
Paramètres des plugins, thèmes, widgets
Données temporairement mises en cache

Ce tableau contient les champs (colonnes) suivants:

option_id
option_name
option_value
autoload (c’est celui qui nous tient à cœur en matière de performances)

L’une des choses importantes à comprendre à propos de la table wp_options est le champ de chargement automatique. Celui-ci contient une valeur oui ou non (indicateur). Cela contrôle essentiellement s’il est chargé ou non par la fonction wp_load_alloptions (). Les données chargées automatiquement sont des données chargées sur chaque page de votre site WordPress. Tout comme nous vous avons montré comment désactiver certains scripts de chargement sur tout le site, la même idée s’applique ici. L’attribut autoload est défini sur «yes» par défaut pour les développeurs, mais tous les plugins ne devraient pas théoriquement charger leurs données sur chaque page.

Le problème que les sites WordPress peuvent rencontrer est lorsqu’il y a une grande quantité de données chargées automatiquement dans la table wp_options. Ceci est généralement le résultat de ce qui suit:

Les données sont chargées automatiquement par un plug-in alors qu’elles devraient être définies sur «non». Un bon exemple de ceci serait un plugin de formulaire de contact. Doit-il charger des données sur chaque page ou simplement sur la page de contact?
Les plugins ou thèmes ont été supprimés du site WordPress, mais leurs options sont toujours laissées pour compte dans la table wp_options. Cela peut signifier que des données inutiles chargées automatiquement sont interrogées à chaque demande.
Les développeurs de plugins et de thèmes chargent des données dans la table wp_options au lieu d’utiliser leurs propres tables. Il y a des arguments pour les deux côtés de cela, car certains développeurs préfèrent les plugins qui ne créent pas de tables supplémentaires. Cependant, la table wp_options n’a pas non plus été conçue pour contenir des milliers de lignes.
Combien de données sont trop chargées automatiquement? Cela peut bien sûr varier, mais idéalement, vous voulez que ce soit entre 300 Ko et 1 Mo. Une fois que vous commencez à approcher la plage de 3 à 5 Mo ou plus, il y a très probablement des éléments qui peuvent être optimisés ou supprimés du chargement automatique. Et tout ce qui dépasse 10 Mo doit être traité immédiatement. Cela ne signifie pas toujours que cela va causer un problème, mais c’est un bon point de départ.

Nettoyer les Transients (transitoires)

Sauf si vous utilisez un cache d’objets, WordPress stocke les enregistrements transitoires dans la table wp_options. En règle générale, ils reçoivent un délai d’expiration et devraient disparaître avec le temps. Cependant ce n’est pas toujours le cas. Nous avons vu des bases de données contenant des milliers d’anciens enregistrements transitoires.

Il est également important de noter que les transitoires ne doivent pas être chargés automatiquement par défaut. Vous pouvez utiliser une requête comme celle ci-dessous pour voir s’il existe des données transitoires chargées automatiquement.

SELECT *
FROM wp_options
WHERE autoload = ‘yes’
AND option_name LIKE ‘%transient%’

Une meilleure option et plus sûre serait d’utiliser un plugin gratuit comme Transient Cleaner ou Delete Expired Transients qui ne peut nettoyer que les transitoires expirés de votre table wp_options. Cependant, il semble qu’il existe maintenant une fonction dans WordPress, ajoutée dans la version 4.9, qui permet d’expirer les transitoires. J’espère donc que cela se produit automatiquement sur votre site maintenant.

WP Rocket a également la capacité de nettoyer les transitoires dans leurs options d’optimisation de base de données.

Nettoyer les sessions WordPress

Un autre problème courant que nous avons constaté est parfois que les tâches cron ne sont pas synchronisées ou ne se déclenchent pas correctement, et que les sessions ne sont donc pas nettoyées. Vous pouvez finir par obtenir des tonnes de lignes wp_session dans votre base de données.

Vous pouvez utiliser une requête comme celle ci-dessous pour voir si vous rencontrez ce problème:

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Dans la plupart des cas, vous pouvez ensuite les supprimer en toute sécurité (comme une tâche cron devrait avoir) avec la commande suivante:

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Ajouter un index au chargement automatique

Si le nettoyage de votre table wp_options ne suffisait pas, vous pouvez essayer d’ajouter un “index” au champ de chargement automatique. Cela peut essentiellement l’aider à être recherché plus efficacement.

Utilisez Redis comme cache d’objets persistant pour WordPress

Redis est un magasin de structure de données en mémoire open source. Dans le contexte de WordPress, Redis peut être utilisé pour stocker les valeurs générées par le cache d’objet natif de WordPress de manière persistante afin que les objets mis en cache puissent être réutilisés entre les chargements de page.

L’utilisation d’un cache d’objets persistant tel que Redis permet la réutilisation des objets mis en cache plutôt que d’exiger que la base de données MySQL soit interrogée une seconde fois pour le même objet. Le résultat est que Redis peut réduire la charge sur la base de données MySQL d’un site Web, en diminuant simultanément le temps de réponse du site et en augmentant la capacité du site à évoluer et à gérer un trafic supplémentaire.

Les sites Web très dynamiques (WooCommerce, sites d’adhésion, forums, forums de discussion, blogs avec des systèmes de commentaires extrêmement actifs) qui ne peuvent pas faire bon usage de la mise en cache de page sont des candidats potentiels pour une option de mise en cache d’objet persistante telle que Redis.

Utilisez Elasticsearch pour accélérer la recherche WordPress

Elasticsearch est un moteur de recherche en texte intégral open source. Il est utilisé pour indexer les données et rechercher ces données incroyablement rapidement.

Dans le contexte de WordPress, Elasticsearch peut être utilisé pour accélérer l’interrogation de la base de données WordPress. Cela se fait en créant un index du contenu de la base de données de votre site, puis en utilisant Elasticsearch pour rechercher cet index beaucoup plus rapidement qu’une requête MySQL ne peut effectuer la même recherche.

Désactiver les fonctionnalités non critiques qui utilisent beaucoup de bases de données

Cela peut sembler un peu évident, mais cela peut faire toute la différence si vous désactivez les plugins non critiques et les fonctionnalités de thème qui utilisent beaucoup de bases de données.

Les widgets et plugins de publication populaires et / ou connexes sont horribles. Ils ont généralement de lourdes requêtes à l’échelle du site.
Par example les plugins d’optimisation d’image qui compressent les images à l’aide de votre serveur. Vous devez toujours utiliser un plugin d’optimisation d’image qui optimise les images en externe.

Nous vous recommandons également de rester à l’écart des plugins qui ajoutent un compteur de vues / publications à votre site, sauf si vous en avez absolument besoin. Par exemple, évitez les éléments tels que “792 messages” à côté de l’avatar d’un utilisateur dans les messages du forum ou “5 243 vues” lorsque vous répertoriez les messages du forum. Lorsque vous avez une longue discussion, ces compteurs auront un impact énorme sur votre base de données. En général, minimisez l’utilisation des compteurs et ne les utilisez que si nécessaire.

Cela vaut également pour de nombreux compteurs sociaux. La mise en cache est activée, mais évidemment, ce plugin a un coût de performance considérable.

Utiliser un réseau de diffusion de contenu (CDN)
CDN est l’abréviation de Content Delivery Network (réseau de diffusion de contenu). Il s’agit d’un réseau de serveurs (également appelés POP) situés dans le monde entier. Ils sont conçus pour héberger et fournir des copies du contenu statique (et parfois dynamique) de votre site WordPress tel que des images, du CSS, du JavaScript et des flux vidéo.

Tout d’abord, vous ne voulez pas confondre un CDN avec votre hébergeur WordPress. Ce sont des services entièrement distincts. Un CDN ne remplace pas votre fournisseur d’hébergement, mais plutôt un moyen supplémentaire d’augmenter la vitesse de votre site. Un CDN peut rendre votre site encore plus rapide.

Comment fonctionne un CDN
Comment fonctionne exactement un CDN? Eh bien, par exemple, lorsque vous hébergez votre site Web, vous devez choisir un emplacement de centre de données physique, tel que les États-Unis, l’Europe, l’Asie-Pacifique ou l’Amérique du Sud.

Disons que vous choisissez US Central. Cela signifie que votre site Web est physiquement situé sur un «serveur hôte» aux Etats Unis. Lorsque des gens en Europe visitent votre site Web, il faudra plus de temps pour qu’il se charge par rapport à quelqu’un qui le visite, par exemple à Dallas, au Texas.

Pourquoi? Parce que les données doivent parcourir une distance supplémentaire. C’est ce qu’on appelle la latence. La latence fait référence au temps et / ou au retard impliqué dans la transmission de données sur un réseau. Plus la distance est éloignée, plus la latence est grande.

Types de CDN
Il existe deux types de réseaux de diffusion de contenu:

Pull CDN traditionnel
CDN de proxy inverse

Les CDN pull traditionnels mettent en cache une copie de l’ensemble de votre contenu et de vos médias, mais une demande du client est toujours adressée directement à votre fournisseur d’hébergement. KeyCDN et CDN77 sont des exemples de CDN traditionnels.

Un CDN proxy inverse est légèrement différent. Bien qu’il agisse toujours comme un CDN, il intercepte toutes les demandes entrantes et agit comme un serveur intermédiaire entre le client et votre hôte. Cloudflare et Sucuri sont des exemples de CDN de proxy inverse. C’est l’une des raisons pour lesquelles vous devez pointer votre DNS directement vers ces fournisseurs au lieu de votre hôte.

L’avantage de ceux-ci est qu’ils agissent en tant que serveur intermédiaire, ils peuvent fournir des pare-feu d’applications Web puissants qui peuvent aider à empêcher le mauvais trafic d’atteindre votre site WordPress et / ou votre fournisseur d’hébergement. Un inconvénient à cela est qu’ils viennent avec un peu de surcharge supplémentaire en termes de performances par rapport à un CDN pull traditionnel. Mais avec des performances et des fonctionnalités de sécurité supplémentaires, cela pourrait être considéré comme négligeable.

Comment trouver les goulots d’étranglement et les plugins lents
Nous allons maintenant plonger dans quelques conseils sur la façon de trouver les goulots d’étranglement sur votre site WordPress et ce que vous pouvez faire pour y remédier.

Utilisez New Relic pour identifier les plugins lents et les requêtes de base de données
Il existe d’excellents outils sur le marché qui peuvent vous aider à identifier et à identifier les requêtes de base de données lentes et les plugins qui prennent beaucoup de temps. Nous sommes de grands fans de New Relic et l’utilisons quotidiennement. New Relic est un outil de surveillance PHP que vous pouvez utiliser pour obtenir des statistiques de performances détaillées sur votre site Web.

Cependant, utilisez New Relic avec précaution car cela affecte les performances du site. Il ajoute JavaScript à votre site Web. Nous vous recommandons de l’activer lorsque vous avez besoin de dépanner les performances, puis de la désactiver par la suite.

Recherche de plugins lents
Lorsqu’un plugin WordPress cause une lenteur globale, les symptômes varient en fonction de l’activité du plugin. Cependant, dans de nombreux cas, vous constaterez qu’un plugin lent affectera chaque page d’un site WordPress.

Utilisez le plugin gratuit Query Monitor
Vous pouvez également utiliser le plugin WordPress gratuit “Query Monitor”. Utilisez-le pour identifier et déboguer les requêtes de base de données lentes, les appels AJAX, les requêtes d’API REST et bien plus encore. En outre, le plugin rapporte les détails du site Web tels que les dépendances de script et les dépendants, les hooks WordPress qui se sont déclenchés lors de la génération de la page, les détails de l’environnement d’hébergement, les balises de requête conditionnelles rencontrées par la page actuelle, et bien plus encore.

Utilisez les sites staging sans toucher à la production
Nous ne savons pas ce que nous ferions sans les environnements de test. Ceux-ci peuvent être inestimables pour résoudre les problèmes de performances. Si votre hébergeur WordPress ne propose pas d’environnements de préparation, vous pouvez également utiliser un plugin comme WP Staging, même si ce n’est pas aussi simple.

Une fois que vous avez un site de développement opérationnel, la première chose que vous pouvez faire est de désactiver tous vos plugins. Puisqu’il s’agit d’une copie de votre site en ligne, vous n’avez pas à vous soucier de quoi que ce soit. C’est de loin l’un des moyens les plus simples de réduire les problèmes. Allez simplement dans Plugins, sélectionnez-les tous et choisissez «Désactiver» parmi les options groupées.

Après cela, vous pouvez surveiller les temps de réponse dans New Relic ou Query Monitor et voir ce qui se passe. Dans cet exemple ci-dessous, les temps de réponse sont immédiatement revenus à la normale sur le site, nous savions donc que c’était l’un des plugins causant un problème. Vous pouvez ensuite les réactiver un par un, en répétant le même processus jusqu’à ce que vous trouviez le coupable.

Que devez-vous faire après avoir trouvé le plugin causant la lenteur? Voici ce que nous vous conseillons:

Mettez à jour vos plugins et thèmes avec la dernière version si vous ne l’avez pas déjà fait.
Contactez le développeur du plugin ou du thème et demandez-lui de l’aide.
Trouvez un plugin alternatif qui peut offrir les mêmes fonctionnalités.
Peut-être que votre version de PHP pose un problème. Changez votre moteur PHP vers une version inférieure et voyez si le plugin ou le thème fonctionne alors.
Vous pouvez également engager un développeur WordPress pour résoudre le problème.

Vérifiez vos logs d’erreurs
Vérifier les logs d’erreurs n’est jamais amusant, mais peut en révéler beaucoup sur les problèmes de performances avec les plugins WordPress.

Vous pouvez également activer les journaux d’erreurs en ajoutant du code à votre fichier wp-config.php. Tout d’abord, vous voudrez vous connecter à votre site via SFTP. Ensuite, téléchargez votre wp-config.php pour pouvoir le modifier. Remarque: effectuez toujours une sauvegarde de ce fichier en premier!

Trouvez la ligne qui dit / * That’s all, stop editing! Happy blogging. * / et juste avant, ajoutez ce qui suit (comme indiqué ci-dessous):

define( 'WP_DEBUG', true );

Si le code ci-dessus existe déjà dans votre fichier wp-config.php mais qu’il est défini sur «false», remplacez-le simplement par «true». Cela activera le mode de débogage. Remarque: vous verrez également des avertissements ou des erreurs dans votre administrateur WordPress s’ils existent.

Vous pouvez ensuite activer le journal de débogage pour envoyer toutes les erreurs à un fichier en ajoutant le code suivant juste après la ligne WP_DEBUG (comme indiqué ci-dessous):

define( 'WP_DEBUG_LOG', true );

Enregistrez vos modifications et téléchargez-les à nouveau sur votre serveur. Les erreurs seront ensuite enregistrées dans le fichier debug.log dans votre dossier / wp-content /. Si, pour une raison quelconque, vous ne voyez pas ce fichier, vous pouvez toujours en créer un.

Recommandations sur l’optimisation du back-end

Nous allons maintenant vous plonger dans quelques façons d’accélérer WordPress en optimisant le back-end. Le back-end implique généralement tout ce qui est entièrement géré par le serveur, tel que PHP, les en-têtes de cache HTTP, la compression GZIP, etc.

Créer une page 404 Légère
Nous avons constaté de première main que les sites hautement dynamiques génèrent généralement un grand nombre d’erreurs 404. Votre site Web génère peut-être plus que vous ne le pensez.

La raison pour laquelle ces erreurs sont graves est que de nombreuses pages 404 sont très gourmandes en ressources. Pour un site WordPress hautement dynamique, vous voudrez éviter une page 404 lourde. Créez un modèle 404 simple qui évite d’interroger davantage la base de données si possible. Et bien sûr, passez un peu de temps et corrigez les erreurs 404 car cela ne demande pas seulement beaucoup de ressources, c’est tout simplement mauvais pour l’expérience utilisateur.

En plus d’utiliser une page 404 légère, nous vous recommandons également de mettre en œuvre une règle de cache de page spéciale pour 404 pages. Nous mettons automatiquement en cache 404 pages pendant 15 minutes. Si notre serveur Web détecte qu’une nouvelle page avec la même URL qu’une page 404 mise en cache a été créée, nous purgerons automatiquement le cache. Si votre site WordPress ne dispose pas de pages 404 pouvant être mises en cache, nous vous recommandons de travailler avec votre hébergeur pour ajouter cette fonctionnalité à votre serveur Web.

Augmenter les PHP workers
Les PHP workers sont peut-être un terme dont vous n’avez jamais entendu parler, mais ils représentent le nombre d’hôtes, qui gèrent les demandes de limitation (plutôt que de vous limiter par le processeur ou la RAM, ce qui est généralement ce que font les fournisseurs d’hébergement partagé).

Les PHP workers déterminent le nombre de requêtes simultanées que votre site peut traiter à un moment donné. Pour faire simple, chaque demande non mise en cache pour votre site Web est gérée par un PHP Worker. Par exemple, si vous avez 4 requêtes qui arrivent sur votre site exactement au même moment et que votre site a 2 workers PHP, deux de ces requêtes seront traitées tandis que les deux autres devront attendre dans la file d’attente jusqu’à ce que les deux premières soient terminées. En traitement.

Rappelez-vous que nous avons discuté plus tôt que l’un des plus gros problèmes avec les sites d’adhésion WordPress est toutes ces demandes non mises en cache. C’est pourquoi les workers PHP deviennent très importants car ils doivent travailler pour chaque requête. Par conséquent, ces sites nécessiteront généralement des workers PHP supplémentaires pour s’assurer que chaque demande est traitée sans délai et terminée avec succès.

Que se passe-t-il si vous maximisez en permanence vos workers PHP? Fondamentalement, la file d’attente commence à expulser les demandes plus anciennes, ce qui peut entraîner 500 erreurs sur votre site. Si vous ne parvenez pas à estimer les besoins de votre site, vous pouvez toujours discuter avec votre hébergeur.

Utiliser la compression GZIP
GZIP est un format de fichier et une application logicielle utilisée pour la compression et la décompression de fichiers. La compression GZIP est activée côté serveur et permet de réduire davantage la taille de vos fichiers HTML, feuilles de style et JavaScript.

Lorsqu’un navigateur Web visite un site Web, il vérifie si le serveur Web a activé GZIP en vérifiant si l’en-tête HTTP content-encoding: gzip existe. Si l’en-tête est détecté, il sert les fichiers compressés et plus petits. Sinon, il sert les fichiers non compressés. Si vous n’avez pas activé GZIP, vous verrez probablement des avertissements et des erreurs dans les outils de test de vitesse tels que Google PageSpeed Insights et GTmetrix.

L’activation de la compression GZIP peut aider à réduire la taille de votre page Web, ce qui peut réduire considérablement le temps de téléchargement de la ressource, réduire l’utilisation des données pour le client et améliorer le temps de premier rendu de vos pages. C’est assez standard maintenant chez la plupart des fournisseurs d’hébergement, mais rien ne nous surprend plus à ce stade.

Activer la protection Hotlink
Le concept de hotlinking est assez simple. Vous trouvez une image quelque part sur Internet et utilisez l’URL de l’image directement sur votre site. Cette image sera affichée sur votre site Web, mais elle sera diffusée à partir de l’emplacement d’origine. C’est très pratique pour le hotlinker, mais il s’agit en fait d’un vol car il utilise les ressources du site hotlink. C’est comme si nous devions monter dans notre voiture et repartir avec de l’essence que nous avons siphonnée de la voiture de notre voisin.

Le hotlinking peut être une énorme perte de ressources pour le serveur cible. Imaginez si vous êtes sur un hébergeur WordPress partagé et que le Huffington Post est soudainement lié à vos images. Vous pouvez passer de quelques centaines de requêtes par heure sur votre site à quelques centaines de milliers. Cela pourrait même entraîner une suspension de votre compte d’hébergement. C’est une raison non seulement d’utiliser un hôte hautes performances (qui peut gérer un hoquet comme celui-ci), mais également d’activer la protection par hotlink.

Réduisez les redirections et ajoutez-les au niveau du serveur
Il faut toujours faire attention à trop de redirections. Des redirections simples comme une seule redirection 301, HTTP vers HTTPS ou www vers non-www (vice versa) conviennent. Et souvent, ceux-ci sont nécessaires dans certaines zones de votre site Web. Cependant, chacun a un coût sur les performances de votre site. Et si vous commencez à empiler les redirections les unes sur les autres, il est important de comprendre leur impact sur votre site. Cela s’applique aux redirections de page et de publication, aux redirections d’images, tout.

Une redirection générera un 301 ou 302 sur l’état de l’en-tête de réponse.

L’utilisation de plugins WordPress gratuits pour implémenter des redirections peut parfois causer des problèmes de performances car la plupart d’entre eux utilisent la fonction wp_redirect, qui nécessite une exécution de code et des ressources supplémentaires. Certains d’entre eux ajoutent également des données chargées automatiquement à votre table wp_options, ce qui augmente le gonflement de la base de données. Les ajouter au niveau du serveur est l’endroit où ils devraient être faits.

Ne laissez pas les tâches Cron devenir incontrôlables
Les tâches CRON (WP-Cron) sont utilisées pour planifier des tâches répétitives pour votre site WordPress. Cependant, au fil du temps, ceux-ci peuvent devenir incontrôlables et entraîner des problèmes de performances. Vous pouvez utiliser le plugin gratuit WP Crontrol pour vérifier et gérer toutes les tâches Cron en cours sur votre site.

Nous avons également constaté des problèmes de performances avec le gestionnaire Cron intégré de WordPress: WP-Cron. Si un site ne dispose pas de suffisamment de nœuds de calcul PHP, parfois une demande arrive, WordPress génère le cron, mais le cron doit attendre le worker, et donc reste juste là. Une meilleure approche consiste à désactiver WP-Cron et à utiliser le système cron à la place. Ceci est même recommandé dans le manuel officiel du plugin.

Pour désactiver WP-Cron, ajoutez ce qui suit à votre fichier wp-config.php, juste avant la ligne qui dit «C’est tout, arrêtez de modifier! Bon blog. » Remarque: Cela l’empêche de s’exécuter au chargement de la page, pas lorsque vous l’appelez directement via wp-cron.php.

define('DISABLE_WP_CRON', true);

Vous devrez ensuite planifier wp-cron.php depuis votre serveur.

Ajouter le contrôle du cache et expirer les en-têtes (déterminer la taille du cache)
Chaque script de votre site WordPress doit être associé à un en-tête de cache HTTP (ou il devrait). Cela détermine quand le cache du fichier expire. Pour résoudre ce problème, assurez-vous que votre hébergeur WordPress dispose des en-têtes de contrôle de cache appropriés et expire la configuration des en-têtes. Si ce n’est pas le cas, vous verrez probablement des avertissements concernant la nécessité d’ajouter des en-têtes d’expiration ou d’exploiter la mise en cache du navigateur dans les outils de test de vitesse.

Alors que l’en-tête de contrôle du cache active la mise en cache côté client et définit l’âge maximal d’une ressource, l’en-tête expires est utilisé pour spécifier un moment spécifique dans lequel la ressource n’est plus valide. Bien que les deux en-têtes puissent être utilisés ensemble, vous n’avez pas nécessairement besoin d’ajouter les deux en-têtes. cache-control est plus récent et est généralement la méthode recommandée.

Si vous utilisez un CDN, ils ajouteront probablement ces en-têtes pour vous également.

Si votre serveur ne dispose pas de ces en-têtes, vous pouvez les ajouter manuellement.

Ajout d’un en-tête de contrôle du cache dans Nginx
Vous pouvez ajouter des en-têtes de contrôle du cache dans Nginx en ajoutant ce qui suit à l’emplacement ou au bloc de serveur de votre configuration de serveur.

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

L’ajout d’un en-tête expire dans Nginx
Vous pouvez ajouter des en-têtes d’expiration dans Nginx en ajoutant ce qui suit à votre bloc de serveur. Dans cet exemple, vous pouvez voir comment spécifier différentes heures d’expiration en fonction des types de fichiers.

    location ~*  \.(jpg|jpeg|gif|png|svg)$ {
        expires 365d;
    }

    location ~*  \.(pdf|css|html|js|swf)$ {
        expires 2d;
    }

Ajout d’un en-tête de contrôle du cache dans Apache
Vous pouvez ajouter des en-têtes de contrôle du cache dans Apache en ajoutant ce qui suit à votre fichier .htaccess. Des extraits de code peuvent être ajoutés en haut ou en bas du fichier (avant # BEGIN WordPress ou après # END WordPress).

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>

Ajouter un en-tête Expires dans Apache
Vous pouvez ajouter des en-têtes d’expiration dans Apache en ajoutant ce qui suit à votre fichier .htaccess.

## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##

Il est également important de noter que vous ne pouvez ajouter des en-têtes de cache HTTP que sur les ressources de votre serveur. Si vous recevez un avertissement à ce sujet, vous devez peut-être tirer parti de la mise en cache du navigateur sur une demande tierce, vous ne pouvez rien faire, car vous n’avez pas de demande sur leur serveur. Les coupables courants incluent le script Google Analytics et les pixels marketing, comme Facebook et Twitter.

Si vous essayez de résoudre ce problème avec le script Google Analytics, vous pouvez l’héberger localement ou sur votre CDN (bien que cela ne soit pas officiellement pris en charge) avec un plugin comme Perfmatters ou WP Rocket.

Ajouter les en-têtes Last-Modified et ETag (valider le cache)
Ensuite, nous avons deux autres ensembles d’en-têtes, last-modified et etag.

Tandis que les en-têtes de contrôle du cache et d’expiration aident le navigateur à déterminer si le fichier a changé depuis la dernière fois qu’il a été demandé (ou plutôt, ils valident le cache). Les en-têtes last-modified et etag valident et définissent la longueur du cache et doivent être inclus dans chaque réponse du serveur d’origine. Si ceux-ci ne sont pas correctement définis, vous pouvez voir un avertissement indiquant que vous devez “Spécifier un validateur de cache”.

Si les en-têtes ne sont pas trouvés, une nouvelle requête pour la ressource sera générée à chaque fois, ce qui augmente la charge sur votre serveur. L’utilisation des en-têtes de mise en cache garantit que les demandes ultérieures n’ont pas à être chargées à partir du serveur, ce qui permet d’économiser de la bande passante et d’améliorer les performances de l’utilisateur.

Kinsta ajoute automatiquement les en-têtes ci-dessus sur toutes les demandes de serveur, et si vous utilisez un CDN, ils ajouteront probablement ces en-têtes pour vous également. Tout comme avec le contrôle du cache et expire, vous ne pouvez pas définir manuellement ces en-têtes HTTP sur des ressources externes.

En-tête de la dernière modification
Le dernier en-tête modifié est généralement envoyé automatiquement depuis le serveur. Il s’agit d’un en-tête que vous n’avez généralement pas besoin d’ajouter manuellement. Il est envoyé pour voir si le fichier dans le cache du navigateur a été modifié depuis la dernière fois qu’il a été demandé. Vous pouvez consulter la demande d’en-tête dans Pingdom ou utiliser Chrome DevTools pour voir la valeur de l’en-tête modifié en dernier.

En-tête ETag
L’en-tête ETag est également très similaire à l’en-tête modifié en dernier. Il sert également à valider le cache d’un fichier. Si vous exécutez Apache 2.4 ou une version ultérieure, l’en-tête ETag est déjà ajouté automatiquement à l’aide de la directive FileETag. Et en ce qui concerne Nginx, l’en-tête ETag est activé par défaut depuis 2016.

Vous pouvez activer l’en-tête ETag manuellement dans Nginx à l’aide du code suivant.

etag on

Ajouter une variable: En-tête Accept-Encoding
L’en-tête varie: Accept-Encoding doit être inclus dans chaque réponse du serveur d’origine, car il indique au navigateur si le client peut ou non gérer les versions compressées du contenu. Si ce n’est pas correctement défini, vous pouvez voir un avertissement indiquant que vous devez “Spécifier une en-tête Vary: Accept-Encoding”.

Par exemple, supposons que vous ayez un ancien navigateur sans compression gzip et un navigateur moderne avec. Si vous n’utilisez pas l’en-tête Varie: Accept-Encoding, votre serveur Web ou CDN pourrait mettre en cache la version non compressée et la fournir au navigateur moderne par erreur, ce qui à son tour nuit aux performances de votre site WordPress. En utilisant l’en-tête, vous pouvez vous assurer que votre serveur Web et / ou CDN fournit la version appropriée.

Ajouter la variable: En-tête Accept-Encoding dans Apache
Vous pouvez ajouter l’en-tête : Accept-Encoding dans Apache en ajoutant ce qui suit à votre fichier .htaccess.

<IfModule mod_headers.c>
  <FilesMatch ".(js|css|xml|gz|html)$">
    Header append Vary: Accept-Encoding
  </FilesMatch>
</IfModule>

Ajouter la variable: En-tête Accept-Encoding dans Nginx
Vous pouvez ajouter l’en-tête Varie: Accept-Encoding dans Nginx en ajoutant le code suivant à votre fichier de configuration. Tous les fichiers de configuration Nginx se trouvent dans le répertoire / etc / nginx /. Le fichier de configuration principal est /etc/nginx/nginx.conf.

gzip_vary on

Modification de la limite de mémoire WordPress dans wp-config.php
Comme indiqué dans le Codex WordPress, avec la version 2.5 de WordPress, l’option WP_MEMORY_LIMIT vous permet de spécifier la quantité maximale de mémoire pouvant être consommée par PHP. Ce paramètre peut être nécessaire dans le cas où vous recevez un message tel que «Taille mémoire autorisée de xxxxxx octets épuisés».

Par défaut, WordPress tentera d’augmenter la mémoire allouée à PHP à 40 Mo pour un seul site et 64 Mo pour le multisite. Ils définissent les limites de mémoire dans le fichier ./wp-includes/default-constants.php, aux lignes 32 – 44 (source).

Vous disposez alors également de PHP memory_limit sur le serveur par votre hébergeur. Ce sont deux choses différentes. Chez Kinsta, nous définissons la limite de mémoire par défaut sur 256 Mo. Si vous rencontrez une erreur de taille de mémoire épuisée, vous pouvez essayer d’augmenter la limite de mémoire PHP dans WordPress.

Ajoutez ce qui suit à votre fichier wp-config.php, juste avant la ligne qui dit “That’s all, stop editing! Happy blogging.”

define( 'WP_MEMORY_LIMIT', '256M' );

Au lieu de définir le montant manuellement, vous pouvez le définir sur la valeur PHP memory_limit.

define (‘WP_MEMORY_LIMIT’, ini_get (‘memory_limit’));

Conseils sur l’optimisation des fonts et les services externes
Nous allons maintenant vous plonger dans quelques façons d’accélérer WordPress en optimisant le front-end. Le front-end implique généralement tout ce qui est entièrement géré par le navigateur côté client, tel que CSS, JavasScript, images, etc. Cela comprend également l’analyse des services externes que vous chargez sur votre site et leur impact sur votre temps de chargement global.

Deux des objectifs les plus importants que vous devriez avoir en matière d’optimisation frontale sont:

Réduire la taille globale de votre page Web. La taille de vos images CSS, JavaScript et JavaScript est importante. Un site Web de 4 Mo se chargera généralement beaucoup plus lentement qu’un site Web de 1 Mo.
Réduire les requêtes HTTP et les services externes. Avec HTTP / 2, plusieurs requêtes et réponses peuvent désormais être envoyées en même temps en utilisant une seule connexion TCP. Bien que ce soit génial pour les performances, la réduction des requêtes HTTP peut toujours aider à accélérer votre site WordPress. Cela comprend également la réduction du nombre total de demandes et de services externes. Chacun de ces éléments ajoute des délais supplémentaires tels que les recherches DNS, les connexions TLS et la latence du réseau.

Testez la vitesse de votre site WordPress pour obtenir une base de référence
Lorsqu’il s’agit d’optimiser le front-end de votre site, il est toujours bon de commencer par une base de référence. Cela signifie généralement que vous devez exécuter un test de vitesse. Il existe une multitude de façons de procéder.

Choisissez un outil et gardez-le
Nous sommes de grands fans de Pingdom, GTmetrix, WebPageTest, PageSpeed Insights et Chrome DevTools. Cependant, peu importe l’outil de test de vitesse que vous utilisez, car il est cohérent. Ils ont tous différents moyens de mesurer et de quantifier la vitesse, alors choisissez un outil et gardez-le tout au long de vos tests et optimisations. Même Google dit d’en choisir un.
Ne soyez pas obsédé par un score parfait
De nombreux outils tels que Google PageSpeed Insights ont tous un certain type de score de vitesse ou de performance. Il est important de se rappeler que le score n’a pas toujours autant d’importance que la vitesse de votre site Web et les performances perçues par l’utilisateur. Le score est là pour vous aider à évaluer vos performances. Mais être obsédé par un score parfait de 100/100 ou A dans certains cas pourrait être une perte de temps. Et les plus gros sites avec beaucoup de scripts externes et de publicités n’obtiendront jamais un score parfait, ce qui est parfaitement acceptable.
L’emplacement de votre test est important
L’emplacement que vous choisissez lorsque les tests de vitesse sont importants. Comme nous l’avons vu dans une section précédente, la raison en est que tout est relatif à l’emplacement du centre de données que vous choisissez. TTFB, latence du réseau, tout entre en jeu. Testez donc votre site à la fois à partir d’un emplacement proche de votre centre de données et d’un emplacement éloigné. Cela vous aidera également à voir quel impact un CDN peut avoir sur votre site WordPress.
Tester plusieurs fois en raison de la mise en cache
Comme nous l’avons vu plus tôt dans la section sur la mise en cache, si le cache a récemment été effacé ou a expiré sur votre hôte WordPress ou CDN, il va enregistrer un “MISS” sur l’en-tête HTTP. Cela signifie que votre site Web ou votre élément n’est pas diffusé à partir du cache.

Pour voir correctement la vitesse de l’ensemble de votre site, vous devez voir tout se charger à partir du cache, votre page initiale et tous les actifs enregistrent un «HIT». Cela nécessite parfois d’exécuter votre test de vitesse plusieurs fois. Vous pouvez ensuite prendre la moyenne.

Passons maintenant à quelques optimisations frontales que vous pouvez effectuer sur votre site WordPress.

Supprimer les chaînes de requête
Un avertissement ou une recommandation courante que les utilisateurs voient dans les outils de test de vitesse est que vous devez supprimer les chaînes de requête. Qu’est-ce que tout cela? Eh bien, fondamentalement, la façon dont cela fonctionne est que vos fichiers CSS et JavaScript ont généralement la version du fichier à la fin de leurs URL, telles que https://domain.com/file.min.css?ver=4.5.3. Certains serveurs et serveurs proxy ne peuvent pas mettre en cache les chaînes de requête. Ainsi, en les supprimant, vous pouvez parfois améliorer votre mise en cache.

Vous pouvez utiliser un plugin premium comme Perfmatters qui dispose d’une option simple en un clic pour supprimer les chaînes de requête. Vous pouvez également ajouter manuellement le code suivant au fichier functions.php de votre thème. Une meilleure alternative serait d’utiliser un plugin gratuit comme les extraits de code pour ajouter le code. De cette façon, vous n’avez pas à modifier directement votre thème.

function remove_query_strings() {
   if(!is_admin()) {
       add_filter('script_loader_src', 'remove_query_strings_split', 15);
       add_filter('style_loader_src', 'remove_query_strings_split', 15);
   }
}

function remove_query_strings_split($src){
   $output = preg_split("/(&ver|\?ver)/", $src);
   return $output[0];
}
add_action('init', 'remove_query_strings')

Cependant, avant de supprimer immédiatement les query strings sur votre site, il est important de savoir pourquoi les query strings sont utilisées. La gestion des versions sur les fichiers est généralement utilisée par les développeurs WordPress pour contourner les problèmes de mise en cache.

Par exemple, si un développeur de plug-in publie une mise à jour et modifie style.css de? Ver = 4.6 à? Ver = 4.7, il sera traité comme une toute nouvelle URL et ne sera pas mis en cache. Si vous supprimez les query strings et mettez à jour un plug-in, la version mise en cache peut continuer à servir. Dans certains cas, cela peut briser l’apparence de votre site jusqu’à ce que la ressource mise en cache expire ou que le cache soit complètement vidé.

Éliminez le JavaScript et le CSS bloquant le rendu
Un avertissement concernant JavaScript et CSS bloquant le rendu peut apparaître lorsque des fichiers empêchent le chargement de la page aussi rapidement que possible. Des JS et CSS spécifiques sont parfois conditionnels, ce qui signifie qu’ils ne sont pas tenus d’afficher du contenu au-dessus de la ligne de flottaison. Vous pouvez les empêcher de bloquer le rendu en utilisant les attributs async et defer.

Pour éliminer le JavaScript et le CSS bloquant le rendu, vous devez procéder comme suit:

Effacer JS du path de rendu critique
Le déplacement de JavaScript hors du path de rendu critique est généralement effectué en ajoutant l’attribut defer ou async aux éléments HTML de script qui appellent des ressources JavaScript.

L’attribut async indique au navigateur de commencer à télécharger la ressource immédiatement sans ralentir l’analyse HTML. Une fois la ressource disponible, l’analyse HTML est suspendue afin que la ressource puisse être chargée.
L’attribut defer indique au navigateur de suspendre le téléchargement de la ressource jusqu’à ce que l’analyse HTML soit terminée. Une fois que le navigateur a terminé avec le HTML, il téléchargera et rendra tous les scripts différés dans l’ordre dans lequel ils apparaissent dans le document.
Optimiser la livraison des ressources CSS
L’optimisation de la livraison du CSS signifie essentiellement que vous devez comprendre comment le rendre non bloquant.

Identifiez les styles requis pour rendre le contenu au-dessus de la ligne de flottaison et fournissez ces styles en ligne avec le HTML.
Utilisez le CSS de manière conditionnelle sur les appareils uniquement lorsque cela est nécessaire.
Chargez le CSS restant de manière asynchrone.
Faire tout ce qui précède peut parfois être un processus délicat et nécessite certainement quelques ajustements en fonction des scripts que vous chargez sur votre site.

Voici quelques plugins WordPress qui peuvent vous aider:

Autoptimize
Async JavaScript
Hummingbird

Combinez CSS externe et JavaScript dans WordPress
L’avertissement de combinaison de CSS externe apparaît généralement lors de l’utilisation d’un CDN, car vous hébergez vos fichiers CSS sur un domaine externe, tel que cdn.domain.com. Dans le passé, un moyen rapide de résoudre ce problème était de concaténer vos fichiers CSS ou de les combiner pour qu’ils se chargent en une seule requête.

Cependant, si vous utilisez HTTPS avec un fournisseur prenant en charge HTTP / 2, cet avertissement n’est plus aussi pertinent qu’avant. Avec HTTP / 2, plusieurs fichiers CSS peuvent désormais être chargés en parallèle sur une seule connexion. Et plus de 86% des navigateurs prennent en charge HTTP / 2.

Mais cela ne signifie pas nécessairement que cette optimisation est complètement morte. Dans certains cas, nous avons vu cela accélérer encore les sites WordPress. Cela dépend de la taille des fichiers et du nombre d’entre eux. Par conséquent, il s’agit d’une optimisation que nous vous recommandons de toujours tester sur votre site.

L’un des moyens les plus simples de combiner vos fichiers CSS et JavaScript externes consiste à utiliser le plugin gratuit Autoptimize. Après les avoir combinés, vous verrez un fichier «autoptimize_xxxxx.css» ou «autoptimize_xxxxx.js». Il prend également en charge leur chargement à partir de votre CDN. Vous pouvez également le faire avec le plugin WP Rocket.

Utiliser la minification sur HTML, CSS et JavaScript
Nous pouvons réduire la quantité de données que le navigateur doit télécharger en minimisant les ressources HTML, CSS et JavaScript. La minification est le processus de suppression des caractères inutiles tels que les commentaires et les espaces du code source. Ces caractères sont extrêmement utiles dans le développement, mais ils sont inutiles pour que le navigateur affiche la page.

Cimalink Blog

Coment optimiser la vitesse de son site WordPress