Above-the-Fold-Optimierung für Mobile: LCP auf Smartphones verbessern

Google verwendet Mobile-First Indexing — das bedeutet: der Crawler bewertet deine Website primär anhand der mobilen Version. Wenn dein LCP (Largest Contentful Paint) auf dem Desktop 1,5 Sekunden beträgt, aber auf dem Smartphone 4,8 Sekunden, schadest du deinem Google-Ranking erheblich.

Der Above-the-Fold-Bereich — alles was ohne Scrollen sichtbar ist — ist für den LCP entscheidend. Denn der LCP misst genau das: wie lange es dauert, bis der größte sichtbare Inhalt im Viewport gerendert ist. Auf einem Smartphone mit 360 px Breite ist dieser Viewport klein, aber trotzdem das erste, was der Nutzer (und Google) sieht.

Was ist überhaupt "Above the Fold" auf Mobile?

Der Begriff stammt aus dem Printjournalismus: der Teil der Titelseite, der im gefalteten Zeitungsstand sichtbar ist. Digital bedeutet er: alles was der Nutzer ohne Scrollen sieht.

Auf Mobilgeräten variiert dieser Bereich erheblich:

Entscheidend: Googlebot verwendet für Mobile-First-Crawling standardmäßig einen Viewport von 412 × 823 px (Pixel 4a-ähnlich). Deine Optimierung sollte also auf diesen Bereich ausgelegt sein.

LCP-Elemente auf Smartphones: Was wird gemessen?

Als LCP-Element wird das größte sichtbare Element im Viewport gewertet. Häufige Kandidaten auf Mobilseiten:

• Hero-Bild (das häufigste LCP-Element auf Websites mit visuellem Header)
• H1-Überschrift (wenn kein großes Bild im Above-the-Fold-Bereich ist)
• Hero-Video-Poster (das Standbild, das vor dem Video-Start angezeigt wird)
• Background-Image via CSS (achtung: das wird oft spät geladen!)

Chrome DevTools zeigt dir welches Element Google als LCP-Element identifiziert: Öffne die DevTools → Performance → Aufnahme starten → Seite laden → im Flame-Graph nach "LCP" suchen. Oder nutze PageSpeed Insights — das markiert das LCP-Element direkt.

Optimierung 1: Hero-Bild für Mobile optimieren

Das Hero-Bild ist auf den meisten Websites der LCP-Kandidat Nr. 1 auf Mobilgeräten. Mehrere häufige Fehler kosten hier Sekunden:

Fehler 1: Nur eine Bild-Größe für alle Geräte

Ein Desktop-Hero-Bild mit 1920 × 800 px hat ~400–600 KB. Auf einem Smartphone wird es auf 390 px skaliert — du überträgst 5× mehr Daten als nötig.

<!-- ❌ Falsch: Ein Bild für alle Geräte -->
<img src="hero-1920.jpg" alt="Hero" class="w-full">

<!-- ✅ Richtig: Responsive Images mit srcset -->
<img
  src="hero-800.webp"
  srcset="
    hero-400.webp  400w,
    hero-800.webp  800w,
    hero-1200.webp 1200w,
    hero-1920.webp 1920w
  "
  sizes="
    (max-width: 480px)  400px,
    (max-width: 900px)  800px,
    (max-width: 1400px) 1200px,
    1920px
  "
  alt="Hero-Bild: Beschreibung mit Keyword"
  width="1920"
  height="800"
  loading="eager"
  fetchpriority="high"
>

Wichtig: fetchpriority="high" weist den Browser an, dieses Bild mit höchster Priorität zu laden — noch bevor andere Ressourcen. Das ist für das LCP-Bild entscheidend.

Fehler 2: Das falsche Format

JPEG und PNG sind veraltet für Hero-Images. WebP ist 25–35 % kleiner bei gleicher Qualität, AVIF nochmal 15–25 % kleiner. Nutze beide mit Fallback:

<picture>
  <source
    type="image/avif"
    srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1200.avif 1200w"
    sizes="(max-width: 480px) 400px, (max-width: 900px) 800px, 1200px"
  >
  <source
    type="image/webp"
    srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
    sizes="(max-width: 480px) 400px, (max-width: 900px) 800px, 1200px"
  >
  <img
    src="hero-800.jpg"
    alt="Hero-Bild: Dein Keyword"
    width="1200"
    height="600"
    loading="eager"
    fetchpriority="high"
  >
</picture>

Fehler 3: Kein explizites width/height

Ohne width und height-Attribute weiß der Browser nicht, wie viel Platz das Bild einnehmen wird. Er muss erst das Bild laden um es zu wissen — das verursacht Layout-Shifts (schlechter CLS) und verzögert das Rendering. Setze immer beide Attribute entsprechend dem Seitenverhältnis des Bildes.

