Améliorer les performances d’un site internet

WebP/AVIF : qu’apportent-ils de plus que JPEG ou PNG ?

Les formats WebP et AVIF permettent de compresser une image bien plus qu’un JPEG ou PNG traditionnel, tout en conservant une bonne qualité visuelle. Résultat : vos pages chargent plus vite, surtout sur mobile ou avec des connexions modestes.

Les conseil pour convertir vos images automatiquement

• Convertir automatiquement : Sur WordPress, il existe des plugins comme Litespeed Cache, Imagify, ShortPixel ou Optimole qui gèrent la conversion en WebP/AVIF et le redimensionnement automatique.
• Détecter la compatibilité navigateur : La plupart des plugins gèrent automatiquement la rétrocompatibilité pour les navigateurs qui ne supportent pas encore ces formats. Attention les formats WebP ne sont pas très bien compatibles avec Safari (iOS). Il est préférable de switcher pour une version jpeg sur ces navigateurs.
• Tester la qualité : Vérifiez qu’il n’y ait pas trop d’artefacts, mais en règle générale, WebP et AVIF restent très fiables.

Compression contrôlée : trouver l’équilibre qualité/poids

Même si vous ne convertissez pas forcément toutes vos images en WebP ou AVIF, il est possible de réduire considérablement la taille de vos JPEG ou PNG. Une compression dite “lossy” bien réglée (environ 70 % à 80 % de qualité) est souvent indétectable à l’œil nu, mais apporte des gains de performance notables.

Solutions

1. Outils en ligne (TinyPNG, Squoosh, Kraken.io) ou plugins WordPress (Smush, Imagify) pour automatiser l’optimisation.
2. Équilibrer compression et qualité : Faire des tests A/B pour trouver le niveau de compression optimal.
3. Surveiller les nouvelles images : La tentation est grande d’uploader directement sa photo depuis un smartphone. Mettez en place un processus qui compresse avant publication.

Pourquoi surdimensionner un visuel ruine la performance

Si votre page affiche une image en 300 × 300 pixels, mais que vous avez importé une image de 3 000 × 3 000 pixels, le navigateur va tout de même télécharger la version XXL (plus lourde), avant de la redimensionner à l’affichage. C’est une perte de temps et de bande passante considérable.

Le “mugshot” de 5 000 px : le mauvais exemple

Sur un site vitrine, la page “À propos” contient un portrait du gérant. L’image est un gros fichier (5 000 px de large !) car le photographe a fourni un tirage HD. Dans le contenu, elle apparaît en 250 px seulement. Résultat : plus de 2 Mo téléchargés pour un simple mugshot. Après redimensionnement à 500 px et compression, on tombe à 80 ko et la page s’est affichée bien plus vite.

Solutions pour le redimensionnement d’images

• Redimensionner avant l’upload : Utilisez un logiciel de retouche (Photoshop, GIMP…) ou des outils en ligne pour adapter la taille de l’image à l’usage prévu.
• Utiliser les balises srcset et sizes : Cela permet de proposer plusieurs tailles d’image et de laisser le navigateur choisir la plus adaptée en fonction de la résolution d’écran de l’utilisateur.
• Limiter la tentation du “full HD” partout : Vérifiez ce qui est vraiment nécessaire pour votre contenu.

Le lazy loading, arme fatale contre l’excès d’images

Le “lazy loading” consiste à ne charger les images qui se trouvent en dehors de la zone visible (en bas de la page, par exemple) que lorsque l’utilisateur fait défiler. Le gain de vitesse initial est énorme, car vous n’alourdissez pas le chargement de la page avec des ressources que l’utilisateur ne voit pas encore.

Exemple

Sur un blog culinaire, la page d’accueil affichait 12 recettes avec des photos très appétissantes, mais lourdes. Avec le lazy loading, seules les 2 ou 3 premières images s’affichaient instantanément. Les suivantes se chargeaient à la volée lors du scroll. PageSpeed Insights est passé de 30 à plus de 80 sur mobile, rien qu’avec cette astuce et un peu de compression.

