Pourquoi mon site est lent et comment corriger ça

Si vous attendez que Google vous aime après avoir ajouté un plugin magique, vous êtes déjà mort. Un site lent tue le taux de conversion, la crawlabilité et votre tranquillité. On va décortiquer les causes réelles, les remèdes précis et vous donner des scripts et configs pour agir vite et sûr.

Diagnostiquer : ce que google et vos utilisateurs voient

Vous ne corrigez pas ce que vous ne mesurez pas. La première faute des équipes : partir en optimisation au feeling. Mesurez d’abord. Core Web Vitals, TTFB, First Contentful Paint, Largest Contentful Paint, Interaction to Next Paint/INP, Cumulative Layout Shift — voilà vos cibles. Mais attention aux différences entre lab et field : Lighthouse (lab) reproduit un environnement contrôlé ; PageSpeed Insights vous donne le mix lab+field ; WebPageTest et RUM (GA4, SpeedCurve, Datadog RUM) vous donnent la réalité utilisateur.

Outils à lancer immédiatement :

  • PageSpeed Insights / Lighthouse (CLI)
  • WebPageTest (private instance si possible)
  • Chrome DevTools (waterfall/network/coverage)
  • curl + timings pour mesurer TTFB serveur
  • RUM : Google Analytics 4 ou un lib maison (boomerang-lite)

Commandes utiles :

Script Node/CLI pour lancer Lighthouse en continu (extrait) :

Interprétez les waterfalls : regardez les requêtes qui démarrent le rendu (CSS/JS/font/image above the fold). Repérez les long tasks (Chrome > Performance). Dans la réalité :

  • Si 50% de vos visites ont LCP > 2.5s, vous êtes en danger.
  • Si TTFB > 600ms, commencez par l’infra.
  • Si JS Time on Main Thread > 3s, refactorisez votre bundle.

Anecdote rapide : j’ai vu un e‑com perdre 18% de conversion après avoir ajouté 6 third‑parties. La première optimisation : mesurer, extraire le coupable, retirer. Vous ne voulez pas patcher ce qui n’est pas cassé.

Les coupables fréquents et comment les corriger

Vous voulez des noms. Les voilà : images non-optimisées, polices web non optimisées, JS/CSS bloquants, scripts tiers, mauvaise mise en cache, hébergement cheap, back-end lent. Pour chaque coupable, une action concrète et testable.

Images

  • Convertissez en WebP/AVIF, générez des srcset responsives, appliquez lazy-loading (loading="lazy").
  • Tools : Squoosh, imagemin, sharp. Exemple de commande sharp : 
    const sharp = require('sharp');

    sharp(‘image.jpg’).resize(1200).webp({quality:80}).toFile(‘image-1200.webp’);

     

    Fonts

  • Preconnect vers les CDNs de fonts, font-display: swap, subset des glyphs, hébergement sur CDN si nécessaire.
  • Exemple dans le head : 
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

    <link href= »https://fonts.googleapis.com/css2?family=Inter:wght@400;600&amp;display=swap » rel= »stylesheet »>

     

    CSS/JS bloquants

  • Inlinez le critical CSS pour la page d’accueil, defer/async le reste. Créez un build qui extrait le critical. Tools : Penthouse, Critical, CriticalCSS.
  • Utilisez type="module" pour servir des modules modernes aux navigateurs modernes et nomodule pour legacy.Third‑parties
  • Auditez : qui appelle Facebook, Tag Manager, ad networks ? Retardez leur chargement après interaction ou mettez-les dans un container asynchrone/iframe.Cache & compression
  • Activez Brotli ou Gzip, mettez des headers Cache-Control longs pour assets statiques et un cache purge mécanisme pour les invalidations.
  • Nginx example: 
    gzip on;

    gziptypes text/plain text/css application/javascript application/json image/svg+xml;

     

    brotli on;

     

    brotlitypes text/plain text/css application/javascript;

     

    Backend inefficace

  • Analysez les requêtes DB lentes (EXPLAIN), indexez, mettez un layer Redis si nécessaire. Vérifiez les logs slowquery et les erreurs PHP-FPM.

Chaque optimisation doit être mesurée avant/après. Faites un A/B technique : un rollback doit être possible en 30 minutes.

Optimisation côté serveur et infrastructure

La vitesse commence au réseau et au serveur. Un bon front sans infra solide, c’est de la poudre aux yeux. Principes : réduire la latence réseau (CDN, HTTP/3), réduire le temps de calcul sur l’origine (cache, microcaching, optimisation DB), et servir les assets depuis l’edge.

CDN et HTTP/3

  • CDN = distribution + TLS termination + cache proche de l’utilisateur. Activez HTTP/3/QUIC si possible. Vous réduisez RTT et améliorez handshake TLS.
  • Mesure : passer d’un origin seul à CDN peut faire chuter le TTFB médian de 400–1200ms à 30–80ms selon la géo.

Caches

  • Types : Browser cache, CDN cache, reverse proxy cache (Varnish/nginx), application cache (Redis/OPcache). Table synthétique :

Nginx fastcgi + microcache (extrait) :

