Changer d'hébergeur va-t-il accélérer mon site ?

Rarement, et c'est la première dépense inutile que je vois. Sur les sites que je mesure, le serveur répond en général entre 40 et 70 millisecondes, ce qui ne représente presque rien dans une page qui met plusieurs secondes à s'afficher. Le seul cas où l'hébergement est vraiment en cause, c'est quand aucun cache n'est configuré : le temps de réponse grimpe alors autour de 600 millisecondes. Mais c'est un problème de configuration, pas de puissance, et ça se règle avec un plugin de cache.

Faut-il viser un score de 100 sur PageSpeed ?

Non, et surtout : ne jugez pas votre site sur ce score seul. Il vient d'une simulation volontairement pessimiste, sur un téléphone d'entrée de gamme et un réseau bridé. La mesure qui compte est celle de vos visiteurs réels, que Google affiche dans PageSpeed sous « découvrez l'expérience de vos utilisateurs » et dans la Search Console. Sur un site que je gère, la simulation annonce un affichage en 6 secondes quand les visiteurs réels sont à 2,2 secondes, avec une évaluation Core Web Vitals au vert. Si vos données de terrain sont bonnes, un rapport de laboratoire alarmant ne décrit personne.

Un plugin de cache suffit-il à régler le problème ?

Il aide beaucoup, surtout si le site n'en avait aucun, mais il ne compense pas une image de plusieurs mégaoctets ni du CSS inutilisé chargé sur chaque page. Pire, mal réglé, il peut ralentir : j'ai mesuré une boutique où le plugin de cache repoussait le chargement de l'image principale alors que le site demandait justement de la charger en priorité. Les deux réglages se contredisaient et le visiteur attendait pour rien.

Est-ce que la vitesse influence vraiment le référencement ?

Oui, mais moins directement qu'on ne le raconte. Google utilise les Core Web Vitals comme signal, à contenu comparable : entre deux pages de qualité équivalente, la plus rapide sera favorisée. La vitesse joue surtout sur le comportement des visiteurs, qui abandonnent avant l'affichage sur mobile en connexion moyenne. Un site lent perd des gens avant même d'avoir eu sa chance, et ça, aucun travail de référencement ne le rattrape.

Combien coûte une remise à niveau de performance ?

Ça dépend entièrement de la cause. Compresser des images, corriger un réglage de cache ou ajouter les dimensions manquantes se traite en quelques heures et transforme souvent le ressenti. En revanche, quand la lenteur vient de l'architecture même du site, typiquement un page builder dont le code bloque l'affichage et alourdit chaque page, il n'y a pas d'optimisation miracle : on gratte quelques centaines de millisecondes, et le vrai gain passe par une refonte.

