Web
Audits
  • Performance
  • SEO
  • Accessibility
  • Sustainability
  • Web Development
  • Web-Performance

    Seitengeschwindigkeit: Warum jede Sekunde zählt

    Eine langsame Website kostet mehr, als man denkt – durch verlorene Besucher, schlechtere Rankings, mangelnde Barrierefreiheit und einen höheren Energieverbrauch. Dieser Post erklärt, was Seitengeschwindigkeit bzw. Page Speed eigentlich ist, warum sie wichtig ist, wie man sie misst und wovon sie beeinflusst wird.

    Web Audits 11 Min. Lesezeit
    Lade-Icon einer Website
    OpenClipart / CC0

    Was ist Seitengeschwindigkeit?

    Die Seitengeschwindigkeit (Page Speed) beschreibt, wie schnell eine Webseite geladen und für einen Besucher nutzbar wird. Sie ist mehr als die reine Ladezeit – sie beinhaltet auch, wie schnell der Browser die ersten relevanten Inhalte anzeigt, wie schnell ein Besucher mit der Seite interagieren kann und wie stabil das Layout während des Ladens bleibt.

    Google hat hierfür drei Schlüsselmetriken definiert, die sogenannten Core Web Vitals:

    MetrikWas sie misstGuter Schwellenwert
    LCP (Largest Contentful Paint)Wie schnell der Hauptinhalt lädtUnter 2,5 Sekunden
    INP (Interaction to Next Paint)Wie schnell die Seite auf Klicks oder Eingaben reagiertUnter 200 Millisekunden
    CLS (Cumulative Layout Shift)Wie stark das Layout während des Ladens hin und her springtWert unter 0,1

    INP hat im März 2024 die ältere Metrik FID (First Input Delay) ersetzt. Sie liefert ein genaueres Bild davon, wie eine Seite auf echte Nutzerinteraktionen reagiert.


    Warum die Seitengeschwindigkeit für die Nutzererfahrung wichtig ist

    Besucher sind ungeduldig. Je länger eine Seite zum Laden braucht, desto höher ist die Wahrscheinlichkeit, dass jemand abspringt, bevor er überhaupt etwas sieht. Gemäss Daten von Google steigt die Absprungwahrscheinlichkeit drastisch an, wenn die Ladezeit von einer auf drei Sekunden steigt.

    Eine schnelle Website sorgt für einen besseren ersten Eindruck und hält die Nutzer bei der Stange. Eine langsame Website vertreibt sie – oft noch bevor sie Ihre Inhalte überhaupt gesehen haben.

    Geschwindigkeit beeinflusst auch das Vertrauen. Eine träge Seite kann unzuverlässig oder veraltet wirken, selbst wenn der Inhalt selbst hochwertig ist.


    Seitengeschwindigkeit und SEO

    Google hat bestätigt, dass die Core Web Vitals Teil seiner Ranking-Signale sind. Sie sind jedoch nicht der wichtigste Faktor – Inhaltsqualität, Relevanz und Autorität fallen nach wie vor deutlicher ins Gewicht.

    Betrachten Sie die Core Web Vitals als das Zünglein an der Waage. Wenn zwei Seiten eine ähnliche Inhaltsqualität aufweisen, rankt die schnellere Seite tendenziell höher. Sobald alle drei Metriken den Schwellenwert „Gut“ erreichen, führen weitere Geschwindigkeitsverbesserungen wahrscheinlich zu keinen spürbaren Ranking-Vorteilen mehr.

    Einige wichtige Nuancen:

    • Nur echte Nutzerdaten (Felddaten) beeinflussen das Ranking – nicht die Lighthouse-Scores oder Labordaten aus PageSpeed Insights.
    • Google bewertet die Core Web Vitals für Mobilgeräte und Desktop separat, wobei die mobile Performance aufgrund der Mobile-First-Indexierung mehr Gewicht hat.
    • Sie müssen alle drei Metriken bestehen, um zu profitieren. Zwei von drei Punkten zu erfüllen, zählt nicht.
    • Es dauert etwa 28 Tage, bis sich Verbesserungen in den Rankings widerspiegeln.

    Seitengeschwindigkeit und Barrierefreiheit

    Diese Verbindung wird oft übersehen. Eine langsame Website stellt echte Barrieren für Nutzer dar, die auf assistive Technologien angewiesen sind.

    Screenreader beispielsweise beginnen unter Umständen mit dem Vorlesen einer Seite, bevor diese vollständig geladen ist – was zu Verwirrung führt und die Navigation erschwert. Nutzer mit kognitiven Beeinträchtigungen wie ADHS oder Legasthenie sind ebenfalls stärker von langsamen oder instabilen Layouts betroffen. Verzögerungen erhöhen die kognitive Belastung und stören die Konzentration.

    Geschwindigkeit ist auch eine Form von Zugangsgerechtigkeit. Nutzer auf älteren Geräten, mit geringerer Bandbreite oder in Regionen der Welt mit langsameren Mobilfunknetzen sind überproportional von langsamen Seiten betroffen. Eine schwere, unoptimierte Website kann diese Nutzer effektiv ausschliessen.

    Seitengeschwindigkeit ist nicht nur ein Performance-Thema – es ist ein Thema der Inklusion.

    Technisch gesehen ist die Seitengeschwindigkeit unabhängig von den WCAG (Web Content Accessibility Guidelines), dem internationalen Standard für digitale Barrierefreiheit. In der Praxis sind beide jedoch eng miteinander verknüpft: Eine schnelle, stabile und gut strukturierte Seite ist für jeden einfacher zu bedienen, auch für Menschen mit Behinderungen.


    Wie man die Seitengeschwindigkeit misst

    Es gibt zwei Arten von Daten:

    Labordaten – synthetische Tests, die in einer kontrollierten Umgebung durchgeführt werden. Nützlich für die Diagnose spezifischer Probleme. Sie haben keinen direkten Einfluss auf die Google-Rankings.

    Felddaten (CrUX) – echte Messungen von realen Nutzern, die über Chrome erfasst werden. Dies sind die Daten, die Google für Ranking-Zwecke heranzieht.

    Die wichtigsten Tools:

    • PageSpeed Insights – zeigt sowohl Labor- als auch Felddaten für einzelne Seiten an. Kostenlos und einfach zu bedienen.
    • Google Search Console – zeigt die Core Web Vitals für Ihre gesamte Website basierend auf echten Nutzerdaten an. Unerlässlich für Website-Betreiber.
    • WebPageTest – detaillierte technische Analyse, besonders nützlich für Entwickler.
    • GTmetrix – laborbasiertes Tool mit Wasserfalldiagrammen. Gut geeignet, um langsame Ressourcen aufzuspüren.
    • Lighthouse – in die Chrome DevTools integriert. Läuft lokal und deckt Performance, Barrierefreiheit, SEO und mehr in einem einzigen Bericht ab.

    Ein praktischer Workflow: Nutzen Sie die Google Search Console, um Seiten mit schlechten Werten zu identifizieren, verwenden Sie dann PageSpeed Insights oder Lighthouse, um die Ursachen zu verstehen, und greifen Sie für tiefere Analysen auf WebPageTest zurück.


    Wie Ihr Tech-Stack die Seitengeschwindigkeit beeinflusst

    Die Wahl der Plattform, des Frameworks und des Hostings hat einen massiven Einfluss darauf, wie schnell eine Website sein kann – und wie viel Aufwand nötig ist, um dieses Ziel zu erreichen. Es gibt keine universell „beste“ Option. Jeder Ansatz bringt Kompromisse mit sich.

    Statische Website-Generatoren

    Statische Website-Generatoren (SSGs) wie Eleventy, Hugo oder Astro erstellen alle Seiten zum Zeitpunkt des Deployments und stellen sie als reine HTML-Dateien bereit, meist über ein CDN. Es gibt keine Datenbankabfrage oder serverseitiges Rendering bei jedem einzelnen Aufruf.

    Vorteile: Von Haus aus schnell. Geringe Hosting-Kosten (Netlify, Vercel und Cloudflare Pages bieten oft großzügige kostenlose Tarife). Minimale Angriffsfläche – kein serverseitiger Code, der ausgenutzt werden könnte. Hervorragende Core Web Vitals mit minimalem Optimierungsaufwand.

    Nachteile: Nicht ideal für häufig aktualisierte Inhalte oder Websites, bei denen technisch nicht versierte Redakteure unabhängig Inhalte veröffentlichen müssen. Das Hinzufügen dynamischer Funktionen (Nutzerkonten, Suche, E-Commerce) erfordert Dienste oder APIs von Drittanbietern. Bei sehr großen Websites können die Build-Zeiten lang werden.

    Am besten geeignet für: Marketing-Websites, Dokumentationen, Portfolios, Blogs mit unregelmäßigen Updates.

    Traditionelle CMS-Plattformen

    Ein dynamisches CMS wie WordPress, Drupal oder Joomla generiert Seiten bei jedem Aufruf neu: Der Server führt PHP aus, fragt eine Datenbank ab, stellt das HTML zusammen und liefert es aus. Dies verlängert die Verarbeitungszeit im Vergleich zur Bereitstellung einer statischen Datei.

    Die Performance variiert enorm und hängt stark von der Qualität des Hostings, der Wahl des Themes sowie der Anzahl und Qualität der Plugins oder Erweiterungen ab. Laut den Daten des HTTP Archive vom November 2025 weichen die Erfolgsquoten bei den Core Web Vitals zwischen den Plattformen stark voneinander ab – von rund 50 % bei WordPress bis zu 87 % bei Duda –, wobei diese Zahlen auch die sehr unterschiedlichen Website-Typen widerspiegeln, die mit den jeweiligen Plattformen betrieben werden.

    Vorteile: Riesige Ökosysteme an Themes und Plugins. Nicht-technische Redakteure können Inhalte ohne Entwicklerhilfe veröffentlichen. Gut geeignet für komplexe Websites mit vielen Inhaltstypen, E-Commerce oder Mitgliederbereichen.

    Nachteile: Von Haus aus langsamer – erfordert Caching, CDN-Einrichtung und kontinuierliche Optimierung. Die Performance kann mit zunehmender Anzahl an Plugins sinken. Regelmäßige Wartung ist erforderlich (Sicherheitsupdates, Plugin-Kompatibilität).

    Am besten geeignet für: inhaltsreiche Websites, E-Commerce, Organisationen, bei denen Redakteure Inhalte unabhängig verwalten.

    Die häufigsten Geschwindigkeitsprobleme bei CMS-basierten Seiten: überladene Themes, zu viele Plugins, fehlendes Caching und unterdimensioniertes Shared Hosting. Die Behebung dieser vier Punkte löst den Großteil aller Probleme.

    JavaScript-Frameworks

    Moderne JavaScript-Frameworks bieten mehr Flexibilität und bei richtigem Einsatz eine hervorragende Performance. Sie sind jedoch nicht für jeden Anwendungsfall gleichermassen geeignet, und ihr Standardverhalten ist der Seitengeschwindigkeit nicht immer dienlich.

    Next.js ist das am weitesten verbreitete React-basierte Framework. Es unterstützt verschiedene Rendering-Strategien, was es für eine Vielzahl von Websites flexibel macht. Bei richtigem Einsatz lassen sich damit starke Core Web Vitals erzielen. Der Kompromiss ist ein relativ grosses JavaScript-Bundle, wenn es nicht sorgfältig optimiert wird.

    React Router v7 verfolgt einen anderen Ansatz. Es konzentriert sich auf Server-Rendering und Progressive Enhancement – Seiten funktionieren auch ohne JavaScript, bevor clientseitiger Code ausgeführt wird. Dies führt tendenziell zu schnelleren initialen Ladezeiten und besseren LCP-Werten, insbesondere bei langsameren Verbindungen. Es ist eine starke Wahl für Websites, bei denen es auf Performance und Ausfallsicherheit ankommt. webaudits.org basiert auf React Router v7 und wird über AWS-Cloud-Dienste bereitgestellt.

    Astro (bereits oben unter SSGs erwähnt) unterstützt mehrere Frameworks wie React, Vue und Svelte, liefert JavaScript jedoch nur für interaktive Komponenten aus – der Rest ist reines HTML. Dieser „Islands“-Ansatz hält die Bundles klein und gehört zu den performancefreundlichsten Optionen auf dem Markt.

    Preact ist eine leichtgewichtige Alternative zu React mit einer weitgehend kompatiblen API, aber einer etwa zehnmal kleineren Bundle-Grösse (ca. 3 KB gegenüber 45 KB). Es ist eine praktische Option, wenn Sie das Komponentenmodell von React nutzen möchten, ohne dessen Gewicht in Kauf zu nehmen – nützlich, um ansonsten schlanken Seiten Interaktivität hinzuzufügen oder wenn es auf jedes Kilobyte ankommt.

    Vue, Svelte und SolidJS sind weitere Alternativen mit unterschiedlichen Kompromissen bei Bundle-Grösse, Entwicklererfahrung und Reife des Ökosystems. Insbesondere Svelte und SolidJS kompilieren zu sehr kleinem, effizientem Code ohne den Overhead eines virtuellen DOMs.

    Ein grober Vergleich:

    Framework / AnsatzGeschwindigkeit ab WerkTechnische KomplexitätAm besten geeignet für
    Statischer Website-GeneratorExzellentNiedrig–MittelInhaltsseiten, Blogs, Dokumentationen
    WordPress + OptimierungGut (mit Aufwand)Niedrig–MittelCMS-gestützte Seiten, E-Commerce
    Next.jsGutMittelFull-Stack-Apps, große Websites
    React Router v7Sehr gutMittelServer-gerenderte Apps, Formulare
    AstroExzellentMittelInhaltslastig, partielle Interaktivität
    PreactExzellent (wenn schlank)MittelSchlanke UIs, ergänzende Interaktivität

    Kein Framework ist von Haus aus schnell, wenn man unvorsichtig damit umgeht. Schwere Drittanbieter-Skripte, grosse, unoptimierte Bilder und zu viel clientseitiges JavaScript können jeden Stack ausbremsen. Das Framework setzt die Obergrenze – was Sie daraus machen, bestimmt das tatsächliche Ergebnis.


    Verbraucht eine schnellere Website weniger Energie?

    Ja – allerdings mit gewissen Nuancen.

    Jeder Seitenaufruf verbraucht Energie: auf dem Server, im Netzwerk und auf dem Gerät des Besuchers. Eine schwerere Seite (mehr Daten, mehr Anfragen, mehr Rechenaufwand) verbraucht über die gesamte Kette hinweg mehr Energie.

    Digitale Technologien verursachen rund 4 % der weltweiten Treibhausgasemissionen, wobei der Energieverbrauch in diesem Sektor um etwa 9 % pro Jahr steigt. Rechenzentren allein machen fast 3 % des weltweiten Stromverbrauchs aus – ein Wert, der mit dem der Luftfahrtindustrie vergleichbar ist.

    Schnellere Websites sind meist effizienter, weil:

    • Ein geringeres Seitengewicht bedeutet, dass weniger Daten über das Netzwerk übertragen werden.
    • Weniger Serververarbeitung bedeutet weniger CPU-Zyklen im Rechenzentrum.
    • Schnelleres Rendering bedeutet, dass das Gerät des Besuchers weniger Arbeit leisten muss.

    Der CO2-Ausstoss einer Website pro Seitenaufruf kann mit Tools wie dem Website Carbon Calculator oder Ecograder geschätzt werden.

    Die Geschwindigkeitsoptimierung allein greift jedoch zu kurz. Die Energiequelle eines Hostings ist ebenso wichtig. Eine langsame Website, die zu 100 % mit erneuerbaren Energien betrieben wird, kann einen kleineren CO2-Fussabdruck haben als eine schnelle Website in einem mit Kohlekraft betriebenen Rechenzentrum. Die Green Web Foundation führt ein Verzeichnis von Hosting-Anbietern, die sich zu grüner Energie bekennen.

    Beide Faktoren zusammen – eine schlanke, schnelle Seite auf einem grünen Hosting – erzielen die grösste Wirkung.


    Bedeutet teures Hosting automatisch eine bessere Seitengeschwindigkeit?

    Nicht automatisch. Aber es bedeutet meistens mehr Optionen.

    Bei günstigem Shared Hosting teilt sich Ihre Website einen Server mit Hunderten oder Tausenden anderen Seiten. Bei Traffic-Spitzen werden die Ressourcen aufgeteilt, was die Antwortzeiten erheblich verschlechtern kann.

    Der Wechsel zu Managed Hosting, einem VPS (Virtual Private Server) oder einem Cloud-Infrastruktur-Anbieter verbessert in der Regel die Serverantwortzeit (TTFB) und ermöglicht bessere Konfigurationen. Diese Umgebungen bieten typischerweise schnellere Hardware, integriertes Caching sowie CDN-Anbindung.

    Teures Hosting kompensiert jedoch keine unoptimierte Website. Eine überladene, skriptlastige Installation wird auch auf einer Premium-Infrastruktur schlecht abschneiden. Das Hosting ist das Fundament – es beseitigt Engpässe, ersetzt aber keine Frontend-Optimierung, Bildkomprimierung oder effizienten Code.

    Bei Websites, die auf statischen Frameworks basieren und über CDN-Plattformen (Vercel, Netlify, Cloudflare Pages) bereitgestellt werden, sind Hosting-Kosten und Geschwindigkeit weitgehend voneinander entkoppelt – diese Plattformen sind konstruktionsbedingt schnell und bei niedrigem bis mittlerem Traffic oft kostenlos.


    Seitengeschwindigkeit aus zwei Perspektiven

    Für Webentwickler

    Seitengeschwindigkeit ist eine technische Disziplin. Entwickler sind verantwortlich für:

    • Die Wahl effizienter Architekturen – statisch, wo es sinnvoll ist, Server-Rendering, wo nötig, und Caching.
    • Das Schreiben von effizienten Code – blockierende Ressourcen vermeiden, JavaScript-Payloads klein halten und das richtige Framework für den Job wählen.
    • Die Optimierung von Assets – Bilder komprimieren, korrekt dimensionieren und moderne Formate wie WebP oder AVIF verwenden.
    • Kontinuierliches Monitoring – Die Geschwindigkeit kann im Laufe der Zeit abnehmen, wenn neue Inhalte oder Abhängigkeiten hinzukommen.

    Ein oft unterschätztes Problem: Performance-Entscheidungen, die früh in einem Projekt getroffen werden (Plattformwahl, Framework, Drittanbieter-Skripte), lassen sich später nur schwer rückgängig machen. Es ist weitaus einfacher, eine Website von Anfang an schnell aufzubauen, als eine langsame nachträglich zu reparieren. Das Testen auf Mobilgeräten unter simulierten langsamen Netzwerkbedingungen – und nicht nur auf einem schnellen Desktop-Rechner – sollte ein fester Bestandteil des Entwicklungsprozesses sein.

    Für Website-Betreiber

    Man muss die technischen Details nicht im Einzelnen verstehen, aber man sollte wissen, worauf man achten und was man einfordern muss.

    Einige praktische Tipps:

    • Website regelmässig überprüfen mit PageSpeed Insights. Das ist kostenlos und dauert nur 30 Sekunden.
    • Entwickler fragen, welche Core-Web-Vitals-Werte für das Projekt angestrebt werden, und die Zusicherung, dass die „Gut“-Schwellenwerte von Google erreicht werden.
    • Vorsicht mit Page-Buildern und Premium-Themes – viele sind optisch beeindruckend, bringen aber enormes Gewicht mit sich.
    • Jedes Skript, das hinzugefügt wird, kostet Performance. Marketing-Pixel, Chat-Widgets, Cookie-Banner und A/B-Testing-Skripte verlangsamen die Seite. Reduce to the max.
    • Ihr Hosting ist wichtig. Wenn die Website auf einem günstigen Shared-Hosting-Tarif läuft, ist ein Upgrade oft die effektivste Stellschraube.

    Seitengeschwindigkeit ist keine einmalige Angelegenheit. Sie erfordert kontinuierliche Aufmerksamkeit, insbesondere nach dem Hinzufügen neuer Inhalte, Plugins oder Funktionen.

    Häufig gestellte Fragen

    Antworten auf häufige Fragen zur Seitengeschwindigkeit – sowohl für Website-Betreiber als auch für Entwickler.