Ein Praxisbericht aus unserem Engineering-Team: die elf Gründe, warum Firmenwebsites 2026 wirklich langsam sind — nach Häufigkeit sortiert, mit der konkreten Lösung, die wir für jeden Fall anwenden.

Eine langsame Website ist nie nur "eine langsame Website". Sie ist das Ergebnis vieler kleiner, langweiliger Entscheidungen, die sich über zwei oder drei Jahre aufaddiert haben — bis die Startseite auf einem Mittelklasse-Smartphone neun Sekunden zum Laden braucht und niemand im Team die Person sein möchte, die sich darum kümmert.

Dieser Beitrag ist ein Praxisbericht. In den letzten Jahren wurden wir gerufen, um Websites zu auditieren und zu retten — Marketingseiten, Online-Shops, Buchungsplattformen, interne Admin-Panels — und immer wieder tauchen die gleichen elf Ursachen auf. Wir haben sie grob danach sortiert, wie oft sie der wahre Schuldige sind und wie viel Performance-Gewinn jede einzelne Korrektur typischerweise bringt.

Wenn Sie 2026 auf einer langsamen Seite sitzen, arbeiten Sie diese Liste von oben nach unten ab. Mit sehr hoher Wahrscheinlichkeit finden Sie Ihr Problem, bevor Sie das Ende erreichen.

1. Unoptimierte Hero- und Produktbilder

Was wir sehen: ein 4 MB großes PNG, das auf 400 Pixel Breite dargestellt wird. Ein Hero-Banner direkt aus Figma exportiert mit 3840 Pixeln Breite, auf einer Seite, die nie breiter als 1280 Pixel ist. Produktgalerien, die 12 Fotos in voller Auflösung pro Seite ohne Lazy Loading ausliefern.

Warum das langsam ist: Bilder machen in der Regel 60–80 % des Gewichts einer Seite aus. Auf Mobilverbindungen sind sie der mit Abstand größte Grund, warum sich "Zeit bis zur sichtbaren Darstellung" schmerzhaft anfühlt.

Die Lösung:

• Liefern Sie Bilder in WebP oder AVIF aus, mit einem PNG/JPEG-Fallback nur, wenn Sie noch sehr alte Browser unterstützen müssen.
• Nutzen Sie die Attribute srcset und sizes, damit der Browser die passende Größe für den Viewport herunterlädt.
• Skalieren Sie beim Build oder über ein Bild-CDN — nicht per CSS.
• Setzen Sie loading="lazy" auf jedes Bild, das nicht above the fold liegt, und fetchpriority="high" auf das LCP-Bild.
• Führen Sie im CMS eine harte Regel ein: nichts über 300 KB wird veröffentlicht. Und setzen Sie sie durch.

Richtig umgesetzt reduziert allein diese Korrektur das Seitengewicht regelmäßig um 70 % und spart 2–4 Sekunden beim mobilen Laden.

2. Renderblockierendes JavaScript durch Third-Party-Tags

Was wir sehen: die Startseite lädt fünf Analytics-Skripte, zwei A/B-Testing-Tools, ein Chat-Widget, einen Consent-Manager, einen Heatmap-Tracker und ein Legacy-Tag, an das sich niemand mehr erinnert. Jedes einzelne blockiert das Rendering, bis es antwortet.

Warum das langsam ist: jedes synchrone Skript im Head ist eine Mautstation auf dem Weg zum ersten Bild. Third-Party-Tags sind besonders schmerzhaft, weil Sie weder ihre Server noch ihre Antwortzeiten kontrollieren.

Die Lösung:

• Auditieren Sie Ihre Tags. Öffnen Sie die Seite, schauen Sie sich im DevTools-Waterfall jedes aufgerufene Fremd-Domain an und listen Sie es auf. Alles, was nicht aktiv genutzt wird, fliegt raus.
• Laden Sie den Rest mit async oder defer, oder besser noch über einen serverseitigen Tag-Manager, damit Skripte nur dann laden, wenn sie wirklich gebraucht werden.
• Verschieben Sie Consent-Manager und Chat-Widget so, dass sie nach dem Hauptinhalt laden, nicht davor.
• Wenn das Skript eines Anbieters das Rendering blockiert und er sich weigert, das zu ändern, kostet Sie dieser Anbieter Geld. Ersetzen Sie ihn.

