ahmedbinirfan/mcmaster-fast

Was macht mcmaster-fast?

Lass andere Websites sich anfühlen wie mcmaster.com: erster Paint in Millisekunden, nächste Seite bevor sich die URL-Leiste aktualisiert.

Das Framework spielt keine Rolle. McMaster macht das mit ASP.NET, YUI und einem ScriptCombiner. Die Reihenfolge und die Anzahl der Requests zählen. Framework-Moden nicht.

Was sie tatsächlich tun

Beobachtet auf der Live-Site (2026-09-13) plus dem Wes Bos Teardown (klinke.studio Notizen):

Schicht	Was McMaster tut	Warum es sich sofort anfühlt
Erstes Byte	Server-gerendertes HTML. Browser malt vor JS. FCP ~64ms, TTFB ~19ms bei einer warmen Shell.	Benutzer sieht eine Seite, keinen Spinner, der auf ein Bundle wartet.
Shell	#ShellLayout_Cntnr + #MainContent. Header/Warenkorb bleiben eingebaut. history.pushState.	Klick auf eine Kategorie behielt denselben Header-Knoten und tauschte den Inhalt in 35ms aus.
Predict	Hover/Intent ruft das nächste HTML vor dem Klick ab.	Klick ist ein Cache-Treffer + DOM-Tausch.
Wiederholter Besuch	Service Worker cache-first für GET-Navigationen (keine PDFs). Cache hält / nach erstem Laden.	Ursprungs-HTML ist ~200ms (mc-turn); SW liefert es lokal aus.
Waterfall	dns-prefetch für Bild-Hosts. preload für woff2-Schriftarten, Logo, LCP-Sprites, Seiten-JS/CSS, ShellDynamic.aspx.	Browser beginnt mit Schriftarten/LCP, bevor er sie im CSS entdeckt.
CSS	~32KB gemeinsames CSS inline in <style> im <head>. Rest über einen seiten-spezifischen Combiner.	Erstes Layout benötigt keinen zusätzlichen CSS-Request.
JS	Seiten-spezifische ScriptCombiner-Bundles (?files=…). Async. WebParts laden nach dem Paint.	Katalogseite lädt keinen Checkout-Code herunter.
Assets	Versionierte URLs (/mv1789156784/, ?ver=). Cache-Control: public,immutable,max-age=31536000. Bild-Host images1.mcmaster.com. Sprites für Kachel-Raster.	Ein Jahr Cache, keine Invalidierungs-Tänze, wenige Requests.
Stabilität	Reservierte Boxen / Sprites. Gemessener CLS 0.	Kein Reflow während Bilder eintreffen.
Gewicht	First-Party-Analytics (/trk/). Keine Werbung. CSP auf *.mcmaster.com beschränkt.	Die Seite ist das Produkt.

HTML-Dokumente selbst sind Cache-Control: no-cache und x-check-cacheable: NO bei Akamai. Kopiere nicht "CDN-Caching für alle HTML-Seiten". Sie cachen die Shell im Browser und cachen unveränderliche statische Dateien am Edge.

Prioritätsleiter

Stoppe auf der ersten Stufe, die die Seite unter ~200ms LCP bei warmem Cache bringt. Installiere nicht Workbox, eine Sprite-Pipeline und Speculation Rules in einem PR.

1. HTML ausliefern, das der Browser malen kann. SSR oder statisches HTML. Kein clientseitiges Rendern der ersten Ansicht. Entferne das JS, das den ersten Bildschirm aufbaut.
2. Ersten Paint freigeben. Nur das oberhalb der Falz liegende CSS inline (oder ein winziges blockierendes Stylesheet). preload das LCP-Bild und woff2-Schriftarten (crossorigin). width/height (oder CSS aspect-ratio) für jedes Bild.
3. Unveränderliche statische Dateien. Fingerprint oder Versions-Query. Cache-Control: public, immutable, max-age=31536000.
4. Persistente Oberfläche + Inhaltswechsel. Gemeinsames Layout. Nächste Navigation ersetzt einen Inhaltsknoten und führt pushState aus. Baue den Header nicht neu ein.
5. Intent Prefetch. Spekuliere das nächste Dokument beim Hover / Viewport. Begrenze es. Nie Checkout, Such-APIs oder authentifiziertes HTML vorladen.
6. Navigations-SW (optional). Cache-first GET-Navigationen für die öffentliche Shell/Startseite. Leere bei Deployment. Invalidiere von der Seite aus, nicht mit einem cleveren SW. Überspringe, wenn die Seite größtenteils privat ist.
7. Seiten-spezifisches JS. Routen-Splitting. Verschiebe Analytics in den Leerlauf. Entferne Drittanbieter-Tags, die nicht das Produkt sind.
8. Sprites / Bild-Host nur, wenn Dutzende kleiner Icons auf einer Ansicht vorhanden sind. HTTP/2 + ein paar komprimierte Bilder reichen darunter aus.

Agenten-Workflow

Wenn aufgefordert, eine Seite auf diese Weise schnell zu machen:

1. Verfolge den echten ersten Ladevorgang und eine In-App-Navigation (Netzwerk + was malt). Benenne das aktuelle LCP-Element und das JS, das es blockiert.
2. Wende die niedrigste fehlende Stufe der Leiter an. Eine Änderung pro Durchgang, es sei denn, der Benutzer hat einen Rundumschlag gewünscht.
3. Bevorzuge Plattformfunktionen, die bereits im Repo vorhanden sind (Next <Link>, next/font, App Router Layouts) gegenüber neuen Bibliotheken.
4. Hinterlasse nach einem Durchgang einen Check: LCP / FCP Zahlen oder eine kleine Assertion, dass der Shell-Knoten bei einer Client-Navigation wiederverwendet wird.
5. Lese techniques.md für das genaue Rezept der Stufe, die du implementierst. Lese recipes.md für Next.js / Vanilla / bestehende-SPA Zuordnungen.

Harte Regeln

• HTML ist das Produkt. JS ist optionale Verbesserung.
• Prefetch ist ein Hinweis, kein Crawler. Nur Same-Origin GET-Dokumente.
• Personalisiertes HTML ist no-store oder nur SW mit kurzer TTL. Niemals Warenkorb-/Konto-HTML auf einen gemeinsamen CDN-Cache legen.
• Füge keinen Service Worker hinzu, der jedes Asset abfängt. Nur Navigationsdokumente, entsprechend McMasters ServiceWorkerJS.aspx.
• Kopiere nicht YUI, Sprites oder ASP.NET. Kopiere die Reihenfolge der Operationen.
• "Modernisiere" keine schnelle HTML-Seite in ein Client-SPA als Lösung.
• Drittanbieter-Skripte (Werbung, Tag-Manager, Chat) sind schuldig, bis ihre Unschuld bewiesen ist. Halte sie vom ersten Paint fern oder schneide sie ab.
• Markiere Abkürzungen mit ponytail:, wenn du eine minderwertige Stufe überspringst.

Fertig, wenn

• Erster Besuch: HTML malt, bevor ein App-Bundle läuft. LCP ist ein serverseitig gesendetes Element, kein clientseitig gerendertes.
• Nächster Klick: Die Oberfläche bleibt eingebaut; nur der Inhaltsbereich tauscht.
• Wiederholter Besuch der Startseite/Shell: Wird lokal oder aus dem Speicher-Cache ausgeliefert.
• Schriftarten und LCP-Bild sind in den ersten 1–2 Roundtrips, nicht erst nach CSS entdeckt.
• CLS bleibt nahe 0 auf den Seiten, die du bearbeitet hast.