Praxis-Guide 2026

Website Performance Optimierung

Dieser Guide zeigt, wie Sie Ihre Website Performance verbessern: Core Web Vitals, Bildoptimierung und Caching, jeweils mit Code-Beispielen. Dazu kommen Empfehlungen speziell für Hamburg.

15 Min. Lesezeit
Code-Beispiele

Inhaltsverzeichnis

1. Performance als Ranking- und Umsatzfaktor 2. Largest Contentful Paint (LCP) 3. Interaction to Next Paint (INP) 4. Cumulative Layout Shift (CLS) 5. Bilder-Optimierung 6. Caching Strategien 7. CDN & Edge Computing 8. Hamburg Hosting-Empfehlungen

Website Performance als Ranking- und Umsatzfaktor

Website Performance ist seit 2021 ein offizieller Google Ranking-Faktor. Mit der Einführung der Core Web Vitals hat Google klare Metriken definiert, die die User Experience messbar machen. Eine langsame Website kostet Sie Rankings und Besucher, und mit den Besuchern auch Umsatz.

53 %
der mobilen Seitenbesuche werden abgebrochen, wenn eine Seite länger als 3 Sekunden lädt
Google/DoubleClick, 2016
bis zu -7 %
Conversion Rate nach 100 ms zusätzlicher Ladezeit
Akamai, State of Online Retail Performance, 2017
2,5 s
ist der LCP-Grenzwert für „gut“, gemessen am 75. Perzentil der Besuche
Google, web.dev

In Hamburg ist der Online-Wettbewerb stark. Hier kann die Ladezeit entscheiden, ob ein Besucher bei Ihnen bleibt oder zur Konkurrenz wechselt. Sie zählt für Ihr Google-Ranking und wirkt sich direkt auf den Umsatz aus.

Largest Contentful Paint (LCP)

LCP misst, wie lange es dauert, bis das größte sichtbare Content-Element im Viewport geladen ist. Dies ist oft ein Hero-Image, eine große Überschrift oder ein Video. Google empfiehlt einen LCP von höchstens 2,5 Sekunden.

Benchmarks

Gut
≤ 2,5 s
Verbesserungsbedarf
2,5-4 s
Schlecht
> 4 s

Optimierungs­maßnahmen

1. Server Response Time optimieren

TTFB (Time to First Byte) sollte nach Googles Richtwert bei höchstens 0,8 Sekunden liegen. In Hamburg empfehlen wir Hetzner oder IONOS für schnelle Server-Response-Zeiten.

Nginx Konfiguration 
# Nginx Performance Tuning
worker_processes auto;
worker_connections 4096;

# Gzip Compression
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml text/javascript
           application/json application/javascript application/xml+rss;

# Caching
proxy_cache_path /var/cache/nginx levels=1:2
                 keys_zone=my_cache:10m max_size=1g
                 inactive=60m use_temp_path=off;

2. Ressourcen priorisieren mit preload

Laden Sie kritische Ressourcen wie Hero-Images oder wichtige Fonts vorab.

HTML Head 
<!-- Preload kritischer Ressourcen -->
<link rel="preload" as="image" href="/hero-image.webp"
      type="image/webp" fetchpriority="high">
<link rel="preload" as="font" href="/fonts/main.woff2"
      type="font/woff2" crossorigin>

<!-- Preconnect zu externen Domains -->
<link rel="preconnect" href="https://cdn.example.com">
<link rel="dns-prefetch" href="https://analytics.example.com">

3. Bilder optimal ausliefern

Verwenden Sie moderne Bildformate (WebP, AVIF) und responsive Images mit srcset.

HTML 
<picture>
  <!-- AVIF für moderne Browser -->
  <source type="image/avif"
          srcset="hero-400.avif 400w,
                  hero-800.avif 800w,
                  hero-1200.avif 1200w"
          sizes="(max-width: 600px) 400px,
                 (max-width: 1200px) 800px,
                 1200px">

  <!-- WebP Fallback -->
  <source type="image/webp"
          srcset="hero-400.webp 400w,
                  hero-800.webp 800w,
                  hero-1200.webp 1200w"
          sizes="(max-width: 600px) 400px,
                 (max-width: 1200px) 800px,
                 1200px">

  <!-- JPEG Fallback -->
  <img src="hero-800.jpg"
       alt="Hero Image"
       loading="eager"
       fetchpriority="high"
       width="1200"
       height="600">
