Core Web Vitals in Elementor, LCP unter 2,5 Sekunden

Auf einen Blick

• Die Core Web Vitals bestehen aus drei Messwerten, und die Grenzwerte sind fest. LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1
• In Elementor ist fast immer das Hero-Bild der LCP-Kandidat, und genau dieses Bild wird durch Lazy Load ausgebremst
• Drei Handgriffe am ersten Bild bringen mehr als jedes Caching-Plugin, nämlich Lazy Load aus, fetchpriority auf high und die Bildgröße an den Anzeigebereich anpassen
• Gewertet wird der Wert am 75. Perzentil aus echten Nutzerdaten, nicht der Laborwert aus einem einzelnen Test

Eine Elementor-Seite sieht im Editor schnell aus. Dann kommt der erste Test mit PageSpeed Insights, der LCP steht bei über vier Sekunden, und der Kunde fragt, warum seine neue Website langsamer ist als die alte.

Die Antwort liegt meistens nicht im Theme, nicht im Hosting und nicht in einem fehlenden Caching-Plugin. Sie liegt in dem einen Bild, das ganz oben steht und das der Browser zu spät anfordert.

Dieser Artikel zeigt dir, was die drei Core Web Vitals messen, warum Elementor beim LCP strukturell im Nachteil ist und welche Reihenfolge von Maßnahmen tatsächlich etwas bewegt.

Was die Core Web Vitals messen und welche Grenzwerte gelten

Die Core Web Vitals sind Googles Versuch, die Nutzererfahrung einer Seite auf drei Zahlen zu reduzieren. Jede davon steht für einen anderen Moment im Seitenaufbau.

Die Grenzwerte sind nicht verhandelbar. LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1.

Google bewertet dabei nicht den Durchschnitt, sondern das 75. Perzentil aller Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Drei von vier Besuchern müssen den guten Wert erreichen, sonst gilt die Seite als durchgefallen. Nachlesen lässt sich das in der Dokumentation zu den Web Vitals. Das ist der Grund, warum ein einzelner guter Testlauf auf deinem Rechner nichts beweist.

Largest Contentful Paint, das größte Element im ersten Bildschirm

Der Largest Contentful Paint misst, wann das größte sichtbare Element fertig geladen ist. Bei einer klassischen Elementor-Startseite ist das der Hero, also das große Bild oder die Headline ganz oben. Alles, was diesen einen Moment verzögert, verschlechtert den Wert direkt.

Interaction to Next Paint und Cumulative Layout Shift

Interaction to Next Paint misst, wie lange die Seite braucht, bis sie nach einem Klick sichtbar reagiert. Cumulative Layout Shift misst, wie stark Inhalte während des Ladens verrutschen, etwa wenn ein nachgeladenes Bild den Text nach unten schiebt. Beide Werte sind in Elementor meist unkritisch, solange du Bildern feste Abmessungen gibst und nicht zu viele Skripte im Header einbindest.

Warum Elementor-Seiten beim LCP so oft scheitern

Elementor bringt von Haus aus mehrere Dinge mit, die den ersten Bildschirm ausbremsen. Das ist kein Argument gegen den Builder, sondern eine Liste dessen, was du danach aufräumen musst.

• Hero-Bilder landen häufig als CSS-Hintergrund in einem Container, statt als img-Tag im HTML. Der Browser findet sie dadurch erst, wenn das Stylesheet verarbeitet ist
• WordPress setzt seit Version 5.5 automatisch loading="lazy" auf Bilder. Trifft das den LCP-Kandidaten, wartet der Browser absichtlich mit dem Laden
• Elementor lädt Icon-Schriften und Slider-Bibliotheken mit, auch auf Seiten, die weder Icons noch Slider verwenden
• Verschachtelte Container erzeugen tiefe DOM-Bäume, was das Rendern verlangsamt