3. Ungenutztes CSS und JavaScript aus dem Theme

Was wir sehen: eine 600 KB große CSS-Datei aus einem Theme oder Page-Builder, von der die Startseite vielleicht 40 KB nutzt. Ein gebündeltes JS-File, das den Code für jede Komponente auf jeder Seite enthält.

Warum das langsam ist: der Browser muss das Ganze herunterladen, parsen und ausführen, bevor er rendern kann. Auf einem günstigen Android-Gerät bedeutet das mehrere Sekunden blockierte Haupt-Thread-Zeit.

Die Lösung:

• Nutzen Sie einen Bundler (Vite, Webpack, esbuild), der Tree-Shaking und Code-Splitting unterstützt.
• Inline das kritische CSS für den oberen Seitenbereich, alles andere wird verzögert geladen.
• Separate Bundles pro Route, damit der Blog nicht den Checkout-Code mitlädt und umgekehrt.
• Bei Templates oder Page-Buildern: prüfen Sie, ob ein Modus "ungenutztes CSS entfernen" existiert. Fast alle haben einen. Schalten Sie ihn ein.

4. Kein Caching oder falsch konfiguriertes Caching

Was wir sehen: jeder Besucher trifft auf PHP. Jede PHP-Anfrage trifft auf die Datenbank. Statische Assets werden mit Cache-Control: no-cache ausgeliefert, weil jemand mal debuggt hat und den Header nie zurückgesetzt hat.

Warum das langsam ist: der Server erledigt für jeden Besucher die gleiche Arbeit noch einmal. Das CDN kann nicht helfen, weil die Origin ihm sagt, nicht zu cachen.

Die Lösung:

• Setzen Sie vernünftige Cache-Control-Header für statische Assets: public, max-age=31536000, immutable für gehashte Dateinamen und kürzere Fenster für Bilder, die sich ändern.
• Cachen Sie das gerenderte HTML für nicht eingeloggte Besucher. Die meisten Marketingseiten müssen nicht pro Anfrage neu erzeugt werden.
• Schalten Sie ein echtes CDN vor die Seite (Cloudflare, Bunny, Fastly) und konfigurieren Sie es so, dass es am Edge cached.
• Für dynamische Inhalte: denken Sie über einen Object-Cache (Redis, Memcached) für teure Abfragen nach.

5. Datenbank-N+1-Abfragen auf der Startseite

Was wir sehen: die Startseite zeigt 8 Featured-Produkte. Im Hintergrund laufen 1 Abfrage für die Produktliste, dann 1 Abfrage pro Produkt für den Preis, 1 pro Produkt für den Lagerbestand, 1 pro Produkt für das Hauptbild — 33 Abfragen, wo 2 oder 3 reichen würden.

Warum das langsam ist: jede Abfrage ist ein Roundtrip. Bei einer entfernten Datenbank können 30 Roundtrips leicht 300 ms reine Netzwerklatenz sein, bevor irgendeine Logik läuft.

Die Lösung:

• Aktivieren Sie Query-Logging in der Entwicklung und zählen Sie die Abfragen pro Seite. Wenn die Zahl mit der Anzahl der angezeigten Zeilen skaliert, haben Sie ein N+1-Problem.
• Nutzen Sie Eager Loading (with() in Laravel, select_related oder prefetch_related in Django, include in Prisma).
• Setzen Sie die richtigen Indizes. Ein fehlender Index auf einem Foreign Key ist eine sehr häufige Ursache für eine "langsame" Seite, die in Wirklichkeit funktionierender Code auf einem kaputten Schema ist.
• Cachen Sie den gerenderten Block, nicht nur die Abfrage.

6. Aufgeblähte Fonts und Icon-Bibliotheken

Was wir sehen: die Seite lädt sechs Font-Gewichte von Google Fonts, obwohl sie nur zwei nutzt. Sie zieht sich die komplette Font-Awesome-Bibliothek (60.000+ Icons), um ein Telefon, einen Umschlag und einen Pfeil anzuzeigen.

Warum das langsam ist: Fonts blockieren standardmäßig das Rendering. Jedes zusätzliche Gewicht ist ein zusätzlicher Download, und die gesamte Icon-Bibliothek muss ankommen, bevor das erste Icon sichtbar wird.

Die Lösung:

