Comment configurer les réglages de W3 Total Cache pour votre site WordPress

Avec plus d’un million d’installations actives, W3 Total Cache est l’une des extensions de mise en cache et d’optimisation les plus populaires du dépôt WordPress. Contrairement aux autres extensions WordPress d’optimisation qui offrent une interface relativement plus simple et rationalisée, W3 Total Cache donne un contrôle complet sur la configuration de la mise en cache de votre site WordPress.

La granularité des réglages de W3TC en fait une extension idéale pour les utilisateurs avancés et les développeurs qui veulent avoir un contrôle ultime sur leurs sites WordPress. Dans cet article, nous allons examiner en détail les réglages de W3 Total Cache, et nous vous donnerons la configuration que nous recommandons pour améliorer les performances de votre site WordPress.

Si vous êtes un utilisateur de Kinsta, vous n’aurez pas besoin de configurer certains réglages dans W3 Total Cache car notre pile d’hébergement intègre déjà de nombreuses optimisations.

Par exemple, dans le cadre de notre intégration avec Cloudflare, le cache edge enregistre le cache de votre site/page Kinsta dans l’un des 260+ centres de données du réseau mondial de Cloudflare.

Le cache edge est inclus gratuitement dans tous les plans Kinsta, ne nécessite pas d’extension séparée, et réduit le temps nécessaire pour servir le HTML WordPress en cache de plus de 50% en moyenne !

Comment installer W3 Total Cache

Si vous n’avez pas W3 Total Cache installé sur votre site, vous pouvez l’installer directement dans votre tableau de bord WordPress. Il vous suffit de rechercher « W3 Total Cache » sur la page « Ajouter des extensions » et de l’installer.

Il existe également une version Pro de W3 Total Cache, qui peut être achetée sur le site web de BoldGrid. La version Pro est dotée de quelques fonctionnalités supplémentaires comme la mise en cache de l’API REST, la mise en cache de Google Maps et d’autres extensions. Dans cet article, nous utiliserons la version gratuite du dépôt des extensions WordPress.

Où sont placés les réglages de W3 Total Cache ?

Après avoir installé W3 Total Cache, vous verrez un onglet « Performance » dans la colonne latérale de votre tableau de bord d’administration WordPress. En cliquant sur l’onglet « Performance », vous verrez apparaître divers sous-menus comme « Paramètres généraux », « Mise en page du cache », « Minifier », et bien d’autres encore.

Vous pouvez également accéder aux réglages de W3 Total Cache en utilisant l’onglet « Performance » de votre barre d’outils d’administration WordPress.

Comment purger le cache de W3 Total Cache

Avant d’entrer dans la configuration de W3 Total Cache, voyons rapidement comment purger ou vider votre cache. Si vous survolez l’onglet « Performance » dans la barre d’outils de l’administrateur, vous verrez deux options de purge.

1. Purger tous les caches – purgez toutes les caches en même temps.
2. Purger des modules – purge d’un cache individuel (par exemple, actifs minifiés, cache de pages, cache d’objets, etc.)

Réglages généraux de W3 Total Cache

Plongeons dans le menu « Paramètres généraux » de W3 Total Cache pour configurer quelques réglages de base.

Cache de page

Par défaut, chaque demande adressée à votre site WordPress est rendue en temps réel. Pour certains types de sites comme les boutiques de commerce électronique ou les forums de discussion, le rendu dynamique est idéal. Toutefois, pour les blogs, les sites d’information et d’autres sites qui ne nécessitent pas de contenu dynamique, l’ajout d’une couche de mise en cache des pages peut améliorer les performances et réduire la charge du serveur.

Si votre site est hébergé sur Kinsta, vous n’avez pas à vous soucier de la mise en cache des pages. Nous disposons d’une configuration performante au niveau du serveur qui met automatiquement en cache les pages de votre site dans des fichiers HTML statiques. Si votre hébergeur ne propose pas de mise en cache des pages, vous pouvez activer la mise en cache des pages dans l’extension W3 Total Cache.

Minifier

La minification de vos ressources HTML, CSS et JavaScript peut réduire la taille globale des pages de votre site en supprimant les espaces inutiles. Pour la plupart des sites WordPress, il suffit d’activer la fonction « Minifier » de W3 Total Cache et de sélectionner l’option « Auto » pour le « Mode Minify ».

Dans certains cas, la minification des ressources peut provoquer la rupture du code CSS ou JavaScript, ce qui entraîne souvent des erreurs visibles sur l’interface publique. Si vous remarquez des problèmes inhabituels sur votre site après la minification des ressources, nous vous recommandons de travailler avec un développeur pour identifier les ressources qui posent problème. Ensuite, vous pouvez utiliser la fonction « Minifier » en mode manuel, qui vous permet de contourner la minification pour des fichiers CSS et JavaScript spécifiques.

Cache Opcode

WordPress est un CMS dynamique, ce qui signifie que les workers PHP exécutent constamment du code en arrière-plan. Le cache Opcode permet d’accélérer votre site en stockant le code PHP compilé, ce qui rend plus rapides les requêtes ultérieures nécessitant le même code.

Si votre site est hébergé chez Kinsta, vous n’avez pas à vous soucier d’activer une couche de mise en cache opcode dans W3 Total Cache. Nous activons OPcache, un cache opcode, sur tous les environnements en production. OPcache est désactivé sur les environnements de staging pour garantir que le code PHP compilé n’est pas mis en cache et n’interfère pas avec le développement et le débogage du site.

Si votre hébergeur ne propose pas de cache opcode, nous vous recommandons de l’activer dans W3 Total Cache. N’oubliez pas que la fonction de cache opcode n’est disponible que dans la version Pro de W3TC.

Cache de base de données

La base de données de W3TC stocke les résultats des requêtes de la base de données MySQL. Bien que cette fonction semble utile, nous recommandons de la désactiver et d’utiliser plutôt un cache objet.

