Warum ist meine Website so langsam? Die echten Ursachen und wie du sie behebst

Kurz gesagt: die üblichen Verdächtigen, sortiert

Die meisten langsamen Websites sind aus denselben paar Gründen langsam, und deinen findest du in der Regel in der Liste unten. Die grössten Verbesserungen bringen fast immer zu grosse Bilder und Drittanbieter-Skripte, die du längst vergessen hast. Fang dort an und arbeite dich nach unten. Ein einmaliger Speed-Test auf deinem eigenen Rechner führt dich in die Irre, deshalb ist der letzte und wichtigste Schritt, die Geschwindigkeit zu messen, die deine tatsächlichen Besucher auf ihren eigenen Handys und Netzen erleben.

• Schwere Bilder und Medien. Unkomprimierte Fotos und überdimensionierte Dateien sind die Ursache Nummer eins für langsames Laden. Komprimieren, verkleinern und moderne Formate nutzen.
• Zu viele Drittanbieter-Skripte. Chat-Widgets, Werbe-Pixel, A/B-Tools und schwere Analytics kosten jeweils ihren Tribut. Das summiert sich schnell.
• Render-blockierendes CSS und JavaScript. Der Browser bleibt an Ressourcen hängen, die er laden muss, bevor er überhaupt etwas anzeigen kann. Verschiebe alles, was nicht sofort gebraucht wird.
• Langsames Hosting ohne Caching oder CDN. Billiges Shared Hosting und fehlendes Caching bedeuten, dass jeder Besucher auf einen langsamen Ursprungsserver wartet.
• Verfehlte Core Web Vitals. Selbst eine 'schnelle' Website kann sich holprig anfühlen, wenn Inhalte herumspringen oder Buttons nicht reagieren. Das sind die Werte, die Google und deine Nutzer bemerken.
• Das Falsche messen. Ein Laborwert auf einem schnellen Rechner ist nicht die Geschwindigkeit, die deine echten Besucher bekommen. Beobachte echte Nutzer, um den langsamen Pfad zu finden, der dich tatsächlich Geld kostet.

Schwere Bilder und Medien

Wenn deine Website langsam ist, sind Bilder der erste Ort, an dem du nachschauen solltest. Ein einzelnes Hero-Foto, das direkt aus einem Handy oder Design-Tool exportiert wurde, kann drei oder vier Megabyte gross sein. Stapel ein paar davon auf einer Seite, und du hast eine Website gebaut, die auf dem Handy kriecht, egal wie sauber dein Code ist.

Die Lösung hat drei Teile. Erstens: Bilder auf die Grösse verkleinern, in der sie tatsächlich angezeigt werden. Ein Foto, das 600 Pixel breit dargestellt wird, muss nicht 4000 Pixel breit sein. Zweitens: komprimieren. Tools und Build-Pipelines können die meisten Bilder um die Hälfte oder mehr verkleinern, ohne sichtbaren Qualitätsverlust. Drittens: moderne Formate wie WebP oder AVIF nutzen, die bei gleicher Qualität dramatisch kleiner sind als alte JPEGs und PNGs.

Zwei weitere günstige Verbesserungen: Lade Bilder unterhalb des sichtbaren Bereichs verzögert (Lazy Loading), damit der Browser sie erst holt, wenn der Besucher in ihre Nähe scrollt, und gib Bildern immer eine explizite Breite und Höhe, damit die Seite beim Laden nicht herumspringt. Letzteres ist wichtiger, als es klingt, und wir kommen darauf zurück, wenn wir über Core Web Vitals sprechen.

Mit Videos verhält es sich genauso, nur schlimmer. Wenn du sie unbedingt brauchst, hoste sie auf einer Plattform, die für Streaming gebaut ist, und lade den Player erst, wenn jemand mit ihm interagiert.

Zu viele Drittanbieter-Skripte (die versteckte Steuer)

Das ist die Ursache, die sich vor aller Augen versteckt. Über ein Jahr hinweg sammelt eine Website still und leise ein Chat-Widget, ein Heatmap-Tool, einen A/B-Test-Snippet, zwei Werbe-Pixel, ein Cookie-Banner, einen Font-Loader und ein Analytics-Tag oder drei an. Jedes einzelne wirkte harmlos, als du es hinzugefügt hast. Zusammen sind sie oft das Schwerste auf der Seite und das Langsamste, weil sie Server kontaktieren, die du nicht kontrollierst.

Drittanbieter-Skripte sind aus zwei Gründen eine Steuer. Sie fügen Bytes hinzu, die heruntergeladen und verarbeitet werden müssen, und sie fügen Netzwerk-Roundtrips zu anderen Domains hinzu, die selbst langsam sein können. Ein einziges träges Marketing-Tag kann den Rest deiner Seite daran hindern, interaktiv zu werden, und diese externen Server kannst du in der Regel nicht schneller machen, also bleibt dir nur der Hebel, das Skript zu entfernen oder zu verzögern.