</picture>

Interaction to Next Paint (INP)

Stand Oktober 2026: Seit dem 12. März 2024 ist INP (Interaction to Next Paint) der Core Web Vital für Reaktionsfähigkeit und hat FID abgelöst. INP wertet alle Interaktionen eines Besuchs aus, FID nur die erste. Lighthouse löst keine Interaktionen aus und liefert deshalb keinen INP. Im Labor dient Total Blocking Time als Näherung, verlässliche INP-Werte kommen aus Felddaten wie PageSpeed Insights und der Search Console.

INP misst während des ganzen Besuchs, wie lange die Seite braucht, um sichtbar auf Klicks, Tippen und Tastatureingaben zu reagieren, und meldet eine der langsamsten Interaktionen. Ein guter INP liegt bei höchstens 200 ms, über 500 ms gilt als schlecht.

Optimierungs­maßnahmen

1. JavaScript Execution reduzieren

Umfangreiches JavaScript blockiert den Main Thread. Teilen Sie den Code per Code Splitting auf und laden Sie Komponenten per Lazy Loading erst bei Bedarf.

Webpack/Vite Config 
// Dynamic Imports für Code Splitting
const HeavyComponent = lazy(() => import('./HeavyComponent'));

// React.lazy mit Suspense
<Suspense fallback={<Loading />}>
  <HeavyComponent />
</Suspense>

// Webpack Magic Comments für Chunk Names
import(/* webpackChunkName: "analytics" */ './analytics');

2. Long Tasks vermeiden

Tasks über 50ms blockieren User-Interaktionen. Nutzen Sie Web Workers für rechenintensive Aufgaben.

Web Worker Beispiel 
// Main Thread
const worker = new Worker('heavy-calculation.js');

worker.postMessage({ data: largeDataset });

worker.onmessage = (e) => {
  
  updateUI(e.data);
};

// heavy-calculation.js (Worker)
self.onmessage = (e) => {
  const result = performHeavyCalculation(e.data);
  self.postMessage(result);
};

3. Third-Party Scripts optimieren

Analytics, Chatbots und andere Third-Party Scripts asynchron oder mit defer laden.

HTML 
<!-- Asynchron laden -->
<script async src="https://widgets.example.com/embed.js"></script>

<script defer src="/analytics.js"></script>

<script defer src="/libs/jquery.min.js"></script>

Cumulative Layout Shift (CLS)

CLS misst die visuelle Stabilität einer Seite. Wenn Elemente während des Ladens "springen", führt das zu schlechter User Experience. Ein guter CLS liegt bei höchstens 0,1.

Häufigste CLS-Verursacher

Bilder ohne Dimensionen

Browser kennt die Größe nicht und reserviert keinen Platz

Dynamisch eingefügte Ads oder Banners

Inhalte erscheinen nach dem initialen Rendering

Web Fonts ohne font-display

FOIT (Flash of Invisible Text) verschiebt Layout

Lösungen

1. Immer width und height angeben


<img src="logo.png" alt="Logo" width="200" height="50">

<img src="hero.jpg" alt="Hero" style="aspect-ratio: 16/9; width: 100%;">

