Mobile-First-Webdesign + Performance – die Praxis-Anleitung für Mittelstand

Lokale Suchanfragen werden zu einem großen Teil unterwegs getippt – am Smartphone, nicht am Schreibtisch. Mobile-First-Design ist deshalb kein Trend, sondern die Voraussetzung: Googles Mobile-First-Index bewertet seit 2018 die mobile Version Ihrer Website als die maßgebliche.

Warum Mobile-First nicht optional ist

Die Suche nach einem „Sanitärbetrieb Bensheim“ beginnt häufig unterwegs statt am Schreibtisch – oft in dem Moment, in dem das Problem auftritt.

Auf dem Handy ist die Trefferliste nur einen Zurück-Tipp entfernt, und bei einer lokalen Suche steht direkt darunter der nächste Anbieter. Eine langsame Seite konkurriert also nicht mit Geduld, sondern mit dem nächsten Ergebnis.

Google's Mobile-First-Index wurde 2018 zum Standard. Das heißt: Google bewertet die mobile Version Ihrer Website als primäre Version – auch für das Desktop-Ranking. Die mobile Fassung ist damit auch für die Desktop-Suche die maßgebliche.

Wie viele Websites in der Region diese Werte reißen, lässt sich von außen nicht seriös beziffern. Die eigene Seite lässt sich dagegen in wenigen Minuten prüfen – wie das geht, steht weiter unten unter Werkzeuge für die Messung.

Mobile-First-Design-Prinzipien

Tap-Targets – die empfohlene Mindestgröße

Buttons, Links und Bedienelemente müssen mit dem Daumen treffbar sein. Rund 48 × 48 px sind dafür ein empfohlener Mindestwert für die Tap-Fläche. Daumen-Spitze ist etwa 8-10 mm breit, was bei typischen Smartphone-Pixeldichten etwa 44–48 px entspricht. Zu eng stehende oder zu kleine Bedienelemente fallen auf dem eigenen Handy sofort auf – dort lässt sich das ohne Werkzeug prüfen.

Häufiger Fehler: Footer-Links zu klein und zu eng nebeneinander. Wer sie mit dem Daumen treffen will, landet dann leicht auf dem Nachbarlink.

Lesbare Schrift ohne Zoom

16 px Body-Text sind ein brauchbarer Ausgangswert. Headlines deutlich größer. Wer zum Lesen zoomen muss, liest nicht weiter – und Google bewertet Ihre Seite in der Handy-Ansicht.

Klickbares Anrufen (tel:-Links)

Jede Telefonnummer auf der Website muss als <a href="tel:..."> ausgezeichnet sein. Ein einziger Tap startet dann den Anruf direkt aus dem Browser. Ohne tel:-Link muss der Nutzer die Nummer merken, die Telefon-App öffnen, manuell eintippen — drei Schritte vor dem Anruf, die ein Link erspart.

Vermeidung horizontaler Scrollerei

Inhalte dürfen niemals breiter als der Bildschirm sein. Tabellen, eingebettete Videos, breite Bilder müssen entweder schrumpfen, scrollbar werden (innerhalb eines begrenzten Containers) oder umgebrochen werden.

Hamburger-Menü statt Mega-Menü

Komplexe Desktop-Mega-Menüs lassen sich auf 375 px nicht sinnvoll abbilden. Standard ist das Hamburger-Icon, das ein Slide-In-Menü öffnet. Für die Hauptpunkte darin sind 6-8 eine brauchbare Obergrenze – was darüber hinausgeht, gehört auf eine Unterseite.

Sticky-Header – wann sinnvoll, wann nicht

Header der beim Scrollen mitgeht ist auf Mobile platzraubend. Maximale Höhe 60–70 px. Sonst gehen zu viel Pixel verloren. Bei wichtigen CTAs im Header (Telefon-Button) lohnt sich Sticky – sonst kompakter Auto-Hide bei Scroll-down.

Core Web Vitals erklärt

Drei Performance-Messwerte, mit denen Google die Nutzererfahrung einer Website bewertet:

LCP – Largest Contentful Paint

Wie lange dauert es bis das größte sichtbare Element (Hero-Bild oder Headline) erscheint?

• Gut: unter 2,5 Sekunden
• Verbesserungsbedarf: 2,5–4 Sekunden
• Schlecht: über 4 Sekunden

Hauptursachen für schlechtes LCP: unkomprimierte Hero-Bilder, Render-Blocking JavaScript, langsamer Server (TTFB > 800 ms), keine Browser-Caching-Header.

INP – Interaction to Next Paint