Plugins WordPress et attributs HTML pour activer le chargement différé

• Plugin WordPress : WP Rocket, a3 Lazy Load ou Lazy Load by WP Rocket permettent d’activer le chargement différé en 1 clic.
• Balise loading="lazy" : Sur les versions récentes de Chrome, Firefox et Edge, vous pouvez ajouter l’attribut loading="lazy" sur les balises <img>.
• Attention aux sliders : Si vous avez un carrousel d’images en haut de page, vérifiez que le lazy loading ne retarde pas l’affichage des premières slides (sinon, l’utilisateur verra un rectangle vide).

Le JS superflu : un fléau pour la vitesse de chargement

JavaScript est plus lourd à interpréter que du HTML ou du CSS. Si vous embarquez des bibliothèques ou des plugins JS entiers pour seulement quelques fonctionnalités, vous ralentissez inutilement le rendu de la page.

Moment.js pour afficher l’heure : le piège classique

Sur un petit site vitrine, le développeur avait chargé la librairie “Moment.js” (65 ko) pour simplement afficher l’heure locale, alors qu’un code JS basique de 2 lignes aurait suffi. De même, jQuery UI était chargé, alors qu’aucun widget UI n’était utilisé. Après avoir retiré tout ça, le site s’est chargé bien plus vite, notamment sur mobile.

Solutions pour désactiver, minifier, et répartir astucieusement le JS

• Passez en revue vos plugins : De nombreux plugins WordPress chargent leur propre JS, même sur des pages qui n’en ont pas besoin. Utilisez un gestionnaire d’actifs (Asset CleanUp, Perfmatters) pour n’activer un plugin que sur la page où il sert réellement.
• Minifiez et concaténez : Regroupez et compressez les fichiers JS, tout en veillant à ne pas casser les dépendances.
• Chargez des scripts seulement au clic : Pour des fonctionnalités peu utilisées, vous pouvez retarder le chargement JS jusqu’à ce que l’utilisateur interagisse (ex. un bouton “Ouvrir la carte”).

Scripts dans le <head> : pourquoi ça bloque tout ?

Si un script est placé dans le <head> et qu’il est considéré comme bloquant, le navigateur suspend l’affichage du reste de la page tant que ce script n’est pas téléchargé et interprété. C’est ce qui peut provoquer une impression d’écran “gelé”.

Exemple d’une galerie photo sophistiquée qui gèle le contenu principal

Imaginez un script de galerie photo sophistiqué, chargé tout en haut du code HTML. Si ce script pèse 300 ko et nécessite des dépendances externes, l’utilisateur ne verra pas le contenu principal avant la fin de ce chargement. Sur un site d’articles de blog, ce n’est pas idéal : le visiteur est venu lire un article, pas forcément lancer la galerie.

Des solutions pour charger les scripts au bon moment

• Placez les scripts en pied de page (</body>) quand c’est possible, ou utilisez l’attribut defer pour qu’ils se chargent en parallèle.
• Identifiez les scripts critiques (ceux qui doivent être chargés immédiatement, comme un menu de navigation) et ceux qui peuvent attendre (outils d’analyse, widgets non essentiels).
• Utilisez un plugin d’optimisation : WP Rocket, par exemple, peut détecter et retarder automatiquement les JS non critiques.

Le poids des polyfills et du code legacy

Les “polyfills” ou scripts de compatibilité pour d’anciens navigateurs peuvent gonfler votre code. Aujourd’hui, la plupart des internautes utilisent des versions modernes de Chrome, Firefox, Safari ou Edge. Continuer à supporter IE9 ou d’autres dinosaures peut sérieusement pénaliser votre performance globale.

Exemple concret d’un bundle JS gonflé pour IE8 : cas concret

