Serveur web optimisé : accélérer sans changer d’hébergeur

Quand un site rame, le premier réflexe est de changer d’hébergement. C’est souvent la dépense la moins rentable, parce que dans la majorité des cas le serveur n’est pas le goulot. Un serveur web optimisé commence par une mesure, pas par un achat. Voici où le temps se perd réellement, dans quel ordre le récupérer, et le point précis qui plombe la plupart des sites WordPress sans que personne le regarde.

Mesurer avant de toucher à quoi que ce soit

Deux durées se confondent en permanence et n’ont pas les mêmes causes ni les mêmes remèdes.

• Le temps jusqu’au premier octet. C’est le temps que met votre serveur à commencer à répondre. Il dépend du code, de la base de données et de la mise en cache. C’est le seul que l’hébergement influence directement.
• Le temps jusqu’à l’affichage. C’est ce que vit le visiteur. Il dépend surtout du poids des ressources et du nombre de requêtes que la page déclenche, donc du site et non du serveur.

Si le premier est bon et le second mauvais, changer d’hébergeur ne changera rien du tout. C’est le cas le plus fréquent, et c’est la raison pour laquelle tant de migrations déçoivent.

Mesurez toujours sur une page réelle et en navigation privée, sans extension de navigateur. Et mesurez deux fois : la première visite, et la seconde, qui bénéficie des caches.

Les images, avant tout le reste

Sur la quasi-totalité des sites vitrines, les images représentent l’essentiel du poids transféré. Trois gestes suffisent, et ils se font sans toucher au serveur.

1. Redimensionner à la taille réellement affichée. Une photographie de 4 000 pixels de large affichée dans un bloc de 800 pixels transfère vingt-cinq fois trop de données. C’est l’erreur la plus courante et la plus coûteuse.
2. Choisir un format moderne. À qualité visuelle équivalente, les formats récents réduisent fortement le poids par rapport au JPEG et au PNG.
3. Déclarer les dimensions dans le code. Sans largeur ni hauteur, le navigateur ne sait pas réserver la place et la page saute pendant le chargement, ce qui dégrade la stabilité visuelle mesurée par Google.

Un mot sur le chargement différé : il est utile pour les images situées en bas de page, et néfaste pour celle du haut. Différer l’image principale retarde précisément l’élément dont Google mesure l’apparition.

Le point qui plombe WordPress, et que personne ne regarde

Voici le contrôle le plus rentable de cet article, et il ne prend qu’une minute.

WordPress conserve ses réglages dans une table d’options, dont une partie est marquée comme devant être chargée à chaque requête, y compris sur les pages qui n’en ont aucun usage. Chaque extension installée y ajoute ses propres entrées, et les extensions désinstallées y laissent souvent les leurs.

SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';

Le résultat s’exprime en octets. Quelques centaines de kilo-octets chargés à chaque page est un poids considérable, et il arrive de trouver plusieurs mégaoctets accumulés au fil des années. Le nettoyage consiste à identifier les plus grosses entrées, à vérifier à quelle extension elles appartiennent, et à supprimer celles dont l’extension n’est plus installée.

Sauvegardez la base avant, selon la méthode décrite dans notre guide sur les sauvegardes automatiques. Ce nettoyage se fait en quelques minutes et améliore souvent le temps de réponse de façon immédiatement visible.

Les trois caches, et ce que chacun fait

Cache	Ce qu’il évite	Gain typique
Cache de code compilé	Recompiler le PHP à chaque requête	Important, et souvent déjà actif
Cache d’objets	Refaire les mêmes requêtes en base	Fort sur les sites à contenu dynamique
Cache de pages	Générer la page entière	Le plus spectaculaire, sur les pages publiques

Le cache de pages est celui qui transforme le temps de réponse, parce qu’il supprime purement et simplement l’exécution du code. Sa limite est évidente : il ne s’applique qu’aux pages identiques pour tout le monde. Un panier, un compte connecté ou un formulaire personnalisé le contournent nécessairement.

