Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe in den letzten 14 Monaten dasselbe Core Web Vitals Playbook für fünf produktive TanStack Start Apps ausgeliefert – ein B2B-Abrechnungs-Dashboard für ~3.200 Kunden, ein mandantenfähiges Analytics-Tool, ein Entwickler-Dashboard und zwei Marktplätze. Jede App liegt jetzt bei 95+ Lighthouse Performance, mit einem p75 LCP von unter 1.4 s und einem p75 INP von unter 120 ms auf simuliertem mobilen 4G. Dieser Artikel enthält das Playbook, die Zahlen und die Regressionen.

Verifizierte Quellen: web.dev — Web Vitals · Google Search Central — Core Web Vitals · Chrome for Developers — INP · TanStack Start documentation · TanStack Router SSR streaming

Zuletzt aktualisiert: 2026-08-28 · Changelog

TL;DR: Core Web Vitals 2026 sind LCP, CLS und INP – Googles Ranking-relevante Metriken, die das reale Laden für Nutzer, die Layout-Stabilität und die Reaktionsfähigkeit messen. Die Ziele des 75. Perzentils, die den veröffentlichten Schwellenwerten von Google entsprechen, sind ein LCP unter 2.5 Sekunden, ein CLS unter 0.1 und ein INP unter 200 Millisekunden. Das Playbook, das eine TanStack Start SaaS-App in Produktion auf 95+ Lighthouse Performance bringt, umfasst acht Schritte: Implementieren Sie ein striktes Performance-Budget, verzögern Sie nicht-kritisches JS, streamen Sie SSR über TanStack Router, reservieren Sie Layout-Platz für Schriftarten und Bilder, komprimieren Sie Assets und erstellen Sie Preconnects, nutzen Sie die Cloudflare Cache API am Edge, isolieren Sie Hydration-Kosten und überwachen Sie kontinuierlich p75 RUM. Für den vollständigen Stack siehe TanStack Ship features; für detailliertere Optimierungen des Routings lesen Sie TanStack Router best practices.

Core Web Vitals 2026: Das 8-Schritte-Playbook, das fünf TanStack Start SaaS-Apps auf 95+ brachte

Googles Ranking-System berücksichtigt die Core Web Vitals seit 2021, aber 2026 ist das Jahr, in dem die Schwellenwerte nicht mehr nur ein Zünglein an der Waage sind, sondern eine harte Untergrenze bilden. Das Page Experience Signal ergänzt weiterhin die Relevanz, aber Websites, die die p75-Schwellen verfehlen, verzeichnen in kompetitiven SERPs nun messbare Positionsverluste – ich habe beobachtet, wie sich drei meiner Kunden nach einem einzigen, auf Lighthouse fokussierten Rewrite von Seite 2 auf Seite 1 verbesserten. Dieser Text ist das Playbook, das ich mittlerweile standardmäßig ausliefere.

Was die Core Web Vitals 2026 sind – und warum sie jetzt von Bedeutung sind

Das Trio der Core Web Vitals misst die drei Dimensionen, die ein Nutzer tatsächlich spürt: wie schnell der größte Inhalt angezeigt wird, wie sehr die Seite während des Ladens herumspringt und wie schnell die Seite reagiert, sobald ein Nutzer sie berührt. Gemäß Googles Web Vitals documentation lauten die offiziellen Schwellenwerte beim 75. Perzentil realer Nutzermessungen:

• LCP (Largest Contentful Paint) — unter 2.5 s für "gut" ("good")
• CLS (Cumulative Layout Shift) — unter 0.1 für "gut" ("good")
• INP (Interaction to Next Paint) — unter 200 ms für "gut" ("good")

Die 75.-Perzentil-Regel ist wichtig. Google betrachtet keine Durchschnittswerte; das Nutzererlebnis beim dritten Quartil Ihres Traffics wird bewertet. Das bedeutet, dass 25% Ihrer Nutzer ein schreckliches Erlebnis haben können und Ihr "Page Experience"-Signal trotzdem noch "gut" ist – aber nicht mehr darüber hinaus. Wenn sich Ihr durchschnittlicher Nutzer auf einem langsamen Smartphone befindet, nutzt Ihr p75-Nutzer ein noch schlechteres Smartphone, und genau das ist es, was Google misst.

Das musste ich im 4. Quartal 2025 bei meiner Analytics-App auf die harte Tour lernen. Lighthouse zeigte 92 Performance auf dem Desktop an, aber die CrUX-Felddaten markierten die Seite als "optimierungsbedürftig" ("needs improvement"), da der mobile p75 LCP bei 3.1 s lag. Die Desktop-Zahl war eine Vanity-Metrik; der p75-Feldwert war die Wahrheit.

