Comment accélérer un site WordPress : guide pratique

Comment accélérer un site WordPress : mesurez d'abord, puis intervenez en ordre de rentabilité. L'ordre vaut pour WordPress 6.5 et ultérieur : temps de réponse serveur et cache de page, puis l'image héroïque volumineux, puis les CSS et JavaScript bloquants, enfin la base de données et la pile de plugins. La plupart des sites lents souffrent de deux ou trois de ces problèmes, pas tous.

Lancez PageSpeed Insights sur votre modèle le plus exigeant, notez l'élément Largest Contentful Paint, et suivez cette liste jusqu'à ce que le nombre passe au vert.

Établissez une ligne de base, sinon vous optimiserez la mauvaise chose

Optimiser sans mesure, c'est de la superstition. Avant de toucher à un plugin, relevez trois chiffres sur votre modèle réel le plus chargé (généralement un article avec image héroïque, ou une page produit WooCommerce) : Largest Contentful Paint, Interaction to Next Paint et Time to First Byte. Testez en configuration mobile, car c'est là que s'éclaire la distance entre « rapide sur ma machine » et « rapide pour les clients de votre client ».

Les objectifs sont publiés, ce ne sont pas des légendes. La documentation Google web.dev sur le LCP fixe 2,5 secondes ou moins comme bon au 75e centile des visites réelles. L'INP doit rester sous 200 millisecondes et le décalage de mise en page sous 0,1. Écrivez ces chiffres sur un post-it à côté de votre écran.

Les outils de labo comme Lighthouse vous offrent un banc reproductible. Les données de terrain du Chrome User Experience Report, affichées en haut de PageSpeed Insights, vous disent ce que les visiteurs ont réellement obtenu. Quand les deux divergent, fiez-vous aux données réelles et utilisez le passage en labo pour identifier la cause.

Marginalia : cet ordre de travail vaut pour WordPress 6.5 et ultérieur. Les installations antérieures ont plus à corriger avant que tout cela n'ait importance.

Réglez d'abord le serveur : hébergement, PHP et Time to First Byte

Chaque optimisation frontale repose sur la première réponse. Si l'HTML demande 1,5 secondes pour arriver, aucune compression d'image ne sauve votre LCP. Le Time to First Byte démasque un hébergeur faible, une branche PHP obsolète ou une page qui se reconstruit entièrement à chaque requête.

Vérifiez trois choses dans cet ordre. Exécutez une branche PHP actuellement soutenue, car chaque version coûte mesurément moins par requête que la précédente. Vérifiez que l'hébergeur offre un cache d'objets persistant (Redis ou Memcached), car il supprime les lectures répétées de la base pour les options, menus et requêtes. Et regardez le plan lui-même : un serveur partagé avec cent voisins vous limitera au moment précis où le trafic monte.

Si vous gérez de nombreux sites clients, c'est ici que l'hébergement géré gagne son prix. Une plateforme qui regroupe hébergement, cache et cible de performance élimine toute une catégorie de doute. 10Web en est un exemple, hébergeant WordPress sur Google Cloud avec pour objectif un score PageSpeed de 90+ d'emblée, ce qui est un bon défaut pour une petite agence sans personne dédiée aux opérations.

Résistez à la tentation d'acheter un plan plus grand avant d'avoir activé le cache. Augmenter le matériel pour servir des pages non cachées, c'est payer plus pour faire le même travail gaspilleur plus vite.

Activez le cache de page entière et vérifiez qu'il se déclenche réellement

WordPress compile chaque page en PHP et MySQL à chaque fois qu'on la demande. Un cache de page sauvegarde le HTML terminé et sert ce fichier à la place. Pour un site surtout consulté comme un blog, un site vitrine ou un portfolio, ce seul changement pousse souvent le TTFB de plusieurs secondes à des dizaines de millisecondes.

Choisissez une couche de cache de page et une seule. Empiler un cache au niveau de l'hébergeur, un plugin de cache et un cache CDN sans savoir lequel sert la requête, c'est comment vous finirez par déboguer du contenu rassis pendant un après-midi entier. Demandez à votre hébergeur ce qu'il fournit déjà avant d'installer n'importe quoi.