Optimierung 2: Critical CSS für mobile Viewports

Jedes externe CSS-Stylesheet blockiert das Rendering, bis es vollständig geladen ist. Das macht CSS zu einem der häufigsten LCP-Killer. Die Lösung: Critical CSS inline einbinden und nicht-kritisches CSS asynchron nachladen.

Aber Achtung: Critical CSS auf Mobile ≠ Critical CSS auf Desktop. Der mobile Viewport ist kleiner, also ist weniger CSS "critical". Ein Desktop-Desktop-Breakpoint-CSS mit 800 px braucht der Smartphone-Nutzer nicht sofort.

<style>
  /* Nur CSS das für den MOBILEN Above-the-Fold sichtbaren Bereich nötig ist */
  /* Mobile-first: Basisstyles + Hero-Bereich */
  *, *::before, *::after { box-sizing: border-box; }
  body { margin: 0; font-family: system-ui, sans-serif; background: #fff; }
  nav { height: 60px; background: #1a1a2e; display: flex; align-items: center; padding: 0 16px; }
  .hero { padding: 32px 16px; background: linear-gradient(135deg, #1a1a2e 0%, #16213e 100%); }
  .hero img { width: 100%; height: auto; border-radius: 8px; }
  h1 { font-size: 1.75rem; font-weight: 800; color: #fff; margin: 16px 0 8px; line-height: 1.2; }

  /* Tablet/Desktop-Breakpoints kommen in das externe Stylesheet */
  /* @media (min-width: 768px) { ... } → NICHT im Critical CSS! */
</style>

<!-- Externes CSS asynchron laden -->
<link rel="stylesheet" href="/styles.css" media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/styles.css"></noscript>

Optimierung 3: Web-Schriftarten ohne Blockierung

Google Fonts und andere Web-Schriftarten sind häufig unsichtbare LCP-Killer. Das Problem: wenn die Schriftart noch nicht geladen ist, bleibt der Text unsichtbar (font-display: block) oder zeigt zunächst eine System-Schrift (font-display: swap).

Empfohlene Konfiguration für mobilen LCP

<!-- 1. Schriftdatei vorladen (für kritische Schriften) -->
<link rel="preload" href="/fonts/inter-700.woff2" as="font" type="font/woff2" crossorigin>

<!-- 2. font-display: optional für nicht-kritische Schriften -->
<style>
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-400.woff2') format('woff2');
  font-weight: 400;
  font-display: swap;    /* Fallback sofort sichtbar, Swap wenn Schrift geladen */
}

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-700.woff2') format('woff2');
  font-weight: 700;
  font-display: optional; /* Bei langsamen Verbindungen: Fallback dauerhaft */
}
</style>

Noch besser: Für den Above-the-Fold-Text (H1, kurze Intro) nutze font-display: swap, damit der Text sofort sichtbar ist (auch wenn zunächst mit System-Schrift). Für dekorative oder weniger wichtige Schriften nutze font-display: optional — damit wird auf schwachen Verbindungen gar nicht erst versucht, die Schrift zu laden.

Selbst-Hosting vs. Google Fonts

Google Fonts erzeugen zwei DNS-Lookups (fonts.googleapis.com und fonts.gstatic.com) plus Latenz für den Download. Selbst-hosting spart diese Roundtrips. Verwende google-webfonts-helper um Schriften lokal einzubinden.

Optimierung 4: LCP-Ressource vorladen (preload)

Das Hero-Bild wird oft "zu spät" entdeckt: der Browser muss erst HTML parsen, dann CSS laden, dann erkennt er im CSS: "Hier kommt ein Bild." Mit <link rel="preload"> machst du das Bild sofort sichtbar im HTML-Head.

<!-- Im <head>: Hero-Bild vorladen -->
<link
  rel="preload"
  as="image"
  href="/images/hero-800.webp"
  imagesrcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  imagesizes="(max-width: 480px) 400px, (max-width: 900px) 800px, 1200px"
  fetchpriority="high"
>

Das teilt dem Browser mit: "Lade dieses Bild sofort, bevor du das restliche HTML parsed hast." In Kombination mit fetchpriority="high" auf dem <img>-Tag erreicht das eine deutlich frühere Darstellung.

Optimierung 5: Render-Blocking-Ressourcen entfernen

Jede Ressource im <head> die das Rendering blockiert, verzögert den LCP. Die wichtigsten Maßnahmen für Mobile:

• JavaScript: Alle <script>-Tags müssen async oder defer tragen. Kein synchrones JavaScript im <head>! Lies dazu JavaScript async und defer für SEO.
• CSS: Externes CSS inline oder asynchron laden (siehe oben). Nur Critical CSS darf render-blocking sein.
• Third-Party-Scripts: Tag Manager, Chat-Widgets, Analytics — alle mit defer oder noch besser: type="module" und dynamischem Laden.

<!-- Google Analytics: async, kein LCP-Blocker -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXX"></script>

<!-- Analytics-Konfiguration: Warte bis DOMContentLoaded -->
<script>
  window.addEventListener('DOMContentLoaded', function() {
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-XXXXXX');
  });
</script>

Prüfe alle blockierenden Ressourcen mit unserem Render-Blocking-Checker.

Optimierung 6: Server-Response-Zeit (TTFB) auf Mobile

Smartphones sind oft in mobilen Netzwerken (4G/5G) unterwegs — mit höherer Latenz als WLAN. Eine langsame Server-Response (TTFB) trifft Mobile-Nutzer härter als Desktop-Nutzer.

Ziel: TTFB unter 200 ms. Maßnahmen:

• CDN nutzen: Cloudflare, Fastly oder CloudFront stellen Inhalte vom nächsten PoP (Point of Presence) aus — reduziert Latenz für Mobile-Nutzer in verschiedenen Regionen drastisch
• Server-seitiges Caching: Dynamische Seiten (WordPress, PHP) cachen — der Server muss bei jedem Request nicht neu rendern
• HTTP/2 oder HTTP/3: Reduziert Verbindungslatenz durch Multiplexing. Prüfe mit dem HTTP/2 & HTTP/3 Checker
• Komprimierung: Gzip oder Brotli auf dem Server aktivieren — reduziert Transfergröße um 60–80 %

Mobil-spezifische LCP-Prüfmethode

Um sicherzustellen, dass deine Optimierung auf Smartphones wirkt:

1. Chrome DevTools → Device Toolbar (Strg/Cmd + Shift + M): iPhone 12 Pro oder Pixel 5 simulieren
2. Netzwerk-Drosselung aktivieren: "Fast 4G" — das entspricht in etwa dem 75. Perzentil der deutschen Mobilverbindungen
3. Performance-Aufnahme starten und Seite laden
4. Im Flame-Graph nach dem LCP-Marker suchen und das LCP-Element identifizieren
5. Prüfe: Wann beginnt der Download des LCP-Elements? Wann endet er? Was kommt dazwischen?

Alternativ: PageSpeed Insights zeigt dir den mobilen LCP-Wert direkt mit der Empfehlung "Largest Contentful Paint image was not lazily loaded" oder "Largest Contentful Paint image was not preloaded" — falls du diese Fehler siehst, sind die oben beschriebenen Optimierungen genau die richtige Reaktion.

Checkliste: Above-the-Fold auf Mobile optimieren

• ☐ Hero-Bild als WebP/AVIF mit srcset und passenden sizes
• ☐ width und height auf dem <img>-Tag gesetzt
• ☐ loading="eager" und fetchpriority="high" auf dem LCP-Bild
• ☐ <link rel="preload"> für das Hero-Bild im <head>
• ☐ Critical CSS inline (unter 10 KB, mobile-first)
• ☐ Externes CSS asynchron: media="print" onload="this.media='all'"
• ☐ Kein synchrones JavaScript im <head> — alles mit async/defer
• ☐ Web-Schriftarten mit font-display: swap oder optional
• ☐ TTFB unter 200 ms (CDN + Server-Caching)
• ☐ HTTP/2 oder HTTP/3 aktiviert
• ☐ Gzip/Brotli-Komprimierung aktiv

Zusammenfassung

Mobile LCP zu verbessern ist kein einzelner Trick, sondern ein Zusammenspiel mehrerer Optimierungen. Das Hero-Bild ist der häufigste Hebel: richtiges Format, responsive sizes und preload kosten relativ wenig Aufwand bei großer Wirkung. Critical CSS und das Entfernen von render-blocking Ressourcen sind die nächsten Schritte.

Google misst deinen LCP auf Mobilgeräten aus echten Chrome-Nutzerdaten (CrUX). Das bedeutet: selbst wenn dein Labor-LCP (DevTools) gut ist, kann der Feldwert schlechter sein — besonders wenn deine Nutzer ältere Geräte oder langsamere Verbindungen nutzen. Fokussiere dich daher auf echte Felddaten, nicht nur auf synthetische Tests.

Nutze regelmäßig den Core Web Vitals Checker um deine Echtmessung im Blick zu behalten — und die Mobile Core Web Vitals Optimierung als erweiterten Leitfaden wenn du tiefer einsteigen möchtest.