Lors d’un audit, j’ai découvert que le bundle principal JS incluait un polyfill pour “Object.assign” et “Promise” spécifiquement pour IE8/IE9, alors que les statistiques de Google Analytics montraient qu’aucun visiteur ne venait de ces navigateurs. Cela représentait plus de 50 ko de JS inutile.

Solutions contre le vieux JS

• Configurez Babel/Webpack pour cibler les navigateurs qui représentent la grande majorité de votre audience (ex. “last 2 versions” de chaque navigateur).
• Surveillez vos stats : Si vous avez réellement besoin de supporter un navigateur ancien, chargez un bundle alternatif uniquement pour ces cas (un “Conditional” JS).
• N’abusez pas des librairies : De nombreuses librairies modernes ont déjà réduit leur support des navigateurs très anciens.

Quand trop de calculs JS gèlent la page

Une fois le code JS téléchargé, il doit être exécuté par le navigateur. Si votre script fait trop de calculs complexes, cela peut geler l’interface. Sur mobile, la puissance de calcul est plus limitée, donc on ressent encore plus cette latence.

Exemple

Sur un site de comparaison de prix, un script devait parcourir un tableau de 10 000 produits et faire des filtres complexes. Il tournait directement au chargement, provoquant un blocage de 2 secondes pendant lequel l’utilisateur ne pouvait pas scroller. Nous avons déplacé cette exécution dans un Web Worker et seul un résumé était affiché sur la page, libérant le thread principal.

Solutions pour fractionner le code et externaliser les tâches lourdes

• Fractionnez votre code : Au lieu de tout exécuter au premier chargement, découpez vos fonctionnalités et chargez-les quand l’utilisateur en a besoin.
• Utilisez des Web Workers : Pour les tâches lourdes en calcul, confiez-les à un thread séparé.
• Optimisez les algorithmes : Si vous devez traiter un grand volume de données, vérifiez que vos boucles ou vos méthodes de filtrage ne sont pas trop gourmandes.

Les “cascades” de dépendances : un frein terrible pour vos performances

Une chaîne critique survient quand un script A a besoin d’un script B, qui lui-même appelle un script C, etc. Le navigateur doit alors télécharger et exécuter chaque maillon de la chaîne avant de pouvoir passer au suivant. Ceci rallonge le temps de rendu de la page.

Exemple : jQuery > jQuery UI > Script X

J’ai vu un cas où un plugin WordPress dépendait de jQuery, lui-même dépendait d’un plugin jQuery UI, qui appelait un autre script de traduction. Tout cela était chargé en série (synchronous loading). Résultat : une attente de plusieurs secondes. En chargeant jQuery de manière asynchrone et en supprimant le plugin jQuery UI non indispensable, on a réduit nettement la cascade.

Solutions pour éviter les chaînes de requêtes critiques

• Évitez les dépendances inutiles : Si un plugin en nécessite un autre, assurez-vous vraiment d’avoir besoin de cette fonctionnalité.
• Charge asynchrone ou “defer” : Permet au navigateur de continuer à parser l’HTML pendant que le script se télécharge.
• Simplifiez la hiérarchie : Parfois, une librairie combinée suffit à gérer plusieurs fonctionnalités, plutôt que d’empiler 4 ou 5 scripts distincts.

Comment de simples listeners peuvent bloquer le scroll

Lorsque vous gérez des événements tactiles ou de scroll (touchstart, scroll…), le navigateur peut attendre la fin de votre code JS pour déterminer si vous allez empêcher le défilement. Avec les “Passive Event Listeners”, vous informez le navigateur que vous n’allez pas bloquer ce comportement. Il peut alors faire défiler la page sans délai d’attente.

Exemple

Sur un site d’actualité, il y avait un effet de parallaxe au scroll. Le script bloquait parfois le défilement sur mobile, créant une sensation de lenteur ou de saccade. En passant certains écouteurs à { passive: true }, le scroll est devenu beaucoup plus fluide.

Solutions pour rendre la navigation plus fluide