Nous avons constaté que dans certains cas, la fonction de cache de la base de données peut entraîner une forte utilisation de l’unité centrale. Cela signifie que la quantité de CPU économisée par le stockage des résultats des requêtes de la base de données pourrait être compensée par l’augmentation de la puissance de calcul nécessaire à cette fonction.

Cache objets

Dans le contexte de WordPress, un cache objet stocke les résultats des requêtes effectuées dans la base de données. WordPress possède en fait un cache objet intégré, mais il ne conserve les données que pour un seul chargement de page. Cela permet un rendu plus efficace des pages car cela garantit qu’un chargement de page ne devra pas gaspiller les ressources du CPU en exécutant des requêtes identiques de base de données.

Si le cache objet par défaut de WordPress est sans aucun doute bénéfique pour les performances, un cache objet qui retient les données à travers les chargements de pages est encore mieux ! La fonction « Cache objet » de W3TC ajoute un script de mise en cache personnalisé dans votre répertoire /wp-content, et modifie le comportement du cache objet de WordPress pour conserver les données de manière persistante (sur plusieurs chargements de pages).

Nous vous recommandons d’activer la fonction de cache objet de W3TC sur votre site WordPress afin d’accélérer les requêtes qui utilisent des requêtes de base de données si votre site n’est pas hébergé sur Kinsta.

Si votre site est hébergé chez Kinsta, nous proposons une couche de mise en cache objet très performante, propulsée par notre module Redis. Redis est une structure open source de données en mémoire souvent utilisée pour les applications de base de données et de courtage de messages.

Comme Redis met les données en cache dans la mémoire vive, il permet à WordPress d’accéder aux données mises en cache à partir d’un cache objet persistant, ce qui est beaucoup plus rapide que les configurations de cache objet traditionnelles.

Cache du navigateur

La mise en cache du navigateur peut accélérer considérablement votre site WordPress en stockant localement des ressources statiques telles que CSS, JavaScript, images et polices. La mise en cache du navigateur utilise une période d’expiration pour déterminer la durée de mise en cache des ressources. Sur le web moderne, la plupart des développeurs spécifient une période d’expiration d’un an pour les ressources statiques.

Pour les sites hébergés chez Kinsta, nous appliquons une période de cache d’un an pour les fichiers statiques. Cela peut être vérifié en vérifiant l’en-tête cache-control pour un fichier statique hébergé chez Kinsta. Si votre hébergeur n’impose pas de « délai d’expiration à long terme » pour la mise en cache du navigateur, vous pouvez activer la fonction « Cache navigateur » dans W3 Total Cache et configurer le délai d’expiration.

CDN (Content Delivery Network)

Si vous utilisez un CDN, ou un réseau de diffusion de contenu, pour décharger des fichiers statiques dans des centres de données du monde entier, vous pouvez configurer W3 Total Cache pour réécrire les URL des « fichiers de thèmes », fichiers joints de la médiathèque, CSS, JS » et autres avec votre nom d’hôte CDN.

Si votre site est hébergé chez Kinsta, nous vous recommandons d’utiliser Kinsta CDN, notre réseau de diffusion de contenu à haute performance alimenté par Cloudflare. Lorsque Kinsta CDN est activé, les URLs des fichiers statiques seront automatiquement réécrits pour être servis depuis Kinsta CDN.

Vous avez également accès à d’autres fonctions intégrées, notamment la fonction de minification du code qui permet aux clients de Kinsta d’activer la minification automatique de CSS et JavaScript directement dans le tableau de bord MyKinsta en cliquant sur un bouton.

Si vous préférez utiliser un autre fournisseur de CDN ou si votre site n’est pas hébergé sur Kinsta, vous pouvez activer la fonction « CDN » dans W3 Total Cache et ajouter votre URL de CDN.

Proxy inverse

Un proxy inverse se trouve entre votre serveur web et WordPress, et peut être utilisé pour effectuer diverses manipulations logiques sur les requêtes entrantes. W3TC prend en charge Varnish, qui est un « accélérateur HTTP » très populaire pour la mise en cache et le service de données dans le but de réduire la charge de la zone d’administration.

Pour pouvoir utiliser Varnish, le paquet Varnish doit d’abord être installé par votre hébergeur. Si vous êtes un client Kinsta, n’activez pas l’option de proxy inverse car notre infrastructure n’est pas conçue pour fonctionner avec Varnish.

Expérience utilisateur

L’optimisation de l’ »expérience utilisateur » de W3TC vous permet d’activer le chargement différé, de désactiver les emojis et de désactiver le script wp-embed.js. Nous vous recommandons d’activer le chargement différé sur votre site WordPress pour accélérer le chargement des pages. Si vous n’utilisez pas encore le chargement différé dans votre navigateur ou à l’aide d’une extension, nous vous recommandons d’utiliser W3 Total Cache pour le chargement différé.

Dans le monde d’aujourd’hui, la plupart des systèmes d’exploitation ont une prise en charge intégrée des emojis. Ainsi, vous pouvez désactiver le script emoji inclus dans WordPress si vous n’êtes pas un utilisateur intensif d’emoji. L’utilisation de W3TC pour supprimer wp-emoji-release.min.js vous aidera à réduire une requête HTTP et à supprimer ~10KB des chargements de vos pages.

De même, si vous n’intégrez pas les articles WordPress, vous pouvez désactiver wp-embed.js avec W3 Total Cache. La désactivation de ce script n’affectera pas la fonctionnalité oEmbed pour l’intégration de vidéos YouTube, de flux SoundCloud, etc.

Divers

W3 Total Cache dispose de quelques réglages divers que vous pouvez également configurer. Si vous souhaitez afficher un widget Google Page Speed dans WordPress, vous pouvez saisir votre clé API Page Speed. Il existe également une option permettant d’afficher le classement de la vitesse des pages dans la barre de menu pour chaque page de votre site WordPress.

Pour les autres réglages comme « chemin d’accès au fichier de configuration du serveur NGINX », « activer le verrouillage des fichiers », « optimiser la page améliorée du disque et minifier la mise en cache du disque pour NFS », nous recommandons de les laisser dans leurs réglages par défaut, à moins que vous n’ayez une raison particulière de les modifier.

