Website-Geschwindigkeit und Core Web Vitals: Ein vollständiger Leitfaden

Die Geschwindigkeit einer Website geht nicht nur um Zahlen in einem Bericht. Es geht um Geld und Rankings. Lassen Sie uns die Kern-Web-Vitalwerte in einfacher Sprache entschlüsseln und zeigen, was zuerst behoben werden muss.

Veröffentlicht: 11. Juli 2026·11 Minuten Lesezeit
Website-GeschwindigkeitCore Web VitalsLeistung

Was Core Web Vitals in einfacher Sprache bedeuten

Lassen Sie uns mit den Grundlagen beginnen.Core Web Vitals sind drei Metriken, die Google verwendet, um zu messen, wie eine Seite tatsächlich aus der Sicht eines echten Menschen und nicht eines Roboters lädt. Sie beantworten drei einfache Fragen: Erschien der Hauptinhalt schnell, reagierte die Seite schnell auf Ihre Aktion und blieb das Layout unter Ihrem Finger stabil.

LCP — wie schnell der Hauptinhalt angezeigt wird

LCP (Largest Contentful Paint) ist der Moment, in dem das größte sichtbare Element mit dem Rendern fertig ist: normalerweise ein Hero-Bild, eine Überschrift oder ein großes Banner. Ein Besucher betrachtet die Seite als geladen, wenn dieser Block erscheint, nicht wenn das letzte Fußzeilenskript ankommt. Ein solides Ziel im Jahr 2026 liegt bei etwa 2,5 Sekunden bei einer typischen mobilen Verbindung.

INP — wie schnell die Seite reagiert

INP (Interaction to Next Paint)ersetzt die alte FID und misst die Reaktionsfähigkeit: du tippst auf einen Button, öffnest ein Menü, beginnst zu tippen — und wie viele Millisekunden vergehen, bevor die Benutzeroberfläche sichtbar reagiert. Wenn nach einem Klick eine halbe Sekunde lang nichts passiert, ist das Gehirn überzeugt, dass die Seite eingefroren ist. Ein angenehmer Bereich liegt unter 200 Millisekunden.

CLS — wie stabil das Layout ist

CLS (Cumulative Layout Shift)fängt den lästigsten Fehler ein: du zielst auf einen Button, ein Bild oder Banner lädt darüber, alles springt nach unten, und du klickst auf das falsche. Es ist eine kumulative Verschiebung des Layouts, und je näher an null, desto ordentlicher fühlt sich die Seite an. Ein gesunder Wert liegt unter 0,1.

Erinnere dich an eine einfache Formel: LCP geht um das Sehen, INP geht um das Tippen, CLS geht um das Nicht-Springen. Google sammelt alle drei von echten Chrome-Nutzern und behandelt sie als Teil eines Seitenqualitäts-Signals für das Ranking.

Warum Geschwindigkeit SEO und Conversion beeinflusst

Lass uns ehrlich sein: eine langsame Seite verliert Geld an der Tür, bevor der Besucher ein einziges Wort gelesen hat. Jede zusätzliche Sekunde des Wartens erhöht den Anteil der Menschen, die den Tab schließen und zu einem Konkurrenten wechseln, der sofort geöffnet wird.

Geschwindigkeit und Suchrankings

Core Web Vitals sind ein offizieller Rankingfaktor. Das bedeutet nicht, dass eine schnelle, aber leere Seite eine langsame, aber fachkundige schlägt: Inhalte kommen immer noch zuerst. Aber wenn zwei Seiten in der Qualität nah beieinander liegen, wird die Geschwindigkeit zum entscheidenden Faktor, der dich höher hebt. Eine schnelle Seite wird auch gründlicher gecrawlt — im gleichen Crawl-Budget erreicht der Bot mehr deiner Seiten.

Geschwindigkeit und Geld

Bei kommerziellen Projekten ist die Verbindung zwischen Website-Geschwindigkeit und Umsatz offensichtlich. Eine schnellere erste Bildschirmdarstellung hebt die Konversionsrate beim Checkout und bei Formularen merklich an, senkt Ihre Akquisitionskosten (Sie hören auf, die Hälfte Ihres bezahlten Traffics auf dem Ladebildschirm zu verlieren) und erhöht, wie tief die Nutzer browsen. Wir haben dies immer wieder in unserer Entwicklungs- und Optimierungsarbeit: Technische Leistung zahlt sich schneller aus als eine weitere Werbekampagne.

