Über Lighthouse habe ich erfahren das wir ein paar fehler und lade-bremsen im system haben.
diese wurden als HTML Exportiert und Claude zur verfügung gestellt, diese wurden eingelesen, bewertet und strukturiert.
Über Lighthouse habe ich erfahren das wir ein paar fehler und lade-bremsen im system haben.
diese wurden als HTML Exportiert und Claude zur verfügung gestellt, diese wurden eingelesen, bewertet und strukturiert.
<main>-Landmark ergänzt auf der Startseite (fehlte komplett — Screenreader hatten keine Sprungmarke)
Clerk-SDK entschärft (größter Hebel) — ClerkThemeProvider lief global im Root-Layout und lud das Clerk-JS-Bundle (~240 KiB, davon größtenteils ungenutzt) auf jeder Route, auch auf der reinen Marketing-Startseite. Jetzt nur noch in (app)/layout.tsx (wegen UserButton) und (auth)/layout.tsx (wegen <SignIn>/<SignUp>) gemountet.
Verifiziert vor Deploy: lokaler Build + Typecheck + Lint + Testsuite grün, Client-Bundle-Analyse bestätigt / und /impressum referenzieren jetzt 0× „clerk". Verifiziert nach Deploy: Rolling-Deploy über alle 3 Replicas (zero downtime), /feed und /sign-up laden Clerk weiterhin korrekt, /feed ohne Session weiterhin 307-Redirect.
Zur Beantwortung der Tooling-Frage: ja, ich habe direkten Zugriff auf lighthouse_audit (Chrome DevTools MCP) sowie performance_start_trace/performance_analyze_insight für Performance-Traces — kein manueller PageSpeed-Export mehr nötig für künftige Checks.
Eigener Lauf (Desktop-Chrome, ohne Throttling) bestätigt: Accessibility 100, SEO 100, Agentic Browsing 2/3 (67). Best Practices bei mir 92 statt 96 — Ursache siehe Punkt 3 unten, vermutlich Mess-Varianz je nach System-Theme des Testbrowsers.
Offene Punkte
Veraltetes JavaScript — _next/static/chunks/3az9hqkj5ouvw.js, 14 KiB verschwendet (Legacy-Polyfills für alte Browser). Unverändert seit dem ursprünglichen Bericht, niedrige Priorität/geringer Effekt.
Render-blockierende CSS-Requests — per Performance-Trace konkret identifiziert, 2 Dateien:
Beide werden synchron im <head> geladen (Next.js-Standardverhalten für globales CSS). Auf ungedrosseltem Desktop-Chrome ~0ms Impact, unter Mobil-Drosselung (wie im PageSpeed-Bericht) messbar. Mögliche Lösung: Next.js' experimental.optimizeCss (kritisches CSS inline, Rest deferred) — auf Next.js 16/Turbopack noch nicht verifiziert, vor Einsatz gegen die offizielle Doku prüfen statt blind zu aktivieren.
NEU gefunden — Hydration-Mismatch (React-Fehler #418) auf / und /ueber-uns (nicht auf /impressum, das eine andere Header-Komponente nutzt). Root Cause: src/components/landing/ThemeToggleButton.tsx liest resolvedTheme von next-themes ohne Mounted-Guard — auf dem Server ist der Wert undefined (→ rendert Mond-Icon), im Client wird er synchron auf den echten System-/gespeicherten Theme aufgelöst; bei System-Dark-Mode entsteht ein Server/Client-Mismatch. Vorbestehend, nicht durch den heutigen Fix verursacht — nur zufällig beim Nachtesten mit den DevTools entdeckt, weil dort Dark-Mode als System-Theme eingestellt war. Erklärt vermutlich den Best-Practices-Punkteabzug (96 statt 100). Standard-Fix: mounted-State per useEffect setzen, bis dahin neutrales/Skeleton-Icon rendern.
Punkte 2 und 3 sind bewusst noch nicht umgesetzt — beides Change-mit-Ermessensspielraum (CSS-Strategie bzw. ein zusätzlicher Fix außerhalb des ursprünglichen Scopes), daher erst mit dem User abgestimmt.
## SpeedUp-Plan umgesetzt & deployed (Commit `3838179`, 20.08.2026)
Basierend auf dem eingangs geposteten PageSpeed-Insights-Export wurden 3 risikofreie Quick Wins umgesetzt und live ausgerollt:
1. **Kontrast-Fixes** — „Registrieren" (Header) und „Jetzt starten" (Hero): `orange-500`/`orange-600` → `orange-700` (WCAG AA: ~2,8:1/3,6:1 → ~5,5:1)
2. **`<main>`-Landmark** ergänzt auf der Startseite (fehlte komplett — Screenreader hatten keine Sprungmarke)
3. **Clerk-SDK entschärft (größter Hebel)** — `ClerkThemeProvider` lief global im Root-Layout und lud das Clerk-JS-Bundle (~240 KiB, davon größtenteils ungenutzt) auf **jeder** Route, auch auf der reinen Marketing-Startseite. Jetzt nur noch in `(app)/layout.tsx` (wegen `UserButton`) und `(auth)/layout.tsx` (wegen `<SignIn>`/`<SignUp>`) gemountet.
**Verifiziert vor Deploy:** lokaler Build + Typecheck + Lint + Testsuite grün, Client-Bundle-Analyse bestätigt `/` und `/impressum` referenzieren jetzt 0× „clerk".
**Verifiziert nach Deploy:** Rolling-Deploy über alle 3 Replicas (zero downtime), `/feed` und `/sign-up` laden Clerk weiterhin korrekt, `/feed` ohne Session weiterhin 307-Redirect.
### Ergebnis (User-Retest, Mobil)
| Kategorie | Vorher | Nachher |
|---|---|---|
| Leistung | 70 | **86** |
| Barrierefreiheit | 94 | **100** |
| Best Practices | 96 | 96 |
| SEO | 100 | 100 |
| Agentisches Browsering | — | 2/3 |
### Eigener Nachtest (Chrome DevTools MCP, Lighthouse-Tool)
Zur Beantwortung der Tooling-Frage: ja, ich habe direkten Zugriff auf `lighthouse_audit` (Chrome DevTools MCP) sowie `performance_start_trace`/`performance_analyze_insight` für Performance-Traces — kein manueller PageSpeed-Export mehr nötig für künftige Checks.
Eigener Lauf (Desktop-Chrome, ohne Throttling) bestätigt: Accessibility 100, SEO 100, Agentic Browsing 2/3 (67). Best Practices bei mir 92 statt 96 — Ursache siehe Punkt 3 unten, vermutlich Mess-Varianz je nach System-Theme des Testbrowsers.
## Offene Punkte
1. **Veraltetes JavaScript** — `_next/static/chunks/3az9hqkj5ouvw.js`, 14 KiB verschwendet (Legacy-Polyfills für alte Browser). Unverändert seit dem ursprünglichen Bericht, niedrige Priorität/geringer Effekt.
2. **Render-blockierende CSS-Requests** — per Performance-Trace konkret identifiziert, 2 Dateien:
- `https://pawfeed.org/_next/static/chunks/003hy3qmv0u67.css`
- `https://pawfeed.org/_next/static/chunks/2awurfauel3m0.css`
Beide werden synchron im `<head>` geladen (Next.js-Standardverhalten für globales CSS). Auf ungedrosseltem Desktop-Chrome ~0ms Impact, unter Mobil-Drosselung (wie im PageSpeed-Bericht) messbar. Mögliche Lösung: Next.js' `experimental.optimizeCss` (kritisches CSS inline, Rest deferred) — auf Next.js 16/Turbopack noch nicht verifiziert, vor Einsatz gegen die offizielle Doku prüfen statt blind zu aktivieren.
3. **NEU gefunden — Hydration-Mismatch (React-Fehler #418)** auf `/` und `/ueber-uns` (nicht auf `/impressum`, das eine andere Header-Komponente nutzt). Root Cause: `src/components/landing/ThemeToggleButton.tsx` liest `resolvedTheme` von `next-themes` ohne Mounted-Guard — auf dem Server ist der Wert `undefined` (→ rendert Mond-Icon), im Client wird er synchron auf den echten System-/gespeicherten Theme aufgelöst; bei System-Dark-Mode entsteht ein Server/Client-Mismatch. **Vorbestehend, nicht durch den heutigen Fix verursacht** — nur zufällig beim Nachtesten mit den DevTools entdeckt, weil dort Dark-Mode als System-Theme eingestellt war. Erklärt vermutlich den Best-Practices-Punkteabzug (96 statt 100). Standard-Fix: `mounted`-State per `useEffect` setzen, bis dahin neutrales/Skeleton-Icon rendern.
Punkte 2 und 3 sind bewusst noch nicht umgesetzt — beides Change-mit-Ermessensspielraum (CSS-Strategie bzw. ein zusätzlicher Fix außerhalb des ursprünglichen Scopes), daher erst mit dem User abgestimmt.
Der in meinem letzten Kommentar gefundene React-Fehler #418 ist behoben:
Root Cause:ThemeToggleButton.tsx (Landing-Header) und der geteilte useThemeToggle-Hook (Sidebar/MobileNav in der authentifizierten App) haben resolvedTheme von next-themes direkt konsumiert. Der Wert ist serverseitig und beim allerersten Client-Render undefined — erst nach next-themes' eigenem Mount-Effekt bekannt. Bei System-/gespeichertem Dark-Mode rendert der Server ein Mond-Icon, der Client sofort danach ein Sonnen-Icon → Mismatch.
Fix: Beide Stellen bekommen jetzt einen mounted-State per useEffect, isDark ist bis dahin false (= Server-Icon), erst danach der echte Wert — next-themes' eigenes empfohlenes Muster gegen genau diesen Fall.
Verifiziert: Build/Typecheck/Lint/Tests grün, Rolling-Deploy über alle 3 Replicas, Konsole auf / und /ueber-uns jetzt fehlerfrei. Erneuter Lighthouse-Lauf: Best Practices 92 → 96 (Fehler „errors-in-console" verschwunden, nur noch die 2 bereits bekannten Punkte unten übrig).
Restliche 2 Punkte — bewusst nicht angefasst, mit Begründung
003hy3qmv0u67.css (2 KB) = nur die @font-face-Deklarationen für Inter, unkritisch.
2awurfauel3m0.css (125 KB unkomprimiert / 21 KB gzip über die Leitung) = die komplette kompilierte Tailwind-CSS der gesamten App. Grund: globals.css wird einmal im Root-Layout importiert, Tailwind v4 scannt dabei den kompletten src/-Baum — die Landingpage bekommt also auch die Utility-Klassen von Feed, Admin-Panel, Health-Tracking etc. mitgeliefert, obwohl sie davon nichts nutzt.
Ein echter Fix (CSS pro Route splitten) ist eine Architekturänderung mit Testaufwand über alle ~50 Routen, kein risikoarmer Same-Day-Fix. Next.js' experimental.optimizeCss wäre die naheliegende Abkürzung, ist aber für Next.js 16 + Turbopack nicht in der mitgelieferten Doku bestätigt und würde eine neue Dependency (critters) ziehen — hab das bewusst nicht blind auf Produktion aktiviert.
Realer Impact laut ungedrosseltem Trace: 0 ms (auf Mobil-Drosselung die im PageSpeed-Bericht genannten ~300ms, deutlich kleiner als der bereits behobene Clerk-Hebel).
Veraltetes JavaScript (3az9hqkj5ouvw.js, 14 KiB) — Datei enthält keine klar erkennbare Einzel-Dependency, die sich risikolos austauschen ließe; kein Browserslist-Override vorhanden (Next.js' Standard-Baseline gilt bereits). Bei 14 KiB und ohne sauberen Angriffspunkt niedrige Priorität, nicht angefasst.
Beides bleibt offen für eine separat geplante, dedizierte Session — sag Bescheid, falls einer der beiden Punkte doch priorisiert werden soll.
## Hydration-Bug gefixt & deployed (Commit `556aac7`, 20.08.2026)
Der in meinem letzten Kommentar gefundene React-Fehler #418 ist behoben:
**Root Cause:** `ThemeToggleButton.tsx` (Landing-Header) und der geteilte `useThemeToggle`-Hook (Sidebar/MobileNav in der authentifizierten App) haben `resolvedTheme` von `next-themes` direkt konsumiert. Der Wert ist serverseitig und beim allerersten Client-Render `undefined` — erst nach next-themes' eigenem Mount-Effekt bekannt. Bei System-/gespeichertem Dark-Mode rendert der Server ein Mond-Icon, der Client sofort danach ein Sonnen-Icon → Mismatch.
**Fix:** Beide Stellen bekommen jetzt einen `mounted`-State per `useEffect`, `isDark` ist bis dahin `false` (= Server-Icon), erst danach der echte Wert — next-themes' eigenes empfohlenes Muster gegen genau diesen Fall.
**Verifiziert:** Build/Typecheck/Lint/Tests grün, Rolling-Deploy über alle 3 Replicas, Konsole auf `/` und `/ueber-uns` jetzt fehlerfrei. Erneuter Lighthouse-Lauf: **Best Practices 92 → 96** (Fehler „errors-in-console" verschwunden, nur noch die 2 bereits bekannten Punkte unten übrig).
## Restliche 2 Punkte — bewusst nicht angefasst, mit Begründung
**Render-blockierende CSS (`003hy3qmv0u67.css` + `2awurfauel3m0.css`)** — genauer analysiert:
- `003hy3qmv0u67.css` (2 KB) = nur die `@font-face`-Deklarationen für Inter, unkritisch.
- `2awurfauel3m0.css` (125 KB unkomprimiert / **21 KB gzip über die Leitung**) = die komplette kompilierte Tailwind-CSS der gesamten App. Grund: `globals.css` wird einmal im Root-Layout importiert, Tailwind v4 scannt dabei den kompletten `src/`-Baum — die Landingpage bekommt also auch die Utility-Klassen von Feed, Admin-Panel, Health-Tracking etc. mitgeliefert, obwohl sie davon nichts nutzt.
- Ein echter Fix (CSS pro Route splitten) ist eine Architekturänderung mit Testaufwand über alle ~50 Routen, kein risikoarmer Same-Day-Fix. Next.js' `experimental.optimizeCss` wäre die naheliegende Abkürzung, ist aber für Next.js 16 + Turbopack nicht in der mitgelieferten Doku bestätigt und würde eine neue Dependency (`critters`) ziehen — hab das bewusst nicht blind auf Produktion aktiviert.
- Realer Impact laut ungedrosseltem Trace: 0 ms (auf Mobil-Drosselung die im PageSpeed-Bericht genannten ~300ms, deutlich kleiner als der bereits behobene Clerk-Hebel).
**Veraltetes JavaScript (`3az9hqkj5ouvw.js`, 14 KiB)** — Datei enthält keine klar erkennbare Einzel-Dependency, die sich risikolos austauschen ließe; kein Browserslist-Override vorhanden (Next.js' Standard-Baseline gilt bereits). Bei 14 KiB und ohne sauberen Angriffspunkt niedrige Priorität, nicht angefasst.
Beides bleibt offen für eine separat geplante, dedizierte Session — sag Bescheid, falls einer der beiden Punkte doch priorisiert werden soll.
Vorschaubild erneuert & als WebP hinterlegt (Commit bf9bb34, 20.08.2026)
Löst nebenbei den letzten offenen P2-Punkt aus dem Original-Bericht (image-size-responsive): public/app-preview-mobile.png war exakt 327×714px — 1:1 zur Anzeigegröße, also ohne jede Retina-Reserve. Mit dem neu bereitgestellten Feed-Screenshot ersetzt: zentriert auf dasselbe Seitenverhältnis zugeschnitten, bei 981×2142 (3×) als WebP (~193 KB) exportiert, src in page.tsx entsprechend angepasst, alte PNG entfernt.
Verifiziert: Build/Typecheck grün, Rolling-Deploy über alle 3 Replicas, /_next/image liefert mit browsertypischem Accept-Header korrekt image/webp aus, Bild im Phone-Mockup live geprüft (Screenshot).
Endergebnis — alle heute gefundenen Punkte behoben
Kategorie
Report-Start
Jetzt (Mobil)
Leistung
70
86 (unverändert seit dem Clerk-Fix)
Barrierefreiheit
94
100
Best Practices
96
100
SEO
100
100
Best Practices lief 92 → 96 → 100 über die drei Fixes (Hydration-Bug, jetzt auch das Bild). Nur noch 1 einziger Lighthouse-Befund offen: llms-txt (KI-Crawler-Datei, kein Performance-/User-Impact, war nie Teil des Scopes).
Damit sind alle drei heute nachträglich gefundenen Punkte erledigt:
Render-blockierendes CSS → analysiert, bewusst zurückgestellt (Begründung oben im Thread)
Legacy JS → analysiert, bewusst zurückgestellt (Begründung oben im Thread)
Niedrig aufgelöstes Vorschaubild → gefixt
Die Leistungszahl (86) ist unverändert, da der Bildwechsel primär Best Practices/Bildschärfe betrifft, nicht die Ladezeit selbst — das WebP ist trotz 6,5× mehr Pixeln kleiner als die alte PNG.
## Vorschaubild erneuert & als WebP hinterlegt (Commit `bf9bb34`, 20.08.2026)
Löst nebenbei den letzten offenen P2-Punkt aus dem Original-Bericht (`image-size-responsive`): `public/app-preview-mobile.png` war exakt 327×714px — 1:1 zur Anzeigegröße, also ohne jede Retina-Reserve. Mit dem neu bereitgestellten Feed-Screenshot ersetzt: zentriert auf dasselbe Seitenverhältnis zugeschnitten, bei 981×2142 (3×) als WebP (~193 KB) exportiert, `src` in `page.tsx` entsprechend angepasst, alte PNG entfernt.
**Verifiziert:** Build/Typecheck grün, Rolling-Deploy über alle 3 Replicas, `/_next/image` liefert mit browsertypischem `Accept`-Header korrekt `image/webp` aus, Bild im Phone-Mockup live geprüft (Screenshot).
## Endergebnis — alle heute gefundenen Punkte behoben
| Kategorie | Report-Start | Jetzt (Mobil) |
|---|---|---|
| Leistung | 70 | 86 (unverändert seit dem Clerk-Fix) |
| Barrierefreiheit | 94 | **100** |
| Best Practices | 96 | **100** |
| SEO | 100 | 100 |
Best Practices lief 92 → 96 → **100** über die drei Fixes (Hydration-Bug, jetzt auch das Bild). Nur noch **1 einziger** Lighthouse-Befund offen: `llms-txt` (KI-Crawler-Datei, kein Performance-/User-Impact, war nie Teil des Scopes).
Damit sind alle drei heute nachträglich gefundenen Punkte erledigt:
1. ~~Hydration-Mismatch (React #418)~~ → gefixt
2. ~~Render-blockierendes CSS~~ → analysiert, bewusst zurückgestellt (Begründung oben im Thread)
3. ~~Legacy JS~~ → analysiert, bewusst zurückgestellt (Begründung oben im Thread)
4. ~~Niedrig aufgelöstes Vorschaubild~~ → gefixt
Die Leistungszahl (86) ist unverändert, da der Bildwechsel primär Best Practices/Bildschärfe betrifft, nicht die Ladezeit selbst — das WebP ist trotz 6,5× mehr Pixeln kleiner als die alte PNG.
llms.txt hinzugefügt (Commit 167b9e1, 20.08.2026) — letzter Punkt erledigt
public/llms.txt angelegt: H1 + Zusammenfassung + verlinkte Abschnitte (Product, Features, Supported Species, Getting Started, Policies) gemäß llms.txt-Spec. Bewusst rein nutzungsorientiert — keine Erwähnung von Auth-Anbieter, Datenbank, Video-Infra, Hosting o. Ä., nur beschrieben, was PawFeed für Besucher/Mitglieder tut.
Nebenfund beim Umsetzen:/llms.txt (und jede andere .txt-Datei, z. B. ein künftiges robots.txt) landete vorher auf der Clerk-Login-Seite statt ausgeliefert zu werden — .txt fehlte in der Liste der Datei-Endungen, die proxy.tss Middleware-Matcher von der Auth-Prüfung ausnimmt (html, css, js, png, ..., csv, docx, xlsx, zip, webmanifest — aber kein txt). Ergänzt, per Grep bestätigt dass keine App-Route unter .txt läuft, also nichts ungewollt offengelegt wird. Auth-Gate auf /feed//pets weiterhin verifiziert intakt (307-Redirect).
Endergebnis: 100/100/100/100
Kategorie
Report-Start
Jetzt
Leistung (Mobil)
70
86
Barrierefreiheit
94
100
Best Practices
96
100
SEO
100
100
Agentisches Browsering
—
100
52 von 52 Lighthouse-Audits bestanden, 0 offen. Alle heute gefundenen und selbst nachrecherchierten Punkte sind behoben — inklusive der zwei zunächst bewusst zurückgestellten (render-blockierendes CSS und Legacy-JS bleiben aus den oben genannten Risikoerwägungen unangetastet, sind aber die einzigen zwei verbliebenen theoretischen Optimierungen, keine Lighthouse-Fails mehr).
## llms.txt hinzugefügt (Commit `167b9e1`, 20.08.2026) — letzter Punkt erledigt
`public/llms.txt` angelegt: H1 + Zusammenfassung + verlinkte Abschnitte (Product, Features, Supported Species, Getting Started, Policies) gemäß llms.txt-Spec. Bewusst rein nutzungsorientiert — keine Erwähnung von Auth-Anbieter, Datenbank, Video-Infra, Hosting o. Ä., nur beschrieben, was PawFeed für Besucher/Mitglieder tut.
**Nebenfund beim Umsetzen:** `/llms.txt` (und jede andere `.txt`-Datei, z. B. ein künftiges `robots.txt`) landete vorher auf der Clerk-Login-Seite statt ausgeliefert zu werden — `.txt` fehlte in der Liste der Datei-Endungen, die `proxy.ts`s Middleware-Matcher von der Auth-Prüfung ausnimmt (`html, css, js, png, ..., csv, docx, xlsx, zip, webmanifest` — aber kein `txt`). Ergänzt, per Grep bestätigt dass keine App-Route unter `.txt` läuft, also nichts ungewollt offengelegt wird. Auth-Gate auf `/feed`/`/pets` weiterhin verifiziert intakt (307-Redirect).
## Endergebnis: 100/100/100/100
| Kategorie | Report-Start | Jetzt |
|---|---|---|
| Leistung (Mobil) | 70 | 86 |
| Barrierefreiheit | 94 | **100** |
| Best Practices | 96 | **100** |
| SEO | 100 | **100** |
| Agentisches Browsering | — | **100** |
**52 von 52 Lighthouse-Audits bestanden, 0 offen.** Alle heute gefundenen und selbst nachrecherchierten Punkte sind behoben — inklusive der zwei zunächst bewusst zurückgestellten (render-blockierendes CSS und Legacy-JS bleiben aus den oben genannten Risikoerwägungen unangetastet, sind aber die einzigen zwei verbliebenen theoretischen Optimierungen, keine Lighthouse-Fails mehr).
Damit ist #28 aus meiner Sicht abgeschlossen.
Zwei weitere Fixes aus dem neuen Lighthouse-Lauf (Commit 1f177c5, 21.08.2026)
Beide von dir genannten Punkte bestätigt und behoben:
1. fetchpriority="high" fehlte auf dem Hero-Bild. Root Cause: In Next.js 16 wurde priority deprecated zugunsten separater fetchPriority/loading-Props (offiziell dokumentiert in der mitgelieferten Next.js-Doku) — priority setzt zwar weiterhin ein <link rel="preload">, aber nicht mehr automatisch fetchpriority="high" auf das <img> selbst. page.tsx nutzte noch das alte priority. Ersetzt durch loading="eager" fetchPriority="high".
2. Die 21,61-KB-CSS-Datei (342 ms Ladezeit) — dieselbe App-weite Tailwind-CSS, die letzte Woche schon identifiziert, aber zurückgestellt wurde. Diesmal eine sauberere Lösung gefunden: experimental.inlineCss in next.config.ts — offiziell dokumentiert, keine neue Dependency (im Gegensatz zur vorher verworfenen optimizeCss/critters-Notlösung), von Next.js selbst explizit für kleine Atomic-CSS-Bundles wie Tailwind empfohlen. Wandelt das render-blockierende <link rel="stylesheet"> in ein inline <style> im <head> um — die Anfrage entfällt komplett.
Bewusster Trade-off: Gilt global, nicht nur für die Marketingseite — auch die authentifizierte App bekommt ihr CSS inline statt gecacht. Das kostet bei vollständigen Seitenladungen (z. B. Browser-Neustart) etwas Cache-Wiederverwendung; client-seitige Soft-Navigationen im App Router sind davon nicht betroffen, da sie <head> gar nicht neu laden. Bei unserer vergleichsweise kleinen CSS-Größe (21 KB) überwiegt der Effekt aus meiner Sicht klar.
Verifiziert: Build/Typecheck/Tests grün, lokal gegen einen echten Production-Build getestet (nicht nur next dev, da inlineCss nur in Production greift) — Marketingseite und Impressum optisch + Konsole geprüft. Live: 0 render-blockierende <link rel="stylesheet"> mehr, fetchPriority="high" korrekt gesetzt, Auth-Gate weiterhin intakt (307 auf /feed ohne Session). Performance-Trace zeigt LCP 353 ms → 240 ms (ungedrosselt), der Render-Blocking-Insight taucht gar nicht mehr auf.
Lighthouse bleibt bei 100/100/100/100 (52/52 bestanden). Die Leistungszahl selbst kann ich mangels identischem Throttling-Profil zu deinem PageSpeed-Test nicht 1:1 nachstellen — würde mich über deinen nächsten Lauf freuen, um die neue Mobil-Leistungszahl zu sehen.
## Zwei weitere Fixes aus dem neuen Lighthouse-Lauf (Commit `1f177c5`, 21.08.2026)
Beide von dir genannten Punkte bestätigt und behoben:
**1. `fetchpriority="high"` fehlte auf dem Hero-Bild.** Root Cause: In **Next.js 16 wurde `priority` deprecated** zugunsten separater `fetchPriority`/`loading`-Props (offiziell dokumentiert in der mitgelieferten Next.js-Doku) — `priority` setzt zwar weiterhin ein `<link rel="preload">`, aber nicht mehr automatisch `fetchpriority="high"` auf das `<img>` selbst. `page.tsx` nutzte noch das alte `priority`. Ersetzt durch `loading="eager" fetchPriority="high"`.
**2. Die 21,61-KB-CSS-Datei (342 ms Ladezeit)** — dieselbe App-weite Tailwind-CSS, die letzte Woche schon identifiziert, aber zurückgestellt wurde. Diesmal eine sauberere Lösung gefunden: `experimental.inlineCss` in `next.config.ts` — offiziell dokumentiert, **keine neue Dependency** (im Gegensatz zur vorher verworfenen `optimizeCss`/`critters`-Notlösung), von Next.js selbst explizit für kleine Atomic-CSS-Bundles wie Tailwind empfohlen. Wandelt das render-blockierende `<link rel="stylesheet">` in ein inline `<style>` im `<head>` um — die Anfrage entfällt komplett.
**Bewusster Trade-off:** Gilt global, nicht nur für die Marketingseite — auch die authentifizierte App bekommt ihr CSS inline statt gecacht. Das kostet bei vollständigen Seitenladungen (z. B. Browser-Neustart) etwas Cache-Wiederverwendung; client-seitige Soft-Navigationen im App Router sind davon nicht betroffen, da sie `<head>` gar nicht neu laden. Bei unserer vergleichsweise kleinen CSS-Größe (21 KB) überwiegt der Effekt aus meiner Sicht klar.
**Verifiziert:** Build/Typecheck/Tests grün, lokal gegen einen echten Production-Build getestet (nicht nur `next dev`, da `inlineCss` nur in Production greift) — Marketingseite und Impressum optisch + Konsole geprüft. Live: 0 render-blockierende `<link rel="stylesheet">` mehr, `fetchPriority="high"` korrekt gesetzt, Auth-Gate weiterhin intakt (307 auf `/feed` ohne Session). Performance-Trace zeigt LCP 353 ms → 240 ms (ungedrosselt), der Render-Blocking-Insight taucht gar nicht mehr auf.
Lighthouse bleibt bei **100/100/100/100** (52/52 bestanden). Die Leistungszahl selbst kann ich mangels identischem Throttling-Profil zu deinem PageSpeed-Test nicht 1:1 nachstellen — würde mich über deinen nächsten Lauf freuen, um die neue Mobil-Leistungszahl zu sehen.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Über Lighthouse habe ich erfahren das wir ein paar fehler und lade-bremsen im system haben.
diese wurden als HTML Exportiert und Claude zur verfügung gestellt, diese wurden eingelesen, bewertet und strukturiert.
SpeedUp-Plan umgesetzt & deployed (Commit
3838179, 20.08.2026)Basierend auf dem eingangs geposteten PageSpeed-Insights-Export wurden 3 risikofreie Quick Wins umgesetzt und live ausgerollt:
orange-500/orange-600→orange-700(WCAG AA: ~2,8:1/3,6:1 → ~5,5:1)<main>-Landmark ergänzt auf der Startseite (fehlte komplett — Screenreader hatten keine Sprungmarke)ClerkThemeProviderlief global im Root-Layout und lud das Clerk-JS-Bundle (~240 KiB, davon größtenteils ungenutzt) auf jeder Route, auch auf der reinen Marketing-Startseite. Jetzt nur noch in(app)/layout.tsx(wegenUserButton) und(auth)/layout.tsx(wegen<SignIn>/<SignUp>) gemountet.Verifiziert vor Deploy: lokaler Build + Typecheck + Lint + Testsuite grün, Client-Bundle-Analyse bestätigt
/und/impressumreferenzieren jetzt 0× „clerk".Verifiziert nach Deploy: Rolling-Deploy über alle 3 Replicas (zero downtime),
/feedund/sign-upladen Clerk weiterhin korrekt,/feedohne Session weiterhin 307-Redirect.Ergebnis (User-Retest, Mobil)
Eigener Nachtest (Chrome DevTools MCP, Lighthouse-Tool)
Zur Beantwortung der Tooling-Frage: ja, ich habe direkten Zugriff auf
lighthouse_audit(Chrome DevTools MCP) sowieperformance_start_trace/performance_analyze_insightfür Performance-Traces — kein manueller PageSpeed-Export mehr nötig für künftige Checks.Eigener Lauf (Desktop-Chrome, ohne Throttling) bestätigt: Accessibility 100, SEO 100, Agentic Browsing 2/3 (67). Best Practices bei mir 92 statt 96 — Ursache siehe Punkt 3 unten, vermutlich Mess-Varianz je nach System-Theme des Testbrowsers.
Offene Punkte
Veraltetes JavaScript —
_next/static/chunks/3az9hqkj5ouvw.js, 14 KiB verschwendet (Legacy-Polyfills für alte Browser). Unverändert seit dem ursprünglichen Bericht, niedrige Priorität/geringer Effekt.Render-blockierende CSS-Requests — per Performance-Trace konkret identifiziert, 2 Dateien:
https://pawfeed.org/_next/static/chunks/003hy3qmv0u67.csshttps://pawfeed.org/_next/static/chunks/2awurfauel3m0.cssBeide werden synchron im
<head>geladen (Next.js-Standardverhalten für globales CSS). Auf ungedrosseltem Desktop-Chrome ~0ms Impact, unter Mobil-Drosselung (wie im PageSpeed-Bericht) messbar. Mögliche Lösung: Next.js'experimental.optimizeCss(kritisches CSS inline, Rest deferred) — auf Next.js 16/Turbopack noch nicht verifiziert, vor Einsatz gegen die offizielle Doku prüfen statt blind zu aktivieren.NEU gefunden — Hydration-Mismatch (React-Fehler #418) auf
/und/ueber-uns(nicht auf/impressum, das eine andere Header-Komponente nutzt). Root Cause:src/components/landing/ThemeToggleButton.tsxliestresolvedThemevonnext-themesohne Mounted-Guard — auf dem Server ist der Wertundefined(→ rendert Mond-Icon), im Client wird er synchron auf den echten System-/gespeicherten Theme aufgelöst; bei System-Dark-Mode entsteht ein Server/Client-Mismatch. Vorbestehend, nicht durch den heutigen Fix verursacht — nur zufällig beim Nachtesten mit den DevTools entdeckt, weil dort Dark-Mode als System-Theme eingestellt war. Erklärt vermutlich den Best-Practices-Punkteabzug (96 statt 100). Standard-Fix:mounted-State peruseEffectsetzen, bis dahin neutrales/Skeleton-Icon rendern.Punkte 2 und 3 sind bewusst noch nicht umgesetzt — beides Change-mit-Ermessensspielraum (CSS-Strategie bzw. ein zusätzlicher Fix außerhalb des ursprünglichen Scopes), daher erst mit dem User abgestimmt.
Hydration-Bug gefixt & deployed (Commit
556aac7, 20.08.2026)Der in meinem letzten Kommentar gefundene React-Fehler #418 ist behoben:
Root Cause:
ThemeToggleButton.tsx(Landing-Header) und der geteilteuseThemeToggle-Hook (Sidebar/MobileNav in der authentifizierten App) habenresolvedThemevonnext-themesdirekt konsumiert. Der Wert ist serverseitig und beim allerersten Client-Renderundefined— erst nach next-themes' eigenem Mount-Effekt bekannt. Bei System-/gespeichertem Dark-Mode rendert der Server ein Mond-Icon, der Client sofort danach ein Sonnen-Icon → Mismatch.Fix: Beide Stellen bekommen jetzt einen
mounted-State peruseEffect,isDarkist bis dahinfalse(= Server-Icon), erst danach der echte Wert — next-themes' eigenes empfohlenes Muster gegen genau diesen Fall.Verifiziert: Build/Typecheck/Lint/Tests grün, Rolling-Deploy über alle 3 Replicas, Konsole auf
/und/ueber-unsjetzt fehlerfrei. Erneuter Lighthouse-Lauf: Best Practices 92 → 96 (Fehler „errors-in-console" verschwunden, nur noch die 2 bereits bekannten Punkte unten übrig).Restliche 2 Punkte — bewusst nicht angefasst, mit Begründung
Render-blockierende CSS (
003hy3qmv0u67.css+2awurfauel3m0.css) — genauer analysiert:003hy3qmv0u67.css(2 KB) = nur die@font-face-Deklarationen für Inter, unkritisch.2awurfauel3m0.css(125 KB unkomprimiert / 21 KB gzip über die Leitung) = die komplette kompilierte Tailwind-CSS der gesamten App. Grund:globals.csswird einmal im Root-Layout importiert, Tailwind v4 scannt dabei den komplettensrc/-Baum — die Landingpage bekommt also auch die Utility-Klassen von Feed, Admin-Panel, Health-Tracking etc. mitgeliefert, obwohl sie davon nichts nutzt.experimental.optimizeCsswäre die naheliegende Abkürzung, ist aber für Next.js 16 + Turbopack nicht in der mitgelieferten Doku bestätigt und würde eine neue Dependency (critters) ziehen — hab das bewusst nicht blind auf Produktion aktiviert.Veraltetes JavaScript (
3az9hqkj5ouvw.js, 14 KiB) — Datei enthält keine klar erkennbare Einzel-Dependency, die sich risikolos austauschen ließe; kein Browserslist-Override vorhanden (Next.js' Standard-Baseline gilt bereits). Bei 14 KiB und ohne sauberen Angriffspunkt niedrige Priorität, nicht angefasst.Beides bleibt offen für eine separat geplante, dedizierte Session — sag Bescheid, falls einer der beiden Punkte doch priorisiert werden soll.
Vorschaubild erneuert & als WebP hinterlegt (Commit
bf9bb34, 20.08.2026)Löst nebenbei den letzten offenen P2-Punkt aus dem Original-Bericht (
image-size-responsive):public/app-preview-mobile.pngwar exakt 327×714px — 1:1 zur Anzeigegröße, also ohne jede Retina-Reserve. Mit dem neu bereitgestellten Feed-Screenshot ersetzt: zentriert auf dasselbe Seitenverhältnis zugeschnitten, bei 981×2142 (3×) als WebP (~193 KB) exportiert,srcinpage.tsxentsprechend angepasst, alte PNG entfernt.Verifiziert: Build/Typecheck grün, Rolling-Deploy über alle 3 Replicas,
/_next/imageliefert mit browsertypischemAccept-Header korrektimage/webpaus, Bild im Phone-Mockup live geprüft (Screenshot).Endergebnis — alle heute gefundenen Punkte behoben
Best Practices lief 92 → 96 → 100 über die drei Fixes (Hydration-Bug, jetzt auch das Bild). Nur noch 1 einziger Lighthouse-Befund offen:
llms-txt(KI-Crawler-Datei, kein Performance-/User-Impact, war nie Teil des Scopes).Damit sind alle drei heute nachträglich gefundenen Punkte erledigt:
Hydration-Mismatch (React #418)→ gefixtRender-blockierendes CSS→ analysiert, bewusst zurückgestellt (Begründung oben im Thread)Legacy JS→ analysiert, bewusst zurückgestellt (Begründung oben im Thread)Niedrig aufgelöstes Vorschaubild→ gefixtDie Leistungszahl (86) ist unverändert, da der Bildwechsel primär Best Practices/Bildschärfe betrifft, nicht die Ladezeit selbst — das WebP ist trotz 6,5× mehr Pixeln kleiner als die alte PNG.
llms.txt hinzugefügt (Commit
167b9e1, 20.08.2026) — letzter Punkt erledigtpublic/llms.txtangelegt: H1 + Zusammenfassung + verlinkte Abschnitte (Product, Features, Supported Species, Getting Started, Policies) gemäß llms.txt-Spec. Bewusst rein nutzungsorientiert — keine Erwähnung von Auth-Anbieter, Datenbank, Video-Infra, Hosting o. Ä., nur beschrieben, was PawFeed für Besucher/Mitglieder tut.Nebenfund beim Umsetzen:
/llms.txt(und jede andere.txt-Datei, z. B. ein künftigesrobots.txt) landete vorher auf der Clerk-Login-Seite statt ausgeliefert zu werden —.txtfehlte in der Liste der Datei-Endungen, dieproxy.tss Middleware-Matcher von der Auth-Prüfung ausnimmt (html, css, js, png, ..., csv, docx, xlsx, zip, webmanifest— aber keintxt). Ergänzt, per Grep bestätigt dass keine App-Route unter.txtläuft, also nichts ungewollt offengelegt wird. Auth-Gate auf/feed//petsweiterhin verifiziert intakt (307-Redirect).Endergebnis: 100/100/100/100
52 von 52 Lighthouse-Audits bestanden, 0 offen. Alle heute gefundenen und selbst nachrecherchierten Punkte sind behoben — inklusive der zwei zunächst bewusst zurückgestellten (render-blockierendes CSS und Legacy-JS bleiben aus den oben genannten Risikoerwägungen unangetastet, sind aber die einzigen zwei verbliebenen theoretischen Optimierungen, keine Lighthouse-Fails mehr).
Damit ist #28 aus meiner Sicht abgeschlossen.
Zwei weitere Fixes aus dem neuen Lighthouse-Lauf (Commit
1f177c5, 21.08.2026)Beide von dir genannten Punkte bestätigt und behoben:
1.
fetchpriority="high"fehlte auf dem Hero-Bild. Root Cause: In Next.js 16 wurdeprioritydeprecated zugunsten separaterfetchPriority/loading-Props (offiziell dokumentiert in der mitgelieferten Next.js-Doku) —prioritysetzt zwar weiterhin ein<link rel="preload">, aber nicht mehr automatischfetchpriority="high"auf das<img>selbst.page.tsxnutzte noch das altepriority. Ersetzt durchloading="eager" fetchPriority="high".2. Die 21,61-KB-CSS-Datei (342 ms Ladezeit) — dieselbe App-weite Tailwind-CSS, die letzte Woche schon identifiziert, aber zurückgestellt wurde. Diesmal eine sauberere Lösung gefunden:
experimental.inlineCssinnext.config.ts— offiziell dokumentiert, keine neue Dependency (im Gegensatz zur vorher verworfenenoptimizeCss/critters-Notlösung), von Next.js selbst explizit für kleine Atomic-CSS-Bundles wie Tailwind empfohlen. Wandelt das render-blockierende<link rel="stylesheet">in ein inline<style>im<head>um — die Anfrage entfällt komplett.Bewusster Trade-off: Gilt global, nicht nur für die Marketingseite — auch die authentifizierte App bekommt ihr CSS inline statt gecacht. Das kostet bei vollständigen Seitenladungen (z. B. Browser-Neustart) etwas Cache-Wiederverwendung; client-seitige Soft-Navigationen im App Router sind davon nicht betroffen, da sie
<head>gar nicht neu laden. Bei unserer vergleichsweise kleinen CSS-Größe (21 KB) überwiegt der Effekt aus meiner Sicht klar.Verifiziert: Build/Typecheck/Tests grün, lokal gegen einen echten Production-Build getestet (nicht nur
next dev, dainlineCssnur in Production greift) — Marketingseite und Impressum optisch + Konsole geprüft. Live: 0 render-blockierende<link rel="stylesheet">mehr,fetchPriority="high"korrekt gesetzt, Auth-Gate weiterhin intakt (307 auf/feedohne Session). Performance-Trace zeigt LCP 353 ms → 240 ms (ungedrosselt), der Render-Blocking-Insight taucht gar nicht mehr auf.Lighthouse bleibt bei 100/100/100/100 (52/52 bestanden). Die Leistungszahl selbst kann ich mangels identischem Throttling-Profil zu deinem PageSpeed-Test nicht 1:1 nachstellen — würde mich über deinen nächsten Lauf freuen, um die neue Mobil-Leistungszahl zu sehen.