La performance se dégrade. Une page qui se chargeait en deux secondes se charge maintenant en quatre secondes. Quelque chose a changé.
Le dépannage répond à ces questions : qu'est-ce qui a changé, et pourquoi la performance s'est-elle dégradée.
Causes racines possibles : une nouvelle fonction a ajouté un gros bundle JavaScript. Une requête de base de données est devenue lente. Un script tiers a été ajouté. Le poids des images a augmenté. Le serveur s'est surchargé.
Un dépannage méthodique trouve la cause racine. Une correction méthodique supprime la cause racine.
Cadre de dépannage
Étape un : identifier le symptôme. Le LCP est passé de deux à quatre secondes. Le CLS est passé de zéro virgule zéro cinq à zéro virgule deux. L'INP est passé de cent à quatre cents millisecondes.
Étape deux : la chronologie. Quand la dégradation a-t-elle commencé ? La semaine dernière. Hier. Il y a une heure. La chronologie réduit le champ de recherche.
Étape trois : corréler avec les changements. Quel code a changé ? Quelles fonctions ont été livrées ? Quelle infrastructure a changé ? La corrélation désigne la cause.
Étape quatre : isoler la cause. La performance s'est dégradée. Hypothèse : le nouveau bundle JavaScript. Test : mesurer le LCP avec le nouveau bundle désactivé. Le LCP revient à deux secondes. Hypothèse confirmée.
Étape cinq : corriger ou revenir en arrière. Corriger la cause (optimiser le bundle) ou revenir en arrière (annuler le changement). La décision dépend de la gravité.
Exemple concret : dégradation de la performance d'une boutique en ligne
Symptôme : le LCP est passé de deux secondes à trois virgule cinq secondes. Détecté par une alerte de suivi.
Chronologie : la dégradation est survenue mardi matin. L'équipe avait livré un nouveau moteur de recommandation lundi soir.
Corrélation : la coïncidence suggère que le moteur de recommandation a causé la dégradation.
Test d'isolation : désactiver le moteur de recommandation. Le LCP revient à deux secondes. Le moteur de recommandation est confirmé comme cause.
Analyse : le moteur de recommandation charge des images de produits pour ses suggestions. Les images ne sont pas optimisées (taille d'origine, sans compression). Charger cinquante images de produits ajoute deux mégaoctets à la page.
Correction : optimiser les images du moteur de recommandation. Compresser les images, utiliser le chargement différé pour les images hors écran. Le poids des images passe à cinq cents kilooctets. Le LCP s'améliore à deux virgule deux secondes.
Déploiement : annuler le moteur de recommandation, déployer la version optimisée. Le LCP revient à deux virgule deux secondes.
Problèmes de performance courants et solutions
Problème un : bundle JavaScript volumineux
- Symptôme : LCP lent, INP lent
- Cause : une nouvelle fonction ajoute du code, le bundle grossit
- Solution : découper le code de la fonction, la charger en différé
- Amélioration attendue : le LCP gagne zéro virgule cinq seconde
Problème deux : requêtes de base de données lentes
- Symptôme : TTFB lent
- Cause : une requête de base de données devient lente (index manquant, requête qui joint beaucoup de tables)
- Solution : ajouter un index, optimiser la requête, mettre les résultats en cache
- Amélioration attendue : le TTFB gagne deux cents millisecondes
Problème trois : images non optimisées
- Symptôme : LCP lent, bande passante élevée
- Cause : les images sont lourdes (non compressées, mauvais format)
- Solution : compresser les images, convertir en WebP, utiliser des images adaptatives
- Amélioration attendue : le LCP gagne une seconde
Problème quatre : scripts tiers
- Symptôme : LCP lent, la page ne répond plus
- Cause : les statistiques, le suivi et les publicités tiers ralentissent la page
- Solution : charger les scripts tiers en différé, utiliser un web worker, charger de façon asynchrone
- Amélioration attendue : le LCP gagne zéro virgule cinq seconde, l'INP gagne cent millisecondes
Problème cinq : CLS dû aux publicités ou aux contenus intégrés
- Symptôme : la mise en page bouge pendant la lecture
- Cause : les publicités se chargent et prennent de la place, le contenu se décale
- Solution : réserver de l'espace pour les publicités, charger en différé les publicités hors écran
- Amélioration attendue : le CLS passe de zéro virgule deux à zéro virgule zéro cinq
Surveiller pour détecter tôt
Alerte sur la dégradation : si le LCP dépasse deux virgule cinq secondes, prévenir l'équipe.
Alerte sur la régression : si le LCP augmente de plus de zéro virgule cinq seconde par rapport au point de départ, prévenir l'équipe.
Alerte sur l'impact business : si la finalisation des inscriptions baisse d'un pour cent, prévenir l'équipe (cela peut indiquer un problème de performance).
Exemple concret : les alertes d'une entreprise SaaS
- Alerte un : si le LCP dépasse deux virgule cinq secondes
- Alerte deux : si une régression de performance est détectée (le LCP augmente de cinquante pour cent en un jour)
- Alerte trois : si les Core Web Vitals passent de bon à à améliorer pour plus de cinq pour cent des utilisateurs
- Alerte quatre : si la finalisation des inscriptions passe sous l'objectif (cela peut indiquer un problème de performance de la page de paiement)
Quand une alerte se déclenche : l'équipe technique enquête dans l'heure. La cause racine est identifiée. La correction est déployée le jour même.
Exemple concret : problème de performance du paiement
Symptôme : le taux d'abandon au paiement est passé de quinze pour cent à vingt-cinq pour cent. Cela a commencé jeudi.
Analyse : la performance de la page de paiement s'est dégradée. Le temps d'interaction du bouton de paiement est passé de deux cents millisecondes à une seconde.
Chronologie : le prestataire de paiement a modifié son infrastructure jeudi matin.
Cause racine : le prestataire de paiement est passé de la Californie à l'Europe. La latence réseau entre l'utilisateur et le prestataire a augmenté de deux cents millisecondes. Le temps total de traitement du paiement est monté à une seconde.
Solution : utiliser un nœud CDN proche de l'utilisateur. Faire passer la demande de paiement par le nœud CDN local. Le nœud CDN la relaie au prestataire de paiement européen. La latence réseau diminue. Le temps de traitement du paiement revient à deux cents millisecondes.
Résultat : le taux d'abandon au paiement revient à quinze pour cent.
Impact business : cinq mille paiements par mois avec quinze pour cent d'abandon, cela fait sept cent cinquante conversions perdues. Avec une valeur de commande de cent dollars, cela représente soixante-quinze mille dollars perdus par mois. Corriger le problème de latence a fait économiser soixante-quinze mille dollars par mois à l'entreprise.
Questions fréquentes
Comment savoir si un problème de performance vient du code ou de l'infrastructure ?
Testez les deux. Désactivez le nouveau code (retour en arrière). Si la performance revient à la normale, le code est la cause. Si elle reste lente, l'infrastructure est la cause. Isolez méthodiquement. N'accusez pas l'infrastructure si le code est en cause (ou l'inverse). Avec le créateur de site web de WEMASY, vous le configurez directement sur votre site.
Faut-il revenir en arrière ou corriger quand la performance se dégrade ?
La gravité décide. Si la dégradation est sévère (le LCP passe de deux à cinq secondes), revenez en arrière immédiatement. L'expérience utilisateur est touchée. Corrigez ensuite. Si la dégradation est mineure (le LCP passe de deux à deux virgule trois secondes), corrigez sur place. Le risque d'un retour en arrière est plus faible que celui de déployer une correction incomplète.
Comment éviter que les problèmes de performance n'arrivent en production ?
Faites des tests de performance dans la chaîne CI/CD. Avant chaque déploiement, mesurez la performance. Si le budget de performance est dépassé, bloquez le déploiement. Évitez les régressions avant qu'elles arrivent.
Que faire si le problème de performance est intermittent ?
Les problèmes intermittents sont plus difficiles à diagnostiquer. Collectez plus de données. Surveillez plus longtemps. Un problème intermittent peut indiquer : un souci de réseau (sur les réseaux lents), un souci de trafic (aux heures de pointe), un souci de navigateur (sur certains navigateurs). Réduisez le périmètre. Testez l'hypothèse sur un réseau, une heure, un navigateur précis.
Comment communiquer les problèmes de performance aux utilisateurs ?
La transparence crée la confiance. Si le problème est connu et en cours de correction, dites-le aux utilisateurs. Exemple : dégradation de la performance de la page de paiement à cause de la migration du prestataire de paiement. Correction attendue d'ici demain. Nous enquêtons. La transparence réduit la frustration.
Faut-il avoir un ingénieur performance d'astreinte ?
Pour les sites critiques (boutique en ligne, SaaS), oui. L'ingénieur d'astreinte répond aux alertes de performance dans les trente minutes. Il enquête. Il déploie une correction ou un retour en arrière. Il évite que le problème de performance touche les utilisateurs durablement.