Das 8-Schritte-Playbook, das ich in jeder TanStack Start SaaS-App ausliefere

Das nachfolgende Playbook wende ich nun standardmäßig in TanStack Ship an. Keiner der Schritte ist exotisch; es sind die simplen, reproduzierbaren Muster, die sich aufsummieren.

Schritt 1: Legen Sie ein Performance-Budget fest, bevor Sie Code schreiben

Performance-Budgets sind die wirkungsvollste Entscheidung, die Sie treffen werden. Das Budget, das ich bei jeder neuen App verwende:

Das Budget wird in der CI über Lighthouse CI bei jedem PR (Pull Request) erzwungen. Ein PR, der das JS-Bundle über 90 KB gzip treibt, wird automatisch blockiert. Diese einzelne Regel hat mich bereits vor vier Performance-Regressionen bewahrt, die sonst unbemerkt in Produktion gegangen wären.

Schritt 2: Verzögern Sie sämtliches nicht-kritisches JavaScript

Der größte LCP-Erfolg einer TanStack Start-App besteht darin, dem First Paint weniger JavaScript auszuliefern. Das Standard-Template von TanStack Start liefert sofort den gesamten Routen-Graphen sowie die Code-Split-Grenzen aller Routen-Loader. Der Trick ist, dieses Konzept beizubehalten, während die eigentlichen Loader-Funktionen und ihre Abhängigkeiten in dynamische Importe verschoben werden.

// src/routes/dashboard.tsx
import { createFileRoute } from '@tanstack/react-router'

export const Route = createFileRoute('/dashboard')({
  // Loader läuft auf dem Server während des SSR — der Code wird NICHT an den Client ausgeliefert
  loader: async ({ context }) => {
    const { getDashboardData } = await import('~/server/dashboard')
    return getDashboardData(context.tenantId)
  },
  component: DashboardPage,
})

function DashboardPage() {
  // useLoaderData() ist typsicher; die Daten befinden sich nach dem SSR bereits im Cache
  const { stats } = Route.useLoaderData()
  return <StatsGrid stats={stats} />
}

Die Loader-Funktion läuft während des SSR-Streamings nur auf dem Server – sie wird im Client-Bundle vollständig entfernt. Der Client empfängt lediglich die JSON-Nutzdaten. Bei meiner B2B-Abrechnungs-App verkleinerte diese einzige Änderung das Client-JS der Dashboard-Route von 184 KB gzip auf 71 KB gzip.

Schritt 3: Streamen Sie SSR über die Loader-Pipeline des TanStack Routers

Die Loader-Pipeline des TanStack Routers streamt HTML schrittweise, während die Daten aufgelöst werden. Der Browser sieht das <head>, dann die Shell und anschließend jeden Bereich, sobald der zugehörige Loader abgeschlossen ist. Laut der TanStack Router documentation ist dieses Streaming-Verhalten standardmäßig aktiviert, wenn die Antwort mit Transfer-Encoding: chunked gesendet wird.

Der LCP-Gewinn liegt darin, dass das LCP-Element – meistens ein Hero-Bild oder eine Überschrift, die aus Loader-Daten gerendert wird – bereits im ersten Chunk ausgeliefert werden kann, anstatt auf das gesamte Dokument zu warten. Bei der Analytics-App senkte das Streaming den p75 LCP von 2.6 s auf 1.4 s.

Schritt 4: Reservieren Sie Layout-Platz für Schriftarten und Bilder

CLS wird fast immer durch drei Dinge verursacht: Web-Schriftarten, die geladen werden, nachdem der Text gerendert wurde, Bilder ohne explizite Dimensionen und dynamische Inhalte, die oberhalb des sichtbaren Bereichs eingefügt werden. Die Fehlerbehebung ist mechanisch:

<!-- Deklarieren Sie bei Bildern immer width und height -->
<img
  src="/hero.webp"
  width="1200"
  height="600"
  alt="Dashboard preview"
  fetchpriority="high"
/>

<!-- Laden Sie die kritische Schriftart per Preload -->
<link
  rel="preload"
  href="/fonts/inter-var.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

<!-- Passen Sie die Metriken der Fallback-Font an die Web-Font an -->
<style>
  @font-face {
    font-family: 'Inter Fallback';
    src: local('Arial');
    size-adjust: 107%;
    ascent-override: 90%;
  }
  html { font-family: 'Inter', 'Inter Fallback', sans-serif; }
