Ladezeit unter 1 Sekunde
Schritt-für-Schritt-Anleitung zur Optimierung der Core Web Vitals (LCP, INP, CLS). In 8 Schritten von langsamer Webseite zu sub-1-Sekunden-Ladezeit. Mit konkreten Tools, Code-Snippets und Schweizer Hosting-Tipps.
Bevor Sie anfangen
- Zugang zum Quellcode (Git, FTP oder CMS-Theme-Editor)
- Zugang zum Hosting bzw. Server für CDN- und Server-Tuning
- Browser mit DevTools (Chrome oder Edge empfohlen)
- Optional: Account bei Cloudflare oder Bunny.net für CDN
- Optional: Node.js installiert für Tooling (Lighthouse-CLI, sharp, critical)
- Vollbackup der Seite (Optimierungen sollten reversibel sein)
Baseline mit PageSpeed Insights und WebPageTest messen
Vor jeder Optimierung Ist-Zustand dokumentieren. Auf pagespeed.web.dev die Domain eingeben, Mobile- und Desktop-Score notieren.
Wichtiger als der Score sind die Core Web Vitals: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift). Diese sind das Google-Ranking-Signal.
Auf webpagetest.org einen tieferen Test laufen lassen (Server in Zürich oder Frankfurt wählen). Waterfall-Diagramm zeigt jeden Request mit Timing.
Mindestens 3 verschiedene Seitentypen testen: Home, Listing-Seite, Detail-Seite. Optimierung pro Template kann sehr unterschiedlich aussehen.
# Lighthouse via Chrome DevTools oder CLI npx lighthouse https://ihrefirma.ch \ --preset=desktop \ --output=html \ --output-path=./report.html # Mobile-Test npx lighthouse https://ihrefirma.ch \ --form-factor=mobile \ --throttling.cpuSlowdownMultiplier=4
Bilder zu WebP/AVIF konvertieren und Lazy-Loading aktivieren
Bilder sind meist 50-70 % der Gesamtgrösse einer Webseite. Konvertierung zu WebP spart 25-35 %, AVIF nochmal 20 %.
Tool für einzelne Bilder: squoosh.app (Browser-basiert, kostenlos). Für Batch-Konvertierung: sharp oder cwebp im Build-Script.
In jedem <img>-Tag loading='lazy' für alles unterhalb des sichtbaren Bereichs setzen. Wichtig: explizit width und height setzen, sonst gibt es Layout-Shift (CLS).
Bei modernen Frameworks: Next.js Image, Astro Picture, Nuxt NuxtImg. Diese machen WebP/AVIF und Responsive-Srcset automatisch.
# Batch-Konvertierung mit cwebp (Linux/macOS)
for img in *.jpg; do
cwebp -q 80 "$img" -o "${img%.jpg}.webp"
done
# HTML mit Picture-Element für Browser-Fallback
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" width="1200" height="600" alt="..." loading="lazy">
</picture>Fonts lokal hosten und font-display: swap setzen
Google Fonts via CDN ist langsam und ein DSG-Problem (US-IP-Abfrage). Schriften herunterladen via google-webfonts-helper (gwfh.mranftl.com) und lokal ablegen.
Nur WOFF2 ausliefern (alle modernen Browser unterstützen es). WOFF und TTF sind heute überflüssig und kosten Bandbreite.
font-display: swap im @font-face setzen. Damit zeigt der Browser sofort eine Fallback-Schrift und tauscht sie aus, wenn die Webfont geladen ist. Kein Flash of Invisible Text mehr.
Nur das geladene Subset definieren (z.B. latin, latin-ext). Eine ganze chinesische Schriftfamilie zu laden, obwohl nur Deutsch verwendet wird, ist Bandbreitenverschwendung.
/* In Ihrem CSS */
@font-face {
font-family: 'Inter';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('/fonts/inter-v12-latin-regular.woff2') format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC;
}
/* Im HTML als Preload für die wichtigste Schrift */
<link rel="preload" href="/fonts/inter-v12-latin-regular.woff2"
as="font" type="font/woff2" crossorigin>Critical CSS extrahieren, Rest deferred laden
Render-Blocking CSS ist meist der grösste LCP-Bremser. Lösung: das CSS für den Above-the-Fold-Bereich inline ins HTML, der Rest deferred.
Tools: critical (npm-Paket), penthouse, Beasties. Sie analysieren das gerenderte HTML und extrahieren nur das nötige CSS.
Restliches CSS via <link rel='preload' as='style' onload='this.rel="stylesheet"'> laden oder via media='print' onload-Trick (lädt aber blockiert beim Rendern nicht).
Bei Frameworks meist automatisch: Next.js inlinet Critical CSS standardmässig, Astro mit experimental.inlineStylesheets.
# Critical CSS mit npm-Paket "critical" extrahieren
npx critical https://ihrefirma.ch \
--inline \
--base ./dist \
--width 1300 --height 900 \
> index.html
# Non-Critical CSS via media-Trick laden
<link rel="stylesheet" href="/main.css" media="print"
onload="this.media='all'">
<noscript><link rel="stylesheet" href="/main.css"></noscript>JS-Bundle reduzieren und Code-Splitting nutzen
JavaScript ist der zweite grosse LCP-Killer. Webpack-Bundle-Analyzer oder Bundlephobia verwenden, um die fettesten Pakete zu identifizieren.
Häufige Sünden: Komplette moment.js statt date-fns, ganzes lodash statt lodash/get, Charting-Lib auf jeder Seite obwohl nur auf einer Detail-Seite verwendet.
Code-Splitting: in Next.js geschieht das automatisch pro Route. Für Komponenten unter dem Fold: dynamic(() => import(...), { ssr: false }) oder React.lazy.
Third-Party-Scripts (Google Analytics, Hotjar, Chatbots) nicht im <head>, sondern async oder defer am Ende. Idealerweise mit partytown in einen Web Worker auslagern.
# Bundle analysieren
npx webpack-bundle-analyzer dist/stats.json
# Next.js Dynamic Import für Komponente unterhalb des Folds
import dynamic from 'next/dynamic';
const HeavyChart = dynamic(() => import('./HeavyChart'), {
loading: () => <p>Lädt...</p>,
ssr: false,
});CDN aktivieren (Cloudflare oder Bunny)
Static Assets über ein CDN auszuliefern macht sie weltweit schnell. Edge-Server in der Nähe des Besuchers heisst Time-to-First-Byte unter 50ms.
Schweizer Realitäten: Cloudflare (Free-Tier reicht meist) ist Standard. Bunny.net ist günstig und schnell. Beide haben PoPs in Zürich oder Genf.
DNS auf Cloudflare umstellen (Wolke orange) oder vor Bunny ein cdn.ihrefirma.ch CNAME setzen. Static Assets (Bilder, CSS, JS, Fonts) automatisch durch das CDN.
Cache-Control-Header korrekt setzen: public, max-age=31536000, immutable für Assets mit Hash im Namen. HTML-Seiten kürzer cachen (z.B. 5 Minuten) oder gar nicht, je nach CMS.
# Beispiel: Cache-Header in nginx für static assets
location ~* \.(woff2|webp|avif|css|js|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# Cloudflare Page Rules:
# *.ihrefirma.ch/static/* → Cache Everything, Edge TTL 1 monthServer-Response-Time prüfen und verbessern
Wenn der Server selbst 800ms zum Generieren braucht, ist LCP unter 1s unmöglich. Ziel: TTFB unter 200ms.
WordPress: WP Rocket, LiteSpeed Cache oder W3 Total Cache für Full-Page-Caching. OpCache aktivieren, MySQL-Slow-Query-Log prüfen.
Next.js: Static Generation (getStaticProps) wo möglich, ISR (revalidate: 60) für semi-dynamische Seiten, Server Components als Default in App Router.
Datenbank-Indizes prüfen. Eine fehlende Index auf einer oft abgefragten Spalte kann den TTFB um Sekunden erhöhen.
# TTFB messen mit curl
curl -o /dev/null -s -w "
DNS Lookup: %{time_namelookup}s
TCP Connection: %{time_connect}s
SSL Handshake: %{time_appconnect}s
TTFB: %{time_starttransfer}s
Total: %{time_total}s
" https://ihrefirma.chErneut messen und iterieren
Nach allen Massnahmen PageSpeed Insights und WebPageTest erneut durchlaufen. Erwartung: LCP unter 1s auf Desktop, unter 2s auf Mobile-Throttled.
Wenn LCP noch zu hoch: in PageSpeed Insights schauen welches Element der LCP ist. Meist Hero-Bild oder grosse Headline-Font. Gezielt diesen Request optimieren (Preload, kleineres Bild, andere Font-Strategie).
Wenn INP noch zu hoch: Performance-Tab in Chrome DevTools öffnen, Interaktion aufnehmen, Long Tasks (rote Balken) identifizieren. Meist verursacht durch Third-Party-Scripts oder grosse React-Rerenders.
Im Live-Betrieb: Web Vitals-Library installieren und reale Nutzer-Metriken in Google Analytics 4 oder ein eigenes Dashboard schicken. Lab- vs. Field-Daten können stark abweichen.
Häufige Fehler vermeiden
Nur Desktop-PageSpeed optimieren
Google verwendet seit 2020 Mobile-First-Indexing. Score 100 auf Desktop und 40 auf Mobile bringt SEO-technisch wenig. Immer Mobile-Score priorisieren.
Alle Bilder pauschal lazy laden
Das Hero-Bild oberhalb des Folds nicht lazy laden, sonst wird es zum LCP-Bremser. Stattdessen mit fetchpriority='high' markieren.
JS in <head> ohne async/defer
Render-blocking JavaScript stoppt das Rendern bis das Script geladen UND ausgeführt ist. Immer async oder defer setzen, ausser bei kritischen Inline-Scripts.
CDN ohne Cache-Header
Cloudflare oder Bunny vor die Seite zu setzen, ohne korrekte Cache-Control-Header, bringt wenig. Static Assets müssen mit max-age=31536000, immutable ausgeliefert werden.
Was wenn etwas nicht klappt?
LCP bleibt trotz Optimierung über 2 Sekunden
In PageSpeed Insights schauen welches Element der LCP ist. Meist Hero-Bild oder Hero-Headline. Bild mit fetchpriority='high' und preload markieren, Hero-Font preloaden.
INP-Score schlecht obwohl Lighthouse ok zeigt
INP misst echte Nutzer-Interaktionen, Lighthouse simuliert nur eine Initiale. Long Tasks im Performance-Tab finden, häufig durch Third-Party-Skripte (Hotjar, Chatbot, Analytics) verursacht. Mit Partytown auslagern.
CLS zu hoch trotz width/height auf Bildern
Late-loading Web-Fonts, dynamisch eingeblendete Banner oder Werbung verursachen Layout-Shift. Font-Loading mit font-display: swap + size-adjust optimieren, Banner-Container mit min-height reservieren.
Server-Response-Time bleibt über 800ms
WordPress mit zu vielen Plugins oder fehlendem Cache. WP Rocket oder LiteSpeed Cache aktivieren. Wenn das nicht reicht, Hosting wechseln auf einen schnelleren Schweizer Anbieter mit NVMe-SSDs.
Lieber von uns optimieren lassen?
Wir messen, optimieren Bilder, Fonts, CSS, JS und Server. Mit Vorher-Nachher-Report und 30 Tage Monitoring. Ab CHF 580 für eine Standard-Webseite.
Verwandte Anleitungen und Services
Vertiefen oder direkt machen lassen.
Häufige Fragen
Ist eine Ladezeit unter 1 Sekunde realistisch?
Ja, für statische und gut optimierte CMS-Seiten absolut. WordPress mit vielen Plugins und ungetrimmtem JS wird schwieriger, ist aber mit konsequenter Optimierung machbar. E-Commerce mit grossen Katalogen wird pro Seitentyp optimiert.
Was sind die wichtigsten Core Web Vitals?
LCP (Largest Contentful Paint, unter 2.5s, idealerweise unter 1s), INP (Interaction to Next Paint, unter 200ms) und CLS (Cumulative Layout Shift, unter 0.1). Google nutzt diese für das Ranking-Signal Page Experience.
Reicht ein CDN allein?
Nein. Ein CDN beschleunigt nur statische Assets, behebt aber kein zu grosses JS-Bundle, kein langsames Backend, keine unoptimierten Bilder. Erst das Gesamtpaket aus allen Massnahmen bringt den grossen Schritt.
Wie oft sollte man die Ladezeit prüfen?
Nach jedem grösseren Release einmal komplett. Im Routinebetrieb monatlich, am besten automatisiert via Lighthouse-CI im Build-Pipeline. So fallen Regressionen auf, bevor Nutzer sie spüren.
Was kostet eine professionelle PageSpeed-Optimierung?
Bei AmuraDesign ab CHF 580 für eine Standard-Seite mit Bilder-, Font-, CSS-, JS-Optimierung plus CDN-Setup. Komplexe E-Commerce-Seiten mit mehreren Templates höher, individuelle Offerte.