Communitygithub.com

performance-site

Améliorez la vitesse du site et les scores Google PageSpeed / Core Web Vitals (LCP, TBT/INP, CLS, FCP) sans modifier l'apparence. Utilisez lorsque l'utilisateur mentionne PageSpeed, Lighthouse, pages lentes, score mobile, Core Web Vitals ou scripts lourds.

Qu'est-ce que performance-site ?

Cette compétence guide l'agent IA pour diagnostiquer et corriger les problèmes de performance web. Elle se concentre sur les métriques Core Web Vitals (LCP, CLS, TBT) et les scores PageSpeed / Lighthouse, sans altérer le design visuel. La compétence s'applique à tout site web ou plateforme : WordPress, Wix, Squarespace, sites personnalisés, etc. La méthode procède par étapes : établir une référence avec PageSpeed Insights mobile (2-3 essais par page + données de terrain), analyser le rapport pour identifier les causes (tâches longues, temps de démarrage, code bloquant le rendu, DOM volumineux), puis corriger une cause à la fois en mesurant l'impact. Elle propose des correctifs éprouvés : réduire le poids des tiers et de la plateforme (désinstaller les applications inutilisées, charger les widgets à la demande, éviter les doublons), optimiser le JavaScript (carrousels, plugins, balisage caché) et améliorer le Largest Contentful Paint (préchargement de l'image LCP, pas de lazy-load sur l'élément LCP). La compétence inclut aussi des conseils pour gérer le premier affichage (CSS critique, polices) et le layout shift (réservation d'espace). En sortie, elle fournit un rapport structuré avec les avant/après et les décisions du propriétaire à prendre.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/4RCustoms/jordan-harris-ux-ui-seo-website-skill/tree/main/skills/website-performance

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Performance du site

Chargez brand-guide (pour que les correctifs de vitesse ne modifient jamais l'apparence de la marque) et suivez website-change-safety.

Méthode

  1. Établir une référence avec PageSpeed Insights mobile, 2-3 exécutions par page, plus les données de terrain. Notez l'élément LCP.
  2. Trouver la cause dans le rapport : tâches longues, temps de démarrage / résumé tiers, requêtes bloquant le rendu, décomposition du LCP (délai de chargement vs délai de rendu), taille du DOM, reflow forcé.
  3. Corriger une cause à la fois, mesurer à nouveau, ne conserver que ce qui aide.
  4. Si possible, effectuez un test A/B localement avant publication : servir le nouveau JS/HTML/CSS via interception de requête par rapport à la page en ligne, et servir les DEUX versions de la même manière (un fichier local non compressé par rapport à un fichier en ligne compressé gzip fausse les temps simulés). Comparez le temps du thread principal, la taille du DOM, le temps de style/mise en page.

Les correctifs qui ont réellement amélioré les scores (vérifiez d'abord ceux-ci)

Poids des tiers et de la plateforme (généralement le plus important)

  • Applications désinstallées qui continuent de se charger. Supprimez les widgets et entrées de script résiduels du constructeur de page. Certaines plateformes continuent d'injecter une intégration après la désinstallation de l'application (par exemple, un exécutable d'éditeur visuel de 50+ fichiers) ; cherchez un interrupteur "Désactiver" au niveau du canal/boutique, sinon demandez au support de la plateforme.
  • Charger à la demande, pas sur chaque page : lecteurs vidéo (afficher une image de poster + bouton play, créer l'iframe au clic), captchas (charger lorsque le formulaire s'ouvre), widgets de chat, widgets de fidélité/récompenses (uniquement sur la page qui en a besoin), widgets d'avis en dessous de la ligne de flottaison.
  • Blocs vidéo intégrés ajoutés via un constructeur de page ne peuvent pas être différés par le thème ; déplacez ces vidéos dans la zone vidéo propre du thème qui utilise une façade "clic pour charger".
  • Doublons : deux bibliothèques d'analyse, la même balise deux fois, un pixel ancien et un nouveau.
  • Ne retarde pas les balises de publicité/analyse jusqu'à l'interaction sans l'accord du propriétaire ; cela modifie leurs données.

JavaScript faisant trop de choses au chargement

  • Carrousels/diaporamas : les paramètres de diaporama d'abord pour ordinateur construisent souvent la mise en page desktop puis la reconstruisent pour les téléphones ; passez aux paramètres mobile-first. Les modes "Infini/Boucle" clonent chaque diapositive 2 à 3 fois (des centaines d'éléments supplémentaires) ; désactivez la boucle là où ce n'est pas nécessaire. Initialisez les diaporamas qui commencent en dessous du premier écran uniquement lorsqu'ils s'approchent du viewport (IntersectionObserver), avec du CSS qui affiche la ligne non initialisée à la même hauteur pour éviter les sauts.
  • Constructeurs de pages et plugins (WordPress/Wix/Squarespace surtout) : chaque plugin peut ajouter son propre CSS/JS à chaque page ; désactivez ce qui n'est pas utilisé et chargez le reste uniquement là où nécessaire.
  • Balisage caché en double : par exemple les pages de listes qui affichent une grille ET une vue liste cachée de chaque produit. Affichez-en un seul.
  • Supprimez les logs de débogage résiduels et les chemins de code mort qui s'exécutent encore.

Largest Contentful Paint

  • Identifiez le véritable élément LCP. S'il s'agit d'une image de fond CSS, le navigateur la trouve tardivement ; ajoutez <link rel="preload" as="image" fetchpriority="high"> sur cette page uniquement, avec l'URL identique en octets à celle à laquelle le CSS résout (sinon elle est téléchargée deux fois).
  • Seule la première rangée visible d'images reçoit fetchpriority="high" (par exemple 2 sur une grille téléphone à 2 colonnes) ; plus d'images haute priorité divisent la bande passante avec la véritable image LCP.
  • Ne lazy-load jamais l'image LCP. Faites du lazy-load pour tout ce qui est en dessous de la ligne de flottaison.
  • Vérifiez quel format la plateforme sert déjà (de nombreux CDN convertissent automatiquement en WebP/AVIF) ; ré-enregistrer les images peut ne rien apporter. Les gros gains proviennent des images source surdimensionnées et des sizes incorrectes.

Premier affichage / blocage du rendu

  • La feuille de style principale du thème est généralement le goulot d'étranglement. Le CSS spécifique à la page peut être séparé ou le CSS critique intégré, mais c'est un projet plus important et risqué ; proposez-le, ne l'ajoutez pas discrètement.
  • Chaque feuille de style bloquant le rendu supplémentaire ou script synchrone dans <head> (souvent injecté par des applications) ajoute du délai.
  • Polices : gardez les choix font-display intentionnels (les polices d'icônes ont besoin de block ; les polices de texte peuvent utiliser swap uniquement si les métriques de fallback sont suffisamment proches pour éviter un décalage de mise en page).

Décalage de mise en page (Layout shift)

  • Réservez de l'espace pour les images (largeur/hauteur), les intégrations (boîte aspect-ratio), les bannières et widgets tardifs.
  • Tout ce qui est initialisé par JS doit avoir un CSS pré-initialisation de la même taille.

Rapport

Chiffres avant/après par page (sous forme de plages), statut des données de terrain, ce qui a changé, et ce qui reste avec la décision du propriétaire nécessaire (compromis tiers). Rappelez-leur que les scores en laboratoire varient ; les tendances et les données de terrain comptent plus qu'une seule exécution.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Skills associés