Déboguage

Si vous rencontrez un problème sur votre site, W3 Total Cache dispose d’un menu « Déboguage » pratique qui vous permet de désactiver des couches de cache et des réglages d’optimisation spécifiques. Par exemple, si vous remarquez un problème visuel sur votre site, vous pouvez activer le mode de débogage pour l’option « Minifier », qui insérera des commentaires HTML dans le code source de votre page pour vous aider à résoudre le problème.

Comme la fonction de débogage alourdit la charge de vos ressources serveur, nous vous recommandons de ne l’utiliser que dans un environnement de staging ou pendant les heures de faible trafic. En outre, assurez-vous de désactiver le mode de débogage une fois que vous avez terminé votre dépannage !

Importer / exporter les réglages

Une fois que vous avez terminé la configuration de vos réglages, vous pouvez utiliser la fonction « Importer / Exporter » de W3TC pour créer une sauvegarde de votre configuration. W3 Total Cache possède un grand nombre de réglages, donc être capable d’exporter une sauvegarde complète est un excellent moyen de garder l’esprit tranquille. De plus, il vous permet de reproduire facilement votre configuration personnalisée de W3TC sur plusieurs sites sans avoir à configurer manuellement quoi que ce soit.

Réglages de W3 Total Cache – Cache de page

Plongeons dans les réglages de « Cache de page » de W3 Total Cache. N’oubliez pas que si votre site est hébergé chez Kinsta, vous n’avez pas à vous soucier de la mise en cache des pages – alors n’hésitez pas à passer cette section.

• Cache de page d’accueil – Pour la plupart des sites, la page d’accueil est généralement celle qui reçoit le plus de trafic. Nous recommandons donc d’activer ce réglage.
• Cache des flux – WordPress génère divers flux RSS, qui permettent à des applications et services externes comme Feedburner d’afficher le contenu de votre site. Bien que le RSS ne soit plus aussi populaire qu’autrefois, nous vous recommandons d’activer ce réglage.
• Cache SSL (requêtes HTTPS) – Si votre serveur web ne force pas le HTTPS pour toutes les requêtes entrantes, l’activation de ce réglage peut avoir un impact positif sur les performances. Si vous forcez déjà le HTTPS au niveau du serveur web, il n’est pas nécessaire de l’activer.
• Cache des URI avec des variables de chaîne de requête – Une chaîne de requête est un paramètre qui est ajouté à la fin de l’URL (par exemple /?version=123). Les chaînes de requête sont souvent utilisées pour demander et afficher des données spécifiques de votre base de données WordPress. En général, l’objectif d’une chaîne de requête est de demander une version unique d’une page, c’est pourquoi nous vous recommandons de la désactiver, sauf si vous avez des chaînes de requête spécifiques que vous souhaitez mettre en cache.
• Cache de pages 404 (Non trouvé) – Par défaut, W3TC maintient cette option désactivée. La raison est probablement due au comportement de la mise en cache si vous utilisez la méthode de mise en cache des pages « Disk Enhanced ». Lorsque cette option est sélectionnée, les pages 404 renvoient un code de réponse 200. Idéalement, les pages 404 devraient renvoyer des codes de réponse 404. Nous vous recommandons donc de tester ce réglage avec votre configuration de mise en cache pour voir s’il est compatible.
• Ne pas mettre en cache les pages pour les utilisateurs connectés – Nous recommandons d’activer cette option. Les utilisateurs connectés travaillent généralement à la mise à jour des pages. Si la mise en cache est activée, les utilisateurs devront vider le cache en permanence pour voir les mises à jour des pages.
• Ne pas mettre en cache les pages pour certains rôles utilisateur – Cette option vous permet de contourner le cache pour certains rôles utilisateur WordPress. Si l’option « Ne pas mettre en cache les pages pour les utilisateurs connectés » est déjà activée, cette option n’aura aucun effet sur le comportement du cache.

Alias

La fonction « Alias » de W3 Total Cache vous permet de mettre en cache du contenu WordPres identique disponible sur différents domaines. Nous vous recommandons de ne pas activer cette fonction. Si votre site WordPress est accessible sur différents domaines (par exemple, domain.com et www.domain.com), il est préférable de mettre en place une règle de redirection 301 pour rediriger les requêtes vers votre domaine principal afin d’éviter les pénalités de contenu dupliqué de Google et d’autres moteurs de recherche.

Préchargement du cache

La fonction « Préchargement du cache » parcourt votre plan de site et demande aux pages de votre site de précharger le cache des pages. Pour la plupart des sites, nous recommandons de désactiver le préchargement du cache car il peut entraîner des pics de ressources du serveur qui annulent les avantages potentiels en termes de performances.

Si vous souhaitez activer le préchargement du cache, W3TC vous permet de spécifier une URL de plan du site, un intervalle de mise à jour et des pages par intervalle. Veillez à ne pas définir « l’intervalle de mise à jour » et « les pages par intervalle » trop haut pour réduire le risque de pics de CPU.

Politique de purge

La « Politique de purge » de W3TC vous permet de spécifier les pages et les flux que vous souhaitez purger automatiquement après la publication ou la modification des publications. Pour la plupart des sites, les réglages par défaut (page d’accueil, page des articles et flux de blog) devraient suffire. Si vous souhaitez ajouter des pages supplémentaires à la politique de purge, vous pouvez configurer diverses options.

API REST

L’API REST incluse dans WordPress vous permet d’interroger les données au format JSON. L’API REST est utilisée par une variété d’extensions, et est cruciale pour les configurations headless de WordPress. En fonction de votre cas d’utilisation exact de l’API REST, la mise en cache des résultats de la requête peut être une bonne idée. La mise en cache de l’API REST fait partie de la catégorie « si vous en avez besoin, vous le saurez », donc si vous n’êtes pas sûr d’activer ou non la mise en cache de l’API REST, nous vous recommandons de la laisser sur « Ne pas mettre en cache ».

