Website schneller machen: eine praktische Checkliste

Um eine Website schneller zu machen, misst du sie zuerst mit PageSpeed Insights und behebst dann die größte Ursache, die dort angezeigt wird. Meist sind das zu große Bilder, zu viel JavaScript, schwere Schriften oder Drittanbieter-Skripte. Ziel sind Googles „guten“ Core-Web-Vitals-Werte: Hauptinhalt sichtbar in 2,5 Sekunden, Reaktion auf Tipper in 200 Millisekunden und kaum Springen des Layouts. Die meisten Websites erreichen das mit einer Handvoll Änderungen, ohne Neuschreiben.

Vor jeder Änderung messen

Raten kostet Zeit. Zwei kostenlose Werkzeuge reichen fast allen:

• PageSpeed Insights (pagespeed.web.dev): Füge eine live erreichbare URL ein. Es zeigt Felddaten echter Chrome-Nutzer (wenn deine Seite genug Besuche hat) und Labordaten aus einem simulierten Laden sowie eine Liste konkreter Probleme.
• Lighthouse in den Chrome-Entwicklerwerkzeugen: derselbe Labortest, auf jeder Seite, die du öffnen kannst, auch auf einer Vorschau. Teste im mobilen Modus; bei langsameren Netzen zeigen sich Probleme am deutlichsten.

Die wichtigen Zahlen sind Googles Core Web Vitals. Stand September 2026 nennt Googles Dokumentation auf web.dev diese „guten“ Schwellenwerte, gemessen am 75. Perzentil der Seitenaufrufe:

INP hat 2024 die ältere Metrik First Input Delay ersetzt. Wenn ein Werkzeug noch FID meldet, ist es veraltet.

Notiere deine Ausgangswerte. Teste nach jeder Korrektur erneut, damit du weißt, was geholfen hat.

Wo die Zeit verloren geht: Optionen und Abwägungen

Jede häufige Ursache hat eine Lösung, und jede Lösung hat ihren Preis. Fang oben an: Das sind die günstigsten und häufigsten Punkte.

Bilder

Bilder sind das häufigste Problem und die einfachste Korrektur. Ein 4.000-Pixel-Foto, das mit 800 Pixeln Breite angezeigt wird, zwingt jeden Besucher, fünfmal mehr herunterzuladen, als er sieht.

• Liefere Bilder in der Größe, in der sie angezeigt werden, mit responsiven srcset-Größen für Smartphones und Desktops.
• Verwende moderne Formate (WebP oder AVIF) und sinnvolle Kompression.
• Setze width und height bei jedem Bild, damit der Browser Platz reserviert. Allein das behebt die meisten Layout-Verschiebungen.
• Lade Bilder unterhalb des sichtbaren Bereichs mit loading="lazy" nach.
• Lade das Hauptbild oben auf der Seite nie lazy. Googles LCP-Empfehlungen sind hier eindeutig: Lazy Loading des LCP-Bildes verzögert es immer. Gib ihm stattdessen fetchpriority="high".

JavaScript

Viele mit KI gebaute Websites sind Single-Page-Apps (SPAs): Der Browser lädt ein JavaScript-Bundle herunter und zeichnet dann die Seite. Je größer das Bundle, desto länger der leere Bildschirm. Die Korrekturen, nach Aufwand sortiert:

1. Entferne, was du nicht nutzt. Lass dir eine Liste der Abhängigkeiten geben und streiche Bibliotheken, die einmal hinzugefügt und dann vergessen wurden: eine Datumsbibliothek für ein einziges Datum, ein komplettes Icon-Paket für fünf Icons.
2. Teile nach Route auf. Lade den Code des Admin-Dashboards erst, wenn jemand es öffnet, nicht auf der Startseite.
3. Render öffentliche Seiten vor. Eine Marketingseite, die als echtes HTML ausgeliefert wird, erscheint, bevor JavaScript läuft. Das hilft auch Suchmaschinen; siehe SEO für mit KI gebaute Websites.

Ein schlechter INP-Wert bedeutet meist eine lange Aufgabe, die die Seite blockiert, etwa das Filtern einer riesigen Liste bei jedem Tastenanschlag oder das Neurendern einer ganzen Tabelle, wenn sich eine Zelle ändert. Das Performance-Panel der Chrome-Entwicklerwerkzeuge zeigt, was genau.

Schriften

Jede Schriftfamilie und jeder Schnitt ist eine weitere Datei. Zwei Familien mit drei oder vier Schnitten reichen meist. Lade die Schrift vor, die oberhalb des sichtbaren Bereichs genutzt wird, verwende font-display: swap, damit Text sofort erscheint, und hoste Schriften selbst, wenn der externe Schriftdienst für deine Besucher langsam ist.

Drittanbieter-Skripte

Chat-Widgets, Analysen, Heatmaps, Werbe-Pixel, eingebettete Videos und Social-Feeds laden Code von anderen Servern. Jeder wirkt klein; zusammen sind sie oft der langsamste Teil der Seite. Behalte nur die, die du tatsächlich anschaust. Lade den Rest, nachdem die Seite interaktiv ist, und ersetze schwere Einbettungen (ein YouTube-Player, eine Karte) durch eine leichte Vorschau, die erst beim Klick das eigentliche Element lädt.

Serverantwort

Time to First Byte (TTFB), also wie lange der Server braucht, um zu antworten, liegt unter allen anderen Metriken. Statische Seiten aus einem CDN (einem Netz von Servern nahe deinen Besuchern; siehe was ist ein CDN) sind fast überall schnell. Seiten, die bei jeder Anfrage von einem Server gebaut werden, hängen von diesem Server und seiner Datenbank ab. Caching für wiederholte Arbeit und Datenbankindizes für langsame Abfragen sind die üblichen Lösungen.

Prompts, die funktionieren

Sei konkret: Nenne Seite, Metrik und Randbedingung. Füge die Ergebnisse von PageSpeed Insights ein, falls du sie hast.

PageSpeed Insights meldet auf dem Smartphone für die Startseite einen LCP von 4,8 s, und das LCP-Element ist das Hero-Bild. Skaliere das Hero-Bild und wandle es nach WebP um, liefere responsive Größen, setze width und height, gib ihm fetchpriority="high" und stelle sicher, dass es nicht lazy geladen wird. Lade jedes Bild unterhalb des sichtbaren Bereichs lazy. Ändere das Design nicht.

Prüfe die Abhängigkeiten dieser App. Liste jedes Paket auf, was es nutzt und grob, wie viel es zum Bundle beiträgt. Entferne ungenutzte Pakete und teile die Routen /admin und /settings in getrennte Chunks auf, die nur beim Besuch geladen werden.

Das Suchfeld auf /products fühlt sich träge an. Verzögere den Filter (Debounce), vermeide das Neurendern der ganzen Liste bei jedem Tastenanschlag und paginiere oder virtualisiere die Liste, wenn sie mehr als 200 Einträge hat.

Schritt für Schritt

1. Teste die Live-Seite in PageSpeed Insights auf dem Smartphone. Notiere LCP, INP und CLS sowie die drei wichtigsten Probleme.
2. Behebe zuerst die Bilder: Größen, Formate, Maße, Lazy Loading unterhalb des sichtbaren Bereichs, Priorität für das Hero-Bild.
3. Entferne Drittanbieter-Skripte, die du nicht nutzt, und lade die übrigen später.
4. Kürze die Schriften auf das, was das Design braucht.
5. Verkleinere JavaScript: nicht genutzte Pakete entfernen, pro Route aufteilen.
6. Render öffentliche Seiten vor, wenn sie noch clientseitig gerendert werden und der LCP weiterhin langsam ist.
7. Prüfe den Server: Caching, Datenbankindizes, statisches Hosting für Inhalte, die sich selten ändern.
8. Veröffentliche neu und teste erneut. Die Felddaten in PageSpeed Insights aktualisieren sich über die folgenden Wochen, während echte Besuche eingehen. Beurteile frühe Ergebnisse deshalb anhand der Labordaten.

Häufige Fehler

• Nur auf einem schnellen Laptop testen. Deine Besucher nutzen Mittelklasse-Smartphones und wechselhaftes mobiles Internet. Teste im mobilen Modus.
• Einer perfekten 100 nachjagen. Der Laborwert ist ein Richtwert. Sobald die Core Web Vitals im guten Bereich liegen, zählen Inhalt und Bedienbarkeit mehr als die letzten Punkte.
• Alles lazy laden, auch das Hero-Bild. Das macht den LCP schlechter.
• Ein Speed-Plugin oder eine Bibliothek obendrauf setzen. Gewicht zu entfernen schlägt fast immer, zusätzlichen Code zu schreiben, um es zu verwalten.
• Die Vorschau optimieren, nicht die Live-Seite. Entwicklungsvorschauen laufen mit nicht optimierten Builds. Miss die veröffentlichte URL.
• Die Geschwindigkeit nur einmal korrigieren. Jedes neue Widget, Bild und Feature fügt Gewicht hinzu. Teste nach großen Änderungen erneut.

Checkliste Geschwindigkeit

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 auf dem Smartphone
• Bilder verkleinert, komprimiert, modernes Format, mit width und height
• Hero-Bild nicht lazy geladen; Bilder unterhalb des sichtbaren Bereichs lazy geladen
• Keine ungenutzten JavaScript-Bibliotheken; schwere Routen ausgelagert
• Zwei Schriftfamilien oder weniger, Hauptschrift vorgeladen
• Nur die Drittanbieter-Skripte, die du nutzt, und spät geladen
• Öffentliche Seiten vorgerendert oder statisch, wo möglich
• Nach dem Veröffentlichen auf der Live-URL erneut getestet

Geschwindigkeit und mobiles Layout gehören zusammen; siehe wie du eine Website mobil responsiv machst. Für eine vollständige Prüfung vor dem Start behandelt wie du einen KI-Prototyp in die Produktion bringst den Rest.

Geschwindigkeit auf Mythex

Auf Mythex nimmst du diese Änderungen im Chat vor oder im Code-Editor mit Pro. Prüfe die veröffentlichte URL und nicht die Vorschau, weil die Vorschau einen Entwicklungsserver nutzt. Statische Frontends werden beim Veröffentlichen als statische Seiten ausgeliefert (statische Websites), was sich für Inhaltsseiten eignet. Apps mit Server skalieren auf null: Sie schlafen, wenn sie untätig sind, und wachen beim nächsten Besuch auf. Die erste Anfrage nach einer ruhigen Phase ist daher langsamer, und eine angehängte Datenbank schläft nach 5 Minuten Inaktivität ein (Hosting-Limits). Wenn eine öffentliche Seite nur beim ersten Besuch langsam ist, ist das die wahrscheinliche Ursache. Statische Marketingseiten helfen. Veröffentliche nach Änderungen erneut und lade die Seite mit Hard-Refresh neu.

Fragen