Ensuite vérifiez que le cache se déclenche. Ouvrez le panneau réseau du navigateur, rechargez une page publique deux fois, et lisez les en-têtes de réponse. La plupart des caches annoncent un accès ou un manque, et beaucoup ajoutent une valeur d'âge. Si vous ne voyez jamais que des manques, votre cache est contourné par un cookie, une chaîne de requête ou un état connecté, et « l'optimisation » n'est que façade.

Les boutiques exigent un soin particulier. Les pages panier, paiement et compte ne doivent jamais être cachées, et les sites WooCommerce dépendent généralement d'un plugin de cache qui connaît ces exclusions. Mal configurer les exclusions et les clients voient les paniers les uns des autres, ce qui pose bien pire problème qu'une page lente.

Réduisez l'image héroïque, la cause LCP habituelle

Sur la plupart des pages WordPress lentes, l'élément LCP est une image : un héroïque, une image d'en-tête ou une bannière pleine largeur. Cela fait du poids de l'image la cause unique la plus courante d'un score défaillant. Un JPEG 4000 pixels de large exporté droit du boîtier d'une caméra, affiché dans une colonne 1200 pixels, expédie plusieurs fois plus d'octets que le calque peut en utiliser.

Parcourez le pipeline d'image dans cet ordre :

• Redimensionnez à la plus grande taille que le calque affiche réellement, pas la taille que le designer a exportée.

• Servez WebP ou AVIF, que le noyau WordPress gère depuis plusieurs releases.

• Laissez le noyau générer les variantes srcset réactives au lieu de coder en dur un seul gros fichier.

• Ne lazy-loadez pas l'héroïque. Depuis WordPress 6.3, le noyau a sauté le lazy loading sur la première image de contenu et ajouté fetchpriority="high" à celle-ci, vérifiez donc que votre thème ou plugin n'a pas défait cela.

• Donnez à chaque image une largeur et une hauteur explicites pour que le navigateur réserve de l'espace et le décalage de mise en page reste près de zéro.

Sous la pli, lazy load est correct et gratuit. Au-dessus de la pli, c'est un délai auto-infligé, et c'est l'erreur qui ressort le plus souvent après que quelqu'un installe un plugin « lazy load partout ».

Pour l'e-commerce, le poids provient souvent de la photographie produit. Produire des visuels cohérents et de bonne taille dès la source coûte moins que compresser cinquante fichiers surdimensionnés après, et une plateforme de photographie produit IA comme Klayn transforme une photo produit en ensemble de scènes, pour que vous puissiez prévoir les dimensions avant que rien n'arrive à la médiathèque.

Coupez les CSS et JavaScript bloquants à la source

Une fois le serveur et l'héroïque classés, le délai suivant est ce que le navigateur doit télécharger et exécuter avant de peindre. Chaque feuille de style dans le head bloque le rendu. Chaque script synchrone bloque l'analyse. Les générateurs de pages et les thèmes polyvalents en sont généralement responsables, car ils expédient styles et scripts pour chaque fonctionnalité, que la page l'utilise ou non.

Les block themes présentent un avantage structurel ici. Le noyau charge les styles pour un bloc seulement quand ce bloc apparaît sur la page, donc un post simple ne paie pas pour la Query Loop ou la Gallery. C'est une raison pour laquelle un thème Full Site Editing maigre démarre en avance sur un thème hérité avec un curseur regroupé et une police d'icônes regroupée. Les générateurs de pages classiques peuvent réduire l'écart, mais seulement si vous désactivez les modules que vous n'utilisez pas.

Divi est un cas d'essai équitable. Divi 5 a été reconstruit sur une architecture plus moderne et expédie des centaines de modules, ce qui est exactement pourquoi ses paramètres de performance, comme le CSS dynamique et le CSS critique, méritent un regard attentif sur chaque site que vous livrez.

Étapes pratiques, dans l'ordre du risque :

• Différez le JavaScript non critique et chargez les scripts tiers (widgets de chat, analytique, gestionnaires de tags) après l'interaction où vous pouvez.

• Inlinisez le CSS critique pour le contenu au-dessus de la pli et chargez le reste de façon asynchrone, si votre outil de cache le soutient.