Avancé

Dans les options « Avancé » de cache de page de W3TC, vous pouvez personnaliser divers réglages, notamment les « chaînes de requête acceptées », les « agents utilisateurs rejetés », les réglages de contournement du cache granulaire, et bien d’autres encore. Par exemple, si vous devez configurer votre W3 Total Cache pour ne jamais mettre en cache les articles dans une certaine catégorie ou étiquette, vous pourrez le faire dans les options « Avancées ».

Comme ces réglages peuvent être très spécifiques à un site, nous ne pouvons pas fournir de « réglage recommandé ». Cela étant dit, si vous cherchez à personnaliser un aspect très spécifique du comportement de mise en cache des pages de votre site, il est certain que vous devrez jeter un coup d’œil aux options avancées.

Réglages de W3 Total Cache – Minifier

Ensuite, passons en revue les réglages « Minifier » de W3 Total Cache.

• Réécrire la structure d’URL – Ce réglage affecte la structure d’URL des ressources minifiées. Nous vous recommandons de le laisser activé pour que vos URL soient « jolies ».
• Désactiver la minification pour les utilisateurs connectés – Si vous effectuez un dépannage ou un débogage, il peut être utile de désactiver la minification pour les utilisateurs connectés. Sinon, nous vous recommandons de garder cette option désactivée.

HTML & XML

Dans la section « HTML & XML », vous pouvez configurer les réglages de minification HTML.

• Minifier le CSS en ligne – Nous recommandons d’activer cette option pour supprimer les espaces dans les CSS en ligne.
• Minifier le JS en ligne – Nous recommandons d’activer cette option pour supprimer les espaces dans le JavaScript en ligne. Dans certains cas, la minification JS peut entraîner une erreur de code. Si l’activation de cette option interrompt la fonctionnalité de votre site, désactivez-la.
• Ne pas minifier les flux – Nous recommandons de ne pas désactiver cette option. Les flux ne sont utilisés que par les lecteurs RSS et autres services similaires, il n’est donc pas nécessaire de les minifier.
• Suppression des sauts de ligne – Cette option est désactivée par défaut, et nous ne recommandons pas de l’activer pour garantir un rendu correct de votre site.

JS

Dans la section « JS », vous pouvez configurer les réglages de minification JavaScript.

• Opérations dans les zones – Cette option vous permet de sélectionner le « type d’intégration » pour le JavaScript minifié. Pour les fichiers JS avant </head> et après <body>,vous pouvez choisir entre « bloquant », « non-bloquant », « non-bloquant par async » et « non-bloquant par defer ». Si les méthodes de chargement non bloquantes offrent généralement de meilleures performances, elles ne sont pas toujours compatibles à 100 % avec tout le code JavaScript. De plus, les cas d’utilisation de « async » et « defer » sont très différents. Nous recommandons donc d’utiliser la méthode « bloquant » par défaut, à moins que vous ne soyez conscient des bizarreries du JavaScript non bloquant.
• Minifier ou combiner uniquement – Vous pouvez choisir entre deux modes d’optimisation pour JavaScript. Lorsque « Minifier » est sélectionné, vos fichiers JS seront combinés et minifiés. Si vous sélectionnez « Combiner uniquement », le fichier JS combiné qui en résulte ne sera pas minifié. Si vous rencontrez des problèmes liés à la minification et que vous ne souhaitez pas déboguer pour trouver quel script est à l’origine du problème, la sélection de l’option « Combiner uniquement » peut corriger l’erreur.
• HTTP/2 Push – Si votre serveur supporte le HTTP/2 Server Push, l’activation de cette option peut vous aider à réduire le temps de chargement des pages. La fonction HTTP/2 Server Push permet de pousser les fichiers vers les visiteurs avant qu’ils ne soient demandés. Nous vous recommandons de faire des tests adéquats avant d’activer cette option dans un environnement de production, car le Server Push est souvent utilisé à mauvais escient. Le Server Push n’est pas idéal pour les fichiers JavaScript plus volumineux, et vous voudrez vous assurer que les avantages l’emportent sur le chargement de fichiers JS directement à partir du cache du navigateur du visiteur.

CSS

Dans la section « CSS », vous pouvez configurer les réglages de minification CSS.

• Combiner uniquement – Contrairement aux fichiers JavaScript, le CSS ne souffre généralement pas de problèmes liés à la minification. Nous ne recommandons donc pas d’activer la fonction « Combiner uniquement ».
• Suppression des commentaires préservés – Ce réglage permet de supprimer les commentaires des fichiers CSS. Nous recommandons d’activer cette option pour réduire la taille des fichiers autant que possible.
• Suppression des sauts de ligne – Ce réglage supprime les sauts de ligne des fichiers CSS. Nous vous recommandons d’activer cette option également. Si vous remarquez des problèmes d’affichage après avoir activé « Suppression des sauts de ligne », désactivez cette option.

Avancé

La section « Avancé » contient quelques réglages supplémentaires permettant de personnaliser le comportement de la minification.

• Mise à jour des fichiers externes chaque – W3TC vous permet de spécifier le temps entre les mises à jour des fichiers CSS et JS. Avec le réglage par défaut de 86400 secondes, vos ressources seront téléchargées et minifiées toutes les 24 heures. Si votre site ne change pas fréquemment, n’hésitez pas à fixer une période plus longue.
• Intervalle de collecte des déchets – Ce réglage de temps spécifie la fréquence à laquelle les données du cache expirées sont supprimées. Le réglage par défaut est de 24 heures. Si votre site manque d’espace de stockage, nous vous recommandons de réduire l’ »Intervalle de collecte des déchets ».

Le reste de la section « Avancé » comprend des champs de saisie qui vous permettent de spécifier des fichiers de ressources qui ne doivent jamais être minifiés. Il y a également un champ « Agents utilisateurs rejetés » qui permet de servir des fichiers non minifiés à certains agents utilisateurs. Enfin, vous pouvez ajouter des fichiers de ressources externes à inclure dans le processus de minification de W3 Total Cache.

