Performance first: Warum Geschwindigkeit kein Feinschliff, sondern Grundlage ist

„Performance machen wir später, wenn die Site steht.“ Dieser Satz ist 2026 fast immer ein teurer Irrtum. Geschwindigkeit ist keine Politur — sie ist Architektur. Wer sie ans Ende schiebt, kann sie meistens nicht mehr nachholen.

Warum eine langsame Site mehr verliert als nur Ranking

Wenn eine Site langsam lädt, passiert zweierlei gleichzeitig. Erstens: Besucher springen ab. Schon ab drei Sekunden Ladezeit verlieren Mittelstands-Sites typischerweise ein Drittel der Erst-Besucher — sie sehen die weiße Fläche, denken „kaputt“ oder „lohnt nicht“ und gehen zurück zur Suchergebnis-Seite. Zweitens: Google merkt das. Bounce-Signale fließen in das Ranking ein, und Core Web Vitals sind seit Jahren ein direkter Ranking-Faktor.

Eine langsame Site verliert also doppelt: Sie verliert die Besucher, die kommen, und sie verliert Besucher, die nie kommen, weil Google sie nicht ausreichend hoch zeigt. Beide Effekte verstärken sich gegenseitig.

Die drei Zahlen, die 2026 zählen

Google misst Performance mit drei Kennzahlen, die zusammen Core Web Vitals heißen. Sie sind keine Feinheit für Entwickler — sie sind das, was die Site real durchlebt.

• Largest Contentful Paint (LCP) — unter 2,5 Sekunden. Wie lange dauert es, bis das größte sichtbare Element (meist das Hero-Bild oder die Hero-Überschrift) geladen ist? Über 2,5 Sekunden fühlt sich die Site träge an.
• Interaction to Next Paint (INP) — unter 200 Millisekunden. Wie schnell reagiert die Site auf den ersten Klick, Tipp oder Tastendruck? Über 200 ms wirkt sie hakelig.
• Cumulative Layout Shift (CLS) — unter 0,1. Wie sehr verspringen Elemente während des Ladens? Über 0,1 ärgert sich der Besucher, weil er auf etwas klickt, das in dem Moment weghüpft.

Diese drei Zahlen sind kostenlos prüfbar (PageSpeed Insights, Lighthouse). Wer im roten Bereich ist, hat ein dringendes Problem — kein Detail.

Die häufigsten Performance-Bremsen — und ihre Lösung

In 90 % der Mittelstands-Sites, die wir auditieren, kommen die Probleme aus vier Quellen.

1. Bilder im Original-Format

Eine Smartphone-Foto-Datei mit fünf bis acht Megabyte direkt auf der Site ist Standard — und Standard ist hier das Problem. Was zu tun ist: automatische Bilder-Pipeline. Jedes hochgeladene Bild wird in mehreren Auflösungen erzeugt, in modernem Format (AVIF, WebP) ausgespielt, mit Fallback für ältere Browser. Lazy-Loading sorgt dafür, dass nur sichtbare Bilder geladen werden.

Das ist kein Hexenwerk und sollte in jeder modernen Plattform eingebaut sein. Bei Page-Buildern und Baukasten-Systemen ist das oft nicht der Fall — und das zeigt sich in den Performance-Zahlen.

2. Fremde Skripte ohne Disziplin

Tracking-Tools, Chat-Widgets, Web-Schriften aus externen Quellen, Cookie-Banner-Bibliotheken, Karten-Einbindungen — jedes einzelne lädt zusätzliche Sekunden Skript-Code, oft asynchron, aber trotzdem mit Blockier-Effekt auf den Haupt-Inhalt.

Was zu tun ist: Inventur. Jedes externe Skript wird begründet — wer hat es bestellt, was leistet es, wie viel kostet es Performance. Was nicht begründet werden kann, fliegt raus. Tracking-Tools werden, wenn möglich, server-seitig integriert statt client-seitig.

3. Schriften aus externen Diensten

Web-Schriften aus großen externen Diensten kosten oft 200 bis 500 ms Ladezeit plus erzeugen Layout-Sprünge (CLS), wenn die Schrift erst nach dem ersten Render verfügbar ist. Lösung: Schriften lokal hosten, mit `font-display: swap` und Pre-Loading der wichtigsten Schnitte.

4. Schwere Page-Builder ohne Bremse

Klassische Baukasten-Page-Builder erzeugen oft Sites mit 200 bis 500 Kilobyte JavaScript, das beim Laden ausgeführt werden muss. Auf einem mittleren Smartphone bedeutet das eine bis drei Sekunden zusätzliche Ladezeit. Lösung: entweder einen schlanken Themen-Stack ohne Page-Builder, oder ein Aufbau-System, das pro Seite nur die wirklich benötigten Komponenten lädt.

Performance wird im Architektur-Schritt entschieden

Die wichtigste Erkenntnis: Performance ist kein Nachgang. Wenn eine Site auf einer langsamen Architektur-Basis aufgebaut ist, lässt sich das hinterher nicht mehr durch „Optimierung“ einholen — höchstens lindern. Wer Performance ernst nimmt, entscheidet vor dem ersten Pixel:

• Welche Plattform-Basis (statisch vs. server-gerendert vs. SPA),
• Welcher Hosting-Standort (DACH-Server für DACH-Publikum),
• Welche Bilder-Pipeline (eingebaut, nicht Plugin),
• Welche Schriften (lokal, nicht extern),
• Welches Tracking-Konzept (server-seitig statt fünf Client-Skripte).

Diese Entscheidungen wirken sich über Jahre aus — und sie sind im Nachhinein teurer zu korrigieren als im Erstaufbau richtig zu machen.

Performance-Disziplin nach dem Live-Gang

Auch eine schnelle Site wird mit der Zeit langsamer, wenn Disziplin fehlt. Jeder neue Inhalt, jede neue Funktion, jedes neue Tracking-Skript kann die Zahlen verschlechtern. Was hilft:

• Performance-Monitoring mindestens monatlich (PageSpeed Insights, Lighthouse, Real-User-Monitoring).
• Performance-Budget als feste Grenze (z.B. „Hauptseite unter 800 Kilobyte gesamt“). Wer das überschreitet, muss begründen.
• Bilder-Check vor Upload — automatisch oder als Routine. Ein 8-MB-Bild rutscht sonst durch.

Was Hannes daraus macht

Performance ist bei uns von Anfang an eingebaut, nicht hinten dran. Unsere Plattform-Basis ist statisch generiert (Astro), was bedeutet: Eine ausgespielte Seite ist HTML mit wenig JavaScript — der schnellste Stand, den eine Site haben kann. Die Bilder-Pipeline läuft automatisch, Schriften sind lokal, Tracking-Tools werden auf das Notwendige begrenzt und server-seitig integriert, wo möglich. Jede Seite, die wir live schalten, hat Core Web Vitals im grünen Bereich — das ist Bedingung, nicht Ziel.

Wenn du wissen willst, wo deine aktuelle Site bei den Core Web Vitals steht, ist das kostenlos in zwei Minuten geprüft. Wenn die Zahlen rot sind, lohnt ein Gespräch über die Architektur — denn dort sitzt das Problem, nicht im Detail.