Comment rendre votre site web plus rapide : une liste de contrôle pratique

Pour rendre un site web plus rapide, mesurez-le d'abord avec PageSpeed Insights, puis corrigez la principale cause qu'il signale — généralement des images trop lourdes, trop de JavaScript, des polices volumineuses ou des scripts tiers. Visez les objectifs « bons » des Core Web Vitals de Google : contenu principal visible en 2,5 secondes, réaction aux appuis en 200 millisecondes, et presque aucun saut de mise en page. La plupart des sites y arrivent avec une poignée de modifications, sans refonte.

Mesurer avant de changer quoi que ce soit

Deviner fait perdre du temps. Deux outils gratuits suffisent presque toujours :

• PageSpeed Insights (pagespeed.web.dev) — collez une URL en ligne. Il affiche les données terrain issues de vrais utilisateurs de Chrome (si votre site a assez de trafic) et les données de laboratoire issues d'un chargement simulé, ainsi qu'une liste de problèmes précis.
• Lighthouse dans les outils de développement de Chrome — le même test de laboratoire, lancé sur n'importe quelle page accessible, y compris un aperçu. Testez en mode mobile : c'est sur les téléphones et les réseaux lents que les problèmes apparaissent.

Les chiffres qui comptent sont les Core Web Vitals de Google. En septembre 2026, la documentation de Google sur web.dev donne ces seuils « bons », mesurés au 75e percentile des chargements de page :

L'INP a remplacé l'ancien indicateur First Input Delay en 2024. Si un outil affiche encore le FID, il est obsolète.

Notez vos chiffres de départ. Après chaque correction, retestez pour savoir ce qui a aidé.

Où le temps se perd : options et compromis

Chaque cause courante a une solution, et chaque solution a un coût. Commencez par celles du haut : ce sont les moins coûteuses et les plus fréquentes.

Images

Les images sont le problème le plus courant et le plus simple à corriger. Une photo de 4 000 pixels affichée à 800 pixels de large oblige chaque visiteur à télécharger cinq fois plus que ce qu'il voit.

• Servez les images à la taille à laquelle elles sont affichées, avec des tailles srcset adaptatives pour les téléphones et les ordinateurs.
• Utilisez des formats modernes (WebP ou AVIF) et une compression raisonnable.
• Définissez width et height sur chaque image pour que le navigateur réserve l'espace. Cela seul corrige la plupart des décalages de mise en page.
• Chargez en différé les images sous la ligne de flottaison avec loading="lazy".
• Ne chargez jamais en différé l'image principale en haut de page. Les recommandations LCP de Google sont claires : le chargement différé de l'image LCP la retarde toujours. Utilisez plutôt fetchpriority="high".

JavaScript

De nombreux sites créés par l'IA sont des applications monopage (SPA) : le navigateur télécharge un paquet JavaScript puis dessine la page. Plus le paquet est gros, plus l'écran reste blanc longtemps. Les corrections, par ordre d'effort :

1. Supprimez ce que vous n'utilisez pas. Demandez la liste des dépendances et retirez les bibliothèques ajoutées une fois puis oubliées — une bibliothèque de dates pour une seule date, un pack d'icônes complet pour cinq icônes.
2. Découpez par route. Chargez le code du tableau de bord d'administration seulement lorsque quelqu'un l'ouvre, et non sur la page d'accueil.
3. Pré-rendez les pages publiques. Une page marketing livrée en HTML réel s'affiche avant que tout JavaScript ne s'exécute. Cela aide aussi les moteurs de recherche ; voir le SEO pour les sites créés avec l'IA.

Un INP lent signale généralement une longue tâche qui bloque la page : filtrer une liste énorme à chaque frappe, ou réafficher tout un tableau quand une seule cellule change. Le panneau Performance des outils de développement de Chrome indique laquelle.

Polices

Chaque famille et chaque graisse de police est un fichier supplémentaire. Deux familles et trois ou quatre graisses suffisent souvent. Précharger la police utilisée au-dessus de la ligne de flottaison, utiliser font-display: swap pour que le texte s'affiche immédiatement, et héberger soi-même les polices si le service externe est lent pour vos visiteurs.

Scripts tiers

Les widgets de chat, l'analyse d'audience, les cartes de chaleur, les pixels publicitaires, les vidéos intégrées et les flux sociaux chargent tous du code depuis d'autres serveurs. Chacun paraît petit ; ensemble, ils constituent souvent la partie la plus lente de la page. Gardez ceux que vous consultez réellement. Chargez les autres une fois la page interactive, et remplacez les intégrations lourdes (un lecteur YouTube, une carte) par un aperçu léger qui ne charge le vrai contenu qu'au clic.

Réponse du serveur