</style>

Die Werte für size-adjust und ascent-override stammen aus der Google Fonts CSS API v2 – die Angleichung der Metriken der Fallback-Font an die der Web-Font bedeutet, dass der Browser beim Austausch der Schriftart keinen Reflow durchführen muss. In fünf Apps reduzierte dieses Muster den CLS von 0.12 auf unter 0.03, ohne das Design zu verändern.

Schritt 5: Komprimieren Sie Datensätze, erstellen Sie Preconnects und verwenden Sie moderne Formate

Das Hero-Bild auf einer SaaS-Landingpage ist fast immer das LCP-Element. Drei Einstellungen reduzieren die Transfergröße dieses Bildes um 60–80%:

• Verwenden Sie avif oder webp anstelle von png/jpg (das Element <picture> greift automatisch auf das Fallback zurück)
• Konfigurieren Sie Preconnect zum Asset-Host, damit die TLS-Verhandlung abgeschlossen ist, bevor die Bildanforderung überhaupt gesendet wird
• Setzen Sie fetchpriority="high" beim LCP-Bild und loading="lazy" bei allem anderen

<head>
  <link rel="preconnect" href="https://imgs.tanstackship.com" crossorigin />
  <link rel="dns-prefetch" href="https://imgs.tanstackship.com" />
</head>

Kombiniert verkleinerten diese drei Änderungen das LCP-Bild auf der Landingpage für Analytics von 240 KB auf 48 KB und reduzierten den p75 LCP um weitere 200 ms.

Schritt 6: Cachen Sie HTML am Edge über die Cloudflare Cache API

Eine SaaS-Landingpage ist für 95% der Besucher gleich. Das HTML sollte am Edge gecacht werden. Die Cloudflare Cache API in einem Workers-Handler ist der einfachste Weg:

// src/server/index.ts
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const cache = caches.default
    const cached = await cache.match(request)
    if (cached) return cached

    const response = await renderToStream(request, env)

    // Cachen Sie nur GET-Anfragen, die HTML sind und keinen Session-Cookie haben
    if (
      request.method === 'GET' &&
      response.headers.get('content-type')?.includes('text/html') &&
      !request.headers.get('cookie')?.includes('session=')
    ) {
      response.headers.set('Cache-Control', 'public, max-age=300, s-maxage=3600')
      await cache.put(request, response.clone())
    }

    return response
  },
}

Edge-gecachtes HTML bringt den TTFB auf unter 30 ms in derselben Region, was das Fundament jeglicher LCP-Verbesserung darstellt. Für Seiten, die personalisiert werden müssen, können Sie den Cache-Key so anpassen, dass er die Session-ID enthält, und den Cache pro Mandant arbeiten lassen.

Schritt 7: Isolieren Sie Hydration-Kosten bei rechenintensiven Routen

INP ist die Metrik, die ich 2025 am meisten unterschätzt habe. Der INP misst die Latenz zwischen der Nutzerinteraktion und dem darauf folgenden Paint, der das Resultat anpasst. Bei einer TanStack Start-App kommt der erste INP-Fehlerpunkt oft durch das Hydration-Verfahren zustande – der Moment nach dem Laden der Seite, wenn React Event-Handler anhängt und verzögerte Client-Aufgaben verarbeitet.

Die Lösung besteht darin, die Hydration von Komponenten "below the fold" (im nicht sichtbaren Bereich) so lange aufzuschieben, bis der Nutzer zu ihnen scrollt. TanStack Start integriert sich hierbei nahtlos in das hier dokumentierte IntersectionObserver-Muster:

// src/components/LazyHydrate.tsx
import { useEffect, useRef, useState } from 'react'

export function LazyHydrate({ children, fallback }: { children: React.ReactNode; fallback: React.ReactNode }) {
  const ref = useRef<HTMLDivElement>(null)
  const [visible, setVisible] = useState(false)

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => { if (entry.isIntersecting) setVisible(true) },
      { rootMargin: '200px' }
    )
    if (ref.current) observer.observe(ref.current)
    return () => observer.disconnect()
  }, [])

  return <div ref={ref}>{visible ? children : fallback}</div>
}

Auf dem Entwickler-Dashboard drückte dieses Muster den INP von 280 ms (über Googles Toleranz) auf 110 ms.

Schritt 8: Überwachen Sie p75 RUM, nicht die Lighthouse-Labordaten

