Vitesse du site: images, polices et scripts tiers
Pourquoi un site charge lentement tient souvent à trois causes: images trop lourdes, polices tardives et scripts tiers accumulés. Que corriger en premier.
Équipe rabbitclipPublié: 6 min de lecture
En bref
Un site qui charge lentement n'a rarement qu'une seule cause; il s'agit le plus souvent de la somme de trois sources: des images plus lourdes que nécessaire, des polices qui retardent l'affichage de la page, et des scripts tiers qui s'accumulent avec le temps. Corriger les trois ensemble fait une différence nette; en corriger un seul suffit rarement.
Google ne mesure plus la vitesse uniquement à la rapidité d'affichage d'une page; il mesure aussi la rapidité de réaction de l'écran dès qu'un visiteur touche un bouton. Cette mesure s'appelle Interaction to Next Paint, ou INP (web.dev, INP). La vitesse ne se résume donc plus à «la page s'est-elle chargée», mais à «la page est-elle réellement utilisable».
Cet article traite les trois sources l'une après l'autre: images, polices, code tiers. Pour chacune, par où commencer et ce qui change vraiment la donne.
Pourquoi les images portent la plus grande charge
L'essentiel du poids total d'une page vient généralement des images. Prenons la galerie produits d'un fabricant de revêtements de sol: une page de cinquante mégaoctets signifie plusieurs secondes d'attente selon l'appareil et la connexion du visiteur. Ce poids ne disparaît que si l'image est servie à la bonne taille et dans le bon format.
La solution tient en deux étapes. D'abord, l'image est recadrée à la taille où elle apparaît réellement; une image affichée à quatre cents pixels de large sur téléphone ne doit pas être envoyée à deux mille pixels. Ensuite, le format est choisi: AVIF et WebP produisent des fichiers bien plus légers que l'ancien JPEG à qualité comparable (web.dev, Optimize LCP). Un framework comme Next.js automatise cette étape, sans que personne n'ait à préparer plusieurs versions à la main.
Pourquoi les polices ralentissent une page
Une police personnalisée fait partie de l'identité d'une marque, mais mal chargée, elle retarde l'affichage de la page. Si le navigateur masque le texte jusqu'au téléchargement du fichier de police, le visiteur voit un écran vide pendant une seconde ou deux; on appelle cela le flash de texte invisible.
Le réglage font-display: swap supprime cette attente: le navigateur affiche aussitôt le texte dans une police système, puis la remplace par la police personnalisée dès qu'elle arrive (web.dev, Best practices for fonts). La page de réservation d'une chaîne de spas n'a parfois besoin que de deux graisses, normale et grasse, alors que le fichier de conception en transporte souvent cinq ou six telles quelles sur le site en ligne; chaque graisse supplémentaire est un téléchargement de plus.
Pourquoi les scripts tiers sont la charge la plus sournoise
Outils d'analyse, fenêtres de chat en direct, pixels publicitaires, intégrations de réseaux sociaux: chacun ajoute à la page un fichier JavaScript externe. Ils s'accumulent en silence; un site avec cinq ou six outils différents ajoutés en un an n'a rien d'exceptionnel.
Le problème est que ces scripts occupent le fil principal du navigateur; tant que ce code s'exécute, le navigateur ne peut pas répondre au clic d'un visiteur, ce qui dégrade directement l'INP (web.dev, INP). Revoir la liste des outils utilisés tous les quelques mois, et retirer un tableau d'analyse que plus personne ne consulte ou un widget de chat que plus personne n'utilise, vaut bien les dix minutes que cela prend.
Dans quel ordre corriger
Il n'est pas nécessaire de corriger les trois sources en même temps; un ordre facilite le travail.
- Mesurer l'état actuel avec PageSpeed Insights ou la Search Console
- Amener les plus grandes images visibles sans défilement à la bonne taille et au bon format
- Réduire le nombre de graisses de police, ajouter font-display: swap
- Retirer les scripts tiers inutilisés, ne charger le reste qu'en cas de besoin
- Mesurer de nouveau avec le même outil après la modification
La vitesse est-elle seulement une question technique
La vitesse est aussi une décision marketing, car c'est le premier contact du visiteur avec le site. Si la page d'intervention d'urgence d'un fabricant de groupes électrogènes charge lentement, le visiteur retourne au résultat de recherche et essaie l'entreprise suivante; cette perte se produit en silence, sans réclamation ni rapport de taux de rebond que quelqu'un lirait.
Le travail sur la vitesse n'est pas un projet ponctuel; il relève de la maintenance continue. La même discipline s'applique dès qu'un nouvel outil est ajouté ou qu'une nouvelle image est mise en ligne.
Ce que Next.js 16 et React 19 changent pour la vitesse
Next.js 16 et React 19, désormais courants en 2026, poussent davantage les composants serveur: l'essentiel d'une page est préparé sur le serveur et envoyé au navigateur déjà fini, ce qui réduit la quantité de JavaScript que le navigateur doit télécharger. C'est un choix d'architecture qui améliore directement l'INP.
Pour le catalogue produits d'un fabricant qui compte des centaines de pages, la différence est concrète: avec une ancienne configuration React, chaque page se réaffiche dans le navigateur; avec la nouvelle architecture, la page arrive déjà prête et le navigateur ne prend en charge que les parties interactives, un filtre, un bouton d'ajout au panier. Au moment d'évaluer un tel changement, cette différence d'architecture entre dans le budget vitesse, pas seulement dans le rafraîchissement visuel.
Pourquoi la mise en cache côté serveur fait une différence
Une page générée une fois et conservée en cache pendant une durée fixe, plutôt que reconstruite à chaque visite, atteint les visiteurs suivants bien plus vite. C'est un gain qui vaut la peine pour toute page dont le contenu ne change pas souvent, une page à propos, une description de service.
Un calendrier d'événements sur le site d'une association professionnelle, mis à jour souvent, a besoin d'une courte durée de cache; une page institutionnelle statique peut conserver la même version en cache pendant des heures, voire des jours. La bonne durée dépend de la fréquence réelle des changements de contenu.
Un cache mal configuré crée ses propres problèmes: un ancien prix qui reste en cache et continue de s'afficher un moment après une mise à jour, par exemple. C'est pourquoi le moment et la manière de vider le cache après une mise à jour doivent être planifiés dès le départ.
Images, polices et scripts tiers, pris ensemble, rendent une page plus rapide à charger et plus réactive au clic. Lors d'un premier échange, rabbitclip établit un rapport de vitesse du site actuel afin de voir ensemble quelle source coûte le plus cher.
Questions fréquentes
Où puis-je mesurer la vitesse de mon site?
Google PageSpeed Insights et le rapport Core Web Vitals de la Search Console donnent des mesures distinctes pour mobile et ordinateur.
L'AVIF fonctionne-t-il dans tous les navigateurs?
La plupart des navigateurs récents le prennent en charge; un site peut être configuré pour servir l'AVIF là où c'est possible et basculer automatiquement vers WebP ou JPEG ailleurs.
Combien de scripts tiers deviennent excessifs?
Il n'existe pas de chiffre fixe; chaque script supplémentaire a un coût, d'où l'intérêt de vérifier régulièrement si chacun sert encore réellement.
font-display: swap abîme-t-il l'apparence de la police de marque?
Non, une police système s'affiche brièvement le temps du téléchargement, puis la police de marque prend le relais peu après.
Passer à Next.js 16 suffit-il à lui seul pour la vitesse?
Non, ce changement d'architecture aide de façon notable, mais sans discipline sur les images, les polices et les scripts, cela ne suffit pas.
