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 cause principale qu'il signale — généralement des images surdimensionnées, un JavaScript trop lourd, des polices volumineuses ou des scripts tiers. Visez les cibles « bonnes » des Core Web Vitals de Google : contenu principal visible en 2,5 secondes ou moins, réaction aux touchers en 200 millisecondes ou moins, et presque aucun saut de mise en page. La plupart des sites y arrivent avec une poignée de changements, et non une réécriture.

Mesurer avant de changer quoi que ce soit

Deviner fait perdre du temps. Deux outils gratuits couvrent presque tous les cas :

PageSpeed Insights (pagespeed.web.dev) — collez une URL en ligne. Il affiche les données de terrain provenant de vrais utilisateurs de Chrome (si votre site a assez de trafic) et les données de laboratoire issues d'un chargement simulé, plus une liste de problèmes précis.
Lighthouse dans les outils de développement de Chrome — le même test de laboratoire, exécutable sur toute page accessible, y compris un aperçu. Testez en mode mobile ; les téléphones sur des réseaux plus lents sont là où 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 centile des chargements de page :

Mesure	Ce qu'elle mesure	Bon
Largest Contentful Paint (LCP)	La rapidité d'apparition du contenu principal (image d'accueil, titre)	2,5 s ou moins
Interaction to Next Paint (INP)	La rapidité de réaction de la page aux clics, aux touchers et à la saisie	200 ms ou moins
Cumulative Layout Shift (CLS)	L'ampleur des sauts de mise en page pendant le chargement	0,1 ou moins

L'INP a remplacé l'ancienne mesure First Input Delay en 2024. Si un outil affiche encore le FID, il est périmé.

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

Où passe le temps : options et compromis

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

Cause	Correction habituelle	Compromis
Images volumineuses	Redimensionner à la taille affichée, compresser, utiliser WebP ou AVIF	Légère perte de qualité si la compression est excessive
Images chargées dans le mauvais ordre	Charger paresseusement les images sous la ligne de flottaison ; donner la priorité à l'image d'accueil	Aucun, si l'image d'accueil n'est pas chargée paresseusement
Trop de JavaScript	Découper le code par page, retirer les bibliothèques inutilisées	Un certain travail de refactorisation
Rendu uniquement côté client	Pré-rendre ou rendre côté serveur les pages publiques	Plus de configuration de build ou de serveur
Polices web	Moins de familles et de graisses, précharger la principale, `font-display: swap`	Moins de variété typographique
Scripts tiers	Retirer ceux qui ne servent pas, charger les autres après la page	Perdre un widget ou un outil de suivi
Réponse lente du serveur	Mise en cache, un CDN, hébergement statique pour les pages de contenu	Gestion de l'invalidation du cache à prévoir

Images

Les images sont le problème le plus courant et le plus facile à 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 règle la plupart des décalages de mise en page.
Chargez paresseusement les images sous la ligne de flottaison avec loading="lazy".
Ne chargez jamais paresseusement l'image principale en haut de page. Les consignes LCP de Google sont catégoriques à ce sujet : charger paresseusement l'image LCP la retarde toujours. Donnez-lui plutôt fetchpriority="high".

JavaScript

Beaucoup de sites construits par l'IA sont des applications monopages (SPA) : le navigateur télécharge un paquet JavaScript puis dessine la page. Plus le paquet est gros, plus l'écran reste vide longtemps. Les corrections, de la moins exigeante à la plus exigeante :

Retirez ce que vous n'utilisez pas. Demandez la liste des dépendances et supprimez les bibliothèques ajoutées une fois puis oubliées — une bibliothèque de dates pour une seule date, un jeu complet d'icônes pour cinq icônes.
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.
Pré-rendez les pages publiques. Une page de marketing livrée en HTML réel apparaît avant que tout JavaScript ne s'exécute. Cela aide aussi les moteurs de recherche ; voir le référencement pour les sites web construits avec l'IA.

Un INP lent signifie généralement une longue tâche qui bloque la page — filtrer une très longue liste à chaque frappe, ou réafficher tout un tableau lorsqu'une seule cellule change. Le panneau Performances des outils de développement de Chrome montre lesquelles.

Polices

Chaque famille de polices et chaque graisse est un fichier de plus. Deux familles et trois ou quatre graisses suffisent généralement. 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 vous-même les polices si le service externe est lent pour vos visiteurs.

Scripts tiers