Réglages de W3 Total Cache – Cache objet

Le prochain point de la liste est le paramétrage du « cache objet » de W3TC. Pour la plupart des sites, les réglages par défaut fonctionneront parfaitement, mais nous allons les passer en revue.

• Durée de vie par défaut du cache objet – La durée d’expiration des éléments inchangés du cache objet. Une période plus longue se traduit par un cache objet plus important. Si vous êtes préoccupé par la capacité de stockage de votre serveur, nous vous recommandons de conserver la valeur par défaut ou de la réduire.
• Intervalle de collecte des déchets – Ce réglage indique la fréquence à laquelle les données du cache expirées sont détruites. La valeur par défaut de 3 600 secondes (1 heure) devrait suffire pour la plupart des sites.
• Groupes globaux – Ce réglage vous permet de configurer des groupes de mise en cache partagés entre les sites d’un même réseau multisite. Nous vous recommandons de laisser ce réglage dans son état par défaut, sauf si vous avez une raison particulière de le modifier.
• Groupes non persistants – Ce réglage vous permet de sélectionner les groupes d’objets à ne jamais mettre en cache. Là encore, nous vous recommandons de conserver la configuration par défaut.
• Activer la mise en cache pour les requêtes wp-admin – Cette option est désactivée par défaut, et nous ne recommandons pas de l’activer car elle peut entraîner des effets secondaires. De plus, les visiteurs de la plupart des sites WordPress n’interagissent jamais avec le tableau de bord wp-admin.

Réglages de W3 Total Cache – Cache du navigateur

La plupart des hébergeurs WordPress, y compris Kinsta, mettent déjà en œuvre des en-têtes de cache de navigateur appropriés au niveau du serveur web. Si votre hébergeur ne le fait pas, ou si vous souhaitez personnaliser davantage le comportement de la mise en cache du navigateur, vous pouvez le faire avec W3 Total Cache.

Dans les réglages du « Cache du navigateur », les réglages par défaut des sections « Général », « CSS & JS », et « HTML & XML » et « Média et autres fichiers » sont adéquats pour la plupart des sites WordPress. Comme il y a beaucoup de réglages sur cette page, nous recommandons de consulter un développeur avant de modifier le comportement du cache du navigateur. Cela dit, vous trouverez ci-dessous quelques réglages clés à prendre en compte en ce qui concerne la mise en cache du navigateur.

• Durée de vie des en-têtes – La configuration d’une longue « durée de vie des en-têtes » est importante pour une mise en cache efficace du navigateur. Chez Kinsta, nous imposons une durée de vie d’un an pour les ressources statiques comme les CSS, JS, les images et les polices. Si vous utilisez W3TC pour configurer la mise en cache du navigateur, assurez-vous de définir cette valeur à 31536000 (1 an).
• Politique de contrôle du cache – Pour garantir que vos ressources statiques puissent être mises en cache par les navigateurs, assurez-vous que la « politique de contrôle du cache » est définie sur « public, max_age=EXPIRES SECONDS ».
• Activer la compression HTTP (gzip) – La compression GZIP réduit considérablement la taille des fichiers des pages HTML et des ressources avant qu’ils ne soient envoyés aux visiteurs. Assurez-vous d’activer cette option si la configuration du serveur de votre hébergeur prend en charge GZIP. Si votre site est hébergé chez Kinsta, il n’est pas nécessaire d’activer la compression GZIP dans W3TC car elle est déjà activée dans notre configuration par défaut.
• Supprimer les chaînes de requête des ressources statiques – Une chaîne de requête est une chaîne supplémentaire qui est ajoutée à la fin d’un chemin d’URL pour spécifier les paramètres de la requête ou forcer un serveur web à fournir une nouvelle ressource. Les chaînes de requête commencent par un ? et la plupart des serveurs web sont configurés pour contourner le cache pour les requêtes comportant des chaînes de requête. La suppression des chaînes de requête des requêtes de pages est utile pour réduire la charge du serveur car ces requêtes utilisent PHP pour le rendu des pages. Nous ne recommandons pas de supprimer les chaînes de requête des ressources statiques dans W3 Total Cache, car cela permet de s’assurer que la dernière version des fichiers CSS et JS est fournie à vos visiteurs.

La page de configuration du « cache du navigateur » contient également une variété de réglages liés aux en-têtes de sécurité comme la politique de sécurité du contenu (CSP) et la protection X-XSS. Nous recommandons toujours de travailler avec un développeur qualifié pour passer en revue ces réglages, car des configurations incorrectes peuvent avoir un impact direct sur l’expérience utilisateur de votre site. Par exemple, l’activation de l’en-tête HSTS sans un certificat SSL et une configuration HTTPS appropriés peut rendre votre site inaccessible.

Réglages de W3 Total Cache – Groupes d’agents utilisateurs

La fonction « Groupes d’agents utilisateurs » de W3 Total Cache est très puissante si vous avez besoin de rediriger le trafic en fonction du type d’appareil d’un utilisateur. Par exemple, vous pouvez configurer votre site pour qu’il soit rendu avec un thème différent si un utilisateur visite votre site depuis un téléphone portable. De même, vous pouvez rediriger les utilisateurs vers un site complètement différent si votre site mobile vit sur un sous-domaine unique.

À l’ère de la conception de sites web adaptatifs, nous ne voyons pas trop de cas d’utilisation de cette fonctionnalité particulière. Aujourd’hui, la meilleure pratique consiste à rendre votre site adaptatif dès le départ au lieu de s’appuyer sur plusieurs thèmes ou un sous-domaine réservé aux mobiles.

Réglages de W3 Total Cache – Groupes de référent

Un référent HTTP est un en-tête HTTP facultatif qui fournit des informations sur l’origine d’une requête. Par exemple, si un visiteur clique sur votre site à partir d’une liste de recherche Google, le référent HTTP sera google.com.