• Ajouter { passive: true } dans vos addEventListener, par exemple :

document.addEventListener('touchstart', handleTouch, { passive: true });

• Auditez vos événements : Vérifiez particulièrement ceux qui concernent le défilement (scroll, touchmove, wheel).
• Surveillez la compatibilité : La plupart des navigateurs modernes supportent désormais les écouteurs passifs.

Les bundles JS/CSS de plusieurs Mo : un vrai repoussoir

Même si vous avez un bon “Time to First Byte”, un bundle JavaScript ou un gros fichier CSS de plusieurs mégaoctets peut nécessiter un long téléchargement. Les utilisateurs sur mobile ou en zone rurale percevront fortement ce ralentissement.

Exemple

J’ai audité un site d’e-learning qui chargeait un seul bundle JS de 3,5 Mo, intégrant toutes les fonctionnalités (vidéos, quiz, tracking, etc.) même sur des pages où ces fonctions n’étaient pas utilisées. Sur mobile, c’était un calvaire à charger. On a donc scindé le code en plusieurs parties (“code splitting”), et chaque page charge désormais uniquement ce qui lui est nécessaire.

Solutions

• Code splitting : Segmenter le code en petits fichiers plus ciblés tout en limitant les dépendances.
• Lazy loading : Ne charger un script qu’au moment où l’utilisateur clique sur une fonctionnalité ou ouvre une section spécifique.
• Minimisez les images inlinées : Évitez d’inliner des images en base64 dans un CSS lourd, par exemple.

Trop de <div> tue la performance… et l’accessibilité !

Le DOM est la représentation interne de votre page Web. Plus il est volumineux, plus le navigateur mettra de temps à analyser et à modifier ses éléments. De nombreux “constructeurs” de pages WordPress créent une profusion de <div> imbriqués, ce qui peut gonfler la structure.

Exemple : un bloc texte Elementor noyé sous 6 conteneurs

Un jour, j’ai constaté qu’un simple bloc texte dans Elementor était niché dans une hiérarchie de 6 <div> avant d’atteindre la balise <p> ! Quand la page accumule plusieurs sections comme ça, on se retrouve avec un DOM de milliers de nœuds. Ce n’est pas seulement un problème de performances, c’est aussi un cauchemar pour l’accessibilité et la maintenance.

Solutions : misez sur la légèreté et préférez les blocs natifs !

• Choisir un constructeur de page plus “propre” : Certains thèmes ou constructeurs sont plus optimisés et génèrent moins d’éléments inutiles.
• Nettoyer régulièrement : Si vous dupliquez des sections, vérifiez que vous ne laissez pas traîner des blocs vides ou trop complexes.
• Utiliser des blocs natifs : Dans Gutenberg, les blocs par défaut sont souvent plus légers qu’un éditeur visuel tiers.

Pourquoi votre CPU se retrouve saturé ?

Le “Main Thread” du navigateur gère à la fois le rendu, le style, le JavaScript. Si trop de tâches s’y déroulent simultanément, l’interface peut se figer, créant un effet de latence désagréable pour l’utilisateur. Sur mobile, c’est encore plus prononcé en raison de CPU moins puissants.

Exemple d’un script qui suit le curseur en continu

J’ai eu un cas sur une boutique en ligne où un script vérifiait en permanence la position du curseur de la souris pour animer un arrière-plan. Sur un PC de bureau, c’était fluide. Sur un smartphone d’entrée de gamme, c’était saccadé. Le script mobilisait trop le thread principal. En le désactivant sur mobile et en optimisant la logique, le site est redevenu fluide.

Conseils : un audit du JS et gestion intelligente du Main Thread

1. Analyser les performances JS : Lighthouse ou Chrome DevTools > Performance vous montre quelles fonctions monopolisent le thread.
2. Web Workers : Si vous faites des calculs lourds (trier une grande liste, traitement d’images client-side, etc.), déléguez cette tâche à un worker (thread séparé).
3. Optimiser les animations : Préférez les transformations CSS (GPU-friendly) aux gros calculs JS, et limitez les triggers qui sollicitent la mise en page.

