Le site tournait bien. Vous avez ajouté un configurateur produit, un module de fidélité, un chat, une intégration ERP ou « juste un plugin SEO » — et depuis, les pages mettent 2 secondes de plus à charger, le mobile rame, Search Console affiche des Core Web Vitals en baisse. Une performance dégradée après ajout de nouvelles fonctionnalités est l'une des régressions les plus fréquentes que nous voyons chez les PME — et l'une des plus évitables avec une bonne discipline de déploiement.
Chez Apresta, nous intervenons régulièrement en Hauts-de-France sur des sites dont la lenteur date d'un commit précis : une feature utile métier, mal intégrée côté front ou base de données. Le diagnostic ne demande pas de tout rollback — il demande de mesurer avant/après et de corriger le bon goulot.
Symptômes : reconnaître une régression liée à une feature
Une régression feature se reconnaît à une dégradation brutale du LCP, de l'INP ou du score Lighthouse à une date identifiable — souvent le jour d'un déploiement ou d'une activation plugin. La lenteur peut toucher toutes les pages après installation d'un plugin global (SEO, cache, sécurité, cookie), ou seulement certaines pages après ajout d'un module métier (filtres, configurateur, réservation).
Dans DevTools Network, le poids JS ou le nombre de requêtes HTTP augmente. Un TTFB en hausse indique que la feature ajoute des requêtes SQL ou du traitement serveur. Si l'admin CMS ralentit en parallèle, la surcharge vient de PHP ou de la base, pas seulement du front.
Ce qui n'est pas une régression feature : une dégradation progressive sur 6 mois (dette technique, croissance catalogue, logs base), une lenteur saisonnière liée à la charge trafic — voir site qui ralentit en forte affluence — ou un problème depuis toujours sur mobile (assets ou scripts tiers préexistants).
Si vous pouvez dater la dégradation au jour d'un déploiement ou d'une activation plugin, vous gagnez 80 % du diagnostic.
Causes fréquentes : ce que les nouvelles features cassent
Plugins WordPress / modules PrestaShop « fourre-tout »
Un plugin SEO, slider, builder ou popup charge souvent du CSS/JS sur 100 % des pages alors qu'il ne sert que sur 2 templates. Chaque activation ajoute 50 à 300 Ko. C'est la cause la plus fréquente de régression globale après une mise à jour « anodine ».
Requêtes SQL N+1
Une feature « produits similaires », « derniers avis » ou « stock temps réel » qui boucle sur 50 produits génère 50 requêtes par page. Multipliez par le trafic : la base sature, le TTFB explose.
JavaScript synchrone et appels API bloquants
Les intégrations carto, paiement, CRM ou A/B test injectées en blocking script font attendre le rendu. Les vérifications stock ERP, calcul livraison ou taux de change appelées pendant le rendu HTML au lieu d'être cachées ou asynchrones ajoutent des centaines de millisecondes à chaque page.
Cache invalidé ou contourné
Une nouvelle feature qui désactive le cache page — cookies aléatoires, sessions, contenu dynamique partout — ou qui ajoute un Set-Cookie sur toutes les réponses force le serveur à régénérer chaque page. Les assets non optimisés embarqués (images lourdes, polices, icônes Font Awesome complètes pour 3 pictos) alourdissent le chargement.
Conflits entre extensions
Deux plugins qui hookent le même événement, doublons de bibliothèques jQuery, CSS chargés deux fois : le site fonctionne, mais chaque ressource est téléchargée en double.
Diagnostic : retrouver la feature coupable
Le diagnostic commence par une comparaison avant/après. Retrouvez la date de déploiement (Git log, historique CMS, email prestataire). Lancez Lighthouse ou PageSpeed sur les mêmes 4 URLs qu'avant le déploiement. Comparez poids page, nombre de requêtes, TTFB, LCP element et JS total. Si un backup ou staging est disponible, mesurez la version N-1.
L'isolation par désactivation confirme l'hypothèse. En staging — obligatoire — désactivez la feature suspecte et remesurez. Sans staging, désactivez temporairement hors heures creuses avec communication interne. DevTools Performance révèle les Long Tasks apparues après déploiement. Query Monitor (WordPress) ou profil SQL identifient les requêtes ajoutées par la feature.
En revue architecture, posez-vous trois questions : la feature devait-elle être globale ou page-specific ? Existe-t-il une alternative plus légère (API cachée, lazy load, SSR partiel) ? La documentation prestataire annonce-t-elle un impact performance ? Priorisez : feature désactivable et rollback possible en urgent ; requêtes SQL, JS blocking et cache bypass en important ; refactor ou remplacement en plus tard.
Corrections : optimiser sans tout supprimer
Étape 1 — Scope limité : charger la feature où elle sert
Chargez le CSS/JS de la feature uniquement sur les templates concernés (conditional enqueue). N'initialisez pas le configurateur sur l'accueil s'il n'y est pas. Préférez un shortcode ou block lazy au chargement global. Gain typique : 30 à 60 % de JS en moins sur les pages non concernées.
Étape 2 — Optimiser les requêtes base de données
Remplacez les boucles N+1 par une requête JOIN ou un WHERE IN. Mettez en cache le résultat (transient WordPress, cache PrestaShop, Redis) avec un TTL adapté : avis clients 1 h, stock temps réel 30 s à 5 min selon métier. Gain typique : TTFB -500 ms à -2 s sur pages catalogue.
Étape 3 — Différer et async le JavaScript
Utilisez defer ou dynamic import pour scripts non critiques. Chargez au clic ou au scroll pour widgets lourds. Séparez le code critique (above the fold) du reste. Voir INP et réactivité pour les interactions post-chargement.
Étape 4 — Externaliser les appels API en arrière-plan
Ne bloquez pas le HTML sur un appel ERP. Affichez le contenu statique ou caché, rafraîchissez en AJAX si nécessaire. Utilisez une queue pour synchronisations lourdes (import, export).
Étape 5 — Restaurer le cache page
Vérifiez que la feature n'ajoute pas de cookie session sur visiteurs anonymes. Excluez uniquement les pages réellement personnalisées. Purgez le cache à la bonne fréquence. Guide infrastructure : CDN, cache et hébergement.
Étape 6 — Remplacer ou challenger le plugin
Une alternative plus légère (SEO plugin minimal vs suite all-in-one) ou un développement sur mesure ciblé peuvent remplacer un plugin qui charge 80 % de fonctions inutilisées. Budget indicatif remplacement : 1 à 5 jours dev vs des mois de lenteur subie.
Cas B2B à Roubaix : module « devis en ligne » ajouté, +1,8 s TTFB partout — requête stock ERP synchrone sur chaque page. Passage en cache 5 min + appel AJAX page devis uniquement : perf revenue au niveau d'avant, feature conservée.
Prévention : déployer des features sans régression
Avant chaque mise en prod, mesurez Lighthouse baseline sur 4 pages clés avant merge, puis la même mesure après sur staging. Fixez un seuil d'alerte : +300 ms LCP ou +100 Ko JS = revue obligatoire. Testez en mobile 4G throttled, pas seulement desktop fibre.
Côté organisation, un environnement staging miroir de prod est non négociable pour l'e-commerce. Tenez un changelog interne : feature, date, impact perf mesuré. Planifiez une revue trimestrielle des plugins actifs : utilisés vs installés. Incluez la perf dans la maintenance site web récurrente.
Pour choisir un plugin ou prestataire, exigez un poids JS/CSS documenté ou mesurable en demo, un chargement conditionnel natif, une compatibilité cache, un support actif et des avis sur l'impact performance — pas seulement les fonctionnalités.
FAQ
Dois-je désinstaller la feature ou la faire optimiser ?
Désinstallez si elle n'est pas utilisée ou si une alternative 10× plus légère existe. Optimisez si la feature est business-critical (checkout, configurateur, réservation). Dans 60 % des cas, un scope + cache suffisent sans abandonner la fonctionnalité.
Mon prestataire dit que c'est normal d'être plus lent avec plus de features. Est-ce vrai ?
Un léger surcoût est acceptable (+100 à 200 ms) si la feature apporte de la valeur. +2 secondes sur toutes les pages pour un widget avis en footer : non, ce n'est pas normal — c'est une mauvaise intégration.
Comment tester sans environnement staging ?
Créez-en un — hébergement staging coûte 5 à 20 €/mois ou clone temporaire. À défaut, testez en heures creuses avec désactivation rapide et rollback planifié. Ne testez jamais une feature lourde directement en prod un lundi matin.
Les page builders (Elementor, Divi) comptent-ils comme « nouvelle feature » ?
Oui. Passer d'un thème léger à un builder sur toutes les pages est une des plus grosses régressions possibles. Mesurez avant migration, page par page si hybridation possible.
Qui doit valider la perf — marketing ou technique ?
Les deux. Marketing valide l'usage, dev/ agence valide l'impact. Personne ne devrait activer un script GTM ou un plugin sans mesure — même « juste pour essayer ».
Et maintenant ?
Une performance dégradée après ajout de nouvelles fonctionnalités se corrige en identifiant la date, isolant la cause et optimisant scope, cache et requêtes — pas en acceptant la lenteur comme prix du progrès.
Liens utiles :