Dans W3 Total Cache, vous pouvez définir un comportement de mise en cache personnalisé basé sur le référent HTTP d’une requête avec « Groupes de référents ». Par exemple, vous pouvez créer un groupe de référence composé de moteurs de recherche et personnaliser le comportement de la mise en cache pour les requêtes provenant de ces seuls domaines.

Comme pour les « groupes d’agent utilisateur » mentionnés ci-dessus, vous pouvez également rediriger les requêtes vers un autre domaine grâce à la fonction « Groupes de référents ». La plupart des sites WordPress n’ont pas besoin de mettre en place des groupes de référents, nous ne recommandons donc pas d’en configurer.

Réglages de W3 Total Cache – Groupes de cookies

Le dernier groupe de mise en cache pris en charge par W3 Total Cache est le « Groupe de cookies » . Cette fonctionnalité vous permet de créer des groupes de mise en cache et des comportements uniques basés sur les cookies d’une requête. Comme pour les « Groupes d’agents utilisateurs » et les « Groupes de référents », la plupart des sites n’auront pas besoin de mettre en place une configuration de mise en cache personnalisée basée sur les cookies. Si votre site nécessite une mise en cache basée sur des cookies, nous vous recommandons de travailler avec un développeur pour le configurer correctement.

Réglages de W3 Total Cache – CDN

Passons maintenant aux réglages CDN de W3 Total Cache.

• Fichiers joints de l’hôte – Activez cette option pour servir des ressources dans votre médiathèque WordPress à partir de votre CDN.
• Hôte des fichiers wp-includes/ – Activez cette option pour servir des fichiers dans le dossier wp-includes depuis votre CDN.
• Hôte des fichiers du thème – Activez cette option pour servir vos fichiers de thème depuis votre CDN.
• Hôte des fichiers CSS et JS minifiés – Activez cette option pour servir les fichiers CSS et JS minifiés de W3TC depuis votre CDN.
• Hôte des fichiers personnalisés – Si vous avez des fichiers qui ne se trouvent pas dans votre médiathèque ou votre dossier de thème, vous pouvez ajouter les chemins d’accès aux fichiers dans W3TC pour les servir depuis votre CDN.
• Ajouter un en-tête canonique – Une balise rel="canonical" aide les moteurs de recherche à identifier la source ou l’URL d’origine. Étant donné que les CDNs utilisent généralement un domaine différent, l’ajout d’une balise canonique informe les moteurs de recherche de l’emplacement de la ressource originale. Cela dit, il n’y a pas de problème à désactiver ce réglage car les moteurs de recherche modernes sont suffisamment intelligents pour identifier les CDNs sans affecter le classement SEO de votre site.

Avancé

• Purger le CDN uniquement manuellement – Nous recommandons de garder cette option désactivée pour permettre à W3TC de gérer les purges de cache automatiquement.
• Désactiver le CDN sur les pages SSL – Laissez ce réglage désactivé. Si vous utilisez un CDN, il est préférable qu’il soit actif sur les pages HTTP et HTTPS.
• Utiliser les liens CDN pour la médiathèque sur les pages d’administration – Nous ne recommandons pas d’activer cette option car elle réécrira les URLs dans votre médiathèque.
• Ajouter l’en-tête CORS – Laissez ce réglage activé pour permettre à vos ressources CDN d’être affichées sur d’autres domaines.
• Désactiver le CDN pour les rôles suivants – Cette option vous permet de désactiver le CDN pour certains rôles d’utilisateur WordPress. Dans la plupart des cas, il est préférable de garder cette option désactivée.
• Type de fichiers à téléverser dans wp-includes – Ce champ spécifie les formats de fichiers dans wp-includes qui seront servis depuis votre CDN. La liste des formats de fichiers par défaut devrait convenir à la plupart des sites. Si vous avez des fichiers personnalisés dans votre dossier wp-includes, n’hésitez pas à ajouter des formats supplémentaires si nécessaire.
• Types de fichiers de thème à téléverser – Ce champ indique les formats de fichiers dans votre dossier de thème WordPress qui seront servis depuis votre CDN. La liste par défaut contient tous les formats de ressources, d’images et de polices les plus courants. N’hésitez pas à ajouter des formats supplémentaires si nécessaire.
• Liste de fichiers personnalisés – Si vous avez activé « Héberger des fichiers personnalisés », vous pouvez ajouter une liste de fichiers dans ce champ pour les servir depuis votre CDN.
• Agents utilisateurs rejetés – Ce champ vous permet de spécifier les agents utilisateurs qui ne seront pas desservis depuis votre CDN. Nous vous recommandons de laisser ce champ vide pour vous assurer que votre CDN est utilisé correctement.
• Fichiers rejetés – Ce champ vous permet de spécifier les fichiers qui ne doivent pas être servis depuis votre CDN. Si un service que vous utilisez exige que les fichiers soient servis à partir de votre domaine racine, vous pouvez ajouter le chemin d’accès au champ « Fichiers rejetés ».

Réglages de W3 Total Cache – Expérience utilisateur

Ensuite, personnalisons les réglages de l’ »expérience utilisateur », ou chargement différé, dans W3 Total Cache.

• Traiter les balises d’image HTML – Activez cette option pour vous assurer que les images sont chargées en différé.
• Traiter les images en arrière-plan – Si vous utilisez « l’arrière-plan » pour afficher une image en CSS, l’activation de cette option permettra à ces images d’être chargées en différé.
• Mots exclus – Dans ce champ, vous pouvez spécifier du texte pour contourner le chargement différé. Par exemple, si vous ajoutez  no-lazy-load à ce champ, une image affichée avec <img src="image.jpg"> ne sera pas chargée en différé.
• Méthode d’intégration de script – Ce réglage vous permet de personnaliser la méthode de chargement pour le script de chargement différé. La méthode async par défaut est la meilleure option pour la plupart des sites. Si votre site ne consiste qu’en une seule page d’atterrissage, la méthode inline peut être utilisée pour réduire le nombre de requêtes HTTP pour charger la page.