Die ersten beiden Punkte erklären in der Praxis den größten Teil eines schlechten LCP. Genau dort setzen die nächsten drei Abschnitte an.

Core Web Vitals verbessern, der Hebel liegt beim ersten Bild

Bevor du Plugins installierst, kümmerst du dich um das eine Element, das den LCP bestimmt. Die Reihenfolge ist dabei wichtig, weil jeder Schritt auf dem vorherigen aufbaut. Die offiziellen Empfehlungen dazu stehen im Leitfaden zum Largest Contentful Paint optimieren.

Lazy Loading beim ersten Bild abschalten

Lazy Loading ist eine gute Sache, solange es Bilder betrifft, die erst beim Scrollen sichtbar werden. Beim Hero-Bild dreht sich der Effekt um. Der Browser sieht das Attribut, stuft das Bild als unwichtig ein und lädt es nach allem anderen.

In Elementor schaltest du das im Bild-Widget unter Erweitert ab, alternativ über einen Filter in der functions.php. Wichtig ist nur, dass es ausschließlich das erste Bild betrifft. Lazy Loading pauschal zu deaktivieren macht die Seite insgesamt langsamer.

Dem Browser mit fetchpriority sagen, was zuerst kommt

Das Attribut fetchpriority="high" hebt eine Ressource in der Warteschlange nach vorne. Der Browser lädt das Bild dann parallel zu den kritischen Stylesheets, statt es hinten anzustellen. Der folgende Ausschnitt nimmt das Hero-Bild vom verzögerten Laden aus und markiert es als vorrangig.

<img src="hero-1600.webp"
     width="1600" height="900"
     alt="Beschreibung des Motivs"
     loading="eager"
     fetchpriority="high">

Die Angaben zu width und height verhindern nebenbei, dass der Text beim Nachladen verrutscht, was dem CLS zugutekommt.

Bildformat und Abmessungen an den Anzeigebereich anpassen

Ein Hero-Bild mit 4.000 Pixeln Breite überträgt für ein 1.600 Pixel breites Layout die zweieinhalbfache Datenmenge ohne sichtbaren Gewinn. WebP spart gegenüber JPEG zusätzlich Dateigröße bei gleicher Qualität.

Als Faustregel reichen 1.600 Pixel Breite für die Desktop-Ansicht und eine mobile Variante über srcset. Wie du Schriftgrößen und Abstände dabei sauber mitskalierst, steht in Fluide Designs und Schriftgrößen in Elementor.

Pagespeed optimieren, wenn das Bild allein nicht reicht

Bleibt der LCP nach den drei Handgriffen über zwei Sekunden, liegt die Ursache meist davor, nämlich in der Zeit bis zur Serverantwort oder in Ressourcen, die das Rendern blockieren.

Schriften lokal einbinden

Werden Schriften von einem externen Server geladen, kommt eine zusätzliche Verbindung dazu, bevor der erste Text erscheint. Lokal eingebundene Schriften mit font-display swap lösen das und sind nebenbei die datenschutzfreundlichere Variante. Was daran rechtlich hängt, steht im Artikel zu DSGVO bei Webseiten.

Unbenutzte Elementor-Bibliotheken abschalten

Unter Elementor, Einstellungen, Funktionen lassen sich Font Awesome und die Eicons für Seiten deaktivieren, die sie nicht brauchen. Das spart zwei Requests und einige hundert Kilobyte. Der Effekt ist kleiner als beim Hero-Bild, aber er kostet zwei Minuten.

Serverantwortzeit prüfen, bevor du weiter optimierst

Liegt die Zeit bis zum ersten Byte über 800 Millisekunden, ist das Hosting der Engpass und kein Frontend-Thema. Dann hilft kein Plugin, sondern ein Wechsel auf besseren Speicher oder eine vorgelagerte Caching-Schicht.

Richtig messen, Labordaten und Felddaten auseinanderhalten

Der häufigste Fehler nach der Optimierung ist, dem falschen Wert zu vertrauen. PageSpeed Insights zeigt zwei Datensätze, die leicht verwechselt werden.

Der Laborwert sagt dir, woran du arbeiten kannst. Der Feldwert entscheidet, ob Google deine Seite als schnell einstuft.

Labordaten stammen aus einem simulierten Testlauf mit festen Geräte- und Netzwerkannahmen. Felddaten kommen aus dem Chrome User Experience Report und bestehen aus echten Messungen echter Besucher. Eine Änderung, die du heute ausrollst, taucht dort erst mit Verzögerung auf.

Was du dir in PageSpeed Insights ansiehst

Oben stehen die Felddaten, sofern für die URL genug Besucher vorliegen. Darunter folgt der Lighthouse-Bericht mit den Diagnosen. Der Eintrag zum LCP-Element ist der wichtigste, denn er nennt dir genau das Element, das du optimieren musst. Das Werkzeug dafür ist PageSpeed Insights. Ohne diesen Blick optimierst du auf Verdacht.

Der Bericht unten zeigt, warum der große Wert oben allein nichts aussagt. Die Seite kommt auf 96 Punkte, alle Balken sind grün, und trotzdem liegt der LCP über der Vorgabe.

PSI und CrUX per MCP direkt aus dem Chat abfragen

Beide Datenquellen haben eine offene Schnittstelle, und für beide gibt es MCP-Server, die sie an einen KI-Assistenten anbinden. Statt jede URL einzeln im Browser zu prüfen, fragst du dann im Chat nach, etwa nach den Feldwerten mehrerer Seiten auf einmal. Diese Server stammen aus der Community, nicht von Google. Was du brauchst, ist ein API-Schlüssel aus der Google Cloud Console und die Freischaltung der PageSpeed Insights API, für reine Felddaten zusätzlich der Chrome UX Report API. Die Einstiegsdoku steht unter Get Started with the PageSpeed Insights API und bei der CrUX API. Ein Punkt am Rande, Google baut die CrUX-Felddaten in der PSI-Antwort ab, für Felddaten führt der Weg künftig über die CrUX API direkt.

Der Core Web Vitals Bericht in der Search Console

Die Search Console gruppiert URLs mit ähnlichem Verhalten und zeigt dir, wie viele Seiten in den Kategorien gut, verbesserungswürdig und schlecht liegen. Wie der Bericht zu den Core Web Vitals aufgebaut ist, erklärt Google in der Hilfe. Für Websites mit vielen ähnlichen Unterseiten ist das die sinnvollere Ansicht, weil du dort Muster siehst statt Einzelwerte.

Was WordPress darüber hinaus schneller macht

Ist der erste Bildschirm sauber, lohnt der Blick auf den Rest. Ein Objekt-Cache entlastet die Datenbank, ein Seiten-Cache spart die PHP-Ausführung, und eine Bereinigung der Plugin-Liste bringt oft mehr als jede einzelne Einstellung. Sinnvolle Alt-Texte gehören ebenfalls dazu, weniger aus Geschwindigkeitsgründen als für die Barrierefreiheit.

Wie sich Ladezeit in das größere SEO-Bild einordnet, steht in Fortgeschrittene SEO-Techniken.

Fazit

Die Core Web Vitals wirken technisch, laufen in Elementor aber fast immer auf eine einzige Frage hinaus. Welches Element ist das größte im ersten Bildschirm, und wie schnell bekommt der Browser es geliefert.

Wer diese Frage beantwortet, spart sich die halbe Plugin-Liste. Lazy Load raus, Priorität hoch, Bildgröße passend, danach messen und erst dann weitersuchen.

Du willst wissen, woran es auf deiner Seite hängt? Schreib mir eine Nachricht, ich schaue mir den ersten Bildschirm an. Wie ich dabei vorgehe, steht bei der WordPress Ladezeitoptimierung.