Lent par erreur vs lent par conception

Lent par erreur vs lent par conception.

Lorsque vous m'engagez pour corriger ou parler des Core Web Vitals, à un moment donné, vous m'entendrez parler de lent par erreur vs lent par conception.  Je pense qu'il s'agit d'une distinction critique à faire et dans cet article, j'expliquerai comment cela vous aidera à améliorer les Core Web Vitals.

Lent par erreur

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

Donc, classer ces 'erreurs' a du sens. 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 discussion nécessaire. L'amélioration de ces anti-patterns est tout simplement logique à tous points de vue. Une fois qu'ils sont 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, j'obtiens généralement 'ohh, je ne savais pas que cela ralentirait la page'.

1. Images non lazy (non chargées en différé)

L'anti-pattern le plus courant est les images non lazy. Les images qui ne sont pas chargées en différé seront mises en file d'attente pour le téléchargement au début du chargement de la page. Cela utilisera des ressources réseau et CPU. Il n'est pas logique d'attribuer des ressources précieuses à des images qui ne sont même pas visibles, n'est-ce pas ? 

2. Polices tierces

3. Scripts tiers

4. Images d'arrière-plan

5. Grandes feuilles de style

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 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 qu'il n'est pas immédiatement réparable en apportant de petits changements. Cela nécessite plus de planification et la réécriture de certaines fonctionnalités principales du site. 

La première chose que je dois faire est de comprendre l'intention : Pourquoi avez-vous fait cela ? Quelles étaient les considérations et qu'aviez-vous exactement l'intention d'accomplir ? Et puis, 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 s'affiche, un JavaScript injecte le slider dans la page. Sans ce JavaScript, la page aura un aspect complètement différent.  Cela provoquera un Largest Contentful Paint plus long, probablement un Layout Shift et très probablement des problèmes avec le First Input Delay.

Il n'y a pas de solution rapide. Différer le JavaScript améliorera les métriques de peinture 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 peinture.

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. 

Ce qui est amusant, c'est que : 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 poser des questions sur les intentions et les considérations de ces sliders. Généralement, ils 'étaient juste là'.

2. Zoom produit

Le zoom produit fonctionne comme ceci : sur votre boutique en ligne moyenne, survolez une image de produit et vous pouvez zoomer sur une partie du produit.  Les 'zooms produits' ont généralement le même problème que les sliders.  Un morceau de code JavaScript prendra vos images, les masquera et les réécrit 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 le First Input Delay.

La différence avec le slider est qu'aucun propriétaire de produit ne dira jamais : "oh, supprimez simplement cette fonctionnalité". C'est important et cela 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 facilement corrigée et nécessitera  un peu de travail pour l'obtenir juste comme il faut.

3. jQuery inline / dépendances JavaScript inline

Le jQuery inline est un problème qui a commencé comme un 'lent par erreur' mais qui a empiré avec le temps. Environ 50 % des sites que je regarde souffrent de ce problème. 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 peinture.

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 '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 tout à fait certain que cette erreur se répétera à l'avenir. Cela signifie que la solution n'est pas la même que le correctif. Je devrai éduquer l'équipe de développement sur les dépendances et le timing JavaScript.

4. Grandes images (hero)

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

À ce stade (en supposant que les images sont toutes optimisées), la seule chose que je puisse faire est de voir s'il y a une marge de manœuvre. Avons-nous vraiment besoin d'images 4k ou la full-hd suffirait-elle également ?

5. Cartes interactives

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

Il n'y a pas moyen de contourner cela. 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 !

6. API lentes

Conclusion

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 facile à corriger tandis que lent par conception nécessite une approche multidimensionnelle plus approfondie.