Lent par erreur vs lent par conception : Un framework de web performance

Lent par erreur vs lent par conception.

Lorsque vous m'engagez pour auditer ou parler des Core Web Vitals, à un moment donné, vous m'entendrez parler de lent par erreur vs lent par conception. Je pense que c'est une distinction cruciale à faire et dans cet article je vais vous expliquer comment cela vous aidera à améliorer les Core Web Vitals.

Dernière révision par Arjen Karel en mars 2026

Quand quelqu'un me demande de faire du consulting et de corriger les Core Web Vitals, il y a toujours quelque chose qui cloche. La lenteur provient toujours d'anti-patterns. Par exemple, une 'image Largest Contentful Paint en lazy loading', des 'images volumineuses non optimisées', des 'sliders', du 'JavaScript bloquant', etc.

Il ne faut pas grand-chose pour introduire un anti-pattern. Parfois, tout ce que vous avez à faire pour créer un anti-pattern est d'installer un plugin ou d'oublier les bonnes pratiques pendant un court instant.

J'aime catégoriser ces anti-patterns en 'lent par erreur' et 'lent par conception' car la façon dont je m'y prends pour les corriger est complètement opposée.

Seulement 48 % des origines mobiles réussissent les trois Core Web Vitals selon le Web Almanac 2025. D'après mon expérience, la majorité de ces échecs proviennent de problèmes 'lents par erreur' qui peuvent être corrigés en quelques heures.

Lent par erreur

J'adore les anti-patterns 'lents par erreur'. Vous avez fait quelque chose qui a ralenti la page. Vous avez fait une erreur. Vous ne saviez pas qu'il y a une façon beaucoup plus rapide de faire cela. Pas de soucis, je peux corriger les erreurs.

Donc, catégoriser ces 'erreurs' est logique. Cela me donnera une liste d'améliorations faciles à corriger et à fort impact que je peux envoyer à votre équipe de développement (ou corriger moi-même). Il y a généralement très peu de discussions nécessaires. L'amélioration de ces anti-patterns est tout simplement logique à tous les niveaux. Une fois qu'ils seront corrigés, les Core Web Vitals s'amélioreront.

Voici quelques exemples d'anti-patterns que je rencontre quotidiennement. Quand j'explique quoi et pourquoi, on me répond généralement 'ohh, je ne savais pas que cela ralentirait la page'.

1. Images sans lazy loading

L'anti-pattern le plus courant est celui des images sans lazy loading. Les images qui ne sont pas en lazy loading seront mises en file d'attente pour le téléchargement pendant les premières étapes du chargement de la page. Cela utilisera des ressources réseau et CPU. Il n'est pas logique d'allouer de précieuses ressources à des images qui ne sont même pas visibles, n'est-ce pas ? Apprenez-en plus sur le report des images hors écran.

L'erreur inverse est tout aussi courante : appliquer le lazy loading à l'image Largest Contentful Paint. Environ 15 % des sites le font, et cela ralentit le chargement de l'image la plus importante de la page au lieu de l'accélérer.

2. Polices tierces

Les web-fonts sont géniales. Elles personnaliseront et amélioreront l'apparence de la page. Malheureusement, l'utilisation d'un fournisseur tiers comme Google Fonts n'optimisera pas les polices pour votre situation spécifique.

