Catégories
Astuces et Design

Core Web Vital Tooling | Astuces CSS

Je pense toujours que les Core Web Vitals conçus par Google sont intelligents. Quand j'ai commencé à me soucier de la performance, c'était tout: réduire les demandes! cache les choses! Faites des choses plus petites! Et bien que ceux-ci soient tous très liés aux performances Web, ils sont abstraitement en relation. Réel les performances Web pour les utilisateurs sont des choses comme combien de temps ai-je dû attendre pour voir le contenu de la page? Combien de temps avant que je puisse réellement interagir avec la page, comme taper un formulaire ou cliquer sur un lien? Est-ce que les choses ont bougé de façon odieuse pendant que j'essayais de faire quelque chose? C’est pourquoi Core Web Vitals est intelligent: il mesure ces choses.

L'onglet Phare de Chrome DevTools les a maintenant:

Ils sont agréables à surveiller, car rappelez-vous que, mis à part ces chiffres ayant un avantage direct pour vos utilisateurs une fois qu'ils accèdent à votre site, ils peuvent affecter les utilisateurs à accéder à votre site. Web Core Vitals prend en compte le référencement et les nouvelles exigences du carrousel qui étaient auparavant réservées uniquement aux pages AMP.

Le suivi de ces chiffres lors d'audits ponctuels est utile, mais il est plus utile de les surveiller au fil du temps pour vous protéger des glissades. Les outils de performance comme Caliber les couvrent. New Relic l'a. SpeedCurve les suit.

Le décalage de mise en page cumulatif (CLS) est délicat. C’est celui où, par exemple, le site a une publicité en haut d’un article. La demande pour cette annonce est asynchrone, il y a donc de fortes chances que l'annonce arrive en retard et pousse le contenu de l'article vers le bas. Ce n’est pas seulement ennuyeux, mais un véritable problème pour les mesures de performance et, en fin de compte, pour le référencement.

«Cumulative Layout Shift in Practice» de Nic Jansma offre une plongée approfondie.

CLS n'est pas simplement «est-ce que la page le fait ou non?» Il y a un score, comme le montre l'illustration ci-dessus. Je dirais que 0 est un bon objectif car il n’existe pas de version de CLS c'est bon pour tout le monde. Il y a beaucoup de nuances à cela, comme le suivre «synthétiquement» (par exemple dans un navigateur sans tête, en particulier pour les outils de performance) et avec de vrais utilisateurs sur votre site réel (qui s'appelle RHUMou mesures de l'utilisateur réel). Les deux sont utiles.

Si vous avez CLS que vous devez combattre, cela peut être délicat. SpeedCurve a un nouvel outillage qui aide:

Pour chaque décalage de mise en page, nous vous montrons l'image de la pellicule juste avant et juste après le décalage. Nous dessinons ensuite une boîte rouge autour des éléments qui ont bougé, mettant en évidence exactement quels éléments ont provoqué le décalage. Le score de changement de disposition pour chaque équipe vous aide également à comprendre l'impact de ce changement et comment il s'ajoute au score cumulé.

Cela faciliterait l’extinction et la réparation, j’espère. Surtout les plus délicats. Je ne savais pas cela, mais CLS peut être causé par des choses beaucoup plus subtiles que Mark Zeman souligne dans le post. Par exemple:

Trucs difficiles mais importants. J'ai vraiment besoin de tests de performance dans mon CI/CD, lequel va vraiment aider avec ça. On a de plus en plus l'impression que la performance Web est un sous-genre de carrière à part entière du développement Web. Les développeurs Web frontaux ont vraiment besoin de comprendre ces éléments et d'aider dans une certaine mesure, mais nous avons déjà beaucoup à faire.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *