Ladezeit der Website verbessern: Core Web VitalsImprove Website Load Time: Core Web Vitals for SMEs
Eine schnelle Website entscheidet mit darüber, ob Besucher bleiben und anfragen. Dieser Beitrag zeigt, welche Werte Google misst, wie Sie sie kostenlos prüfen und was bei Bildern, Schriften, Skripten und Hosting wirklich hilft.A fast website helps decide whether visitors stay and get in touch. This article shows which values Google measures, how to check them for free, and what actually helps with images, fonts, scripts and hosting.
Was Google bei der Ladezeit tatsächlich misst
„Ladezeit“ ist kein einzelner Wert. Google fasst das Nutzungserlebnis in den Core Web Vitals zusammen, und die bestehen aus drei Kennzahlen. Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element der Seite erscheint, meist ein Hauptbild oder ein großer Textblock. Der Interaction to Next Paint (INP) misst, wie schnell die Seite nach einem Klick, Tippen oder Tastendruck reagiert. Der Cumulative Layout Shift (CLS) misst, wie stark Inhalte beim Laden verrutschen.
Die Zielwerte nennt web.dev, das Entwicklerportal von Google, in der Übersicht zu den Web Vitals: LCP innerhalb von 2,5 Sekunden, INP von höchstens 200 Millisekunden, CLS von höchstens 0,1. Gemessen wird am 75. Perzentil der Seitenaufrufe, getrennt nach Smartphone und Desktop. Anders gesagt: Drei von vier Besuchen sollen den Zielwert erreichen, nicht der Durchschnitt.
Der INP ist übrigens der jüngste Wert. Er hat am 12. März 2024 den früheren First Input Delay (FID) als Core Web Vital abgelöst. Ältere Ratgeber, die noch FID erklären, sind damit überholt. Der INP erfasst alle Interaktionen eines Besuchs, nicht nur die erste, und ist deshalb deutlich strenger.
Was schnelle Seiten für Ranking und Anfragen bedeuten
Google sagt in der Dokumentation zur Seitenerfahrung klar, dass es kein einzelnes Signal gibt. Die Ranking-Systeme berücksichtigen verschiedene Signale, die zur Seitenerfahrung passen. Und Google zeigt laut dieser Seite weiterhin die relevantesten Inhalte, selbst wenn die Seitenerfahrung mäßig ist. Perfekte Werte nur für das Ranking anzustreben, sei womöglich nicht der beste Einsatz Ihrer Zeit.
Das ist eine ehrliche Einordnung, und sie ist hilfreich. Wer lokal auf Platz drei steht, steigt nicht automatisch auf, weil der LCP von 3,2 auf 2,4 Sekunden fällt. Der eigentliche Hebel liegt woanders: Besucher, die mit dem Smartphone aus der Suche kommen, warten nicht lange. Eine Seite, die beim Laden springt oder auf Tippen nicht reagiert, verliert die Anfrage, bevor der Kontaktweg überhaupt sichtbar war. Wie sich das auf Ihr Formular und Ihren Anruf-Button auswirkt, zeigt unser Beitrag zu den Hebeln der Conversion-Optimierung.
Messen, bevor Sie etwas ändern
Bevor Sie Bilder austauschen oder Plugins löschen, brauchen Sie eine Ausgangslage. Zwei kostenlose Werkzeuge reichen für die meisten KMU aus, und sie messen Unterschiedliches.
Search Console: der Blick auf Ihre ganze Website
Der Bericht „Core Web Vitals“ in der Search Console stützt sich laut Google-Hilfe auf den Chrome-UX-Report (CrUX), also auf anonymisierte Messwerte echter Besucher (Feldwerte). Er gruppiert Seiten mit ähnlichem Nutzungserlebnis, trennt Mobil und Desktop und weist jeder Gruppe den Status „Schlecht“, „Verbesserungsbedarf“ oder „Gut“ zu. Maßgeblich ist der schwächste Wert der Gruppe. Wenn Sie die Search Console noch nicht eingerichtet haben, erklärt unsere Anleitung zur Einrichtung für KMU die ersten Schritte. Beachten Sie: Bei wenig Besuchen fehlen oft Daten, dann fasst die Search Console auf einer höheren Ebene zusammen.
PageSpeed Insights: eine einzelne Seite im Detail
PageSpeed Insights zeigt zwei Datenquellen nebeneinander. Die Felddaten stammen aus dem CrUX der vergangenen 28 Tage. Die Labordaten erzeugt Lighthouse in einer simulierten Umgebung, laut Google ein Mittelklasse-Gerät im Mobilfunknetz. Laut Google eignen sich Labordaten zum Debuggen, Felddaten zeigen das echte Erlebnis. Eine Seite besteht die Bewertung, wenn die 75. Perzentile aller drei Werte „Gut“ sind. Fehlen Daten für den INP, genügen LCP und CLS.
Daraus folgt eine Faustregel: Entscheiden Sie anhand der Felddaten, ob ein Problem besteht, und nutzen Sie die Labordaten, um die Ursache zu finden. Ein Laborwert von 98 beruhigt wenig, wenn die Felddaten rot sind. Umgekehrt kann ein schwacher Laborwert harmlos sein, wenn Ihre Besucher überwiegend schnelle Geräte nutzen.
Die drei Werte verbessern
Jeder der drei Werte hat eigene typische Ursachen. Die folgenden Abschnitte gehen sie nacheinander durch, in der Reihenfolge, in der sich der Aufwand meist lohnt.
LCP verbessern: Bilder und Server zuerst
Bei den meisten KMU-Seiten ist das LCP-Element ein großes Titelbild. Laut web.dev gelten als Kandidaten unter anderem Bilder, Videos mit Vorschaubild, Elemente mit Hintergrundbild und große Textblöcke. Wer die Ladezeit verbessern will, beginnt deshalb beim obersten Bild.
Die Anleitung Optimize LCP teilt die Zeit in vier Phasen: Serverantwort (TTFB) mit rund 40 Prozent, Verzögerung vor dem Laden des Bildes unter 10 Prozent, die Ladedauer des Bildes mit rund 40 Prozent und die Verzögerung bis zur Darstellung unter 10 Prozent. Der Kern der Aussage: Die Zeit soll in HTML und Hauptbild fließen, nicht in Wartezeiten. Prüfen Sie also, welche Phase bei Ihnen auffällt.
- Bild verkleinern: Verwenden Sie moderne Formate wie WebP oder AVIF und liefern Sie kleinere Dateien für kleinere Bildschirme (srcset). Ein 4-MB-Foto direkt aus der Kamera hat auf einer Startseite nichts verloren.
- Das Hauptbild nie lazy laden: web.dev warnt ausdrücklich davor, das LCP-Bild mit
loading="lazy"zu versehen. Dieses Attribut gehört nur an Bilder unterhalb des sichtbaren Bereichs. - Priorität setzen: Mit
fetchpriority="high"am wahrscheinlichen LCP-Bild sagen Sie dem Browser, dass es zuerst kommen soll. Sparsam einsetzen, sonst verliert der Hinweis seine Wirkung. - Server und Hosting prüfen: Die Serverantwort zählt zum LCP. Ein träger Billig-Tarif, fehlendes Seiten-Caching oder ein Server weit weg von Ihrer Zielgruppe verlängern jede Seite, egal wie gut die Bilder sind.
Beim Hosting hilft eine nüchterne Prüfung: Wie lange dauert die erste Antwort Ihres Servers? Zeigt PageSpeed Insights eine lange Serverantwort, bringt Bildoptimierung nur einen Teil des Erfolgs. Dann lohnt sich ein Wechsel auf einen schnelleren Tarif oder ein Cache-Plugin, bei WordPress zusätzlich ein Blick auf Wartung und Updates.
CLS verbessern: nichts darf verrutschen
Layoutsprünge entstehen fast immer aus drei Gründen: Bilder ohne Größenangabe, nachladende Elemente wie Banner oder Einbettungen und Schriften, die beim Laden die Zeilenumbrüche verändern. Die Anleitung Optimize Cumulative Layout Shift nennt dafür konkrete Gegenmittel.
- Geben Sie bei Bildern und Videos immer
widthundheightan oder reservieren Sie den Platz per CSSaspect-ratio. - Reservieren Sie für nachladende Inhalte (Karten, Videos, Buchungswidgets) von Anfang an Platz, etwa mit
min-height. - Laden Sie wichtige Schriften früh per
<link rel="preload">und legen Sie eine passende Ersatzschrift fest. Mitfont-display: optionaloder dem Overridesize-adjustvermeiden Sie das Springen des Textes. - Animieren Sie mit
transform, nicht mit Eigenschaften wietopoderleft.
Auch ein Cookie-Banner kann Inhalte verschieben, wenn es erst spät eingeblendet wird und die Seite nach unten drückt. Wie Sie das Banner rechtskonform und ohne Layoutsprung einbinden, erklärt unser Beitrag zum Cookie-Banner.
INP verbessern: weniger Skripte, kürzere Aufgaben
Der INP leidet, wenn der Browser mit JavaScript beschäftigt ist, während jemand tippt. Laut web.dev (INP-Anleitung) misst der Wert die Zeit von der Eingabe bis zum nächsten gezeichneten Bild, inklusive Verzögerung, Ausführung der Ereignisbehandlung und Darstellung. Gut ist ein Wert bis 200 Millisekunden, über 500 Millisekunden gilt als schlecht.
In KMU-Websites kommen die Verzögerungen selten aus eigenem Code. Häufiger sind es angesammelte Zusatzskripte: Tracking, Chat-Widgets, Seitenbaukasten-Effekte, Slider, Social-Plugins. Jedes davon blockiert den Hauptthread ein Stück weit. Die Optimierungsanleitung zum INP empfiehlt, lange Aufgaben in kleinere zu zerlegen und nur das unmittelbar Nötige sofort auszuführen. Für Sie als Betreiber heißt das praktisch: Prüfen Sie jedes Skript auf seinen Nutzen und entfernen Sie, was niemand mehr auswertet. Ein sauber eingerichtetes Tracking, wie in unserem Beitrag zu GA4 beschrieben, braucht nicht mehr Skripte als nötig.
Schriften und Caching: die unterschätzten Hebel
Webschriften sind schnell zu viel. Jede Schriftart und jeder Schnitt ist eine eigene Datei. Die Font-Empfehlungen von web.dev nennen WOFF2 als das Format mit der besten Kompression und raten, überflüssige Zeichen zu entfernen (Subsetting). Außerdem heißt es dort: Die schnellste Schrift ist die, die gar nicht erst angefordert wird. Zwei Schnitte statt sechs sind für die meisten Firmenseiten genug.
Beim Caching entscheidet der Header Cache-Control. Für Dateien mit Versionsnummer im Namen (Skripte, Stylesheets, Bilder) empfiehlt web.dev laut HTTP-Cache-Leitfaden max-age=31536000, also ein Jahr. Für Adressen ohne Versionierung gilt no-cache mit Prüfung per ETag, damit Besucher bei Änderungen die neue Datei bekommen, bei Unverändertem aber nur eine kleine Bestätigung. Wiederkehrende Besucher laden dadurch vieles gar nicht mehr.
Ursachen und Maßnahmen im Überblick
| Symptom | Betroffener Wert | Häufige Ursache | Maßnahme |
|---|---|---|---|
| Titelbild erscheint spät | LCP | Zu große Datei, Bild lazy geladen | WebP/AVIF, srcset, kein loading="lazy", fetchpriority="high" |
| Weiße Seite vor dem ersten Inhalt | LCP | Lange Serverantwort | Seiten-Caching, schnellerer Tarif, Standort prüfen |
| Text oder Buttons springen | CLS | Bilder ohne Maße, spät geladene Schriften oder Banner | width/height, Platz reservieren, Schrift-Fallback |
| Klick reagiert verzögert | INP | Viele oder schwere Skripte | Skripte prüfen, entfernen, lange Aufgaben aufteilen |
| Wiederholte Besuche bleiben langsam | LCP | Fehlende Cache-Header | Langes max-age für versionierte Dateien |
Ihre Schritte in der Reihenfolge
- Rufen Sie in der Search Console den Bericht „Core Web Vitals“ auf und notieren Sie den Status für Mobil und Desktop.
- Testen Sie Startseite und wichtigste Leistungsseite in PageSpeed Insights, und lesen Sie zuerst die Felddaten, dann die Labordiagnose.
- Identifizieren Sie das LCP-Element und prüfen Sie Größe, Format und Ladepriorität.
- Ergänzen Sie fehlende Bildmaße und reservieren Sie Platz für Banner und Einbettungen.
- Entfernen Sie Skripte und Plugins, die keinen erkennbaren Nutzen mehr haben.
- Prüfen Sie Cache-Header und die Serverantwort beim Hosting.
- Starten Sie in der Search Console die Validierung der Korrektur. Laut Google läuft sie über 28 Tage, weil die Felddaten so lange gesammelt werden.
Wer nicht selbst in Code und Server eingreifen möchte, kann mit dem kostenlosen Selbsttest für Ihre Website eine erste Einschätzung holen. Bei neuen Websites gehört die Ladezeit zum Leistungsumfang von Webdesign bei TRIUM, und bei einem Relaunch hilft die Checkliste für den Website-Relaunch, damit Geschwindigkeit nicht nebenbei verloren geht.
Wann Optimierung nicht der richtige Schritt ist
Nicht jede langsame Seite braucht Feintuning. Wenn Ihre Inhalte kaum jemanden ansprechen oder die Seite für die Suche gar nicht relevant ist, bringt ein besserer LCP wenig. Google betont, dass relevante Inhalte auch bei durchschnittlicher Seitenerfahrung angezeigt werden. Beheben Sie dann zuerst Inhalt und Auffindbarkeit.
Auch die Messung hat Grenzen. Bei Seiten mit wenig Besuchen liefert der CrUX gar keine Felddaten, und Laborwerte schwanken von Test zu Test. Verlassen Sie sich deshalb nicht auf eine einzelne Messung, sondern auf den Trend über mehrere Wochen. Und: Ein Baukasten-System mit festem Seitenaufbau lässt sich manchmal nur begrenzt beschleunigen. Dann ist ein Umbau die ehrlichere Lösung als das hundertste Plugin. Wenn Sie unsicher sind, was bei Ihnen zutrifft, klären wir das gern im kostenlosen Erstgespräch.
Häufige Fragen
Welche Ladezeit ist für eine KMU-Website gut genug?
Google nennt keine pauschale Sekundenzahl für die ganze Seite, sondern drei Zielwerte: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1, jeweils für 75 Prozent der Besuche. Orientieren Sie sich an diesen Werten.
Warum zeigt PageSpeed Insights bei mir keine Felddaten?
Die Felddaten stammen aus dem Chrome-UX-Report. Hat eine Seite zu wenige Besuche, fällt PageSpeed Insights auf die gesamte Domain zurück. Reicht auch das nicht, bleiben nur die Labordaten.
Verbessern bessere Core Web Vitals mein Google-Ranking?
Google sagt, dass gute Werte zur Seitenerfahrung gehören, die von den Ranking-Systemen berücksichtigt wird. Ein einzelnes Signal gibt es nicht, und relevante Inhalte haben Vorrang. Ein Ranking-Sprung lässt sich daraus nicht versprechen.
Wie lange dauert es, bis Verbesserungen in der Search Console ankommen?
Die Felddaten beruhen auf einem Zeitraum von 28 Tagen. Die Validierung einer Korrektur läuft laut Google ebenfalls über 28 Tage. Rechnen Sie deshalb mit mehreren Wochen, bis sich der Status ändert.
Was ist der Unterschied zwischen INP und FID?
Der FID maß nur die Verzögerung der ersten Interaktion. Der INP erfasst alle Klicks, Tippgesten und Tastatureingaben eines Besuchs und hat den FID am 12. März 2024 als Core Web Vital ersetzt.
Kann ich die Ladezeit ohne Programmierkenntnisse verbessern?
Teilweise. Bilder komprimieren, ungenutzte Plugins löschen und einen besseren Hosting-Tarif wählen gelingt oft ohne Code. Schrift-Einbindung, Cache-Header und Skript-Reihenfolge sollten Sie dagegen einer technisch versierten Person überlassen.
Quellen
- Web Vitals. web.dev (Google), Stand 31.10.2024. https://web.dev/articles/vitals
- Optimize Largest Contentful Paint. web.dev (Google), Stand 31.03.2025. https://web.dev/articles/optimize-lcp
- Interaction to Next Paint (INP). web.dev (Google), Stand 02.09.2025. https://web.dev/articles/inp
- Optimize Cumulative Layout Shift. web.dev (Google), Stand 07.02.2025. https://web.dev/articles/optimize-cls
- Core Web Vitals report (Search Console-Hilfe). Google, abgerufen am 03.10.2026. https://support.google.com/webmasters/answer/9205520
- About PageSpeed Insights. Google for Developers, Stand 21.10.2024. https://developers.google.com/speed/docs/insights/v5/about
- Understanding page experience in Google Search results. Google Search Central, Stand 22.09.2026. https://developers.google.com/search/docs/appearance/page-experience
- Prevent unnecessary network requests with the HTTP Cache. web.dev (Google), abgerufen am 03.10.2026. https://web.dev/articles/http-cache
- Optimize Interaction to Next Paint. web.dev (Google), Stand 02.09.2025. https://web.dev/articles/optimize-inp
- Best practices for fonts. web.dev (Google), Stand 04.10.2022. https://web.dev/articles/font-best-practices
What Google actually measures when it talks about load time
"Load time" is not a single number. Google summarises the user experience in the Core Web Vitals, which consist of three metrics. Largest Contentful Paint (LCP) measures when the largest visible element appears, usually a hero image or a big block of text. Interaction to Next Paint (INP) measures how quickly the page responds after a click, tap or key press. Cumulative Layout Shift (CLS) measures how much content jumps around while the page loads.
The targets come from web.dev, Google's developer site, in its overview of Web Vitals: LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less. They are measured at the 75th percentile of page loads, split by mobile and desktop.
INP is the newest of the three. It replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024, so guides that still explain FID are out of date. INP looks at all interactions during a visit, not just the first one, which makes it noticeably stricter.
What fast pages mean for rankings and enquiries
Google's documentation on page experience is clear that there is no single signal. Its core ranking systems look at a variety of signals that align with overall page experience. According to the same page, Google still aims to show the most relevant content even when page experience is sub-par, and chasing perfect scores purely for SEO may not be the best use of your time.
That is an honest framing, and a useful one. If you rank third locally, you will not automatically move up because your LCP drops from 3.2 to 2.4 seconds. The real lever lies elsewhere: visitors who arrive from search on a smartphone do not wait long. A page that jumps while loading or ignores a tap loses the enquiry before the contact option was even visible. What that does to your form and your call button is covered in our article on the levers of conversion optimisation.
Measure before you change anything
Before you swap images or delete plugins, you need a baseline. Two free tools cover most SMEs, and they measure different things.
Search Console: the view across your whole site
According to Google's help page, the Core Web Vitals report in Search Console draws on the Chrome UX Report (CrUX), which means anonymised measurements from real visitors (field data). It groups pages with a similar experience, separates mobile from desktop, and assigns each group the status Poor, Needs improvement or Good. The slowest status in a group is the one that counts. If Search Console is not set up yet, our setup guide for SMEs covers the first steps. Note that low-traffic pages often lack data, in which case Search Console falls back to a higher-level group.
PageSpeed Insights: one page in detail
PageSpeed Insights shows two data sources side by side. Field data comes from CrUX over the previous 28 days. Lab data is generated by Lighthouse in a simulated environment, which Google describes as a mid-tier device on a mobile network. Google says lab data is good for debugging, while field data shows the real-world experience. A page passes the assessment when the 75th percentiles of all three metrics are Good. If there is not enough INP data, LCP and CLS are enough.
A rule of thumb follows: use field data to decide whether there is a problem, and lab data to find the cause. A lab score of 98 offers little comfort if the field data is red. Conversely, a weak lab score can be harmless if your visitors mostly use fast devices.
Improving the three values
Each of the three values has its own typical causes. The sections below go through them one by one, in the order in which the effort usually pays off.
Improving LCP: images and server first
On most SME pages the LCP element is a large header image. According to web.dev, candidates include images, videos with a poster image, elements with a background image and large text blocks. If you want faster loading, the topmost image is where to begin.
The guide to optimising LCP splits the time into four phases: server response (TTFB) at about 40 percent, delay before the image starts loading under 10 percent, image load duration at about 40 percent, and render delay under 10 percent. The point is that time should go into the HTML and the main image, not into waiting. So check which phase stands out on your page.
- Shrink the image: use modern formats such as WebP or AVIF and serve smaller files to smaller screens (srcset). A 4 MB photo straight from the camera does not belong on a homepage.
- Never lazy-load the hero image: web.dev explicitly warns against putting
loading="lazy"on the LCP image. The attribute belongs on images below the visible area only. - Set a priority:
fetchpriority="high"on the likely LCP image tells the browser to fetch it first. Use it sparingly, or the hint loses its effect. - Check server and hosting: server response counts toward LCP. A sluggish budget plan, missing page caching or a server far from your audience slows every page, however good the images are.
For hosting, a sober check helps: how long does your server take to send the first response? If PageSpeed Insights shows a long server response, image optimisation only gets you part of the way. Then a faster plan or a caching plugin is worth considering, and on WordPress a look at maintenance and updates.
Improving CLS: nothing should move
Layout shifts almost always have three causes: images without dimensions, late-loading elements such as banners or embeds, and fonts that change line breaks when they arrive. The guide to optimising Cumulative Layout Shift lists concrete countermeasures.
- Always set
widthandheighton images and videos, or reserve the space with CSSaspect-ratio. - Reserve space from the start for content that loads later (maps, videos, booking widgets), for example with
min-height. - Load key fonts early with
<link rel="preload">and define a suitable fallback font.font-display: optionalor thesize-adjustoverride prevents text from jumping. - Animate with
transform, not with properties such astoporleft.
A cookie banner can also push content around if it appears late and shoves the page down. How to add one in a compliant way and without a layout shift is explained in our article on cookie banners.
Improving INP: fewer scripts, shorter tasks
INP suffers when the browser is busy with JavaScript while someone taps. According to web.dev (INP guide), the metric measures the time from the input to the next painted frame, including input delay, event handler processing and presentation delay. Good is 200 milliseconds or less; above 500 milliseconds is poor.
On SME websites the delays rarely come from custom code. More often it is an accumulation of add-on scripts: tracking, chat widgets, page-builder effects, sliders, social plugins. Each one blocks the main thread a little. The guide to optimising INP recommends breaking long tasks into smaller ones and running only what is immediately necessary. For you as the site owner this means: check every script for its value and remove what nobody evaluates any more. A cleanly set up tracking, as described in our GA4 article, does not need more scripts than necessary.
Fonts and caching: the underrated levers
Web fonts add up quickly. Every typeface and every weight is a separate file. The font recommendations from web.dev name WOFF2 as the format with the best compression and advise removing unused characters (subsetting). They also note that the fastest font is the one that is never requested.
For caching, the Cache-Control header decides. For files with a version in their name (scripts, stylesheets, images), web.dev's HTTP cache guide recommends max-age=31536000, one year. For unversioned URLs, use no-cache with ETag validation, so visitors get the new file after a change but only a small confirmation when nothing changed. Returning visitors then skip downloading much of the page.
Causes and fixes at a glance
| Symptom | Metric affected | Common cause | Fix |
|---|---|---|---|
| Header image appears late | LCP | File too large, image lazy-loaded | WebP/AVIF, srcset, no loading="lazy", fetchpriority="high" |
| Blank page before first content | LCP | Slow server response | Page caching, faster plan, check server location |
| Text or buttons jump | CLS | Images without dimensions, late fonts or banners | width/height, reserve space, font fallback |
| Click reacts with a delay | INP | Many or heavy scripts | Audit, remove, split long tasks |
| Repeat visits stay slow | LCP | Missing cache headers | Long max-age for versioned files |
Your steps in order
- Open the Core Web Vitals report in Search Console and note the status for mobile and desktop.
- Test your homepage and your most important service page in PageSpeed Insights, reading the field data first and the lab diagnosis second.
- Identify the LCP element and check its size, format and loading priority.
- Add missing image dimensions and reserve space for banners and embeds.
- Remove scripts and plugins that no longer have a visible purpose.
- Check cache headers and the server response at your host.
- Start validation of the fix in Search Console. According to Google it runs for 28 days, because field data is collected over that period.
If you would rather not touch code and servers yourself, the free self-test for your website gives you a first assessment. For new sites, load time is part of what web design at TRIUM delivers, and for a relaunch the website relaunch checklist helps keep speed from getting lost along the way.
When optimisation is not the right step
Not every slow page needs fine-tuning. If your content appeals to hardly anyone, or the page is not relevant for search at all, a better LCP achieves little. Google stresses that relevant content is shown even when page experience is average. Fix content and findability first.
Measurement has limits too. For pages with few visits, CrUX provides no field data at all, and lab values vary from test to test. So do not rely on a single measurement; look at the trend over several weeks. And a page-builder system with a fixed structure can sometimes only be sped up so far. In that case a rebuild is the more honest answer than the hundredth plugin. If you are unsure which case applies to you, we are happy to look at it in a free initial call.
Frequently asked questions
What load time is good enough for an SME website?
Google does not give one blanket number of seconds for the whole page. It gives three targets: LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1, each for 75 percent of visits. Use these as your guide.
Why does PageSpeed Insights show no field data for my site?
Field data comes from the Chrome UX Report. If a page has too few visits, PageSpeed Insights falls back to the whole origin. If that is not enough either, only lab data remains.
Will better Core Web Vitals improve my Google ranking?
Google says good values are part of page experience, which its ranking systems take into account. There is no single signal, and relevant content comes first. A ranking jump cannot be promised on this basis.
How long until improvements show up in Search Console?
Field data is based on a 28-day period, and according to Google the validation of a fix also runs for 28 days. Expect several weeks before the status changes.
What is the difference between INP and FID?
FID measured only the delay of the first interaction. INP captures all clicks, taps and key presses during a visit and replaced FID as a Core Web Vital on 12 March 2024.
Can I improve load time without programming skills?
Partly. Compressing images, deleting unused plugins and choosing a better hosting plan often works without code. Font embedding, cache headers and script order are better left to someone technical.
Sources
- Web Vitals. web.dev (Google), updated 31 Oct 2024. https://web.dev/articles/vitals
- Optimize Largest Contentful Paint. web.dev (Google), updated 31 Mar 2025. https://web.dev/articles/optimize-lcp
- Interaction to Next Paint (INP). web.dev (Google), updated 2 Sep 2025. https://web.dev/articles/inp
- Optimize Cumulative Layout Shift. web.dev (Google), updated 7 Feb 2025. https://web.dev/articles/optimize-cls
- Core Web Vitals report (Search Console Help). Google, accessed 3 Oct 2026. https://support.google.com/webmasters/answer/9205520
- About PageSpeed Insights. Google for Developers, updated 21 Oct 2024. https://developers.google.com/speed/docs/insights/v5/about
- Understanding page experience in Google Search results. Google Search Central, updated 22 Sep 2026. https://developers.google.com/search/docs/appearance/page-experience
- Prevent unnecessary network requests with the HTTP Cache. web.dev (Google), accessed 3 Oct 2026. https://web.dev/articles/http-cache
- Optimize Interaction to Next Paint. web.dev (Google), updated 2 Sep 2025. https://web.dev/articles/optimize-inp
- Best practices for fonts. web.dev (Google), updated 4 Oct 2022. https://web.dev/articles/font-best-practices
Möchten Sie das für Ihr Unternehmen umsetzen?Want this for your business?
In einem kostenlosen 30-Minuten-Gespräch zeigen wir Ihnen, wo bei Ihnen der größte Hebel liegt. Passende Leistung: Webdesign Wien.In a free 30-minute call we show you where your biggest lever is. Related service: Webdesign Wien.
Termin buchenBook a call Demo anfragenRequest a demo