Base de données

  • Activez slowquerylog, corrigez les requêtes lentes via EXPLAIN. Exemple : 
    SET global slowquerylog = 1;

    SET global longquerytime = 0.5;

     

    PHP/Python tuning

  • Réduisez les cold starts : PHP-FPM avec pm.maxchildren adapté, OPcache activé, workers Node/ASGI préchauffés. Sur des architectures serverless, utilisez warmers ou préchauffage lors des déploiements.

Autoscaling & observabilité

Pour optimiser l’efficacité de l’autoscaling, il est essentiel de comprendre comment le trafic peut varier au fil du temps. Un audit SEO approfondi peut révéler des problèmes courants qui affectent la performance du site. De plus, il est important de se demander pourquoi certains backlinks ne génèrent pas de trafic. Pour explorer cette question, consulter l’article sur le manque de résultats des backlinks peut s’avérer utile. Enfin, il ne faut pas perdre de vue que même des contenus bien rédigés peuvent ne pas attirer le trafic naturel espéré. Pour en savoir plus sur ce sujet, l’article sur les raisons du manque de trafic naturel apporte des éclaircissements précieux.

  • Mise en place d’alertes sur TTFB/LCP et autoscaling basé sur latence. Sans monitoring, vous naviguez à vue.

Anecdote : pour un site à fort trafic, on a placé un microcache de 10s sur les pages produits — résultat : TTFB médian divisé par 6 pendant les pics, sans perte de fraîcheur critique.

Javascript et rendu : prenez le contrôle du thread

Le vrai boulet de la plupart des sites modernes : trop de JS, mal orchestré. Votre bundle est souvent l’ennemi public numéro 1. L’objectif : réduire le Main Thread Work et la quantité de code hydraté inutile.

Stratégies efficaces

  • Server-Side Rendering (SSR) ou Static-Site Generation (SSG) pour réduire le JavaScript initial. Si vous êtes sur React/Vue/Angular, utilisez Next.js/Nuxt/Remix/Astro.
  • Adoptez islands architecture (Astro) ou progressive hydration pour hydrater uniquement ce qui nécessite de l’interactivité.
  • Code-splitting et dynamic imports : ne chargez pas la librairie de chat avant que l’utilisateur n’interagisse.
  • Évitez les polyfills larges : servez-les conditionnellement via feature-detection.

Outils pour analyser votre bundle

  • source-map-explorer, webpack-bundle-analyzer, Vite’s visualizer.
  • Commande : npx source-map-explorer dist/main..js

Exemple de dynamic import :

Minimiser les tâches longues

  • Détectez les Long Tasks (>50ms) avec Performance API ou Lighthouse. Fractionnez via requestIdleCallback, setTimeout(...,0) ou web workers pour dégager le main thread.
  • Exemple : déplacer les parses lourds en web worker.

Politiques d’hydratation

  • Hydrate seulement ce qui est visible et interagit. Priorisez l’input et les boutons clés en priorité. Tout le reste peut attendre.

Chiffres parlants : diminuer l’exécution JS de 5s à 1.2s peut améliorer LCP de 1s–2s et réduire INP de façon spectaculaire. Vous gagnez en SEO et en conversions.

Surveillance, tests continus et checklist d’exécution

La performance est un processus, pas un sprint. Mettez en place un pipeline de tests, des budgets et une surveillance continue.

Checklist opérationnelle (à exécuter en 1 heure)

  • Lancer Lighthouse CLI et comparer avec la baseline.
  • Exécuter curl -w pour TTFB et vérifier anomalies.
  • Audit des 10 premières requêtes dans le waterfall (DevTools).
  • Vérifier les headers: Cache-Control, Content-Encoding, Strict-Transport-Security.
  • Tester RUM : vérifier distribution LCP/CLS/INP sur GA4.
  • Désactiver 1 third‑party suspect et mesurer l’impact.

Exemples automatisables

  • Lighthouse CI config (extrait .lighthouserc.json) : 
    {

    « ci »: {

     

    « collect »: [{ « url »: « https://votresite.tld« , « numberOfRuns »: 3 }],

     

    « assert »: { « assertions »: { « largest-contentful-paint »: [« error », {« maxNumericValue »: 2500}] } }

     

    }

     

    }

     

  • GitHub Action pour Lighthouse : exécuter sur PR et bloquer si budget dépassé.

Budgets et alertes

  • Définissez des budgets : max JS bundle 200KB, LCP < 2.5s pour 75% des sessions. Créez des alertes dans Datadog / Grafana si les SLO échouent.

RUM + Lab = vérité

  • Usez du RUM pour détecter régions problématiques ; usez du lab pour reproduire et fixer. Conservez des snapshots avant/après et documentez chaque changement dans un ticket.

Conclusion opérationnelle

Vous avez maintenant la méthode : mesurer, détecter, corriger, automatiser. Ne laissez pas la perception guider vos choix ; laissez les metrics trancher. Faites ces actions, validez avec RUM/Lab, répétez. Si vous hésitez encore : retirez les third‑parties, activez CDN, et réduisez JS. Le reste suit.

Gagnez du temps, récupérez des conversions. Vous voulez des résultats ? Passez à l’action. Le Web ne pardonne pas l’inaction.