Les polices tierces nécessiteront une feuille de style supplémentaire bloquant le rendu, une nouvelle connexion à un serveur web (alors que vous avez déjà cette connexion très rapide à votre serveur d'origine) et ajouteront probablement plus de polices au navigateur que vous n'en utilisez réellement.

Il serait plus logique d'auto-héberger vos polices, de les précharger et d'attribuer une stratégie de chargement de police personnalisée à chaque fichier de police. C'est un autre gain rapide juste là !

3. Scripts tiers

Bien qu'il n'y ait rien de mal avec les scripts tiers, ils causent beaucoup de problèmes en raison de la façon dont ils sont ajoutés aux pages. Je rencontre des scripts tiers sans importance (comme les pixels de suivi Facebook, les boutons de réseaux sociaux, les widgets d'évaluation, etc.) qui bloquent en fait la page entière.

Il est relativement facile et logique de différer et de planifier ces scripts jusqu'à ce que le navigateur ait fait le travail le plus important. Au final, je n'ai rien changé de critique au site, il a toujours la même apparence et se charge beaucoup plus rapidement. J'ai juste changé l'ordre dans lequel les choses sont faites.

4. Images d'arrière-plan

Du point de vue des Core Web Vitals, les images d'arrière-plan n'ont pas beaucoup de sens. Les images d'arrière-plan n'ont pas de support natif pour le lazy loading, elles ne sont pas responsives et vous avez peu de contrôle sur leur timing et leur priorité.

Avec quelques correctifs simples, nous pouvons transformer ces images d'arrière-plan en images normales que nous pouvons charger en lazy loading, rendre responsives et dont nous pouvons ajuster la priorité. Cela améliorera certainement le Largest Contentful Paint.

5. Grandes feuilles de style

Les feuilles de style sont bloquantes pour le rendu. Cela signifie que pendant que le navigateur charge les feuilles de style, la page restera blanche. Il y a beaucoup de choses que vous pouvez faire pour corriger cela. Par exemple, supprimer les styles inutilisés, diviser la feuille de style, améliorer la mise en cache du navigateur ou ajouter du CSS critique.

Une fois que nous aurons amélioré les feuilles de style, votre Largest Contentful Paint et votre First Contentful Paint s'amélioreront considérablement !

Lent par conception

Lent par conception est la partie dont vous devriez vous inquiéter. Vous avez fait des choix structurels qui ont ralenti la page. Ils impliquent généralement des choix de conception d'UX ou du code JavaScript qui modifie la partie visible de la page à un point tel qu'il n'y a pas de bonnes solutions de contournement.

Le problème avec 'lent par conception' est que cela ne peut pas être corrigé immédiatement en faisant de petits changements. Cela nécessite plus de planification et la réécriture de certaines fonctionnalités de base du site.

La première chose que je dois faire est de comprendre l'intention : Pourquoi avez-vous fait cela ? Quelles ont été les considérations et que vouliez-vous accomplir exactement ? Et ensuite, dans ces paramètres, trouver une meilleure alternative !

Voici quelques exemples des erreurs 'lent par conception' les plus courantes.

1. Sliders

Les sliders fonctionnent généralement comme ceci : Lorsque la page est rendue, un JavaScript injectera le slider dans la page. Sans ce JavaScript, la page aura un aspect complètement différent. Cela entraînera un Largest Contentful Paint plus long, probablement un Layout Shift et très probablement des problèmes avec l'Interaction to Next Paint (INP).

Il n'y a pas de solution miracle. Différer le JavaScript améliorera les métriques de rendu mais retardera le slider et provoquera un layout shift. Rendre le script du slider critique corrigera le Layout Shift mais ralentira les métriques de rendu.

La solution est d'améliorer progressivement la page. Assurez-vous d'abord que le slider s'affiche sans JavaScript, puis améliorez la page et transformez l'image du slider déjà présente en un slider complet.

Le plus amusant, c'est que seulement environ 1 % des visiteurs cliquent réellement sur un slider. 9 fois sur 10, lorsque j'explique cela, le propriétaire du site suggère immédiatement de supprimer le slider. C'est pourquoi il est important de se renseigner sur les intentions et les considérations de ces sliders. En général, ils 'étaient juste là'.

2. Zoom produit

Le zoom produit fonctionne ainsi : sur votre boutique en ligne classique, passez la souris sur l'image d'un produit et vous pouvez zoomer sur une partie du produit. Les 'zooms produit' ont généralement le même problème que les sliders. Un morceau de code JavaScript prendra vos images, les masquera, puis les réécrira sur la page en tant qu'images zoomables. Cela provoquera un Largest Contentful Paint plus long, probablement un Layout Shift et très probablement des problèmes avec l'Interaction to Next Paint (INP).

La différence avec le slider est qu'aucun propriétaire de produit ne dira jamais : "oh, supprimez juste cette fonctionnalité". Elle est importante et augmente la conversion.

La solution est la même que pour le correctif du slider. Le script de zoom ne doit pas masquer les images originales, mais étendre la fonctionnalité de l'image du produit. Malheureusement, la fonctionnalité de zoom n'est généralement pas facile à corriger et nécessitera un peu de travail pour être parfaitement au point.

3. jQuery inline / dépendances JavaScript inline

Le jQuery inline est un problème qui a commencé comme un 'lent par erreur' mais qui s'est aggravé avec le temps. Environ 50 % des sites que j'examine souffrent de ce problème. jQuery fonctionne toujours sur environ 70 % de tous les sites web selon W3Techs, donc cela ne va pas disparaître de sitôt. Parce que les scripts inline dépendent d'un script antérieur (généralement jQuery), vous ne pouvez plus différer jQuery. Cela retardera toutes les métriques de rendu.

Le correctif est simple : déplacez simplement ces scripts vers un script externe. Maintenant, vous pouvez différer à la fois jQuery et le script personnalisé.

Alors pourquoi ai-je placé cela dans la catégorie 'lent par conception' ? Quand je pose des questions sur l'intention et la considération, j'obtiens généralement un 'oh, je ne sais pas'. Et c'est là le vrai problème. Il y a un manque de connaissances sur le fonctionnement de JavaScript. Je peux être à peu près certain que cette erreur sera répétée à l'avenir. Cela signifie que la solution n'est pas la même que le correctif. Je devrai former l'équipe de développement sur les dépendances et le timing JavaScript.

4. Grandes images (hero images)

Un autre problème de lenteur par conception concerne les grandes images. Certains sites ont simplement besoin d''éblouir le public' avec de nombreuses images en taille réelle. Imaginez que vous vendez des affiches. Vous voudriez probablement servir de grandes images de haute qualité à vos visiteurs. Ces images, peu importe à quel point vous les optimisez, mettront toujours plus de temps à se télécharger que des images plus petites.

À ce stade (en supposant que les images sont toutes optimisées), la seule chose que je peux faire est de voir s'il y a une marge de manœuvre. Avons-nous vraiment besoin d'images 4K ou le Full HD suffirait-il également ? Consultez comment corriger les hero images lentes pour des techniques pratiques.

5. Cartes interactives

Un autre problème que je rencontre fréquemment concerne les cartes interactives. Lorsqu'une page comporte une carte interactive, l'intention première de cette page est de faire interagir le visiteur avec la carte. Évidemment, il va falloir un certain temps pour que cette carte se charge.

Il n'y a pas moyen d'y échapper. Nous devrons accepter une certaine lenteur. Mais il y a des choses que nous pouvons faire. Nous pouvons nous assurer que les cartes sont chargées avec la plus haute priorité. Généralement, ces pages ne sont pas optimisées pour une exécution précoce de JavaScript. Dans ce cas, c'était le mauvais choix. Nous avons besoin que le script se télécharge et s'exécute le plus tôt possible ! J'ai écrit un guide complet sur la façon d'intégrer Google Maps sans perdre de PageSpeed.

6. API lentes

Les problèmes de lenteur par conception qui découlent d'API lentes se trouvent généralement sur les sites SPA comme React, Next.js ou Angular. Les API lentes causeront généralement d'importants Layout Shifts car les composants sont rendus trop tard après l'interaction de l'utilisateur. Des problèmes comme ceux-ci nécessitent généralement une approche multi-équipes.

Il peut être utile de faire la distinction entre lent par erreur et lent par conception en ce qui concerne les Core Web Vitals. Lent par erreur est généralement facilement corrigé tandis que lent par conception nécessite une approche multidimensionnelle plus approfondie. Une fois que vous avez catégorisé et corrigé les problèmes 'lents par erreur', configurez le Real User Monitoring pour suivre l'impact. Les données de terrain vous indiquent si vos correctifs ont réellement amélioré l'expérience pour les vrais visiteurs. Les problèmes 'lents par conception' ressortiront alors clairement dans vos données car c'est ce qu'il en restera.