Warum ist der Largest Contentful Paint bei Handwerksseiten oft zu hoch?
Der sichtbare Hero-Bereich ist bei vielen Handwerksbetrieben ein einziges großes Foto: Meisterbetrieb vor der Werkstatt, Team vor dem Transporter, Referenzobjekt auf der Baustelle. Wird dieses Bild als 1,8-MB-JPEG aus dem Content-Management-System ausgeliefert, beginnt der Largest Contentful Paint auf einem Mittelklasse-Smartphone im Mobilfunknetz regelmäßig erst nach mehr als vier Sekunden. Der Server antwortet oft in unter 200 Millisekunden; der Engpass sitzt in der Bildkette. Für lokale Sichtbarkeit ist das kein Detail, weil Google den LCP als Core Web Vital bewertet.
Welche Ursache hat das in der Praxis?
Die Ursache ist selten ein fehlendes Cache-Plugin. Häufiger lädt das CMS das Originalfoto mit 4.000 Pixeln Breite hoch, erzeugt keine responsiven Varianten und setzt zusätzlich Lazy-Loading auf das Hero-Bild. Damit wartet der Browser auf einen Download, der für den ersten Viewport entscheidend ist. Dazu kommen fehlende width– und height-Angaben, ein render-blockierendes Stylesheet und ein Slider, der drei weitere große Motive nachlädt. Die Kasseler Webentwicklung von twindor behandelt diese Kette als zusammenhängendes System, nicht als einzelne Plugin-Frage.
Wie sieht die Lösung konkret aus?
Statt das Originalbild unverändert auszuliefern, entstehen beim Build oder Upload mehrere Formate und Breiten: AVIF und WebP für moderne Browser, JPEG als Rückfall, dazu srcset mit 480, 960 und 1440 Pixeln. Das Hero-Bild erhält hohe Priorität und wird vorgeladen; Bilder unterhalb des sichtbaren Bereichs bleiben lazy. Ein fester Seitenrahmen mit definierten Bildmaßen verhindert Layoutsprünge. In einem typischen Projekt sinkt der mobile LCP dadurch von 4,3 auf 1,8 Sekunden, während die Bildqualität auf Retina-Displays erhalten bleibt. Entscheidend ist die Reihenfolge: erst kritische Bildkette, dann Slider und dekorative Grafiken.
Welche Messwerte zählen nach der Umstellung?
Für die Bewertung reichen Laborwerte nicht aus. Aussagekräftig sind Felddaten aus dem Chrome User Experience Report: LCP unter 2,5 Sekunden, CLS unter 0,1 und INP unter 200 Millisekunden. Ein Kasseler Betrieb sollte zusätzlich nach dem Deployment prüfen, ob die Startseite auf einem gedrosselten 4G-Profil ohne Warm-up-Cache unter drei Sekunden LCP bleibt. Wird nur der Lighthouse-Score im Büro-WLAN gemessen, verschwindet das eigentliche Problem häufig aus dem Blick.
Was sollten Betriebe vor der Beauftragung prüfen?
- Liefert die Startseite im mobilen Netz ein Hero-Bild unter 150 KB im modernen Format aus?
- Sind srcset, sizes und feste Bildmaße technisch gesetzt?
- Wird das erste sichtbare Bild priorisiert statt lazy geladen?
- Gibt es eine Messung mit Felddaten statt nur einem einmaligen Labortest?
Diese vier Punkte trennen eine echte LCP-Optimierung von einer kosmetischen Änderung. Wer die Bildkette nicht misst, optimiert an der Stelle, an der der Browser ohnehin schnell ist.