Extensions disponibles pour W3 Total Cache

W3 Total Cache offre diverses extensions pour s’intégrer à des services tiers. W3TC dispose actuellement d’extensions pour les services suivants.

• AMP
• Cloudflare
• Google Feedburner
• Fragment Cache
• Genesis Framework
• New Relic
• Swarmify
• Yoast SEO
• WPML

Si vous utilisez l’un de ces services sur votre site, nous vous recommandons de mettre en place l’extension appropriée pour assurer une bonne compatibilité avec W3 Total Cache. Dans cette section, nous allons examiner l’extension Cloudflare pour W3 Total Cache.

Comment configurer W3 Total Cache avec l’extension Cloudflare

Pour intégrer Cloudflare à W3 Total Cache, vous aurez besoin de deux éléments d’information de votre tableau de bord Cloudflare : l’e-mail du compte et la clé API. L’e-mail du compte est l’e-mail que vous utilisez pour vous connecter à Cloudflare. Voyons comment configurer une clé d’API Cloudflare.

Dans le tableau de bord de Cloudflare, cliquez sur l’onglet « Vue d’ensemble ». Ensuite, faites défiler vers le bas et cliquez sur « Obtenez votre jeton d’API » dans la colonne latérale de droite.

Faites défiler vers le bas et cliquez sur Voir à côté de « Clé API globale » pour obtenir votre clé API Cloudflare. Veillez à ne pas partager cette clé API en dehors de W3 Total Cache, car elle peut être utilisée pour contrôler votre compte Cloudflare.

Ensuite, activez l’extension Cloudflare dans la page « Extensions » de W3 Total Cache et cliquez sur « Réglages ». Dans la section « Informations », cliquez sur le bouton Autoriser.

Dans la fenêtre contextuelle suivante, saisissez l’e-mail de votre compte Cloudflare et la clé API. Si vous recevez un message d’erreur, vérifiez que votre e-mail et votre clé API sont correctes. Une fois les informations d’identification autorisées, vous devriez voir des réglages Cloudflare supplémentaires sur la page.

Passons en revue les réglages de Cloudflare dans W3 Total Cache.

• Intervalle du widget des statistiques – Ceci spécifie la période couverte par le widget Cloudflare de W3TC. Le réglage par défaut est de 30 minutes. Si vous souhaitez une période plus longue, n’hésitez pas à l’augmenter.
• Temps de mise en cache – Il s’agit de la durée pendant laquelle les données des widgets de Cloudflare sont mises en cache. Si vous ne prévoyez pas d’utiliser beaucoup le widget, nous vous recommandons d’augmenter ce nombre afin de réduire le nombre de requêtes adressées à Cloudflare depuis votre site.
• Mise en cache de page – Si vous avez configuré Cloudflare pour mettre en cache les pages HTML de votre site WordPress, activez cette option pour vider automatiquement le cache Cloudflare après les modifications et les mises à jour des publications.

Mise en cache de Cloudflare

Cette section vous permet de personnaliser les réglages de mise en cache de Cloudflare.

• Mode de développement – Maintenez cette option désactivée, sauf si vous devez mettre Cloudflare en mode de développement. Lorsque Cloudflare est en mode de développement, la mise en cache, la minification et l’optimisation d’image sont désactivées pendant trois heures. Cela vous permet de voir immédiatement les mises à jour des fichiers CSS et JS et est utile pour le dépannage.
• Niveau du cache – Pour la plupart des sites, nous recommandons d’utiliser le niveau de cache « Standard », qui sert une ressource différente chaque fois que la chaîne de requête change. Si vous êtes sûr à 100 % que votre site WordPress n’utilise pas de chaînes de requête pour servir du contenu dynamique, vous pouvez également utiliser le réglage « Ignorer la chaîne de requête ».
• TTL du cache navigateur – Nous recommandons de régler le TTL du cache navigateur de Cloudflare sur 31536000 secondes, ce qui équivaut à un an.
• Challenge TTL – Cloudflare offre une variété de services liés à la sécurité, et les défis pour les visiteurs en font partie. Si Cloudflare détecte un utilisateur malveillant ou un comportement étrange, il enverra un message de défi sous la forme d’un Captcha. Le réglage « Challenge TTL » précise la durée pendant laquelle un utilisateur aura accès à votre site après avoir répondu à un défi. Avec le réglage par défaut de 3600 secondes, un visiteur qui a fait l’objet d’un défi pourra utiliser votre site pendant 1 heure avant un autre défi.
• Edge Cache TTL – Ce réglage contrôle la durée de mise en cache des ressources sur les serveurs edge de Cloudflare. Nous recommandons de configurer ce réglage sur la valeur maximale de 31536000 secondes, soit 1 an.

Traitement du contenu Cloudflare

Plongeons dans les réglages de traitement du contenu de Cloudflare dans W3 Total Cache.

• Rocket Loader – Le Rocket Loader de Cloudflare accélère le chargement de JavaScript pour votre site WordPress. Nous vous recommandons d’activer Rocket Loader si votre site comporte beaucoup de JS.
• Minification JS/CSS/HTML – Si vous avez déjà activé la minification pour HTML, CSS et JavaScript dans W3 Total Cache, n’hésitez pas à laisser ces options désactivées dans les réglages de l’extension Cloudflare, car il n’est pas nécessaire de minifier les ressources qui ont déjà été minifiées.
• Exclusion côté serveur (SSE) – Cette option vous permet de masquer des informations sensibles aux visiteurs suspects (jugés par Cloudflare). Les exclusions côté serveur sont utiles pour masquer des informations telles que l’e-mail, les numéros de téléphone et d’autres informations personnelles sur votre site. Pour utiliser SSE, activez cette option et insérez des informations sensibles dans les balises <!--sse--><!--/sse--> de votre code HTML ou de votre modèle de thème PHP.
• Obfuscation des e-mails – Lorsque cette option est activée, Cloudflare obfusquera automatiquement les adresses e-mails de votre site WordPress avec JavaScript. Bien que l’obsfusquation n’élimine pas complètement le spam, nous recommandons d’activer cette option car elle dissuade les robots de base de récupérer les adresses e-mail de votre site.