Wie lange braucht die Site um auf Nutzer-Interaktion (Klick, Tap) zu reagieren? Löste 2024 die alte FID-Metrik ab.

• Gut: unter 200 ms
• Verbesserungsbedarf: 200–500 ms
• Schlecht: über 500 ms

Hauptursachen für schlechtes INP: schwere JavaScript-Bibliotheken (Slider, Pop-up-Plugins), viele WordPress-Plugins, blockierende Third-Party-Scripts (Chat-Widgets).

CLS – Cumulative Layout Shift

Wie sehr verschiebt sich der Seiteninhalt während des Ladens? Nutzer-frustrierend wenn der Button plötzlich nach unten rutscht und man auf etwas anderes klickt.

• Gut: unter 0,1
• Verbesserungsbedarf: 0,1-0,25
• Schlecht: über 0,25

Hauptursachen für schlechtes CLS: Bilder ohne feste Dimensionen, Web-Fonts ohne font-display: swap, nachgeladene Werbe-Boxen, Embeds (YouTube, Maps) ohne reservierten Slot.

Mehr Details im Glossar-Eintrag Was sind Core Web Vitals?

Bildoptimierung

Bilder sind ein wirksamer Performance-Hebel – und ein häufiger Bremsklotz. Drei Maßnahmen:

WebP-Format statt JPEG/PNG

WebP ist Google's modernes Bildformat. Laut Google 25–34 % kleiner als JPEG bei vergleichbarer Qualität, von allen modernen Browsern unterstützt. Bei großen Hero-Bildern fällt die Ersparnis oft deutlicher aus – ohne sichtbaren Qualitätsverlust.

Konvertierungstool: Squoosh.app kostenlos online. Oder WordPress-Plugin „WebP Express“.

Responsive Images mit srcset

Mehrere Größen pro Bild bereitstellen. Mobile bekommt die 768-px-Variante, Desktop die 1920-px-Variante. Das Handy lädt dann die kleinere Datei statt der großen. WordPress macht das automatisch, wenn man Bilder über die Mediathek einbindet.

Lazy-Loading

Bilder unterhalb der Fold-Linie werden erst geladen, wenn der Nutzer scrollt. HTML5-Standard seit 2019: <img loading="lazy" ...>. Beim ersten Aufbau der Seite fällt damit alles weg, was noch außerhalb des Bildschirms liegt. Ausnahme: das Hero-Bild – das soll sofort erscheinen, nicht lazy.

Caching + CDN

Browser-Caching: Statische Assets (Bilder, CSS, JavaScript) bekommen Cache-Header die Browser mitteilen wie lange sie lokal gespeichert bleiben sollen. Beim zweiten Besuch lädt der Browser nur das was sich geändert hat.

Server-Caching (WordPress): Plugins wie WP Rocket (Premium), Cache Enabler (Free), oder WP Super Cache erstellen statische HTML-Versionen Ihrer Pages. Statt jede Anfrage durch PHP zu schicken, liefert der Server die fertige HTML-Datei. Solange die zwischengespeicherte Fassung gültig ist, entfällt dabei die Datenbank- und PHP-Arbeit.

CDN – Content Delivery Network: Bilder und Assets werden global verteilt gespeichert. Für lokale Mittelstandsbetriebe in der Bergstraße meist NICHT nötig – die Besucher eines örtlichen Betriebs kommen überwiegend aus der Region, und für sie ist ein deutscher Server nah genug. CDN wird relevant ab überregionaler Reichweite.

JavaScript + CSS Optimierung

Render-Blocking Scripts vermeiden. JavaScript das im <head> ohne async oder defer eingebunden ist, blockiert das Rendering. Nutzer sehen weiße Seite bis das Script geladen ist.

Minification. CSS und JavaScript-Dateien lassen sich verkleinern, indem Whitespace, Kommentare und überflüssige Zeichen entfernt werden. WordPress-Plugins erledigen das automatisch.

Third-Party-Scripts asynchron laden. Tracking-Tools (Google Analytics), Chat-Widgets, Embed-Codes – alles was nicht direkt zur Anzeige beiträgt, sollte mit async oder defer nachgeladen werden.

Critical-CSS inline. Das CSS für Inhalte above-the-fold direkt im HTML einbinden. Spart einen Round-Trip zum Server für die Hauptanzeige.

Hosting-Auswahl + Server-Performance

TTFB (Time to First Byte) ist die Zeit vom Anfragen bis zur ersten Server-Antwort. Sollte unter 800 ms liegen. Liegt sie darüber, lohnt der Blick zuerst auf Hosting, Caching und die Zahl der aktiven Plugins.

Shared Hosting vs. Managed WordPress vs. eigener Server:

• Shared Hosting (IONOS, Hosteurope, Strato): die günstigste Stufe. Reicht für die meisten Mittelstandsbetriebe. Achten Sie auf SSD und HTTP/2-Support.
• Managed WordPress (Raidboxes, WPEngine): deutlich teurer, dafür bessere Performance, automatische Updates und technischer Support. Empfehlenswert wenn die Site geschäftskritisch ist.
• Eigener Server (Hetzner, Netcup): im Mittelfeld. Volle Kontrolle über die Leistung – aber technisches Know-how nötig.

Werkzeuge für die Messung

• Google PageSpeed Insights (pagespeed.web.dev) – Googles eigenes Messwerkzeug. Zeigt CWV für Mobile + Desktop, konkrete Verbesserungs-Vorschläge.
• Google Search Console – Section „Core Web Vitals“ zeigt Probleme über die ganze Site.
• WebPageTest – Tieferes Tool für Spezial-Analysen. Zeigt Waterfall-Charts, Server-Standorte testbar.
• GTmetrix – Alternative zu PageSpeed Insights, etwas anderer Fokus. Free Tier nutzbar.
• Chrome DevTools Lighthouse – Im Browser eingebaut (F12 → Lighthouse-Tab). Schnelle Spot-Checks.

Mobile UX-Patterns für Conversion

Mobile-First-CTAs

Auf Mobile sind die Bildschirmflächen knapp. Der wichtigste CTA gehört „above the fold“ und prominent. Ein großes, klickbares „Jetzt anrufen“ ist dort die bessere Wahl als mehrere kleine Buttons nebeneinander – die unterschreiten schnell das Daumen-Maß von weiter oben.

Sticky-Bars unten

Eine flach am unteren Bildschirmrand klebende Bar mit den 2-3 wichtigsten Actions (Anrufen / Termin / Kontakt) ist auf Mobile oft die beste Conversion-Komponente. Erreicht ohne zu scrollen, immer sichtbar.

Click-to-Call vs. Click-to-Form

Für Handwerker und Notdienst-Branchen ist der Anruf der direktere Weg: ein Tap startet das Gespräch, ein Formular muss erst ausgefüllt, abgeschickt und danach gelesen werden. Wenn das Rohr platzt, ist das der Unterschied zwischen jetzt und später. Für Steuerberater und Anwälte spricht mehr für das Formular: was ein Interessent dort aufschreibt, liegt schon vor dem ersten Gespräch schriftlich vor.

Form-Friction reduzieren

Mobile Tastaturen sind langsam. Halbieren Sie die Formularfelder: nur das Absolut-Notwendige (Name, Telefon ODER Email, kurze Nachricht). Optionale Felder klar markieren oder weglassen.

Häufige Fragen zu Mobile-First und Performance

Reicht Responsive Design für Mobile-First?

Nicht ganz. Responsive Design heißt: die Website passt sich verschiedenen Bildschirmgrößen an. Mobile-First geht weiter – startet vom kleinen Bildschirm aus und priorisiert mobile UX. Manche Responsive Sites sind faktisch Desktop-First mit Mobile-Anpassung.

Was wenn meine Site bereits 90+ PageSpeed-Score hat?

Score und Core Web Vitals sind verschiedene Dinge. Ein Score von 90 sagt wenig. Die echten Field-Daten (in Google Search Console „Core Web Vitals“-Bereich) sind aussagekräftiger.

Soll ich AMP nutzen?

Nein. AMP (Accelerated Mobile Pages) wurde von Google nicht mehr stark gepusht. Für Mittelstand-Sites ist normales Mobile-First-Design mit guten CWV der bessere Weg.

Wie wichtig ist Performance für AI-Search?

Indirekt. Dass eine AI-Engine schnelle Quellen bevorzugt, sage ich Ihnen nicht zu – wonach die Anbieter auswählen, weiß ich nicht. Benennen lässt sich nur die Mechanik davor: Läuft ein Abruf in eine Zeitgrenze, wird die Seite unter Umständen nicht vollständig erfasst – und was nicht erfasst wurde, taucht in einer Antwort auch nicht auf. Deshalb liefere ich Seiten schnell aus; ein Versprechen auf eine Nennung ist das nicht.

Lohnt sich professionelle Performance-Optimierung?

Bei bestehenden Sites läuft das üblicherweise als einmaliger Audit mit anschließender Optimierung – der Aufwand hängt davon ab, wie viel im Argen liegt. Bei Bergstraße Digital ist Performance-Optimierung in allen Webdesign-Paketen Standard, kein Aufpreis.

Verfasst von David Rupa, Inhaber von Bergstraße Digital.