Prüfe, was du hast. Öffne das Netzwerk-Panel deines Browsers, lade die Seite und sortiere nach Domain. Mit ziemlicher Sicherheit findest du Anfragen an Dienste, die du vergessen oder vor Monaten nicht mehr genutzt hast. Lösche alles, was du nicht aktiv brauchst. Den Rest lädst du asynchron oder erst, nachdem die Seite interaktiv ist, und du ziehst eine leichtere Alternative in Betracht. Die schwersten Übeltäter sind selten die, die du erwarten würdest.

Eine gute Gewohnheit: Behandle jedes neue Skript als Kosten, nicht als kostenlose Zugabe. Bevor du einen Snippet in deine Website einfügst, frag dich, ob er sein Gewicht wert ist. Wenn du ein neues Projekt aufsetzt, hilft dir ein kurzer Blick auf eine Checkliste für den Website-Start, nicht fünf Tools anzuschrauben, die du später wieder herausreissen musst.

Render-blockierendes CSS und JavaScript

Selbst mit schlanken Bildern und wenigen Skripten kann sich eine Seite langsam anfühlen, weil der Browser die Dinge in einer bestimmten Reihenfolge erledigt. Wenn der Browser im Head deiner Seite auf ein Stylesheet oder ein Skript stösst, muss er oft anhalten, diese Datei herunterladen und verarbeiten, bevor er überhaupt etwas auf dem Bildschirm anzeigen kann. Genau diese Pause erleben Besucher als leere, weisse Seite.

Das Ziel ist, den Browser so früh wie möglich etwas Nützliches anzeigen zu lassen. Binde das bisschen CSS, das nötig ist, um den zuerst sichtbaren Bereich ('above the fold') darzustellen, direkt inline ein und lade den Rest danach. Bei JavaScript nutzt du die Attribute defer oder async, damit Skripte das erste Rendern nicht blockieren, und du teilst grosse Bundles auf, damit der Browser nur den Code lädt, den eine bestimmte Seite wirklich braucht.

Moderne Frameworks und Website-Baukästen erledigen vieles davon für dich, aber nicht alles. Schriften sind ein häufiger Übeltäter: Eine eigene Web-Schrift, die das Anzeigen von Text blockiert, lässt Besucher ins Leere starren oder verursacht ein Flackern, wenn der Text einspringt. Sag dem Browser, dass er sofort Ersatztext anzeigen soll, während die Schrift lädt. Kleine Änderung, echter Unterschied.

Hosting, Caching und ein CDN

Manchmal ist die Seite selbst in Ordnung und der Server dahinter ist das Problem. Bei günstigem Shared Hosting sitzt deine Website auf einer Maschine mit Hunderten anderen, und wenn eine davon beschäftigt ist, werden alle langsamer. Das erste Byte deiner Seite kann eine Sekunde oder länger brauchen, bevor überhaupt irgendetwas anderes beginnt. Wenn deine Time-to-First-Byte dauerhaft langsam ist, rettet dich auch keine Bildkomprimierung der Welt.

Caching ist hier die Lösung mit dem grössten Hebel. Ein Cache speichert eine fertige Kopie deiner Seiten, damit der Server sie nicht bei jeder Anfrage von Grund auf neu aufbauen muss. Bei einer Content-Website oder einem Blog kann Full-Page-Caching aus einem trägen Ursprung etwas machen, das nahezu sofort antwortet. Die meisten Plattformen und Content-Management-Systeme haben Caching eingebaut oder nur ein Plugin entfernt.

Ein Content Delivery Network (CDN) ist der andere grosse Hebel. Ein CDN hält Kopien deiner statischen Dateien (Bilder, CSS, JavaScript) auf Servern rund um die Welt, sodass ein Besucher in Sydney aus einer nahen Stadt lädt, statt darauf zu warten, dass Bytes von deinem Ursprung in Frankfurt über einen Ozean reisen. Für ein globales Publikum kann allein das die Ladezeit spürbar verkürzen, und wenn dein Hosting keines enthält, lassen sich viele CDNs kostenlos starten.

Und bevor das alles überhaupt eine Rolle spielt, muss der Server erst einmal erreichbar sein. Eine Website, die offline ist, ist unendlich langsam, und Ausfälle passieren gern zu den ungünstigsten Zeiten, ohne dass es jemand stundenlang bemerkt. Wenn du dir noch nie Gedanken darüber gemacht hast, was dein Hosting eigentlich garantiert, erklären unsere Notizen zur Website-Verfügbarkeit, warum sich eine Reihe kleiner Ausfälle still und leise zu weit mehr verlorener Zeit summiert, als die meisten Betreiber annehmen. Den Moment zu kennen, in dem dein Ursprung dunkel wird oder langsam zu antworten beginnt, ist das Fundament unter allem anderen hier.