Es gibt auch eine Reputationsebene. Eine langsame Website wird unbewusst als unzuverlässig wahrgenommen: Wenn hier alles ruckelt, kann ich ihr dann bei meiner Zahlung vertrauen? Geschwindigkeit ist der erste Handschlag Ihrer Marke, und er sollte selbstbewusst wirken.

Wie man Geschwindigkeit misst: Labor vs. Feld

Bevor Sie etwas beheben, messen Sie ehrlich. Und hier ist es wichtig, zwei grundlegend unterschiedliche Arten von Daten zu trennen, da die Menschen sie ständig verwechseln.

Labordaten

LaborMessungen werden von einem Tool unter kontrollierten Bedingungen durchgeführt: eine feste Verbindung, ein definiertes Gerät, eine saubere Umgebung. Dies ist Lighthouse (in Chrome DevTools integriert) und der Laborbereich von PageSpeed Insights. Der Vorteil ist die Wiederholbarkeit: Sie ändern den Code und sehen sofort, ob sich die Dinge verbessert haben. Der Nachteil ist, dass es eine Simulation ist, keine lebenden Menschen.

Felddaten

FeldDaten sind Metriken, die von echten Chrome-Nutzern (dem CrUX-Datensatz) gesammelt werden. Dies sind genau die Daten, die Google für das Ranking verwendet. Sie zeigen, wie sich die Seite auf echten Geräten, echten Netzwerken und in echter Geografie verhält. Feldzahlen werden im 75. Perzentil gemessen: Das Ziel ist, dass die Seite nicht im Durchschnitt schnell ist, sondern für drei Viertel des Publikums.

Eine praktische Messbestellung

  1. Führen Sie Ihre Schlüsselvorlagen (Startseite, Kategorie, Produkt, Formular) separat für Mobilgeräte und Desktop durch PageSpeed Insights.
  2. Schauen Sie sich zuerst die Kern-Web-Vitalwerte an, wenn sie vorhanden sind; verwenden Sie den Laborscore als Debugging-Tool.
  3. Öffnen Sie die Leistungsregisterkarte in den DevTools und finden Sie heraus, welches Element LCP antreibt und welche Skripte den Hauptthread blockieren.

Die goldene Regel: optimieren nach dem Feld, debuggen im Labor. Ein hübsches Hundert in Lighthouse zu verfolgen, ohne Rücksicht auf echte Benutzer, ist Arbeit, die für einen Screenshot und nicht für das Geschäft erledigt wird.

LCP: Was es abdeckt und wie man es verbessert

LCP ist normalerweise das, was die Leute meinen, wenn sie sagen, die Seite braucht ewig zum Laden. Es zu verbessern bedeutet, das Haupt-Element des ersten Bildschirms früher anzuzeigen. Lassen Sie uns das in Teile zerlegen.

Woraus LCP besteht

LCP hat vier Bestandteile: Server-Antwortzeit (TTFB), eine Verzögerung, bevor die Ressource zu laden beginnt, die Ladezeit der Ressource selbst und die Renderzeit. Jeder dieser Punkte kann der Engpass sein, daher beginnt die Behandlung mit einer Diagnose, nicht mit Vermutungen.

Was LCP tatsächlich beschleunigt

  • Eine schnelle Serverantwort.Halten Sie TTFB niedrig: serverseitiges Caching, angemessenes Hosting und wenige schwere Datenbankabfragen bei der Erstellung des ersten Bildschirms.
  • Priorität für die Hauptressource.Das LCP-Bild oder die Überschrift-Schriftart sollte mit hoher Priorität (Preload) geladen werden, nicht in der allgemeinen Warteschlange.
  • Kein Lazy Loading für den ersten Bildschirm.Ein klassischer Fehler ist es, Lazy-Load auf das obere Banner anzuwenden. Lassen Sie Lazy Loading für das, was unterhalb der Falz sitzt.
  • Ein leichtes, richtig komprimiertes LCP-Element.Ein riesiges 2 MB PNG-Held wird die Metrik selbst auf einem schnellen Server ruinieren.

Ein Wort zu render-blockierenden Elementen. Wenn der Browser schwere CSS- und JavaScript-Dateien herunterladen und ausführen muss, bevor der erste Bildschirm angezeigt wird, wird LCP genau um diese Zeit verzögert. Deshalb ist kritisches CSS inline, während sekundäre Skripte nach unten verschoben und verzögert werden.

INP und CLS: Reaktionsfähigkeit und Stabilität

Wenn LCP darum geht, zu sehen, geht es bei INP und CLS um das Gefühl von Qualität nach dem Laden. Sie werden oft unterschätzt, und das ist ein Fehler: Sie sind genau das, was eine Website sorgfältig gebaut erscheinen lässt.

Wie man INP verbessert

Schlechtes INP bedeutet fast immer, dass der Hauptthread des Browsers mit schwerem JavaScript beschäftigt ist. Der Benutzer tippt — aber in diesem Moment verarbeitet der Thread Analysen, steuert einen Slider oder rendert ein Widget, und die Reaktion wird verzögert. Was hilft:

  • Teilen Sie lange Aufgaben in kurze auf, damit der Browser Pausen hat, um Klicks zu verarbeiten.
  • Entfernen oder verzögern Sie Drittanbieter-Skripte, die im Hintergrund arbeiten.
  • Vermeiden Sie schwere Handler bei jeder Bewegung und jedem Tastendruck.
  • Bewegen Sie optionale Berechnungen aus dem Moment der Interaktion heraus.

Wie man Layoutverschiebungen (CLS) entfernt

CLS wird durch Markup-Disziplin geheilt. Die Hauptregeln:

  1. Setzen Sie immer Breite und Höhe (oder Seitenverhältnis) für Bilder und Videos, damit im Voraus Platz reserviert wird.
  2. Reservieren Sie Platz für Banner, Widgets und Anzeigenplätze, anstatt sie den Inhalt zu verschieben, wenn sie erscheinen.
  3. Laden Sie Schriftarten so, dass der Austausch der Systemschrift durch eine benutzerdefinierte Schriftart den Text nicht verschiebt (korrekte Schriftanzeige und Fallback-Metriken).
  4. Fügen Sie niemals Inhalte über das ein, was der Benutzer bereits sieht – nur darunter.

Zahlungen und Formulare sind ein spezieller Schmerzpunkt. Bei unserem Payora-Zahlungsdienstprojekt haben wir die Stabilität des ersten Bildschirms besonders genau beobachtet: Wenn Geld im Spiel ist, verringern ein springendes Layout und eine langsame Schaltflächenreaktion direkt das Vertrauen und die Anzahl der abgeschlossenen Transaktionen.

Die größten Ursachen für eine langsame Website

Gute Nachrichten: Langsame Seiten haben wenige Ursachen, und sie sind überraschend typisch. In neun von zehn Fällen ist jemand auf dieser Liste schuld.

Schwere Bilder

Das absolute Schwergewicht der Seitengröße. Fotos in voller Auflösung, mehrmegabyte große PNG-Screenshots, Bilder, die der Browser auf eine kleine Größe verkleinert, aber in voller Größe herunterlädt. Oft ist das Bild auch das LCP-Element, was einen doppelten Schlag bedeutet.

Schriftarten

Mehrere Gewichte in schweren Formaten, von einer externen Domain geladen, ohne Vorabladung – und der Text flackert entweder oder erscheint spät, wodurch das Layout verschoben wird.

Blockierendes CSS und JavaScript

Riesige Bündel, die heruntergeladen und ausgeführt werden müssen, bevor der erste Paint erfolgt. Schwere Frameworks sind besonders verschwenderisch, wo ein paar Zeilen Code ausreichen würden.

Drittanbieter-Skripte

Chats, Pixel, ein Dutzend Analytik-Tags, soziale Widgets, A/B-Tests. Jedes ist für sich leicht, aber zusammen belasten sie den Hauptthread und ruinieren INP. Dies ist die am meisten unterschätzte Kategorie.

Langsame Hosting und hohe TTFB

Wenn der Server einen Moment lang nachdenkt, kann keine Front-End-Magie das vollständig verbergen. Günstiges überlastetes Hosting, kein Server-Cache, schwere Datenbankabfragen – all das liegt der LCP zugrunde.

Die praktische Erkenntnis: Eile nicht, alles auf einmal zu beheben. Messen Sie zuerst, finden Sie Ihre Hauptursache für Verluste – und konzentrieren Sie sich darauf.

Bildoptimierung: Formate und Lazy Loading

Da Bilder die Schwergewichte sind, beginnt die Geschwindigkeitsoptimierung fast immer dort. Dies ist der schnellste, sichtbarste Gewinn mit dem geringsten Risiko.

Moderne Formate