.hero-image {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

2. Platzhalter für dynamische Inhalte reservieren


.ad-placeholder {
  width: 100%;
  height: 250px;
  background: linear-gradient(90deg, #1c2333 25%, #2c3446 50%, #1c2333 75%);
  background-size: 200% 100%;
  animation: loading 1.5s infinite;
}

@keyframes loading {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}

3. Font Loading optimieren

/* font-display für besseres Fallback */
@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap; /* Zeigt Fallback sofort */
  font-weight: 400;
  font-style: normal;
}

/* Preload kritischer Fonts */
<link rel="preload" as="font"
      href="/fonts/custom.woff2"
      type="font/woff2"
      crossorigin>

Bilder-Optimierung

Bilder machen oft einen großen Teil der gesamten Seitengröße aus. Hier liegt deshalb meist einer der größten Hebel für bessere Performance.

Format-Vergleich

Format Browser Support Dateigröße Empfehlung
AVIF Alle aktuellen großen Browser Kleinste Erste Wahl für moderne Browser
WebP Alle aktuellen großen Browser Meist kleiner als JPEG Bester Fallback
JPEG 100% Baseline Legacy Support
PNG 100% Größte Nur für Transparenz

Optimierungs-Tools

Sharp (Node.js)

const sharp = require('sharp');

// Bild in mehrere Formate konvertieren
await sharp('input.jpg')
  .resize(1200, 800, { fit: 'cover' })
  .webp({ quality: 80 })
  .toFile('output-1200.webp');

await sharp('input.jpg')
  .resize(1200, 800, { fit: 'cover' })
  .avif({ quality: 70 })
  .toFile('output-1200.avif');

Squoosh (Web-App)

Für einzelne Bilder zeigt Ihnen die Web-App squoosh.app Original und komprimierte Version direkt nebeneinander. Die Squoosh CLI gibt es im Repository nicht mehr; für viele Bilder auf einmal nehmen Sie Sharp.

Caching Strategien

Mit Caching senken Sie die Server-Last, und bei wiederkehrenden Besuchern laden Ihre Seiten deutlich schneller.

Browser Caching (.htaccess)

<IfModule mod_expires.c>
  ExpiresActive On

  # Bilder - 1 Jahr
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/avif "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"

  # CSS und JS - 1 Monat
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"

  # Fonts - 1 Jahr
  ExpiresByType font/woff2 "access plus 1 year"
  ExpiresByType font/woff "access plus 1 year"

  # HTML - 1 Stunde
  ExpiresByType text/html "access plus 1 hour"
</IfModule>

Service Worker Caching

// service-worker.js
const CACHE_NAME = 'v1';
const urlsToCache = [
  '/',
  '/styles/main.css',
  '/scripts/main.js',
  '/images/logo.png'
];

// Install Event - Cache Ressourcen
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then((cache) => cache.addAll(urlsToCache))
  );
});

// Fetch Event - Cache-First Strategy
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((response) => {
        // Cache hit - return cached response
        if (response) return response;

        // Fetch from network
        return fetch(event.request);
      })
  );
});

CDN & Edge Computing

Ein Content Delivery Network (CDN) verteilt Ihre Inhalte auf Server weltweit und liefert sie vom geografisch nächsten Standort aus. Für Hamburg empfehlen wir CDNs mit starker Präsenz in Europa.

Cloudflare

  • Kostenloser Plan verfügbar
  • DDoS Protection inklusive
  • Workers für serverseitiges Rendering am Edge

BunnyCDN

  • Abrechnung nach Datenvolumen
  • Schnelle Auslieferung in Europa
  • Bildoptimierung als kostenpflichtiges Add-on (Bunny Optimizer)

Hamburg Hosting-Empfehlungen

Für schnelle Ladezeiten in Hamburg empfehlen wir Hosting-Anbieter mit Servern in Deutschland oder direkt in Hamburg.

Hetzner

Server in Nürnberg & Falkenstein

Cloud Server
  • • Viel Performance für den Preis
  • • Daten bleiben in Deutschland, wenn Sie einen deutschen Standort wählen
  • • Kurze Wege zu Besuchern aus Hamburg
Empfohlen für: KMU, Startups, High-Traffic Websites

IONOS

Datacenter in Berlin & Karlsruhe

VPS
  • • Deutscher Support und Datenschutz
  • • Managed WordPress Hosting
  • • Inklusive SSL-Zertifikate
Empfohlen für: Business-Websites, WordPress-Projekte

Cloudflare Workers

Globales Edge-Netzwerk

Kostenlose und bezahlte Pläne
  • • Passt gut zu Astro und Next.js
  • • Automatische Deployments via Git
  • • Statische Dateien kommen direkt aus dem CDN
  • • Der kostenlose Plan reicht für kleine Projekte
Empfohlen für: Moderne Web-Apps, Static Sites, Headless CMS

Guide drucken oder speichern

Drucken Sie diesen Guide als PDF aus oder teilen Sie ihn mit Ihrem Team.

Erstgespräch anfragen

Performance-Optimierung für Ihre Website

Wir messen Ihre Website mit Lighthouse und PageSpeed Insights, beheben, was sie ausbremst, und arbeiten auf grüne Core Web Vitals hin. Das Erstgespräch ist kostenlos, danach erhalten Sie ein individuelles Festpreisangebot.

Kostenloses Erstgespräch Weitere Performance Guides