Core Web Vitals in einfachen Worten

Google misst die Geschwindigkeit einer Website über eine Reihe von Werten namens Core Web Vitals, und sie tauchen in der Suche und im Chrome-Erlebnisbericht auf. Es lohnt sich, sie zu verstehen, weil sie eng abbilden, was ein echter Besucher tatsächlich spürt, und nicht nur die reine Downloadzeit. Es gibt drei davon, und die Schwellenwerte sind öffentlich auf web.dev einsehbar.

Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das grösste sichtbare Element (meist dein Hero-Bild oder die Überschrift) fertig geladen ist. Ziel sind unter 2,5 Sekunden. Interaction to Next Paint (INP) misst, wie schnell die Seite reagiert, wenn jemand tippt oder klickt, mit einem Ziel unter 200 Millisekunden. Cumulative Layout Shift (CLS) misst, wie stark die Seite beim Laden herumspringt, und du willst ihn unter 0,1 halten. Die vollständigen Definitionen liest du auf der offiziellen Core-Web-Vitals-Seite.

Im Klartext: LCP ist 'wie schnell ist die Seite erschienen', INP ist 'wie schnell reagiert sie, wenn ich sie berühre', und CLS ist 'blieb das Layout an seinem Platz oder ist der Button gerade verrutscht, als ich tippen wollte'. Dieser CLS hängt direkt mit Bildern ohne Massangaben und spät ladender Werbung zusammen, weshalb es so wichtig ist, Bildern eine Breite und Höhe zu geben. Falls dir hier ein Begriff neu ist, erklärt das Glossar die gängigen an einem Ort.

Zwei der drei drehen sich um Reaktionsfähigkeit und Stabilität, nicht nur um die Downloadgeschwindigkeit. Genau das verbirgt ein einzelner Lighthouse-Durchlauf auf deinem Laptop in der Regel, was uns zum wichtigsten Abschnitt bringt.

Labordaten lügen: beobachte deine echten Nutzer

Hier ist der Haken, der die meiste Arbeit an der Geschwindigkeit untergräbt. Wenn du ein Tool wie Lighthouse laufen lässt und einen glänzenden Wert bekommst, ist das ein Labortest: eine Seite, ein schneller Rechner, eine stabile Verbindung, einmal ausgeführt. Deine echten Besucher sind ganz anders. Sie sind auf Mittelklasse-Handys, im Hotel-WLAN, im Zug, mit einem Dutzend Hintergrund-Tabs offen. Die Geschwindigkeit, die sie bekommen, kann sich gewaltig von dem unterscheiden, was dein Laptop meldet, und ein Skript, das bei dir gut lädt, könnte genau das sein, was alle anderen ausbremst.

Deshalb reicht ein einzelner Wert, so grün er auch sein mag, nicht aus. Der einzige Weg, die Geschwindigkeit zu kennen, die Menschen tatsächlich erleben, ist, sie von deren Seite aus zu messen, auf deren Geräten und Netzen, und das fortlaufend. Wenn du die Geschwindigkeit beobachten kannst, die echte Besucher bekommen, hörst du auf, für eine Zahl zu optimieren, die sonst niemand sieht, und fängst an, den langsamen Pfad zu beheben, der dich Besucher kostet: die Seite, die auf deinem Rechner flott ist, aber auf einem Handy hängt, das Skript, das über Glasfaser in Ordnung ist, aber im Mobilfunknetz alles blockiert.

Der einfachste Anfang ist die grundlegendste Frage von allen: Antwortet die Website gerade überhaupt, und wie schnell? Du kannst eine Verlangsamung nicht beheben, von der du nie erfährst, und Ausfälle und langsame Antworten bleiben gern stundenlang unbemerkt. Ein bisschen Uptime-Monitoring, das deinen Ursprung nach einem Zeitplan prüft, sagt dir, wenn die First-Byte-Zeiten ansteigen oder der Server verstummt, was das Fundament unter jeder anderen Lösung in diesem Beitrag ist.

Sobald du echte Nutzer beobachtest, ändert sich die Arbeit. Statt einem perfekten Laborwert hinterherzujagen, achtest du auf die Seiten und Geräte, bei denen die Geschwindigkeit einbricht, behebst diese und bestätigst, dass die Lösung für echte Menschen gehalten hat. Für einen umfassenderen Rahmen, was du verfolgen solltest und warum, behandelt unser Leitfaden zu Best Practices für Web-Analytics, wie du Geschwindigkeits- und Verhaltensdaten mit Ergebnissen verknüpfst, die zählen.