Wechseln Sie zu WebP, und wo möglich zu AVIF. Bei vergleichbarer Qualität wiegen sie deutlich weniger als klassische JPEG- und PNG-Dateien. Für Icons und einfache Grafiken verwenden Sie SVG: es ist vektorbasiert, schwerelos und auf jedem Bildschirm perfekt scharf.

Korrekte Größe und Responsivität

Serviere niemals ein Bild, das breiter ist, als es tatsächlich angezeigt wird. Bereite mehrere Größen vor und verwende srcset, damit ein Handy eine kompakte Version und ein Desktop eine große erhält. Ein 4000-Pixel-Hero in einem 800-Pixel-Container sind verschwendete Megabytes und Sekunden.

Lazy Loading — aber weise

  • Fügen Sie loading="lazy" für Bilder unterhalb des ersten Bildschirms, damit sie das anfängliche Rendering nicht stören.
  • Lade jedoch das LCP-Bild des ersten Bildschirms sofort und mit Priorität — Lazy Loading schadet hier nur.
  • Setze immer die Abmessungen, damit Lazy Loading keine Layoutverschiebungen verursacht (dasselbe CLS).

Und vergiss die Kompression nicht. Das Durchlaufen von Assets durch einen anständigen Optimierer reduziert oft 40–70% des Gewichts, ohne sichtbaren Qualitätsverlust. Für Inhaltsseiten sind das buchstäblich kostenlose Sekunden.

Schriften, kritisches CSS und überflüssiges JavaScript

Nach Bildern ist der zweitwichtigste Bereich der Code, den der Browser verarbeiten muss, bevor die Seite angezeigt wird. Die meisten render-blockierenden Probleme verstecken sich hier.

Schriftarten

  • Halte die minimale Anzahl an Schriftarten — zwei sind oft genug.
  • Verwende woff2 und stelle Schriftarten von deiner eigenen Domain bereit.
  • Preload die Schlüssel-Schriftart für den ersten Bildschirm.
  • Setze font-display: swap, damit der Text sofort lesbar ist, anstatt auf die Schriftart zu warten.

Kritisches CSS

Die Idee ist einfach: Die Stile, die für den ersten Bildschirm benötigt werden, sind direkt in das HTML eingebettet, und der Rest des CSS wird später geladen. So malt der Browser den oberen Teil der Seite, ohne auf das gesamte Stylesheet zu warten. Entferne auch tote Regeln — im Laufe der Jahre sammelt eine Seite viele davon an.

Weniger JavaScript

Die ehrlichste Optimierung besteht darin, nicht zu laden, was du entbehren kannst. Überprüfe, ob du ein schweres Framework für ein paar Effekte lädst. Verzögere sekundäre Skripte mit verschieben und asynchron, teile das Bundle auf und lade den Code nach Bedarf. Überprüfe separat Drittanbieter-Widgets: jeder Chat, jedes Pixel und jedes Tag muss seinen Platz im Leistungsbudget rechtfertigen. Wir haben behandelt, wie dies mit mehrsprachigen Seiten zusammenpasst, ohne die Seite aufzublähen, in unserem Artikel über die mehrsprachige Seite und SEO.

Caching, CDN, HTTP/2 und Hosting

Die Front-End-Optimierung stößt an eine Grenze, wenn das Fundament — der Server und die Auslieferung — langsam ist. Diese Punkte zahlen sich auf jeder Seite gleichzeitig aus.

Caching

Es funktioniert auf zwei Ebenen.Server-Cacheverhindert, dass eine schwere Seite wiederholt regeneriert wird, und senkt direkt die TTFB.Browser-Cache(korrekte Cache-Control-Header für statische Assets) bedeutet, dass bei Rückbesuchen Bilder, Schriftarten und Skripte nicht erneut heruntergeladen werden.

CDN

Ein Content Delivery Network liefert statische Assets vom geografisch nächstgelegenen Server an den Benutzer. Je weiter Ihr Publikum vom Ursprung entfernt ist, desto stärker ist der Effekt: Die Latenz sinkt und das erste Byte kommt schneller an.

HTTP/2, HTTP/3 und Kompression

  • Aktivieren Sie ein modernes Protokoll (HTTP/2 oder HTTP/3) – es lädt Dutzende kleiner Dateien parallel effizienter.
  • Aktivieren Sie die Kompression von Textressourcen (Brotli oder gzip) auf dem Server.
  • Minifizieren Sie HTML, CSS und JS, indem Sie Leerzeichen und Kommentare entfernen.

