Un site de gîte ou de domaine construit il y a quatre ans est presque toujours devenu lourd, et rarement par négligence. Il a accumulé une extension de réservation, une galerie, un formulaire, un module d’avis, un traducteur, une bannière de consentement, chacun ajouté pour répondre à un besoin réel. La somme de ces bonnes décisions produit une page de quatre mégaoctets qui met six secondes à s’afficher sur le téléphone d’un visiteur en vacances.
Compter avant de couper
La tentation est de désactiver au jugé et de regarder si le site va mieux. La méthode produit des pannes et aucune information exploitable. Commencez par un relevé : nombre de requêtes réseau, poids total, temps de génération côté serveur, nombre d’extensions actives. Puis identifiez la contribution de chacune, ce que plusieurs outils font en quelques minutes. Jimenez Julien chiffre d’ailleurs rarement l’objectif en secondes ; il le chiffre en nombre de requêtes supprimées, parce que c’est la seule grandeur qu’on puisse attribuer précisément à une décision et vérifier ensuite.
Les extensions, premier poste de surcharge
Le problème n’est pas leur nombre mais leur comportement : beaucoup chargent leurs feuilles de style et leurs scripts sur toutes les pages du site, y compris là où elles ne servent à rien. Une extension de formulaire utilisée uniquement sur la page contact ajoute ainsi son poids à la page d’accueil, aux articles et aux fiches de chambre. Trois gestes règlent l’essentiel : supprimer pas seulement désactiver celles qui ne servent plus, remplacer les modules à fonction unique par quelques lignes dans le thème, et restreindre le chargement des autres aux pages concernées. Il n’est pas rare de retirer un tiers des requêtes sans qu’aucune fonctionnalité disparaisse. Vérifiez au passage qu’il n’existe pas deux extensions d’optimisation installées en parallèle : elles se neutralisent, produisent des pages cassées de façon intermittente, et occupent des heures de diagnostic pour un problème qu’on a créé soi-même.
Le constructeur de pages, décision à assumer
Les constructeurs visuels facilitent la mise en page et produisent un balisage abondant, avec des couches de conteneurs imbriqués et des feuilles de style générées automatiquement. Sur un site de quelques pages éditoriales, le coût est réel mais supportable. Il devient difficile à justifier quand la structure est stable depuis trois ans et que plus personne ne modifie la mise en page. Reconstruire les cinq gabarits principaux en dehors du constructeur représente deux à trois jours de travail et divise fréquemment le poids par deux. C’est un arbitrage entre autonomie éditoriale et performance : les deux se défendent, mais il faut le trancher explicitement plutôt que de le subir.
La base de données que personne ne regarde
Elle grossit silencieusement. Chaque enregistrement d’une page conserve une révision, et une page modifiée deux cents fois occupe deux cents entrées. S’y ajoutent les données temporaires expirées, les tables laissées par des extensions supprimées il y a des années, les journaux d’activité. Une base de cent mégaoctets sur un site de trente pages est un signal clair. Limitez le nombre de révisions conservées, purgez les données obsolètes, et faites une sauvegarde vérifiée avant toute opération de nettoyage cette précaution n’est pas rhétorique.
Un site s’allège en continu, pas une fois par an
Le nettoyage annuel donne d’excellents résultats sur le moment et une reprise du poids en quelques mois, parce que rien n’a changé dans la façon dont le site évolue. Trois habitudes suffisent à stabiliser la situation : essayer toute nouvelle extension sur un site de test, relever le poids de la page d’accueil chaque trimestre dans un simple tableur, et se donner une limite haute à ne pas dépasser. Un site rapide n’est pas un site qu’on a optimisé une fois, c’est un site dont on refuse régulièrement des ajouts.
About Author