• Auto-hébergez les polices, amputez-les, et utilisez font-display: swap pour que le texte soit visible pendant que la police charge.

• Supprimez ou remplacez tout plugin qui charge un gros script sur chaque page pour une fonctionnalité utilisée sur une seule.

• Testez après chaque changement. Le différé JavaScript agressif est la première cause d'un menu cassé ou d'un bouton de paiement mort.

Élagez la pile de plugins et laissez la base de données respirer

Le nombre de plugins est une mauvaise métrique. Ce qui compte, c'est ce que chaque plugin charge frontalement et ce qu'il fait sur chaque requête. Un plugin mal écrit avec une requête lourde peut coûter plus que trente bien comportés. Utilisez Query Monitor sur une copie de staging pour voir les requêtes lentes, le plugin qui les a déclenchées, et les scripts que chacun enfile.

Ensuite regardez la table d'options. Les plugins que vous avez supprimés il y a des années laissent souvent des lignes marquées pour autoload, ce qui signifie que WordPress les lit en mémoire à chaque requête. Site Health commence à signaler les options en autoload une fois qu'elles atteignent à peu près 800 kilo-octets. Si vous voyez cet avertissement, auditez les plus grandes lignes et nettoyez les résidus des plugins que vous ne lancez plus.

Les révisions de posts, les transitoires expirés et les métadonnées orphelines ajoutent du poids au fil du temps, mais traitez cela comme maintenance plutôt que corrective. Sauvegardez d'abord, exécutez le nettoyage en staging, et mesurez de nouveau. Le gain est souvent modeste sur un petit site et considérable sur une boutique avec des années de commandes et de sessions.

Utilisez un CDN et le chargement spéculatif pour la dernière étape

Un réseau de distribution de contenu sert les fichiers statiques, et souvent le HTML en cache aussi, depuis un endroit proche du visiteur. Pour un public éparpillé dans les régions, comme un site en langue arabe lu du Golfe et de l'Afrique du Nord alors que le serveur d'origine est en Europe, la latence gagnée n'est pas cosmétique. La distance a un coût, et un CDN en est la voie la moins chère pour la réduire.

WordPress 6.8 a ajouté quelque chose qui coûte rien : le chargement spéculatif. Il utilise l'API Speculation Rules pour précharger une page au moment où le visiteur commence à cliquer, pour que la navigation suivante semble presque instantanée. L'équipe noyau rapporte que les sites utilisant la version antérieure du plugin ont amélioré leur taux de passage LCP d'environ 1,9 % à la médiane, comme décrit dans la note développeur de chargement spéculatif WordPress 6.8. C'est petit par site, et cela n'exige aucune configuration.

Le noyau l'active pour les visiteurs non connectés sur les sites avec des permaliens jolis. Si un plugin utilise des URL d'action qui changent l'état sur une requête GET simple, excluez ces chemins avec le filtre wp_speculation_rules_href_exclude_paths avant de rendre le paramètre plus enthousiaste. Restez sur la valeur défaut jusqu'à ce que vous ayez vérifié vos paniers et vos analytiques.

Quand cesser l'élagage et quelle correction exécuter d'abord

Il y a un point où plus d'élagage WordPress coûte plus qu'il rapporte. Si une petite boutique dépense chaque mois à combattre les exclusions de cache, les conflits de plugins et les mises à niveau d'hébergement, la question honnête est si la pile correspond au commerce. Une plateforme hébergée comme WiziShop échange un peu de flexibilité contre une boutique dont la vitesse est le travail d'un autre, et elle vaut le coup d'évaluer contre les heures que vous facturez pour la maintenance.

Pour les sites de contenu, agences et projets RTL, WordPress reste le bon outil, et tout ce qui précède vaut la peine d'être fait. Le point est de savoir de quel côté de la ligne chaque client se situe.

Lancez la mesure de base sur votre modèle le plus lent aujourd'hui. Si le TTFB est au-dessus de 800 millisecondes, commencez par l'hébergement, PHP et le cache. Si le TTFB est sain mais que le LCP échoue, ouvrez la cascade et trouvez l'image héroïque. Si les deux passent et que l'interaction est lente, regardez les scripts et la pile de plugins. Lequel de ces trois votre pire page échoue-t-elle ?