G.STANCUTA
Veröffentlicht · 2026 · 05 · 318 Min. Lesezeit

Schnell von Haus aus: Performance und SEO, die einen Crawler überleben

  • Performance
  • SEO
  • Next.js

Statisches Rendering, ehrliche Bilder und SEO-Grundinstallation, die auch ohne JavaScript funktioniert. Wie diese Seite schnell und auffindbar bleibt, und wie ich es prüfe.

Geschwindigkeit und Ranking sind keine Funktionen, die man am Ende dranschraubt. Es sind Architekturentscheidungen vom ersten Tag an. So bleibt diese Seite schnell und auffindbar, und so prüfe ich beides, statt zu raten.

Einmal rendern, für immer ausliefern

Die schnellste Antwort ist eine statische Datei. Jede Seite hier wird zur Build-Zeit vorgerendert, ein HTML-Dokument pro Route und Sprache. Keine Serverarbeit pro Anfrage, kein Datenbank-Roundtrip, kein clientseitiges Laden vor dem ersten Paint. Ein CDN liefert sie vom Rand des Netzes, und der Browser rendert sofort.

Deshalb funktioniert die Seite auch mit abgeschaltetem JavaScript. Der Inhalt steht im HTML, er wird nicht im Browser zusammengebaut, also bekommen Crawler, Screenreader und langsame Verbindungen die ganze Seite. Die Animationen sind eine Schicht obendrauf, nie eine Voraussetzung.

tsx
export function generateStaticParams() {
  return routing.locales.map((locale) => ({locale}));
}

export default async function Page({params}) {
  const {locale} = await params;
  setRequestLocale(locale); // enables fully static rendering
  return <Sections />;
}

Bilder sind der Ort, an dem Geschwindigkeit stirbt

Der häufigste Performance-Fehler ist das Ausliefern schwerer Bilder. Meine Projektdiagramme waren als 1,7-MB-PNGs gestartet, fast 12 MB insgesamt. Die Umwandlung in WebP brachte das auf 0,76 MB ohne sichtbaren Unterschied. Danach läuft jedes Bild durch next/image, das dem Browser AVIF oder WebP in genau der vom Layout angeforderten Größe gibt.

  • AVIF oder WebP automatisch, nie die schwere Originaldatei.
  • Ein expliziter sizes-Hinweis, also eine passend skalierte Variante pro Breakpoint.
  • Lazy Loading unterhalb der Falz, priority nur beim Hero für ein schnelles LCP.
  • Reservierte Maße, damit das Layout beim Laden nicht springt.
tsx
import Image from "next/image";

// Below the fold: lazy, sized, served as AVIF/WebP at the right width.
<Image
  src="/renders/rn-04.webp"
  alt="Polysong, system diagram"
  fill
  sizes="(max-width: 640px) 100vw, 50vw"
  className="object-cover"
/>
Diagramm aus statischem HTML und passend skalierten Bildern für schnelles Laden
Statisches HTML plus passend skaliertes WebP: die Seite ist schnell, bevor ein einziges Skript läuft.

SEO ist Installation, keine Magie

Suche ist meist konsequent betriebene Hygiene. Jede Seite deklariert ihre eigene canonical-URL und hreflang-Alternativen für alle vier Sprachen, damit Google die richtige Seite je Sprache indexiert statt sie zu verschmelzen. Eine Sitemap listet jede Route in jeder Sprache, strukturierte Daten beschreiben, wer ich bin und wo ich arbeite, und jede Seite trägt lokalisierten Titel, Beschreibung und Open-Graph-Bild.

Der erwähnenswerte Bug: ein einziges aus dem Layout geerbtes canonical ließ jeden Blogbeitrag auf die Startseite zeigen. Ein gemeinsames canonical ist schlimmer als keines, weil es Google aktiv sagt, die Seite fallenzulassen.

ts
export async function generateMetadata({params}) {
  const {locale, slug} = await params;
  const path = "/blog/" + slug;
  return {
    title: post.title,
    description: post.excerpt,
    alternates: {
      canonical: localeUrl(locale, path),
      languages: {
        en: localeUrl("en", path),
        it: localeUrl("it", path),
        de: localeUrl("de", path),
        ro: localeUrl("ro", path)
      }
    },
    openGraph: { type: "article", images: [path + "/01.webp"] }
  };
}

Gib dem Agenten eine Checkliste, die er behält

Wenn ein KI-Agent an diesem Code arbeitet, sollte er die Performance- und SEO-Regeln nicht in jeder Sitzung neu herleiten. Ich halte sie in einer Markdown-Gedächtnisdatei, die er zuerst liest, damit die Konventionen über Sitzungen hinweg bestehen und der Agent danach handelt, statt zu raten.

md
# PERFORMANCE.md  (read me before touching the UI)

## Images
- Convert source art to WebP before commit, target under 200 KB.
- Always render through next/image with an explicit sizes attribute.
- Use priority only on the LCP image (the hero); everything else stays lazy.

## Rendering
- Pages must stay static: generateStaticParams + setRequestLocale.
- No client-side data fetching above the fold.

## SEO
- Every page sets its own canonical and hreflang for en, it, de, ro.
- Update the sitemap and JSON-LD whenever routes change.
Ein KI-Agent liest eine Markdown-Performance-Checkliste, bevor er die Seite bearbeitet
Eine Markdown-Gedächtnisdatei hält die Performance- und SEO-Regeln über Agenten-Sitzungen hinweg stabil.

Schnell und auffindbar sind dieselbe Disziplin: mach die langweilige Arbeit auf der Architekturebene, halte die Payload klein und lass die Plattform statische Dateien ausliefern. Das Bemerkenswerte ist, dass nichts daran bemerkenswert ist.

Portfolio · Schriftfeld
Gezeichnet von
G. STANCUTA
Disziplin
AI & AUTOMATION
Standort
MORTER · SÜDTIROL
Status
Verfügbar
Sprachen
IT · EN · RO · DE+
Stack
PLOI · HETZNER
Revision
REV 2026.A
2026

© 2026 Gabriel Stancuta · jumpinotech.com — Mit KI entworfen, gebaut, um sich selbst zu betreiben.