Les widgets de clavardage, l'analytique, les cartes de chaleur, les pixels publicitaires, les vidéos intégrées et les fils de médias sociaux chargent tous du code depuis d'autres serveurs. Chacun semble 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 charge le vrai contenu au clic.

Réponse du serveur

Le temps jusqu'au premier octet (TTFB) — le délai avant que le serveur commence à répondre — se trouve sous 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 qu'un serveur construit à chaque requête dépendent de ce serveur et de sa base de données. La mise en cache du travail répété et l'ajout d'index de base de données pour les requêtes lentes sont les corrections habituelles.

Requêtes qui fonctionnent

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

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

Audite les dépendances de cette app. Liste chaque paquet, ce qui l'utilise et à peu près ce qu'il ajoute au paquet JavaScript. Retire ceux qui ne servent pas et découpe les routes /admin et /settings en fragments distincts qui ne se chargent que lorsqu'on les visite.

La boîte de recherche sur /produits est lente à réagir. Ajoute un délai (debounce) au 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

Testez la page en ligne dans PageSpeed Insights sur mobile. Notez le LCP, l'INP et le CLS, ainsi que les trois principaux problèmes listés.
Corrigez les images d'abord : tailles, formats, dimensions, chargement paresseux sous la ligne de flottaison, priorité pour l'image d'accueil.
Retirez les scripts tiers que vous n'utilisez pas, et reportez les autres.
Réduisez les polices à ce dont le design a besoin.
Allégez le JavaScript : retirez les paquets inutilisés, découpez par route.
Pré-rendez les pages publiques si elles sont encore rendues côté client et que le LCP reste lent.
Vérifiez le serveur : mise en cache, index de base de données, hébergement statique pour le contenu qui change rarement.
Republiez et retestez. Les données de terrain dans PageSpeed Insights se mettent à jour pendant les semaines suivantes, à mesure que les visites réelles arrivent ; jugez donc 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 irrégulières. Testez en mode mobile.
Chercher un 100 parfait. Le score de laboratoire est un guide. Une fois les Core Web Vitals dans la plage « bonne », le contenu et la facilité d'utilisation comptent davantage que les derniers points.
Charger paresseusement tout, y compris l'image d'accueil. Cela aggrave le LCP.
Ajouter un plugin ou une bibliothèque d'accélération par-dessus. 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, chaque image et chaque fonction ajoute du poids. Retestez après les gros changements.

Liste de contrôle de vitesse

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

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

La vitesse sur Mythex

Sur Mythex, vous apportez ces changements en le demandant dans le clavardage, ou dans l'éditeur de code avec le forfait 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 lorsque vous publiez (sites statiques), ce qui convient aux pages de contenu. Les apps dotées d'un serveur se mettent en veille 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 rattachée se met en veille après 5 minutes d'inactivité (limites d'hébergement). Si une page publique n'est lente qu'à la première visite, c'est la cause probable. Garder les pages de marketing statiques aide. Après les changements, publiez à nouveau et faites un rechargement complet.

Questions

Quel est un bon temps de chargement de page ?

Les Core Web Vitals de Google donnent les cibles les plus claires : le contenu principal doit apparaître en 2,5 secondes ou moins (LCP), la page doit réagir à une action en 200 millisecondes ou moins (INP), et le décalage de mise en page doit rester à 0,1 ou moins (CLS), mesuré au 75e centile des visites réelles.

La vitesse du site influence-t-elle le référencement ?

Oui, un peu. Google utilise des signaux d'expérience de page, dont les Core Web Vitals, mais le contenu pertinent compte bien davantage. La vitesse influence davantage les visiteurs, qui quittent les pages lentes avant même de lire quoi que ce soit.

Pourquoi mon score PageSpeed Insights change-t-il à chaque fois ?

Le score de laboratoire provient d'un seul chargement simulé ; les délais du réseau et du serveur varient donc d'une exécution à l'autre. Lancez le test plusieurs fois et observez la tendance, et accordez plus de poids à la section des données de terrain, qui provient de vrais utilisateurs de Chrome.

Qu'est-ce qui ralentit le plus la plupart des sites web ?

Habituellement, des images surdimensionnées, un JavaScript trop lourd, des polices web et des scripts tiers comme les widgets de clavardage, les pixels publicitaires et les intégrations. Une réponse lente du serveur ou un backend qui démarre à froid s'ajoute à tout cela.