Tu cliques sur un bouton… rien.
Tu scannes l’écran du regard. Est-ce que tu as bien cliqué ? Tu réessaies. Toujours rien.
Tu scrolles, et là… ton site se met à ramer comme un vieux PC sous Windows 95.
Pourtant, il charge vite ! Alors où est le problème ?
Bienvenue dans le monde merveilleux de l’INP (Interaction to Next Paint), un indicateur qui mesure
le temps entre ton action (clic, scroll, saisie) et l’affichage du résultat.
Google a récemment intégré ce critère dans son algorithme SEO, et les chiffres sont parlants :
Un site avec un bon INP peut améliorer de 25% le taux de conversion.
Et si ton INP est mauvais ? Bah… tes visiteurs s’en vont, frustrés.
Pourquoi ton site réagit lentement ?
Premier indice... Trop de JavaScript, ça tue le JavaScript
Chaque script JS que tu ajoutes, c’est un peu comme rajouter une brique dans ton sac à dos.
Trop de scripts ? Ton navigateur croule sous la charge et galère à répondre.
Et si tu veux vérifier par toi-même… ouvre ton gestionnaire des tâches.
Regarde bien la consommation RAM de ton navigateur. C’est toujours lui qui bouffe le plus, même quand tu ne fais rien !
Chaque onglet ouvert, chaque site mal optimisé rajoute une couche… et au bout d’un moment, c’est l’overdose.
Que faire ?
- Supprime les scripts inutiles.
- Évite les bibliothèques lourdes pour un simple effet de transition.
- Priorise le CSS pour les animations plutôt que du JS qui tourne en boucle en arrière-plan.
L’API externe qui prend son temps
Si ton site dépend d’une API lente… ton utilisateur attend.
C’est comme commander un café et voir le serveur partir en pause avant de te le servir.
Que faire ?
- Mets en cache les résultats si les données ne changent pas toutes les secondes.
- Affiche un indicateur de chargement plutôt qu’un écran figé.
Base de données surchargée = site qui rame
Tu affiches 10.000 résultats dans un tableau sans pagination ?
Tu forces ton site à charger une montagne de données d’un coup, et ton navigateur n’aime pas ça.
Que faire ?
- Pagination SQL : Charge 20 ou 50 résultats max à la fois.
- Stocke en cache ce qui peut l’être.
Un cloud scalable ne sauvera pas un site mal conçu
Tu peux avoir le meilleur hébergement du monde, un cloud scalable, du Kubernetes prêt à tout absorber…
Si tes pages ne sont pas en cache, ton serveur va quand même transpirer, et Kubernetes finira par t’envoyer un SMS en mode "OK, j’abandonne... je pars en vacances".
Quand ton site prend 300 clics par seconde, la moindre requête inutile est une menace.
Que faire ?
- Cache les pages au moins 1 minute pour éviter de recalculer sans arrêt.
- Utilise Redis ou un fichier JSON pour stocker les résultats de recherches fréquemment demandées.
- Délègue certaines tâches en arrière-plan pour éviter les blocages inutiles.
Gérer les pics de trafic intelligemment
Si tu te retrouves avec une file d’attente de requêtes, il faut lisser la charge pour éviter une surcharge instantanée de la base de données.
RabbitMQ (ou tout autre message broker) peut t’aider :
- Au lieu de traiter toutes les actions immédiatement, on les met en file d’attente.
- Cela évite de bloquer l’utilisateur et garantit un traitement progressif.
Mais attention ! Si tu envoies toutes ces actions en retard, elles risquent d’avoir exactement la même timestamp lorsque la base va les enregistrer.
Que faire ?
Toujours envoyer le created_at avec l’action
Ça permet de garder l’ordre réel des événements et éviter une base de données qui raconte n’importe quoi.
Les fichiers médias trop lourds
Un site peut ramer à cause d’images énormes, de vidéos mal encodées ou de
polices custom qui pèsent 500 Ko.
Mon expérience dans l'immobilier a toujours consisté à trouver le bon équilibre entre satisfaire le product owner / client et plaire à Google ! Et ce n'est pas une mince affaire, car c'est un univers où une belle photo, une grande
image, ou une vidéo percutante suffisent presque à convaincre.
Que faire ?
- Optimiser les images (formats modernes comme WebP, AVIF).
- Ne charger que ce qui est visible (
lazy loading). - Éviter d’ajouter 10 polices différentes juste pour un effet de style.
Les scripts tiers qui ralentissent tout
Un site rapide… jusqu’à ce que tu lui colles 3 pixels Facebook, 2 scripts Google Ads, et un chat en live. Et pour rappel ! Tes lecteurs adoooorent lire sur leur téléphone ta page avec :
- une vidéo en autoplay tout en haut,
- deux pubs bien envahissantes sur les côtés,
- une bannière clignotante en bas qui hurle "Dépêche-toi, il ne reste que 2 exemplaires !!!"
Ces scripts tiers peuvent bloquer le rendu et ralentir l’affichage des pages.
Que faire ?
-
Charger ces scripts en différé (
asyncoudefer). - Vérifier lesquels sont vraiment utiles (les outils comme Tag Manager permettent d’activer/désactiver facilement).
Mais pourquoi ces problèmes ne se voient pas toujours ?
Les outils comme Lighthouse te donnent un bon aperçu… mais ils ne détectent pas tout.
Un site peut avoir 99% de score et pourtant offrir une expérience utilisateur catastrophique.
Et J'ai connus des score à 10% qui étaient des fusées !!!
C’est là qu’intervient le test manuel, avec un protocole précis.
Exemples de tests manuels que je met en place ( job pour le PO généralement) :
- Je clique une fois → délai de réponse ?
- Je clique plusieurs fois rapidement → Est-ce que ça enregistre plusieurs actions ?
- Un pic de trafic → Est-ce que tout explose ou est-ce que la file d’attente gère bien ?
Il faut savoir que lorsqu'on développe… c'est notre bébé ! On fait attention à lui, on en prend soin… on est méticuleux et on ne clique pas comme un sauvage partout, de peur de lui faire mal.
Le client, lui, va toujours te sortir des trucs improbables. Et là, tu auras droit à un :
"Ah d'accord… ok… celle-là, je l’avais pas vue venir !!! Il a fait ça comment ?"
Bien sûr, ce n'est pas tout. La liste des vérifications ressemble à une to-do list interminable, où chaque élément de la page est passé au crible : un bouton, une image (title ok ? Nom correct ? Différentes versions pour l'adaptabilité ? Format optimisé ? etc.).