Le délai avant le premier octet (TTFB) — le temps que met le serveur à commencer à répondre — est sous-jacent à toutes les autres mesures. Les pages statiques servies depuis un CDN (un réseau de serveurs proches de vos visiteurs ; voir qu'est-ce qu'un CDN) sont rapides presque partout. Les pages générées par un serveur à chaque requête dépendent de ce serveur et de sa base de données. La mise en cache des traitements répétés et l'ajout d'index de base de données pour les requêtes lentes sont les corrections habituelles.

Des prompts qui fonctionnent

Soyez précis : nommez la page, l'indicateur et la contrainte. Collez les constats de PageSpeed Insights si vous les avez.

PageSpeed Insights indique un LCP de 4,8 s sur mobile pour la page d'accueil, et l'élément LCP est l'image d'en-tête. Redimensionne et convertis l'image d'en-tête en WebP, sers des tailles adaptatives, définis width et height, donne-lui fetchpriority="high" et assure-toi qu'elle n'est pas en chargement différé. Charge en différé chaque image sous la ligne de flottaison. Ne modifie pas le design.

Audite les dépendances de cette application. Liste chaque paquet, ce qui l'utilise et ce qu'il ajoute approximativement au bundle. Supprime ceux qui ne sont pas utilisés et découpe les routes /admin et /settings en morceaux distincts qui ne se chargent que lorsqu'on les visite.

La boîte de recherche sur /products est lente à réagir. Temporise le filtre, évite de réafficher toute la liste à chaque frappe, et pagine ou virtualise la liste si elle contient plus de 200 éléments.

Étape par étape

1. Testez la page en ligne dans PageSpeed Insights en mode mobile. Notez le LCP, l'INP et le CLS, ainsi que les trois principaux problèmes signalés.
2. Corrigez d'abord les images : tailles, formats, dimensions, chargement différé sous la ligne de flottaison, priorité pour l'image d'en-tête.
3. Retirez les scripts tiers que vous n'utilisez pas, et reportez les autres.
4. Réduisez les polices à ce que le design exige.
5. Allégez le JavaScript : supprimez les paquets inutilisés, découpez par route.
6. Pré-rendez les pages publiques si elles sont encore rendues côté client et que le LCP reste lent.
7. Vérifiez le serveur : mise en cache, index de base de données, hébergement statique pour les contenus qui changent rarement.
8. Republiez et retestez. Les données terrain de PageSpeed Insights se mettent à jour pendant les semaines suivantes, à mesure que les visites réelles arrivent ; jugez les premiers résultats d'après les données de laboratoire.

Erreurs courantes

• Tester seulement sur un ordinateur portable rapide. Vos visiteurs utilisent des téléphones de milieu de gamme et des données mobiles instables. Testez en mode mobile.
• Viser un 100 parfait. Le score de laboratoire est un guide. Une fois les Core Web Vitals dans la plage « bon », le contenu et l'utilisabilité comptent davantage que les derniers points.
• Charger en différé tout, y compris l'image d'en-tête. Cela dégrade le LCP.
• Ajouter un plugin ou une bibliothèque d'accélération. Retirer du poids l'emporte presque toujours sur l'ajout de code pour le gérer.
• Optimiser l'aperçu, et non le site en ligne. Les aperçus de développement utilisent des builds non optimisés. Mesurez l'URL publiée.
• Corriger la vitesse une seule fois. Chaque nouveau widget, image et fonction ajoute du poids. Retestez après les gros changements.

Liste de contrôle de la vitesse

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 sur mobile
• Images redimensionnées, compressées, au format moderne, avec width et height
• Image d'en-tête non chargée en différé ; images sous la ligne de flottaison chargées en différé
• Aucune bibliothèque JavaScript inutilisée ; routes lourdes séparées
• Deux familles de polices au maximum, police principale préchargée
• Seulement les scripts tiers utilisés, chargés tardivement
• Pages publiques pré-rendues ou statiques lorsque c'est possible
• Retesté sur l'URL en ligne après publication

La vitesse et la mise en page mobile vont de pair ; voir comment rendre un site web adaptatif sur mobile. Pour une revue complète avant lancement, comment passer d'un prototype IA à la production couvre le reste.

La vitesse sur Mythex

Sur Mythex, vous effectuez ces modifications en les demandant dans le chat, ou dans l'éditeur de code avec Pro. Vérifiez l'URL publiée, et non l'aperçu, car l'aperçu fait tourner un serveur de développement. Les interfaces statiques se déploient comme des sites statiques lors de la publication (sites statiques), ce qui convient aux pages de contenu. Les applications avec serveur s'endorment lorsqu'elles sont inactives et se réveillent à la visite suivante ; la première requête après une période calme est donc plus lente, et une base de données attachée se met en veille après 5 minutes d'inactivité (limites d'hébergement). Si une page publique n'est lente que lors de la première visite, c'est la cause probable. Garder les pages marketing statiques aide. Après les modifications, republiez et rafraîchissez la page en forçant le rechargement.

Questions