Vérifiez aussi votre version de PHP. Les versions récentes apportent des gains de performance réels sur le même matériel, et une version ancienne ne reçoit plus de correctifs de sécurité, ce qui pose un second problème traité dans notre article sur la sécurisation d’un site WordPress.

Les scripts tiers, le coût invisible

Chaque outil ajouté à une page, mesure d’audience, bandeau de consentement, chat, carte, vidéo intégrée, apporte son propre code et ses propres connexions vers d’autres domaines.

Ces appels ne pèsent pas seulement en octets : ils occupent le fil d’exécution du navigateur, celui-là même qui doit répondre aux clics de l’utilisateur. C’est la principale cause de mauvaise réactivité, et aucun réseau de diffusion ni aucun hébergement ne la corrige, comme nous l’expliquons dans notre article sur l’utilité d’un CDN.

Comptez-les, et supprimez ceux que personne ne consulte. La lenteur se cumule d’ailleurs avec les défauts du parcours lui-même, que nous listons dans notre article sur les erreurs UX qui font fuir les visiteurs. Une carte interactive vue par trois visiteurs par mois coûte à chaque affichage de la page, y compris aux autres.

Les polices, souvent oubliées

Une police chargée depuis un service extérieur ajoute une résolution de nom, une connexion et un téléchargement avant que le moindre texte ne s’affiche. Trois réglages suppriment ce coût.

• Héberger les fichiers sur votre domaine, ce qui supprime une connexion à un tiers et vous évite d’en dépendre.
• Ne charger que les graisses réellement utilisées. Une famille complète représente souvent six fichiers là où deux suffisent.
• Afficher le texte immédiatement avec la police de substitution, plutôt que de laisser la page muette le temps du chargement.

Le dernier point se voit tout de suite : sur une connexion lente, une page mal réglée reste blanche plusieurs secondes alors que le texte était prêt à s’afficher.

Quand il faut vraiment changer d’hébergement

La réserve doit être posée, car il existe des cas où l’optimisation ne suffira pas.

• Le temps de réponse est mauvais même sur une page mise en cache. Le serveur est alors réellement en cause.
• Le site ralentit aux heures de pointe et redevient normal ensuite. C’est le symptôme d’un plafond imposé par l’hébergeur, détaillé dans notre comparaison entre mutualisé, VPS et dédié.
• Vous ne pouvez ni changer la version de PHP ni activer un cache d’objets. L’offre vous bloque, et aucune optimisation ne contournera cela.
• Vos visiteurs sont à l’autre bout du monde. C’est un problème de distance, pas de puissance.

Dans tous les autres cas, l’ordre reste le même : mesurer, alléger les images, nettoyer la base, activer les caches, supprimer les scripts inutiles. Changer d’hébergement avant d’avoir fait cela revient à déménager pour ranger moins souvent.

Questions fréquentes sur l'optimisation d'un site

Changer d'hébergeur accélère-t-il vraiment un site ?

Seulement si le temps de réponse du serveur est mauvais, y compris sur une page mise en cache. Quand le serveur répond vite et que la page s’affiche lentement, la cause est le poids des ressources et le nombre de requêtes, pas l’hébergement.

Par quoi commencer pour accélérer un site ?

Par les images : les redimensionner à la taille réellement affichée est le gain le plus important et le plus simple. Une photo de 4 000 pixels affichée dans un bloc de 800 transfère vingt-cinq fois trop de données.

Qu'est-ce qui ralentit un site WordPress sans qu'on le voie ?

Les options chargées automatiquement à chaque requête. Chaque extension y ajoute ses entrées et les extensions désinstallées y laissent souvent les leurs, ce qui finit par représenter plusieurs centaines de kilo-octets lus à chaque page.

Faut-il activer le chargement différé sur toutes les images ?

Non. Il est utile pour les images situées en bas de page et néfaste pour celle du haut, car différer l’image principale retarde précisément l’élément dont Google mesure l’apparition.

Pourquoi mon site est-il lent aux heures de pointe uniquement ?

C’est le symptôme d’un plafond imposé par l’hébergement mutualisé, sur le temps de calcul ou le nombre de traitements simultanés. Aucune optimisation du site ne relève ce plafond.