Traitement d’images de Cloudflare

Passons en revue les réglages de traitement d’image de Cloudflare.

• Protection des liens dynamiques (hotlink) – L’activation de la protection des liens dynamiques empêchera d’autres sites d’intégrer vos images. Si vous êtes confronté à des limites de bande passante en raison d’incorporations externes non autorisées, l’activation de la « protection contre les dynamiques » peut vous aider à réduire l’utilisation de la bande passante.
• Mirage (Pro Only) – Mirage optimise la transmission des images vers les appareils et les réseaux à faible bande passante. Cette fonction n’est disponible que sur le plan Cloudflare Pro et au-delà.
• Polish (Pro uniquement) – Polish optimise les images de votre site et peut être configuré pour servir des images WEBP aux navigateurs les prenant en charge. Cette fonction n’est disponible que sur le plan Cloudflare Pro et au-delà.

Protection Cloudflare

La principale caractéristique de Cloudflare est un pare-feu sophistiqué qui peut vous aider à vous protéger contre les attaques DDoS et les acteurs malveillants. Passons en revue les réglages de sécurité de Cloudflare.

• Niveau de sécurité – Ce réglage contrôle la sensibilité du pare-feu et des règles de sécurité de Cloudflare. Nous recommandons de régler le « Niveau de sécurité » sur « Moyen » pour la plupart des sites.
• Contrôle d’intégrité du navigateur – Cette fonction permet de détecter les mauvais comportements et les agents utilisateurs suspects. Si elle détecte un utilisateur ou un spammeur potentiellement malveillant, Cloudflare relève automatiquement le défi. Nous vous recommandons d’activer cette fonction.
• Toujours en ligne – Cette option servira les pages HTML statiques de votre site si votre origine baisse. Nous vous recommandons de l’activer si vous avez configuré Cloudflare pour mettre le HTML en cache.
• Pare-feu d’application web – Le WAF de Cloudflare, ou pare-feu d’application web, analyse le trafic entrant et filtre le « trafic illégitime » pour l’empêcher d’atteindre votre site. Nous vous recommandons d’activer cette fonction.
• Protection DDoS avancée – Cette fonction est activée par défaut et ne peut être désactivée tant que le proxy de Cloudflare est actif. La protection DDoS permet de protéger votre site contre les attaques de type « déni de service distribué ».
• Téléversement maximum – Cette option fixe la taille maximale autorisée des fichiers à téléverser sur votre site. Vous devez vous assurer que ce réglage est égal ou supérieur à celui de la taille de votre fichier téléversé dans WordPress.

SSL Cloudflare

Enfin, vous devez vous assurer que vos réglages de SSL Cloudflare sont correctement configurés. Nous allons passer en revue la bonne configuration dans cette section.

• SSL – Si votre site est hébergé chez Kinsta, nous vous recommandons d’utiliser l’option SSL « Full » ou « Full (Strict) ». L’option « Flexible » n’est pas compatible avec notre infrastructure. L’option « Full Strict » nécessite un SSL provenant d’une autorité de certification valide, tandis que l’option « Full » prend également en charge les SSL auto-signés. L’option « Flexible » ne nécessite pas de certificat SSL sur le serveur d’origine – nous ne recommandons pas cette option car elle est la moins sûre.
• TLS 1.2 uniquement – TLS, ou Transport Layer Security, est un protocole sécurisé pour le transfert de données sur un réseau. Certaines normes de conformité PCI exigent l’abandon de la prise en charge de TLS 1.1 et inférieur. Si c’est une exigence pour votre site, vous pouvez activer le réglage « TLS 1.2 Only » dans Cloudflare pour fixer la version minimale de TLS à 1.2.

Lecture suggérée : Comment configurer l’APO de Cloudflare pour WordPress.

Réglages WooCommerce de W3 Total Cache

WooCommerce est la plateforme de commerce électronique la plus populaire pour les sites WordPress. Si vous utilisez W3 Total Cache avec votre boutique WooCommerce, vous devez vous assurer que votre configuration est correcte pour éviter la mise en cache des données des clients.

Contourner les cookies WooCommerce

Pour contourner la mise en cache des pages qui contiennent des cookies spécifiques à WooCommerce, allez dans les réglages de « Mise en cache des pages » de W3TC, faites défiler la page jusqu’à « Cookies rejetés » et ajoutez les quatre éléments ci-dessous.

• woocommerce_items_in_cart
• woocommerce_cart_hash
• wp_woocommerce_session
• wordpress_logged_in

Par mesure de sécurité, nous vous recommandons également de contourner les URLs spécifiques à WooCommerce comme la page du panier, la page de paiement et la page de compte. Pour éviter que ces pages ne soient mises en cache, allez dans les réglages de « mise en cache de page » de W3TC, et ajoutez les URLs à la section « Ne jamais mettre en cache les pages suivantes ».

Comment réinitialiser tous les réglages dans W3 Total Cache

Dans certains cas, vous devrez peut-être recommencer avec votre configuration W3TC. Voici comment rétablir les réglages par défaut de W3 Total Cache. Allez dans le menu « Paramètres généraux » de W3TC, faites défiler vers le bas jusqu’à la section « Importer / Exporter les paramètres », et cliquez sur « Restaurer les paramètres par défaut ».

Résumé

Comme vous pouvez le voir, l’extension W3 Total Cache est bourrée de fonctionnalités et de réglages. De la mise en cache des pages à la minification des ressources, en passant par l’intégration de Cloudflare, W3TC a tout ce dont vous avez besoin pour améliorer les performances de votre site WordPress !

Dans cet article, nous avons passé en revue la configuration recommandée pour l’extension W3TC. Avez-vous une extension d’optimisation WordPress préférée ? Faites-le nous savoir dans les commentaires ci-dessous !