Communitygithub.com

ahmedbinirfan/mcmaster-fast

Appliquez les techniques de style McMaster-Carr pour rendre les sites Web instantanés : rendu HTML d'abord, navigation par app-shell, préchargement intentionnel, mise en cache par couches, CSS critique, JS spécifique à la page et stabilité de mise en page. Utilisez-le lorsque l'utilisateur souhaite un site extrêmement rapide ou réactif, mentionne McMaster-Carr / mcmaster.com, pages instantanées, préchargement au survol, ou demande d'implémenter ces techniques sur un autre site Web.

Qu'est-ce que mcmaster-fast ?

Ce skill transforme n'importe quel site Web pour lui donner la rapidité quasi instantanée de McMaster-Carr (mcmaster.com), célèbre pour ses premier affichages en quelques dizaines de millisecondes et ses pages suivantes chargées avant même que l'URL ne change. Il s'inspire de l'architecture réelle observée sur le site : rendu HTML côté serveur, shell persistant avec remplacement de contenu, préchargement basé sur l'intention (survol/entrée dans le viewport), mise en cache multi-couches (service worker, navigateur, CDN), CSS critique en ligne, JS spécifique à la page et stabilité de mise en page (CLS nul). L'approche est agnostique du framework ; elle se concentre sur l'ordre des opérations et le nombre de requêtes plutôt que sur la mode des frameworks. Le skill propose une échelle de priorités à huit niveaux, chaque niveau apportant un gain mesurable jusqu'à atteindre un LCP sous 200 ms sur cache chaud. Il évite les solutions lourdes : pas de Workbox, pas de pipeline de sprites, pas de règles de spéculation en une seule PR. Il inclut des règles strictes concernant le traitement des pages personnalisées, des scripts tiers et des service workers, et privilégie les fonctionnalités déjà présentes dans le projet (comme le routage Next.js ou les polices `next/font`).

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add ahmedbinirfan/mcmaster-fast

Demander à votre IA préférée

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

Documentation

Que fait mcmaster-fast ?

Faites en sorte que les autres sites ressemblent à mcmaster.com : premier affichage en quelques dizaines de millisecondes, page suivante avant que la barre d'URL ne se mette à jour.

La stack importe peu. McMaster le fait avec ASP.NET, YUI et un ScriptCombiner. L'ordre et le nombre de requêtes comptent. La mode des frameworks, non.

Ce qu'ils font réellement

Observé sur le site en direct (2026-09-13) ainsi que le démontage de Wes Bos (notes de klinke.studio) :

CoucheCe que fait McMasterPourquoi ça semble instantané
Premier octetHTML rendu côté serveur. Le navigateur paint avant le JS. FCP ~64ms, TTFB ~19ms sur un shell chaud.L'utilisateur voit une page, pas un spinner attendant un bundle.
Shell#ShellLayout_Cntnr + #MainContent. L'en-tête/panier restent montés. history.pushState.Un clic sur une catégorie conserve le même nœud d'en-tête et échange le contenu en 35ms.
PrédictionLe survol/intention récupère le HTML suivant avant le clic.Le clic est un cache hit + échange DOM.
Visite répétéeService worker en cache-first pour les navigations GET (pas les PDF). Cache de / après le premier chargement.Le HTML source est ~200ms (mc-turn) ; le SW le sert localement.
Waterfalldns-prefetch pour les hébergeurs d'images. preload pour les polices woff2, le logo, les sprites LCP, le JS/CSS de page, ShellDynamic.aspx.Le navigateur commence les polices/LCP avant de les découvrir dans le CSS.
CSS~32KB de CSS commun inline dans <style> dans <head>. Le reste via un combineur spécifique à la page.Le premier layout n'a besoin d'aucune requête CSS supplémentaire.
JSBundles ScriptCombiner spécifiques à la page (?files=…). Async. Les WebParts se chargent après le paint.La page catalogue ne télécharge pas le code de la caisse.
AssetsURLs versionnées (/mv1789156784/, ?ver=). Cache-Control: public,immutable,max-age=31536000. Hôte d'images images1.mcmaster.com. Sprites pour les grilles de tuiles.Cache d'un an, pas de danse d'invalidation, peu de requêtes.
StabilitéBoîtes réservées / sprites. CLS mesuré 0.Pas de reflow pendant l'arrivée des images.
PoidsAnalytiques first-party (/trk/). Pas de pubs. CSP verrouillé sur *.mcmaster.com.La page est le produit.