La barre des 50 ms : au-delà, ça rame.

Une “tâche longue” est définie par Chrome comme un bout de code qui prend plus de 50 ms d’exécution. Pendant ce temps, l’utilisateur ne peut pas interagir. C’est un critère surveillé par PageSpeed Insights. Si vous avez plusieurs tâches longues, votre site semblera “lagger”.

Exemple

En travaillant sur un configurateur de produit (pour personnaliser la couleur, la taille, etc.), j’ai remarqué que le script se lançait dès l’arrivée sur la page, évaluant toutes les possibilités (des milliers de combinaisons), provoquant un freeze de plus d’une seconde. Nous avons décalé ce calcul pour ne le faire qu’une fois que l’utilisateur clique réellement sur le bouton “Personnaliser”.

Solutions pour retarder les scripts lourds

• Segmenter votre code : Au lieu de tout traiter dans une seule fonction, scindez en plusieurs morceaux plus courts, déclenchés progressivement.
• Lazy loading : Ne chargez un script avancé qu’au moment où l’utilisateur commence à l’utiliser (par exemple, quand il clique pour ouvrir un configurateur).
• Surveiller la console : Lighthouse détaille souvent quelles fonctions JS prennent trop de temps.

Pourquoi le LCP influe directement sur l’impression de vitesse

Le “Largest Contentful Paint” (LCP) correspond au moment où l’élément principal de la fenêtre (souvent une image large ou un bloc de texte) devient visible. C’est un indicateur clé pour Google : si le LCP est long, votre site est considéré comme lent.

Une bannière HD de 1,5 Mo : le faux pas à éviter

Une page d’accueil avec une grande bannière (Hero Image) pèse 1,5 Mo. Le LCP correspond à l’affichage de cette bannière. Si cette image n’est pas optimisée, le LCP peut grimper à 3 ou 4 secondes, et l’utilisateur ne voit pas encore le contenu principal. J’ai eu le cas sur un site de mode où la bannière initiale était en PNG alors qu’un JPEG ou WebP aurait suffi.

Solutions

• Optimisez l’image LCP : Compressez-la, servez-la en WebP/AVIF, vérifiez sa dimension exacte.
• Priorité de chargement : Dans WordPress, vous pouvez marquer votre image principale pour qu’elle soit chargée en priorité (<link rel="preload" …> ou via certains plugins).
• Vérifiez la position : Parfois, utiliser un background-image dans du CSS pour la bannière peut ralentir l’affichage (surtout si c’est chargé en dernier). Un <img> optimisé peut être plus efficace.

Le CLS : une page « qui bouge », ça agace l’utilisateur.

Le Cumulative Layout Shift (CLS) mesure les mouvements intempestifs de la page pendant le chargement. Vous avez sans doute déjà vu un bouton “sauter” au moment où vous alliez cliquer, à cause d’une image ou d’une pub qui s’insère. C’est frustrant, et Google le détecte.

Exemple : une pub tardive qui décale le texte au dernier moment

Sur un site éditorial, un encart publicitaire prenait parfois quelques secondes à s’afficher, décalant le texte. Les visiteurs cliquaient à côté d’un lien ou sélectionnaient le mauvais article par erreur. Pour corriger ça, nous avons réservé un emplacement fixe pour la pub, évitant ainsi le décalage. d’

Solutions

• Réserver l’espace : Donnez des dimensions (width, height) aux images, iframes ou pubs pour que le navigateur sache dès le départ combien d’espace allouer.
• Loaders et placeholders : Utilisez des zones grises ou des squelettes (skeleton screens) pour indiquer qu’un élément va se charger ici.
• Évitez les widgets dynamiques : Si possible, insérez-les en pied de page ou dans une zone qui ne perturbe pas le contenu principal.