• Hosten Sie Fonts selbst, liefern Sie sie als WOFF2 aus und preloaden Sie die Fonts, die above the fold verwendet werden.
• Subsetten Sie Fonts auf die tatsächlich genutzten Zeichen — für Seiten mit reiner Latin-Schrift spart das typischerweise 70 % Dateigröße.
• Ersetzen Sie Icon-Bibliotheken durch inline SVG für die 10 bis 20 Icons, die Sie wirklich brauchen.
• Fügen Sie font-display: swap hinzu, damit Text sofort mit einer Fallback-Schrift gerendert wird, während der Webfont lädt.

7. Hosting, das zu klein, zu weit weg oder beides ist

Was wir sehen: eine Seite mit deutschen Kunden, die auf einem Shared-Server in einem US-Rechenzentrum liegt. Eine PHP-Anwendung auf einem Vier-Euro-Plan, die 20.000 monatliche Besucher bedient. Ein VPS mit 1 GB RAM, auf dem MySQL, PHP-FPM und ein Headless-CMS gleichzeitig laufen.

Warum das langsam ist: Netzwerklatenz ist Physik. Ein Roundtrip über den Atlantik dauert rund 80 ms, bevor irgendetwas anderes passiert. Und wenn der Server aus Speichermangel auf die Festplatte auslagert, ist jede Anfrage katastrophal langsam.

Die Lösung:

• Hosten Sie in der Region, in der die Mehrheit Ihrer Nutzer sitzt. Bei mehreren Regionen nutzen Sie ein CDN mit Edge-Compute zumindest für das gecachte HTML.
• Dimensionieren Sie den Server auf den Spitzenverkehr, nicht auf den Durchschnitt. Achten Sie auf Speicherdruck, nicht nur auf CPU.
• Für WordPress-, PHP-, Laravel- oder Rails-Seiten: stellen Sie sicher, dass OPcache beziehungsweise Opcode-Caching in Produktion tatsächlich aktiviert ist. Das ist nicht immer der Standard.

8. Zu viele Weiterleitungen, besonders verkettete

Was wir sehen: http → https → www → trailing-Slash — drei Weiterleitungen, bevor die eigentliche Seite lädt.

Warum das langsam ist: jede Weiterleitung ist ein vollständiger Roundtrip. Auf einer langsamen mobilen Verbindung können das 1 bis 2 Sekunden Wartezeit mit leerem Bildschirm sein.

Die Lösung:

• Entscheiden Sie sich für einen kanonischen Host (www oder ohne www, mit HTTPS) und leiten Sie alles in einem einzigen Sprung am Edge dorthin um.
• Pflegen Sie eine Redirect-Map für Legacy-URLs, aber verflachen Sie Ketten. Jede alte URL sollte per 301 direkt auf ihr endgültiges Ziel zeigen.
• Führen Sie mindestens einmal im Jahr einen Crawl durch (Screaming Frog, Sitebulb oder die Analytics Ihres CDNs), um eingeschlichene Ketten zu finden.

9. Übergewichtige Single-Page-Apps für überwiegend statische Inhalte

Was wir sehen: eine Marketingseite, komplett als clientseitig gerenderte React-App gebaut, die 700 KB JavaScript ausliefert und auf dem Handy vier Sekunden bis zum ersten Rendering braucht — für Seiten mit zwei Buttons und einem Kontaktformular.

Warum das langsam ist: der Browser lädt die App-Shell herunter, parst und führt das JS aus, holt Daten und rendert dann. Suchmaschinen sehen einen Spinner. Nutzer in schlechten Mobilfunknetzen sehen sekundenlang einen leeren Bildschirm.

Die Lösung:

• Für überwiegend statische Inhalte (Marketing, Blog, Dokumentation) nutzen Sie Static-Site-Generation oder Server-Rendering. Next.js, Astro, Nuxt, Remix, Laravel mit Blade — alles gute Optionen.
• Liefern Sie zuerst HTML. Hydrieren Sie nur die Teile, die Interaktivität brauchen — sogenannte "Islands"-Architektur.
• Behalten Sie SPAs für die Teile Ihres Produkts, die wirklich eine App sind: Dashboards, Editoren, mehrstufige Flows.

10. Fehlendes oder kaputtes Core-Web-Vitals-Budget

Was wir sehen: niemand im Team weiß, wie hoch der Largest Contentful Paint der Startseite ist oder wo das Budget für Cumulative Layout Shift liegen sollte. Neue Features werden ohne Messung ausgeliefert. Die Performance driftet langsam nach unten, bis das Problem offensichtlich ist.