Hosting und TTFB

Ein angemessener Server ist kein Luxus, sondern eine Grundvoraussetzung. Bei dem geschäftigen 24freelance-Marktplatzprojekt haben wir genau die Serverebene erreicht: Ohne Caching und Abfrageoptimierung kam das erste Byte nur langsam, und keine Menge an Bildbearbeitung erreichte die Zielzahlen, bis wir das Backend in Ordnung brachten.

Geschwindigkeit auf mobilen Geräten

Eine wichtige Wahrheit von 2026: Google bewertet Ihre Website hauptsächlich nach ihrer mobilen Version, und der Großteil des Traffics kommt von Handys. Und ein Handy bedeutet einen schwächeren Prozessor, ein weniger stabiles Netzwerk und weniger Geduld vom Benutzer.

Warum Mobilgeräte strenger sind

Was auf einem leistungsstarken Laptop sofort läuft, dauert auf einem durchschnittlichen Smartphone mehrere Male länger. Schweres JavaScript trifft INP besonders hart auf Mobilgeräten, genau weil der Prozessor schwächer ist und jede Aufgabe länger benötigt.

Was tun

  • Testen Sie mit einem gedrosselten Gerät und einer langsamen Netzwerkemulation, nicht nur auf Ihrem Flaggschiff.
  • Gestalten Sie die Bedienelemente groß genug und reservieren Sie im Voraus Platz, um versehentliche Berührungen und Verschiebungen zu vermeiden.
  • Schneiden Sie Drittanbieter-Skripte besonders stark — ihre Kosten auf Mobilgeräten sind mehrere Male höher.
  • Liefern Sie Bilder in mobiler Größe, nicht Desktop-Bilder, die vom Browser verkleinert wurden.

Die gute Nachricht: Wenn eine Seite auf einem durchschnittlichen Telefon über ein mittelmäßiges Netzwerk schnell ist, wird sie fast sicher auch auf dem Desktop schnell sein. Optimieren Sie also für das schlechteste realistische Szenario, nicht für Ihren Arbeitsmonitor.

Überwachung und fortlaufende Kontrolle

Geschwindigkeit ist kein einmaliges Projekt, sondern eine Form der Hygiene. Eine Seite lebt: Inhalte werden hinzugefügt, neue Widgets und Banner kommen, der Code wird aktualisiert — und die Leistung verschlechtert sich leise. Ohne Überwachung erfahren Sie von einem Problem durch sinkende Verkaufszahlen, nicht durch einen Bericht.

Wie man den Puls im Auge behält

  • Überprüfen Sie regelmäßig die Core Web Vitals im Google Search Console — es zeigt den echten Trend für Ihr Publikum.
  • Richten Sie automatisierte Überprüfungen der wichtigsten Vorlagen ein, um Rückschritte direkt nach einer Veröffentlichung zu erfassen, nicht einen Monat später.
  • Setzen Sie ein Leistungsbudget — eine Obergrenze für das Seitengewicht und die Anzahl der Skripte, die das Team nicht überschreiten darf.
  • Behandeln Sie jedes neue Drittanbieter-Skript als eine separate Entscheidung: was es dem Unternehmen bringt und was es an Geschwindigkeit kostet.

Wer überwacht es

In der Praxis hilft es, eine Person für die Geschwindigkeit verantwortlich zu machen — andernfalls wird die Kennzahl zu niemandem und sinkt zuerst. Wenn Sie keine solche Person im Team haben, kann die Rolle ausgelagert werden: wir übernehmen beispielsweise regelmäßige Audits und Leistungsunterstützung, was am einfachsten zu organisieren ist über unser Kontaktformular.

Die Kernidee: Messen Sie vor und nach jeder größeren Änderung. Die Behauptung, dass die Dinge schneller geworden sind, sollte bewiesen und nicht nur gefühlt werden.

Eine praktische Checkliste zur Website-Geschwindigkeit

Lassen Sie uns alles in einer angewandten Liste zusammenfassen. Arbeiten Sie sie von oben nach unten durch — die Punkte sind grob nach Verhältnis von Effekt zu Aufwand sortiert. Sie müssen nicht alles auf einmal erledigen, aber jeder Punkt ist es wert, überprüft zu werden.

Messen und priorisieren

  1. Messen Sie Ihre wichtigen Vorlagen in PageSpeed Insights (mobil und Desktop) und protokollieren Sie die aktuellen Core Web Vitals.
  2. Finden Sie das LCP-Element jeder wichtigen Vorlage und ihren Hauptengpass.

