Website beschleunigen: Was 2026 wirklich zählt
Eine schnelle Website ist kein technisches Detail, sondern eine geschäftliche Grundvoraussetzung. Google misst die Ladegeschwindigkeit seit 2021 als offiziellen Rankingfaktor, Besucher entscheiden in den ersten zwei Sekunden, ob sie bleiben oder zurückspringen, und mobile Nutzung dominiert in den meisten Branchen. Wer 2026 noch über Performance redet wie 2014, verliert in beiden Disziplinen: Sichtbarkeit und Conversion.
Dieser Beitrag erklärt, was heute tatsächlich den Unterschied macht. Er richtet sich an Selbstständige, kleine Unternehmen und Marketingverantwortliche, die ihre Website ernst nehmen, aber nicht selbst Frontend-Entwickler werden wollen.
Was Google heute misst: Core Web Vitals
Seit Google die Core Web Vitals als Rankingfaktor verankert hat, gibt es drei Messgrößen, die zählen:
- LCP (Largest Contentful Paint): Wann ist das größte sichtbare Element geladen? Zielwert: unter 2,5 Sekunden.
- INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Klicks, Tippen oder Tastatureingaben? Zielwert: unter 200 Millisekunden. INP hat im März 2024 das ältere FID abgelöst.
- CLS (Cumulative Layout Shift): Wie stark verschiebt sich das Layout nach dem Laden? Zielwert: unter 0,1.
Diese drei Werte beschreiben, wie sich eine Website tatsächlich anfühlt: Wie schnell sie da ist, wie reaktionsfreudig sie reagiert, wie ruhig sie sich aufbaut. Wer diese drei Werte im grünen Bereich hat, hat 90 Prozent der Performance-Arbeit erledigt.
Messen können Sie sie kostenlos:
- PageSpeed Insights von Google liefert eine schnelle Einschätzung mit konkreten Empfehlungen
- Search Console zeigt unter „Nutzerfreundlichkeit" reale Felddaten deiner Besucher
- Chrome DevTools (Lighthouse-Tab) für die Detailanalyse während der Entwicklung
Der wichtigere Wert sind dabei die Felddaten, nicht die Labordaten. Eine Seite kann im Lighthouse-Test 95 Punkte haben und im echten Leben trotzdem zäh sein, wenn die Zielgruppe mit schlechtem Mobilfunk unterwegs ist.
Wo Performance heute tatsächlich verloren geht
Die Engpässe haben sich seit den frühen 2010er-Jahren verschoben. Damals waren CSS- und JavaScript-Bundling, GZip und Sprite-Sheets entscheidend. Heute sind die Hebel andere:
Bilder und Medien
Bilder sind in den meisten Projekten weiterhin der größte Brocken, oft 60 bis 80 Prozent des Seitengewichts. Drei Maßnahmen sind 2026 Standard:
- AVIF und WebP statt JPEG. AVIF liefert bei gleicher Qualität rund 30 Prozent kleinere Dateien als WebP, WebP wiederum etwa 25 bis 35 Prozent kleiner als JPEG. Mit dem
<picture>-Element fallen ältere Browser sauber auf das nächste Format zurück. - Responsive Images mit
srcsetundsizes. Ein Smartphone soll keine 2.000-Pixel-Datei laden müssen, wenn 800 reichen. - Lazy Loading nativ über das
loading="lazy"-Attribut. Bilder unterhalb des Viewports werden erst geladen, wenn sie gebraucht werden.
Ein typisches Markup für ein verantwortlich ausgeliefertes Foto sieht heute so aus:
<picture>
<source srcset="bild-800.avif 800w, bild-1600.avif 1600w" type="image/avif">
<source srcset="bild-800.webp 800w, bild-1600.webp 1600w" type="image/webp">
<img src="bild-800.jpg" srcset="bild-800.jpg 800w, bild-1600.jpg 1600w"
sizes="(max-width: 768px) 100vw, 50vw"
loading="lazy" alt="Beschreibung des Bildes">
</picture>
Kirby CMS bringt diese Funktionalität über die Thumb-API von Haus aus mit, sodass die Varianten automatisch beim ersten Aufruf generiert werden.
Schriften
Webfonts sind ein unterschätzter Performance-Killer. Drei Regeln:
- Schriften lokal hosten statt von Google Fonts oder Adobe einbinden. Das spart eine externe DNS-Anfrage, vermeidet datenschutzrechtliche Probleme und gibt dir die Kontrolle über das Caching.
- Nur die tatsächlich genutzten Schnitte und Subsets laden. Eine Website, die Latin-Texte zeigt, braucht kein Cyrillic-Subset.
font-display: swapsetzen, damit Text sofort lesbar ist, auch wenn die Webfont-Datei noch lädt.
JavaScript
JavaScript blockiert das Rendering, wenn es synchron geladen wird, und kostet Akku und CPU auf älteren Smartphones. Drei Hebel:
- Externe Skripte (Tracker, Chat-Widgets, Karten) nur laden, wenn sie wirklich gebraucht werden. Ein Cookie-Banner, der erst nach Zustimmung tatsächlich Tracking lädt, ist nicht nur datenschutzkonform, sondern schneller.
- Eigenes JavaScript mit
defereinbinden, damit es das initiale Rendering nicht blockiert. - Das HTTP/2-Multiplexing macht Bundling weniger wichtig als früher. Mehrere kleine Dateien sind oft schneller als eine große, weil sie parallel geladen und einzeln gecacht werden können.
Hosting und Auslieferung
Auch das beste Frontend nützt wenig, wenn der Server zu langsam antwortet. Hier liegen oft die größten ungehobenen Reserven:
- Brotli-Kompression statt nur GZip. Brotli liefert bei Textinhalten rund 15 bis 20 Prozent kleinere Übertragungsgrößen.
- HTTP/2 oder besser HTTP/3 als Protokoll. Inzwischen Standard bei seriösen Hostern, sollte aber geprüft werden.
- Aussagekräftige Cache-Header für statische Assets. Schriften, Bilder, CSS und JavaScript können getrost ein Jahr im Browser-Cache liegen, wenn die Dateinamen versioniert sind.
- Ein guter Standort des Servers. Für deutsche Zielgruppen ein deutscher Hoster, das spart Latenz im Vergleich zu US-amerikanischen Standardanbietern.
Was 2026 nicht mehr empfohlen wird
Manche Empfehlungen aus der Anfangszeit der Performance-Optimierung halten sich hartnäckig, sind aber überholt:
- Iconfonts. SVG-Icons sind heute der bessere Standard, weil sie skalieren, frei einfärbbar sind und keine Web-Schrift-Anfrage produzieren.
- CSS-Sprites. Unter HTTP/2 entfällt ihr Hauptvorteil, gleichzeitig erschweren sie die Pflege.
- Aggressives Bundling aller CSS- und JS-Dateien zu einer Riesendatei. Häufig kontraproduktiv, weil eine kleine Änderung den gesamten Cache invalidiert.
- AMP. Google hat AMP als Sonderbehandlung in den Suchergebnissen abgeschafft, der Sonderaufwand lohnt sich nicht mehr.
Performance ist eine Architekturfrage, keine Optimierungsfrage
Die wichtigste Erkenntnis aus 14 Jahren Webdesign-Praxis: Performance lässt sich nicht zuverlässig nachträglich reparieren. Wer eine Website mit einem schweren Theme, drei Animationsbibliotheken und vier externen Skripten baut und am Ende „noch optimiert", wird selten unter 60 Lighthouse-Punkten landen. Wer von Anfang an mit Performance-Bewusstsein baut, schafft ohne große Mühe 90 oder mehr.
Konkret heißt das:
- Klare Entscheidung für ein schlankes CMS oder Framework. Kirby CMS etwa verzichtet auf Datenbank-Overhead und liefert HTML in Millisekunden aus. WordPress mit zwanzig Plugins kommt nie dorthin, egal wie viel Caching darübergelegt wird.
- Verzicht auf Page-Builder und Theme-Frameworks, die hunderte Kilobyte CSS und JavaScript für Funktionen mitbringen, die Sie nicht nutzen.
- Bewusstes Design, das mit wenigen Schriftschnitten, klaren Farbsystemen und ruhigen Layouts auskommt.
Performance ist damit weniger ein technisches als ein gestalterisches und konzeptionelles Thema. Eine schnelle Website ist meistens auch eine klare Website.
Was sich konkret bewegt, wenn man es ernst meint
Eine bestehende Website von 6 Sekunden Ladezeit auf 1,5 Sekunden zu bringen, ist in den allermeisten Fällen möglich. Die typischen Effekte einer ernsthaften Optimierung:
- Niedrigere Absprungraten, oft im zweistelligen Prozentbereich
- Bessere Rankings für die wichtigen Suchbegriffe, weil Google Performance als Faktor wertet
- Höhere Conversion-Raten in Kontaktformularen und Shop-Abschlüssen
- Weniger Rechenzentrumsstrom, weniger Datenvolumen für Besucher, kleinerer ökologischer Fußabdruck
Der letzte Punkt wird oft übersehen. Eine schlanke Website ist nachhaltig in jeder Bedeutung des Wortes: technisch, ökologisch, redaktionell.
Selber prüfen oder prüfen lassen
Den ersten Eindruck können Sie sich in fünf Minuten selbst verschaffen:
- PageSpeed Insights aufrufen, URL eingeben, sowohl Mobile als auch Desktop laufen lassen
- Auf die Felddaten oben achten (sofern vorhanden), nicht nur auf die Labor-Score
- Die drei Core Web Vitals notieren
- Bei den „Möglichkeiten" und „Diagnose" einen Blick auf die größten Brocken werfen
Sind alle drei Werte grün, haben Sie eine gesunde Basis. Sind ein oder mehrere im roten Bereich, lohnt sich eine ernsthafte Analyse.
Falls Sie Kirby als CMS nutzen oder einen Relaunch planen, in dem Performance von Beginn an mitgedacht wird: Ich begleite Projekte aus Detmold und Ostwestfalen-Lippe seit 2010 und arbeite seit 2012 ausschließlich mit Kirby. Ein unverbindliches Erstgespräch klärt in 30 Minuten, was sich bei deiner Website bewegen lässt.
Sie wünschen eine grobe erste Kostenindikation für Ihr Webdesign-Projekt? Gerne.
Bitte kontaktieren Sie uns oder lesen Sie unsere Hinweise für Projektanfragen.