Warum das langsam ist: ohne Budget bringt jedes neue Widget, jeder Tracker, jede Hero-Animation etwas mehr Gewicht mit. Ein Jahr "nur ein kleines bisschen" summiert sich zu einer kompletten Neuentwicklung.

Die Lösung:

• Setzen Sie explizite Budgets: LCP unter 2,5 Sekunden auf mobil, INP unter 200 ms, CLS unter 0,1, Gesamtseitengewicht unter 1,5 MB.
• Lassen Sie Lighthouse oder WebPageTest in CI bei jedem Pull-Request laufen. Build bricht, wenn das Budget gerissen wird.
• Schalten Sie Real User Monitoring ein, damit Sie die tatsächliche Nutzererfahrung sehen, nicht nur synthetische Laborwerte. Beide widersprechen sich oft — und die Nutzer haben immer recht.

11. Legacy-Code, den niemand anfassen will

Was wir sehen: ein Teil der Seite, der "schon immer langsam war". Eine Report-Seite, die 12 Sekunden braucht. Eine Admin-Suche, die die komplette Tabelle in den Speicher lädt. Alle haben gelernt, damit zu leben, weil die letzte Person, die es reparieren wollte, etwas anderes kaputt gemacht hat.

Warum das langsam ist: oft ist es ein naiver Algorithmus (quadratisch, wo linear reicht), eine Abfrage ohne Index, ein Skript, das eine komplette Datei einliest statt sie zu streamen, oder ein Report, der bei jedem Aufruf aus Rohdaten neu rechnet, statt Zwischenergebnisse zu cachen.

Die Lösung:

• Behandeln Sie das langsame Stück als vollwertiges Feature, nicht als lästige Pflicht. Geben Sie ihm einen Owner, schreiben Sie Tests um das aktuelle Verhalten, refaktorieren Sie dann unter dem Schutz der Tests.
• In 80 % der Fälle ist die Lösung ein einzelner Index, ein einzelner Cache oder ein einzelnes umgeschriebenes Query. Eine komplette Neuentwicklung ist selten nötig.
• Fangen Sie nicht mit der Neuentwicklung an. Fangen Sie mit der Messung an.

Das ehrliche Fazit

Websites werden nicht wegen eines dramatischen Fehlers langsam. Sie werden langsam, weil niemand misst, niemand das Budget hütet, und jede Woche ein neues Bild, ein neues Skript oder ein neues Plugin hinzugefügt wird, ohne dass jemand eine Frage stellt.

Wenn Sie Ihre Website 2026 wirklich schnell machen wollen, ist die Reihenfolge einfach:

• Messen Sie mit echten Werkzeugen (Lighthouse, WebPageTest, RUM). Finden Sie heraus, wo Sie tatsächlich stehen.
• Beheben Sie die großen Brocken zuerst — Bilder, Third-Party-Skripte, Datenbankabfragen. Diese liefern in der Regel 80 % des Gewinns.
• Setzen Sie ein Budget und verteidigen Sie es. Alles, was Gewicht hinzufügt, muss seine Existenz rechtfertigen.
• Automatisieren Sie die Prüfung so, dass der nächste Rückschritt in CI auffällt und nicht erst in Produktion.

Die meisten Seiten, die wir retten, brauchen keine Neuentwicklung. Sie brauchen einen sorgfältigen Durchgang durch diese Liste, ein wenig Engineering-Disziplin und jemanden, dem wirklich wichtig ist, wie sich die Seite auf einem Mittelklasse-Android-Handy in einer schlechten Verbindung auf einem Parkplatz anfühlt.

Wenn Sie vor einer Seite sitzen und nicht wissen, wo Sie anfangen sollen, fangen Sie bei den Bildern an. Sie werden überrascht sein, wie weit Sie damit allein schon kommen.

Möchten Sie Hilfe dabei, Ihre Seite anhand dieser Liste zu auditieren? Genau das ist die Arbeit, die unser Engineering-Team täglich macht — schreiben Sie uns über die Kontaktseite und wir geben Ihnen eine ehrliche Einschätzung.

Original Source: Warum Ihre Firmenwebsite 2026 langsam ist: die 11 echten Ursachen (und wie Sie jede davon beheben)