Bilder

  1. Konvertieren Sie Bilder in WebP oder AVIF und Icons in SVG.
  2. Liefern Sie responsive Größen über srcset, niemals größer als der Container.
  3. Aktivieren Sie das Lazy Loading unterhalb des ersten Bildschirms; laden Sie das LCP-Bild mit Priorität.
  4. Setzen Sie die Bildabmessungen so, dass es keine Layoutverschiebungen gibt.

Code und Schriftarten

  1. Inline den kritischen CSS und laden Sie den Rest später.
  2. Reduzieren Sie die Schriftgewichte, fügen Sie Preload hinzu und verwenden Sie font-display: swap.
  3. Verschieben Sie Skripte mit defer/async und entfernen Sie ungenutztes CSS und JS.
  4. Überprüfen Sie Drittanbieter-Widgets und löschen Sie alles Überflüssige.

Server und Lieferung

  1. Aktivieren Sie das Server-Caching und senken Sie TTFB.
  2. Richten Sie das Browser-Caching für statische Assets und Brotli/gzip-Kompression ein.
  3. Fügen Sie ein CDN und ein modernes Protokoll, HTTP/2 oder HTTP/3, hinzu.
  4. Minifizieren Sie HTML, CSS und JS.

Kontrolle

  1. Überprüfen Sie das Ergebnis in einer gedrosselten Emulation eines Mobilgeräts.
  2. Richten Sie die Überwachung von Feldmetriken und ein Leistungsbudget ein.
  3. Vor und nach dem Messen erneut messen — den Gewinn in Zahlen festhalten.

Arbeiten Sie ehrlich durch diese Checkliste und Sie erhalten nicht nur eine schöne Punktzahl, sondern auch eine schnellere, stabilere und profitablere Website. Und das ist letztendlich der Punkt.

Häufig gestellte Fragen

Was sind Core Web Vitals in einfachen Worten?

Es sind drei Google-Metriken, die die tatsächliche Ladeerfahrung messen: LCP (wie schnell der Hauptinhalt erscheint), INP (wie schnell die Website auf Aktionen reagiert) und CLS (wie stabil das Layout ist und ob es springt). Sie werden von echten Chrome-Nutzern gesammelt und als Ranking-Signal verwendet.

Welche Ladezeit wird 2026 als gut angesehen?

Zielen Sie auf die Schwellenwerte der Core Web Vitals ab: LCP etwa 2,5 Sekunden oder weniger, INP unter 200 Millisekunden und CLS unter 0,1. Und messen Sie dies beim 75. Perzentil echter Nutzer auf Mobilgeräten, nicht unter idealen Laborbedingungen auf einem Desktop.

Beeinflusst die Geschwindigkeit der Website die Suchrankings?

Ja, Core Web Vitals sind ein offizieller Ranking-Faktor. Geschwindigkeit wird starken Inhalten nicht überlegen sein, aber wenn Seiten in der Qualität nahe beieinander liegen, wird sie zum entscheidenden Tiebreaker. Eine schnelle Website wird auch effizienter gecrawlt und bietet eine bessere Benutzererfahrung.

Wie unterscheiden sich Labordaten von Felddaten?

Labordaten (Lighthouse) sind eine Messung unter kontrollierten Bedingungen, die sich gut zum Debuggen eignet und wiederholbar ist. Felddaten (CrUX) werden von echten Nutzern gesammelt und sind das, was für das Ranking tatsächlich verwendet wird. Die Regel ist einfach: Optimieren Sie im Feld, debuggen Sie im Labor.

Was bremst eine Website am häufigsten aus?

Schwere, unkomprimierte Bilder, nicht optimierte Schriftarten, render-blockierendes CSS und JavaScript, eine Fülle von Drittanbieter-Skripten (Chats, Pixel, Tags) und langsames Hosting mit hoher TTFB. In den meisten Fällen sind ein oder zwei Ursachen verantwortlich – finde sie mit Messungen.

Wo sollte ich anfangen, eine Website mit begrenzten Ressourcen zu beschleunigen?

Zuerst messen und die Hauptquelle des Verlusts finden. Der schnellste, risikoärmste Gewinn ist normalerweise die Bildbearbeitung: moderne Formate, responsive Größen und Lazy Loading unterhalb des ersten Bildschirms. Danach kommen kritisches CSS, verzögertes JavaScript und ein Server-Cache.