Les documents HTML eux-mêmes sont Cache-Control: no-cache et x-check-cacheable: NO chez Akamai. Ne copiez pas "cache-tout-le-HTML-sur-CDN". Ils mettent en cache le shell dans le navigateur et les fichiers statiques immutables en périphérie.

Échelle de priorités

Arrêtez-vous au premier échelon qui amène la page sous ~200ms de LCP sur un cache chaud. N'installez pas Workbox, un pipeline de sprites et des règles de spéculation en une seule PR.

  1. Livrez du HTML que le navigateur peut peindre. SSR ou HTML statique. Pas de rendu client-only pour la première vue. Supprimez le JS qui construit le premier écran.
  2. Débloquez le premier affichage. Inlinez seulement le CSS au-dessus-de-la-ligne (ou une petite feuille bloquante). preload l'image LCP et les polices woff2 (crossorigin). width/height (ou aspect-ratio CSS) sur chaque image.
  3. Fichiers statiques immutables. Empreinte ou requête de version. Cache-Control: public, immutable, max-age=31536000.
  4. Chrome persistant + échange de contenu. Layout partagé. La navigation suivante remplace un nœud de contenu et fait pushState. Ne remontez pas l'en-tête.
  5. Préchargement intentionnel. Document suivant spéculé au survol / dans le viewport. Limitez-le. Ne préchargez jamais la caisse, les API de recherche ou le HTML authentifié.
  6. Service worker de navigation (optionnel). Cache-first pour les navigations GET du shell/public/accueil. Effacez au déploiement. Invalidez depuis la page, pas avec un SW malin. Sautez si le site est majoritairement privé.
  7. JS spécifique à la page. Route-split. Reportez les analytiques jusqu'à l'inactivité. Supprimez les tags tiers qui ne sont pas le produit.
  8. Sprites / hôte d'images seulement si vous avez des dizaines de petites icônes sur une vue. HTTP/2 + quelques images compressées suffisent en dessous.

Workflow de l'agent

Lorsqu'on vous demande de rendre un site rapide de cette manière :

  1. Tracez le vrai premier chargement et une navigation dans l'application (réseau + ce qui s'affiche). Nommez l'élément LCP actuel et le JS qui le bloque.
  2. Appliquez l'échelon le plus bas manquant. Un changement par passage, sauf si l'utilisateur demande une révision complète.
  3. Préférez les fonctionnalités déjà présentes dans le dépôt (Next <Link>, next/font, layouts App Router) aux nouvelles bibliothèques.
  4. Après un passage, laissez un indicateur : les chiffres LCP / FCP, ou une petite assertion que le nœud du shell est réutilisé lors d'une navigation client.
  5. Lisez techniques.md pour la recette exacte de l'échelon que vous implémentez. Lisez recipes.md pour les correspondances Next.js / vanilla / SPA existant.

Règles strictes

  • Le HTML est le produit. JS est une amélioration optionnelle.
  • Le préchargement est une indication, pas un crawler. Uniquement des documents GET de même origine.
  • HTML personnalisé est no-store ou uniquement via SW avec un TTL court. Ne mettez jamais le HTML du panier/compte sur un cache CDN partagé.
  • N'ajoutez pas de service worker qui intercepte tous les assets. Uniquement les documents de navigation, correspondant à ServiceWorkerJS.aspx de McMaster.
  • Ne copiez pas YUI, sprites ou ASP.NET. Copiez l'ordre des opérations.
  • Ne "modernisez" pas une page HTML rapide en un SPA client comme solution.
  • Les scripts tiers (pubs, gestionnaires de tags, chat) sont présumés coupables. Gardez-les hors du premier affichage ou supprimez-les.
  • Marquez les raccourcis avec ponytail: lorsque vous sautez un échelon de moindre valeur.

Fait quand

  • Première visite : le HTML s'affiche avant qu'aucun bundle d'application ne s'exécute. LCP est un élément envoyé par le serveur, pas un élément rendu côté client.
  • Prochain clic : le chrome reste monté ; seule la zone de contenu est remplacée.
  • Visite répétée de l'accueil/shell : servie localement ou depuis le cache mémoire.
  • Polices et image LCP dans les 1 à 2 premiers allers-retours, pas découvertes après le CSS.
  • CLS reste proche de 0 sur les pages que vous avez touchées.

Skills associés