Lighthouse nutzt eine simulierte, gedrosselte Verbindung innerhalb einer virtuellen Maschine. Dies ist zwar ein nützlicher CI-Check, spiegelt jedoch nicht das wider, was Nutzer sehen. Die einzige Metrik für tatsächliche "User Experience" ist das 75. Perzentil realer Nutzermessungen, die durch ein RUM-Tool aufgezeichnet und in Produktion ausgewertet werden. Die RUM-Implementierung ist das Thema meines nächsten Beitrags – Real User Monitoring for SaaS 2026 – aber das grundlegende Prinzip lautet: Aktivieren Sie RUM am ersten Tag, setzen Sie Alarme bei p75 90% Ihres Budgets und behandeln Sie jede Regression als P1.

Wie die Zahlen nach dem Playbook aussahen

Fünf produktive Apps, p75 mobile 4G, gemessen anhand von CrUX-Felddaten und der Cloudflare Analytics Engine RUM-Pipeline:

Sämtliche Metriken befinden sich nun bequem innerhalb von Googles "gut"-Schwellenwerten und jede App erreicht 95+ Lighthouse Performance in der CI. Aber ich möchte auch ehrliche Einschränkungen mitgeben: Ich habe nicht auf 3G-Fallback-Netzwerken getestet, und alle fünf Apps basieren auf der gleichen Stack-Familie (TanStack Start + Cloudflare Workers + D1). Ob sich das Playbook demnach direkt auf andere Laufzeitumgebungen übertragen lässt, ist noch unbestätigt.

Die Regressionen, die mich getroffen haben und was ich daraus gelernt habe

Das Playbook ist keine einmalige Maßnahme. Sobald Features veröffentlicht werden, geht Performance kontinuierlich zurück. Drei Regressionen, die mir im vergangenen Jahr auf die Füße gefallen sind:

• Eine Marketingseite erhielt in Q1 2026 ein Chat-Widget eines Drittanbieters. Das Widget fügte dem kritischen Pfad 47 KB an blockierendem JS hinzu. Der p75 INP sprang in 48 Stunden von 95 ms auf 240 ms. Lösung: Lazy-Load erst nach der ersten Interaktion aktivieren.
• Zu einem Dashboard kam eine riesige Charting-Bibliothek dazu. Dieser erste Chunk steigerte das JS der Dashboard-Route von 71 KB auf 138 KB. Der p75 LCP rutschte von 1.2 s auf 2.1 s ab. Lösung: Wechsel auf eine leichtgewichtigere Chart-Bibliothek und Dynamic Import via Hover.
• Ein Marktplatz fügte dynamische Werbeplätze above the fold ein. Der CLS stieg von 0.02 auf 0.18. Lösung: Reservieren Sie jeweils einen Container mit starrer Höhe für jeden Slot.

Jede dieser Regressionen wurde durch den RUM-Alarm und nicht über Lighthouse eingefangen. Der Laborwert blieb grün; der Feldwert wurde rot. Wer lediglich Lighthouse in der CI verwendet, wird all dies übersehen.

Was TanStack Ship als "Out of the Box"-Lösung mitliefert

TanStack Ship ist der Boilerplate für TanStack Start, den ich für Solo-Entwickler gebaut habe, die dieses Playbook ohne eigenen Rewrite anwenden möchten. Jedes Template beinhaltet:

• Alle acht Schritte dieses Playbooks, fertig konfiguriert
• Ein striktes Performance-Budget, das in der CI über Lighthouse CI forciert wird
• Das SSR-Streaming-Muster von TanStack Router direkt integriert
• Die Cloudflare Cache API-Integration mit vernünftigen Standardeinstellungen
• Die oben genannte Komponente LazyHydrate zur sofortigen Nutzung
• Eine RUM-Pipeline, die bereits auf die Cloudflare Analytics Engine angebunden ist

Für einen direkten Vergleich mit anderen TanStack Start-Templates schauen Sie in das TanStack Ship review oder den vs Shipfast comparison. Für die Cloudflare Edge Cache-Strategie im Besonderen behandelt der Cloudflare Workers SSR writeup das Streaming im Detail.

Die Untergrenze 2026 ist einfach: Veröffentlichen Sie ein TanStack Start SaaS-Produkt, das die CWV p75-Schwellen nicht schafft, und Sie werden Ihre Ranking-Position an Wettbewerber abtreten. Das oben beschriebene Playbook liefert die minimal erforderliche Arbeit dafür; TanStack Ship hat exakt diese Arbeit vorab eingebaut, damit Sie stattdessen Features entwickeln können.