Meine Website
[site address] auf meinem Opus Growth Server (Server
[server name], Site-Key
[site key], falls es eine zusätzliche Website ist) wurde mit dem Site-Kit gebaut und ist auf Smartphones langsam. Das Kit lädt Tailwind über das Play CDN, das im Browser kompiliert, die Schriften von Fontshare und die Animationsbibliotheken von jsDelivr und gibt das Menü per JavaScript aus. Verwandle all das in kompilierte Dateien auf meinem eigenen Server, ohne das Aussehen der Website zu verändern. Das Ziel: Während eine Seite lädt, sendet die Website keinen einzigen Request an eine fremde Domain.
1. Ausgangswerte. Notiere die aktuelle Version mit site_versions. Führe core_web_vitals für die Startseite und
[heaviest page] auf Mobilgerät und Desktop mit resources=true aus. Trage Performance-Score, LCP, CLS, Gesamtzahl der Requests, Gesamtgröße und die Requests, die deine eigene Domain verlassen, in eine Tabelle ein. Liste die HTML-Dateien mit site_list_files auf und hole aus jeder Seite alle `<script>`- und `<link>`-Tags.
2. Zeig mir den Plan und warte auf meine Freigabe. Liste jede Datei auf, die geändert oder hinzugefügt wird.
3. Tailwind kompilieren. Verschiebe die Inline-Einstellung `tailwind.config` aus den Seiten nach `_src/tailwind.config.js`; setze content auf `
["./*.html", "./**/*.html"]` und füge jede JavaScript-Datei hinzu, die noch Klassen erzeugt. Erstelle `_src/input.css` aus den Zeilen `@tailwind base; @tailwind components; @tailwind utilities;`, gefolgt vom Inhalt von assets/app.css. Führe `npx --yes tailwindcss@3 -c _src/tailwind.config.js -i _src/input.css -o assets/site.css --minify` mit site_run_command aus. Gib der Datei einen aus dem Hash ihres Inhalts abgeleiteten Namen, zum Beispiel `assets/site.3f9a1c2b.css`, aktualisiere den Link auf jeder Seite und lösche das Play-CDN-Skript sowie die Inline-Einstellung. Baue nach jeder HTML-Änderung, die Klassen betrifft, neu, sonst fehlen die neuen Klassen im CSS.
4. Schriften selbst hosten. Hole das Fontshare-CSS mit einem EIGENEN Request für jede Familie und jeden Schnitt, zum Beispiel `https://api.fontshare.com/v2/css?f[]=satoshi@400&display=swap`; wir haben erlebt, dass andere Familien zurückkamen, wenn mehrere Familien oder Schnitte gleichzeitig angefragt wurden. Prüfe daher jedes Mal den zurückgegebenen font-family-Namen. Lade die woff2-Dateien nach `assets/fonts/` herunter, schreibe die `@font-face`-Regeln mit `font-display: swap` an den Anfang von assets/app.css (design-check sucht dort nach auffälliger Typografie) und lade die Fließtextschrift sowie die Schrift der großen Überschrift im ersten Bildschirmbereich mit `<link rel="preload" as="font" type="font/woff2" crossorigin>` vor. Lösche die Fontshare-Links für `preconnect` und Stylesheet. Prüfe, ob die Schriftlizenz Self-Hosting erlaubt.
5. Bilder neu erzeugen. Verschiebe die JPG- und PNG-Quelldateien nach `_src/img/`. Installiere sharp außerhalb des Website-Ordners: Starte `mkdir -p /data/_build && cd /data/_build && npm init -y && npm i sharp` mit site_run_command und background=true und verfolge es mit site_command_status; falls dieser Ordner nicht beschreibbar ist, sag mir, warum. Erzeuge mit einem Node-Skript für jedes Bild WebP (Qualität 72) und AVIF (Qualität 50) in 480, 800, 1200 und 1600 Pixeln Breite. Umschließe im HTML jedes Bild mit `<picture>`: ein `<source type="image/avif" srcset sizes>` für AVIF, ein WebP-`<img>` als Fallback mit eigenem srcset und sizes sowie der tatsächlichen Breite und Höhe des Quellbilds. Das Hauptbild im ersten Bildschirmbereich bekommt `fetchpriority="high"` und wird nicht lazy geladen; alle anderen bekommen `loading="lazy" decoding="async"`. Schreibe sizes passend zur Breite, die das Bild tatsächlich einnimmt.
6. Skripte aufräumen. Wenn die Website keine Animationen hat oder nur dekorative Hooks wie `data-reveal`, entferne GSAP, ScrollTrigger, SplitText, Lenis, Swiper, motion.js und das Inline-Skript, das die Klasse `anim` hinzufügt, vollständig und lösche die Lenis- und anim-Regeln aus app.css. Wenn Animationen wirklich nötig sind, kopiere die Bibliothek nach `assets/vendor/`, lade sie mit `defer` nur auf den Seiten, die sie nutzen, und prüfe, dass der Inhalt bei `prefers-reduced-motion` sichtbar bleibt. Mach Menü und Footer mit einem Skript `chrome-stamp.mjs` zu statischem HTML: Es liest site.config.js, schreibt zwischen die Marker `<!-- chrome:nav:start -->`, `<!-- chrome:nav:end -->` und chrome:footer, baut das mobile Menü mit `<details>`, hält Links mindestens 44 Pixel hoch und verwendet für die Spaltentitel im Footer Absätze statt h4. Entferne dann chrome.js und das site.config.js-Script-Tag aus den Seiten; site.config.js bleibt nur als Datendatei, die die Skripte lesen.
7. Drittanbieter-Requests auf null bringen. Durchsuche HTML und CSS mit site_run_command nach src- und href-Werten, die mit `https://` beginnen; verschiebe jede Ressource außerhalb deiner eigenen Domain, tel:-, mailto:- und wa.me-Links auf die Website oder entferne sie. Lege das Favicon in `assets/img/` ab und verlinke es auf jeder Seite, sonst fragt der Browser /favicon.ico an und protokolliert einen 404 in der Konsole.
8. Cache-Header. Führe site_headers mit mode="list" aus. Wenn keine Datei unter assets jemals unter demselben Namen ersetzt wird (der CSS-Name trägt einen Hash, Bilder bekommen bei Änderung einen neuen Namen), zeige die Zeile `/assets/* Cache-Control: public, max-age=31536000, immutable` mit confirm=false als Vorschau und wende sie nach meiner Freigabe mit confirm=true an. Frag nicht nach Cache-Control für HTML; die Plattform liefert HTML bereits als no-cache aus.
9. Prüfungen und neue Messung. Führe `node seo-stamp.mjs`, `node chrome-stamp.mjs`, den CSS-Build, `node seo-check.mjs`, `node design-check.mjs` und `npx --yes html-validate "**/*.html"` in dieser Reihenfolge aus und bring alle auf null Fehler. Prüfe jede Seite mit site_preview bei 360, 390, 768 und 1440 Pixeln Breite. Wiederhole die core_web_vitals-Messung aus Schritt 1 auf denselben Seiten und führe außerdem seo_audit mit runs=2 für die Startseite aus. Liegt die mobile Performance unter 95, finde die Ursache in den resources=true-Listen und behebe sie; die häufigste Ursache ist ein Layout Shift durch eine Überschriftenschrift, die nicht vorgeladen wurde.
Ausgabe: eine Vorher-Nachher-Tabelle (Seite, Gerät, Performance, LCP, CLS, Anzahl Requests, Gesamt-KB, Anzahl Drittanbieter-Requests), die Liste der hinzugefügten und gelöschten Dateien, die aktiven site_headers-Zeilen und ein kurzer Hinweis, welche Befehle nach der nächsten Änderung in welcher Reihenfolge erneut auszuführen sind. Wenn ein Schritt die Website kaputt macht, geh mit site_restore zu der notierten Version zurück und sag es mir.