Pourquoi votre site WordPress est lent (ce n'est pas votre hébergeur)

Sur un site que j'ai audité au début du mois, la page d'accueil pèse 36 mégaoctets. À elle seule, la vidéo de fond du bandeau en représente 34,7. Elle se lance automatiquement, sans image de remplacement le temps qu'elle arrive, et le navigateur a interdiction de la garder en mémoire : chaque visite la retélécharge intégralement.

Sur mobile, le contenu principal met entre 6,3 et 9,5 secondes à apparaître selon les pages. Le propriétaire du site, lui, était persuadé que son hébergeur était en cause.

C'est presque toujours la première hypothèse, et c'est presque toujours la mauvaise. Pour cet article, j'ai mesuré quatre sites : deux audits clients récents, mon propre portfolio, et le site d'une association pour laquelle je suis aux commandes. Les chiffres qui suivent viennent de ces mesures, pas de moyennes glanées ailleurs. Et vous verrez qu'un de ces sites m'a servi une leçon en cours de route.

D'abord, ce que Google regarde vraiment

Les Core Web Vitals ont mauvaise réputation parce qu'on les présente toujours par leurs sigles. En réalité, ils mesurent trois choses que n'importe qui comprend intuitivement.

Le LCP répond à la question : quand est-ce que je vois enfin quelque chose d'utile ? Pas le fond de page, pas le menu : le gros bloc qui porte l'information, en général une image de bandeau ou un titre. En dessous de 2,5 secondes, c'est bon. Au-delà de 4, le visiteur a eu le temps de se demander si ça marche.

Le CLS mesure les sauts de mise en page. Vous commencez à lire, une image finit de charger au-dessus du texte, et tout descend d'un coup. Vous cliquez sur le mauvais bouton parce qu'il a bougé pendant que votre doigt descendait. C'est le plus énervant des trois et souvent le plus simple à corriger.

L'INP mesure le délai entre votre clic et la réaction visible. Vous appuyez sur « menu », rien ne se passe pendant un demi-instant, vous rappuyez. Ce délai vient du code JavaScript qui occupe le navigateur au lieu de répondre.

Trois questions, donc : est-ce que je vois vite, est-ce que ça reste stable, est-ce que ça répond quand je touche. Le reste, ce sont des détails de mesure.

Le coupable qu'on accuse à tort

Voici les temps de réponse serveur que j'ai relevés sur les quatre sites, c'est-à-dire le délai avant que le premier octet arrive, ce qu'on appelle le TTFB :

Mon portfolio, 40 millisecondes. Le site de l'association, 62 millisecondes. La boutique en ligne auditée, 64 millisecondes. Les trois tournent sur du mutualisé, l'hébergement d'entrée de gamme que tout le monde accuse.

Précision utile : ce chiffre mesure le temps que met le serveur à fabriquer la page, depuis une bonne connexion. Chez un visiteur mobile, il faut y ajouter le temps d'établir la connexion, qui dépend de son réseau et non de votre hébergeur. Le partage compte, parce que c'est justement la partie que changer d'hébergement ne corrigera pas.

Sur une page qui met plusieurs secondes à s'afficher, soixante millisecondes de fabrication représentent une portion négligeable du problème. Migrer vers un hébergement plus cher n'y changerait presque rien, et c'est pourtant la première dépense que beaucoup engagent.

Le quatrième site fait exception, avec un serveur qui répond entre 577 et 697 millisecondes. Dix à quinze fois plus lent que les autres. La cause n'est pas la machine : le site n'a aucun cache de page configuré, donc chaque visiteur déclenche la reconstruction complète de la page par WordPress. Un plugin de cache correctement réglé ramènerait ça au niveau des autres, pour zéro euro d'hébergement supplémentaire.

Le partage est donc simple. Quand la page se fabrique en quelques dizaines de millisecondes, l'hébergement n'a rien à se reprocher et le problème se trouve dans ce que la page demande ensuite. Quand ce délai se compte en centaines de millisecondes, ce n'est presque jamais la puissance de la machine, mais un cache absent ou mal réglé.

Ce qui pèse vraiment : les médias

Reprenons la vidéo de 34,7 mégaoctets. Sur une connexion mobile ordinaire, ça se compte en dizaines de secondes de téléchargement, et le visiteur regarde un bandeau vide pendant ce temps. Trois réglages auraient suffi : une image de remplacement affichée immédiatement, l'autorisation faite au navigateur de garder le fichier, et une compression sérieuse. La mesure estime le gain entre 6 et 8 secondes. Sur une seule ressource.

Le reste suit la même logique. Sur ce même site, des photos de 1999 pixels de large s'affichent dans des cadres de 651 pixels : le visiteur télécharge une image qui contient sept fois plus de pixels que ce qu'il verra. Une page de réalisation atteint 6,3 mégaoctets avec ses 26 images, toutes en JPEG, format que les navigateurs modernes savent remplacer par des équivalents deux à trois fois plus légers.

Je ne suis pas au-dessus de ça. Sur le site de l'association, les images représentent 549 kilooctets pour neuf fichiers, soit plus de la moitié du poids de la page d'accueil. C'est le premier poste sur lequel je travaillerai.

Le nombre de fichiers CSS ne veut rien dire tout seul

Le site de l'association charge 61 feuilles de style. Sorti de son contexte, le chiffre paraît catastrophique. Il ne l'est pas, et c'est un bon exemple de métrique qu'on ne peut pas lire seule.

Dix-neuf de ces fichiers viennent de WordPress lui-même, qui découpe volontairement son CSS bloc par bloc. Chaque page ne charge alors que le style des blocs qu'elle utilise, au lieu d'une grosse feuille contenant le nécessaire pour tous les blocs existants. Les 23 kilooctets que ça pèse ici sont le prix d'un mécanisme qui évite d'en charger bien plus. C'est une optimisation, pas un défaut. Le reste se répartit entre le thème, les blocs sur-mesure et la boutique.

Surtout, le site est servi en HTTP/2, qui récupère ces fichiers en parallèle sur une seule connexion au lieu de les enchaîner. L'idée qu'une requête supplémentaire coûte un aller-retour complet appartient à la génération précédente du protocole. La mesure ne signale d'ailleurs aucune ressource bloquant l'affichage sur ce site.

Comparez maintenant avec les deux sites clients. La boutique en charge 37, la vitrine entre sept et douze selon la page. Bien moins dans les deux cas, et pourtant l'audit les signale tous les deux comme retardant l'affichage. Là, le CSS des page builders, Oxygen dans un cas, Elementor dans l'autre, se charge en travers du rendu et coûte entre 300 millisecondes et 1,7 seconde.

Sept fichiers qui bloquent l'affichage font donc plus de dégâts que soixante et un qui le laissent passer. La question n'a jamais été de savoir combien de fichiers, mais s'ils bloquent l'affichage et s'ils servent à quelque chose. Sur le site de l'association, il reste d'ailleurs 470 millisecondes à récupérer, en réduisant le CSS inutilisé que chargent le thème et la boutique. Recoller ce que WordPress a séparé exprès n'y changerait rien.

Quand l'outil d'optimisation se contredit

Le cas le plus intéressant vient de la boutique en ligne. Ce site est correctement outillé : cache actif, compression, images en chargement différé, connexion moderne, police hébergée localement. Le travail a été fait sérieusement.

Sauf que l'image principale du bandeau, celle qui détermine le LCP, est en lazy loading. Le thème demande explicitement au navigateur de la charger en priorité, et le plugin d'optimisation lui demande au contraire d'attendre. Les deux instructions se contredisent, et c'est l'attente qui l'emporte. Entre une demi-seconde et une seconde perdues sur la métrique la plus importante, à cause de deux outils qui font chacun leur travail sans se parler.

Sur le même site, le plugin de cache diffère 84 scripts, qui se déclenchent tous ensemble au premier clic du visiteur. L'affichage initial paraît rapide, puis la page se fige au premier contact. La mesure de laboratoire est flatteuse, l'expérience réelle beaucoup moins.

C'est pour ça que j'installe peu de plugins d'optimisation et que je regarde ce qu'ils font avant de les laisser en place. Empiler des outils censés accélérer un site produit régulièrement l'inverse.

Mes propres sites, sans filtre

Le portfolio que vous lisez obtient 95 sur 100 dans la simulation, avec un contenu principal affiché en 2,8 secondes, aucun blocage à l'interaction et pratiquement aucun saut de mise en page. C'est facile à expliquer : il n'y a pas de CMS, quinze requêtes en tout et 177 kilooctets. Un site sans base de données, sans plugin et sans page builder part avec une avance considérable.

Le site de l'association joue dans une autre catégorie : WordPress, un thème complet, une boutique, des images, du contenu qui vit. 82 requêtes contre 15, un mégaoctet contre 177 kilooctets. Comparer les deux n'aurait aucun sens, ils ne font pas le même travail.

Et c'est précisément là que j'ai failli me tromper d'analyse, ce qui vaut le détour.

Le laboratoire dramatise, le terrain tranche

En lançant l'outil de mesure depuis ma machine, j'obtiens pour ce site un contenu principal affiché en 6 secondes. De quoi conclure que le site est lent et facturer une optimisation.

Sauf qu'il existe une autre source, et c'est la bonne : les mesures faites chez les vrais visiteurs. Google les collecte via Chrome et les affiche dans PageSpeed sous « découvrez l'expérience de vos utilisateurs ». Sur les vingt-huit derniers jours, tous appareils et toutes connexions confondus, ce site affiche son contenu principal en 2,2 secondes avec un score de stabilité parfait à zéro. Verdict de Google sur les Core Web Vitals : réussite.

Six secondes en laboratoire, 2,2 secondes dans la vraie vie. Le même site, le même jour.

L'écart s'explique. La mesure de laboratoire simule volontairement un téléphone d'entrée de gamme sur un réseau bridé, pour révéler les problèmes en amplifiant les conditions. Elle sert à diagnostiquer, elle ne photographie pas votre audience. Vos visiteurs ont de meilleurs appareils, de meilleures connexions, et bénéficient du cache quand ils reviennent.

Le score de performance suit la même logique : 73 sur mobile et 97 sur ordinateur pour ce site selon l'outil de Google, contre le chiffre plus bas que m'affichait ma propre machine. Trois instruments, trois réponses, et pas une ligne de code modifiée entre les mesures.

Je peux même remonter plus loin. Mon étude de cas sur ce site, publiée en mars, affichait 76 sur mobile. Aujourd'hui le même outil en donne 73. Le site n'a pas ralenti de trois points : c'est la mesure qui respire.

La conséquence pratique est simple. Avant de payer pour de l'optimisation, regardez les données de vos visiteurs réels, dans PageSpeed ou dans la Search Console. Si elles sont au vert, un rapport de laboratoire alarmant ne décrit personne. Et si un prestataire vous vend une remise à niveau en s'appuyant uniquement sur une capture d'écran d'outil, demandez-lui ce que disent vos utilisateurs.

Ça ne veut pas dire que le laboratoire ne sert à rien. Il pointe des choses réelles, comme les 470 millisecondes de CSS inutilisé de tout à l'heure, et il reste le seul outil disponible quand un site est trop récent ou trop peu visité pour avoir des données de terrain. Voyez-le comme une marge de progression à explorer plutôt que comme un constat de panne.

Et l'écart peut jouer dans l'autre sens. J'ai vu des sites gagner des points de score en repoussant tout ce qui n'était pas indispensable à l'affichage initial, au prix d'une page qui se fige au premier clic. La note monte, l'expérience se dégrade. C'est exactement le mécanisme de la boutique dont je parlais plus haut, dont la mesure était flatteuse alors que ses visiteurs attendaient. Le laboratoire se trompe dans les deux sens, ce qui est une raison de plus de ne pas s'y fier seul.

Les bonnes questions restent les trois du début. Est-ce que le visiteur voit le contenu utile en moins de deux secondes et demie. Est-ce que la page reste stable pendant qu'il lit. Est-ce que ça répond quand il clique. À poser à vos visiteurs réels avant de les poser à un mobile simulé.

Ce qui se corrige vite, et ce qui ne se corrige pas

Quelques heures de travail suffisent pour compresser et redimensionner les images, activer un cache de page absent, corriger un chargement différé mal appliqué sur l'image principale, ou ajouter les dimensions manquantes qui font sauter la mise en page. Sur le site à 36 mégaoctets, traiter la seule vidéo diviserait le temps d'affichage par deux ou trois. C'est le meilleur rapport entre effort et résultat que je connaisse.

D'autres problèmes ne se corrigent pas par optimisation. Quand le code d'un page builder se charge en travers du rendu et alourdit chaque page, on gratte quelques centaines de millisecondes sans transformer le site : la lenteur est dans sa structure. Là, le vrai gain passe par une refonte sans page builder, et je préfère le dire franchement plutôt que vendre trois mois d'optimisation qui déçoivent.

Une chose reste vraie dans les deux cas : la performance se maintient. Un site rapide à la livraison se dégrade au fil des images ajoutées sans compression et des plugins installés au fil de l'eau. C'est du même ordre que ce qui casse quand on ne maintient pas son site.

Et après ?

Si votre site vous semble lent, commencez par vérifier ce que vivent vos visiteurs réels, dans PageSpeed ou dans la Search Console, avant tout devis et avant tout changement d'hébergeur. Vous éviterez peut-être de payer pour un problème que personne ne rencontre. Et si les chiffres confirment la lenteur, regardez d'abord vos images et vos réglages de cache : c'est là que se trouve l'essentiel, pas dans la puissance du serveur.

Je peux aussi le mesurer pour vous et vous dire ce qui se corrige en quelques heures et ce qui relève de l'architecture. C'est gratuit, ça prend une trentaine de minutes en visio, et vous repartez avec les chiffres de votre site, même si vous décidez de faire le travail ailleurs. Pour maintenir la performance dans la durée, ça se traite ensuite dans le cadre d'un contrat de TMA.