Optimisation de site
On mesure d’abord. On corrige ensuite
Un site lent l’est toujours pour une raison précise, et rarement celle qu’on croit. Nous mesurons ce qui prend du temps — serveur, base, images, scripts — puis nous traitons ce qui pèse réellement.
- Mesure avant intervention : on ne devine pas
- Cache serveur, images et base de données
- Hébergement à ressources dédiées et garanties
- Ce qui compte pour vos visiteurs, pas un score de vanité
Le principe
Un site lent l’est pour une raison, pas pour dix
Le réflexe coûteux
Devant un site lent, la réaction habituelle est d’empiler : une extension de cache, une autre de compression, une troisième d’optimisation d’images. On obtient un site tout aussi lent, plus fragile, et devenu impossible à diagnostiquer parce que dix couches se marchent dessus.
La démarche inverse est plus rapide et moins chère : mesurer d’abord. Sur la plupart des sites, une seule cause explique l’essentiel du temps de chargement — une requête de base de données qui balaie une table entière, une image de quatre méga-octets servie en pleine page, un script tiers qui bloque l’affichage. Le reste est du bruit.
Ce qu’on mesure vraiment
Le temps total ne dit rien tant qu’on ne l’a pas décomposé :
- Le temps du serveur : ce que met votre application à produire la page, avant que le navigateur reçoive quoi que ce soit. C’est souvent là que tout se joue, et c’est ce que les extensions front ne corrigent jamais.
- Le poids transféré : images, polices, scripts. Une image mal dimensionnée coûte plus cher que dix optimisations de code.
- Ce qui bloque l’affichage : scripts tiers, feuilles de style, polices chargées avant le texte.
- Le rendu sur mobile, sur une connexion mobile — pas sur votre fibre au bureau, où tout est rapide.
Où ça se corrige
Sur la machine, quand la cause est là : nos hébergements reposent sur des ressources dédiées et garanties, avec LiteSpeed plutôt qu’Apache — meilleure gestion des processus PHP, HTTP/2 et cache intégré, sans licence de plugin de cache à acheter. Un site lent parce qu’il partage son processeur avec cinquante voisins ne se répare pas dans le code.
Dans l’application, quand la cause est là : cache de page, cache d’objets en mémoire — Redis, KeyDB, Memcached — requêtes revues, index posés là où ils manquent. Sur les cas les plus lourds, une base spécialisée pour la recherche plutôt que des requêtes coûteuses sur la base principale.
Et dans le contenu, parce que c’est souvent le moins cher : images redimensionnées et converties, scripts tiers dont on vérifie qu’ils servent encore à quelque chose. Chez Antinea, regrouper du contenu épars a fait plus pour la page que n’importe quel réglage technique.
Ce que nous ne promettons pas
Un score de 100. Les outils de mesure sont utiles pour trouver ce qui pèse, pas comme objectif : optimiser pour l’outil finit par dégrader l’expérience réelle. Ce que nous visons, c’est le temps qu’attend votre visiteur, sur son téléphone, avec sa connexion.
Les leviers
Ce que nous traitons
-
Mesure et diagnostic
Décomposition du temps de chargement : serveur, transfert, rendu. On identifie la cause principale avant de toucher quoi que ce soit.
-
Le socle
LiteSpeed plutôt qu’Apache, dernières versions de PHP, ressources dédiées et garanties. Un site qui partage son processeur ne se répare pas dans le code.
-
Base de données
Requêtes revues, index posés là où ils manquent. Une seule requête qui balaie une table entière suffit à ralentir toutes les pages d’un site.
-
Caches
Cache de page côté serveur, cache d’objets en mémoire avec Redis, KeyDB ou Memcached. Varnish devant, quand le volume le justifie.
-
Images et contenu
Redimensionnement, conversion, chargement différé. C’est le levier le moins cher et le plus souvent négligé.
-
Le résultat, mesuré
Les mêmes mesures qu’au départ, pour dire ce qui a changé. Sans avant, un après ne veut rien dire.
Questions fréquentes
Optimisation : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Faut-il refaire le site pour l’accélérer ?
Rarement. La plupart des sites lents le sont pour une cause identifiable qui se corrige sans tout reprendre. La refonte se justifie quand le socle est obsolète ou que l’outil bloque, pas parce que les pages mettent trois secondes à s’afficher.
La vitesse joue-t-elle sur le référencement ?
Oui, et directement : une page lente est pénalisée, et elle l’est deux fois puisque les visiteurs partent avant de l’avoir vue. C’est l’un des leviers du référencement naturel, mais ce n’est pas le seul — la structure et les contenus comptent autant.
Mon site est hébergé ailleurs, pouvez-vous intervenir ?
Oui, la mesure et une bonne partie des corrections ne dépendent pas de l’hébergeur. Nous vous dirons en revanche honnêtement si la cause principale est la machine : dans ce cas, optimiser le code revient à repeindre une pièce dont le plancher est pourri.
Combien de temps cela prend-il ?
La mesure et le diagnostic sont courts — c’est la partie qui donne la réponse. Les corrections dépendent de ce qu’on trouve : redimensionner des images est l’affaire de quelques heures, revoir des requêtes qui datent de dix ans peut demander plusieurs jours. Nous chiffrons après le diagnostic, pas avant.
Votre site met combien de temps à s’afficher ?
Donnez-nous son adresse. Nous mesurons, nous vous disons ce qui pèse, et vous décidez ensuite de ce qui vaut la peine d’être corrigé.