Häufige Fragen
Häufig gestellte Fragen zur Performance-Optimierung
Von den Grundlagen der Ladezeit-Optimierung über Core Web Vitals bis zu Server-Konfiguration und laufendem Monitoring: Hier finden Sie fundierte Antworten auf die wichtigsten Fragen rund um Website-Performance.
Allgemeine Fragen zur PageSpeed-Optimierung
- Was genau ist PageSpeed-Optimierung? PageSpeed-Optimierung umfasst alle technischen Maßnahmen, die Ladezeit und Reaktionsfähigkeit einer Website verbessern. Sie betrifft zwei Ebenen: die serverseitige Optimierung mit Caching, Brotli-Komprimierung, PHP- und Datenbanktuning sowie die Frontend-Optimierung mit Bildkomprimierung, Critical CSS, JavaScript-Bundling und entschlackten Rendering-Pfaden. Beide Ebenen greifen ineinander: Ein schneller Server nützt wenig, wenn das Frontend ihn durch blockierende Skripte ausbremst. Wir betrachten Performance dabei nicht als einmalige Aktion, sondern als messbaren Zustand. Konkret bedeutet das, die Core Web Vitals (LCP, INP, CLS) auf gute Werte zu bringen und dort zu halten. Aus 50+ Projekten (Projekterfahrung) wissen wir: Der größte Hebel liegt fast immer dort, wo niemand ihn vermutet. Deshalb steht am Anfang jedes Projekts eine systematische Analyse statt blinder Standardmaßnahmen.
- Warum ist die Ladezeit meiner Website so wichtig? Ladezeit ist keine technische Spielerei, sondern wirkt direkt auf den Umsatz. Drei Kennzahlen reagieren besonders sensibel: Die Conversion-Rate sinkt mit jeder zusätzlichen Sekunde Ladezeit um bis zu 7 Prozent (Deloitte, 2020). Die Absprungrate steigt drastisch, weil 53 Prozent der mobilen Nutzer eine Seite verlassen, die länger als drei Sekunden lädt (Google, 2022). Und die Sichtbarkeit leidet, seit Google die Core Web Vitals 2021 als Rankingfaktor einführte. Das Tückische daran: Diese Verluste sind unsichtbar. Ein Besucher, der nach zwei Sekunden abspringt, hinterlässt keine Beschwerde, sondern fehlt einfach in der Statistik. Genau deshalb messen wir in der Performance-Analyse nicht nur Laborwerte, sondern auch die realen Felddaten Ihrer Besucher. Eine schnellere Website verbessert Nutzererlebnis, Umsatz und SEO-Rankings in einem Zug, ohne dass Sie an den Inhalten etwas ändern müssen.
- Was ist der Unterschied zwischen PageSpeed Insights und echtem Nutzererlebnis? PageSpeed Insights von Google liefert zwei grundverschiedene Datenarten, die oft verwechselt werden. Die Lab-Daten stammen aus einem synthetischen Test in einer kontrollierten Umgebung: ein standardisiertes Mittelklasse-Gerät, eine gedrosselte Netzwerkverbindung, ein einzelner Seitenaufruf. Sie sind reproduzierbar und ideal, um konkrete Probleme zu diagnostizieren. Die Felddaten aus dem Chrome User Experience Report (CrUX) hingegen bilden ab, wie Ihre echten Besucher die Seite erleben, über 28 Tage hinweg, mit ihren tatsächlichen Geräten, Netzen und Standorten. In der Praxis driften beide Werte häufig auseinander: Eine Seite kann im Labor langsam wirken, aber gute Felddaten haben, weil die realen Besucher auf schnellen Verbindungen zugreifen. Für Google zählt am Ende das Feld. Deshalb stützen wir jede Performance-Analyse auf beide Quellen, nutzen die Lab-Daten zur Ursachensuche und die Felddaten als Erfolgsmaßstab.
- Welchen PageSpeed-Score sollte meine Website erreichen? Ein Lighthouse-Score von 90 oder höher gilt als gut und signalisiert grüne Werte bei den wesentlichen Metriken. Der Score ist allerdings nur eine gewichtete Zusammenfassung aus mehreren Laborwerten und kann von Messung zu Messung schwanken. Wichtiger sind die einzelnen Core Web Vitals: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Diese Schwellen entscheiden darüber, ob Google Ihre Seite als schnell einstuft. Wir warnen ausdrücklich davor, den Score zum Selbstzweck zu machen. Eine Seite mit Score 85 und hervorragenden Felddaten ist besser aufgestellt als eine mit Score 98, deren reale Besucher auf langsamen Mobilgeräten lange warten. Unser Ziel ist daher immer ein stabil grüner Bereich in den Felddaten, der Lighthouse-Score folgt dem fast automatisch. Im Erstgespräch ordnen wir Ihren aktuellen Score realistisch ein.
- Wie lange dauert eine typische Performance-Optimierung? Die Dauer richtet sich nach Ausgangszustand und Umfang. Eine gezielte Frontend-Optimierung einer einzelnen Landingpage ist oft in wenigen Tagen abgeschlossen. Ein vollständiges Audit mit anschließender Umsetzung für eine komplexe Website dauert in der Regel zwei bis sechs Wochen, weil jede Änderung in einer Staging-Umgebung getestet und gemessen wird, bevor sie live geht. Bei Shopware-Shops mit tiefer Server-, Cache- und Plugin-Optimierung können umfangreichere Projekte vier bis acht Wochen beanspruchen, vor allem wenn Varnish-Konfiguration und Datenbank-Tuning hinzukommen. Wichtig: Erste messbare Verbesserungen liefern wir bewusst früh, indem wir mit den wirkungsvollsten Maßnahmen beginnen. Eine realistische Zeitschätzung für Ihren konkreten Fall erhalten Sie im kostenfreien Erstgespräch.
- Kann jede Website schneller gemacht werden? In unserer Erfahrung aus 50+ Projekten (Projekterfahrung) ließ sich bisher jede Website spürbar beschleunigen, der Spielraum unterscheidet sich aber stark je nach Ausgangslage. Eine WordPress-Seite mit unkomprimierten Bildern, einem aufgeblähten Page-Builder und blockierendem JavaScript lässt sich häufig um 60 bis 80 Prozent beschleunigen, weil hier viele offensichtliche Bremsen wirken. Eine bereits teiloptimierte Web-Applikation oder ein sauber gebauter Shop profitieren dagegen eher von gezielten Feinabstimmungen, etwa beim TTFB, bei der Hydration-Strategie oder beim Third-Party-Script-Management. Auch dort summieren sich kleine Gewinne zu einer deutlich besseren Nutzererfahrung. Welches Potenzial in Ihrer Website steckt, zeigt unsere systematische Analyse, bevor irgendeine Maßnahme umgesetzt wird.
Core Web Vitals im Detail
- Was sind Core Web Vitals und warum sind sie wichtig? Core Web Vitals sind drei von Google definierte Metriken, die die Nutzererfahrung aus unterschiedlichen Blickwinkeln messen. LCP (Largest Contentful Paint) erfasst, wie schnell der größte sichtbare Inhalt erscheint, also wann die Seite gefühlt geladen ist. INP (Interaction to Next Paint) misst, wie zügig die Seite auf Klicks, Tipps und Eingaben reagiert. CLS (Cumulative Layout Shift) bewertet, wie ruhig das Layout beim Laden bleibt, also ob Buttons unter dem Finger wegspringen. Seit Juni 2021 sind diese drei Werte ein bestätigter Rankingfaktor und damit für jede Website-Betreiberin relevant, nicht nur für SEO-Spezialisten. Sie übersetzen abstraktes Nutzerempfinden in messbare Zahlen, die sich gezielt verbessern lassen. Auf unserer Fachseite zu den Core Web Vitals erläutern wir jede Metrik im Detail und zeigen die typischen Ursachen schlechter Werte.
- Welche Schwellenwerte gelten für gute Core Web Vitals? Google teilt jede Metrik in drei Stufen ein. LCP gilt als gut unter 2,5 Sekunden, als verbesserungswürdig zwischen 2,5 und 4,0 Sekunden und als schlecht darüber. INP ist gut unter 200 Millisekunden, verbesserungswürdig bis 500 Millisekunden und schlecht darüber. CLS ist gut unter 0,1, verbesserungswürdig bis 0,25 und schlecht darüber. Diese Werte finden Sie auch in der Vergleichstabelle weiter unten auf dieser Seite. Entscheidend ist der oft übersehene Messpunkt: Bewertet wird das 75. Perzentil der realen Felddaten. Es zählt also der Wert, den die langsamsten 25 Prozent Ihrer Besucher gerade noch erleben, nicht der Durchschnitt. Eine Seite besteht erst dann, wenn alle drei Metriken gleichzeitig im grünen Bereich liegen. Genau hierauf richten wir jede Performance-Analyse aus.
- Wie stark beeinflussen Core Web Vitals das Google-Ranking? Core Web Vitals sind ein bestätigter Rankingfaktor, aber einer unter vielen. Google hat mehrfach betont, dass die inhaltliche Relevanz das mit Abstand stärkste Signal bleibt. Wer also auf Platz 30 steht, klettert nicht allein durch schnelle Ladezeiten nach oben. In der Praxis wirken die Vitals vor allem als Tie-Breaker: Bieten zwei Seiten ähnlich relevante Inhalte, bevorzugt Google die schnellere und nutzerfreundlichere. Gerade bei stark umkämpften Suchbegriffen kann dieser Unterschied über Platz 3 oder Platz 8 entscheiden, und damit über einen erheblichen Teil des Klick-Anteils. Aus unseren Projekten (Projekterfahrung) verbessern sich Websites nach umfassender Optimierung der Core Web Vitals typischerweise um zwei bis fünf Positionen bei relevanten Begriffen. Garantieren lässt sich das nie, weil das Ranking von vielen Faktoren abhängt, doch Performance ist einer der wenigen, die vollständig in Ihrer Hand liegen.
- Was hat INP mit der früheren Metrik FID zu tun? INP (Interaction to Next Paint) hat im März 2024 die ältere Metrik FID (First Input Delay) als Core Web Vital abgelöst. FID maß nur die Verzögerung der allerersten Interaktion und auch nur bis zum Reaktionsbeginn, nicht bis zum sichtbaren Ergebnis. Das war ein leicht zu bestehender Test, der wenig über das echte Bedienerlebnis aussagte. INP misst dagegen alle Interaktionen über den gesamten Seitenbesuch und meldet den schlechtesten Wert (abzüglich statistischer Ausreißer). Für die Optimierung verschiebt das den Fokus erheblich: Es reicht nicht, dass die Seite beim ersten Klick reagiert. Auch das Öffnen eines Menüs, das Filtern einer Produktliste oder das Absenden eines Formulars müssen flüssig bleiben. Wir analysieren dafür lange JavaScript-Tasks, die den Main-Thread blockieren, und brechen sie auf. Mehr zu diesem Thema auf der Seite zur Frontend-Optimierung.
- Warum ist mein CLS-Wert schlecht, obwohl die Seite schnell lädt? CLS misst etwas völlig anderes als die Ladegeschwindigkeit, nämlich die optische Stabilität. Eine Seite kann blitzschnell laden und trotzdem einen schlechten CLS-Wert haben, wenn Elemente nach dem ersten Rendern noch herumspringen. Typische Verursacher sind: Bilder und Videos ohne festes width/height-Attribut, nachgeladene Web-Fonts, die einen Schriftwechsel auslösen, dynamisch eingefügte Banner oder Cookie-Consent-Layer, die den Inhalt nach unten drücken, sowie Animationen, die Layout-Eigenschaften statt der GPU-freundlichen transform-Eigenschaft verändern. Das Heimtückische ist, dass diese Sprünge oft nur auf langsameren Verbindungen sichtbar werden, also genau dort, wo Sie beim eigenen Testen nicht hinschauen. Wir spüren in der Performance-Analyse jeden einzelnen Layout-Shift auf, ordnen ihn dem auslösenden Element zu und beheben die Ursache gezielt, etwa durch reservierten Platz für Bilder und Anzeigen oder vorgeladene Schriften.
- Wie verbessere ich den LCP-Wert meiner Website? Der LCP entsteht aus vier Phasen, die sich addieren. Erstens die Server-Antwortzeit (TTFB), gesenkt durch optimiertes Hosting, Caching und gegebenenfalls ein CDN. Zweitens render-blockierende Ressourcen wie unkritisches CSS und synchrones JavaScript, die das erste Zeichnen verzögern. Drittens die Ladezeit der LCP-Ressource selbst, meist ein großes Hero-Bild. Viertens die Renderzeit auf dem Client, die bei JavaScript-lastigen Frameworks ohne Server-Side-Rendering stark wachsen kann. In der Praxis liegt der größte Hebel fast immer in den ersten beiden Phasen. Wir senken die TTFB über die Server-Optimierung, liefern das LCP-Bild im modernen WebP- oder AVIF-Format aus und priorisieren es per Preload, damit der Browser es sofort lädt. Werden render-blockierende Skripte ausgelagert und Critical CSS inline eingebettet, sinkt der LCP häufig um mehr als die Hälfte (Projekterfahrung).
Technische Fragen zu Server und Frontend
- Welche Rolle spielt das Hosting für die Website-Performance? Das Hosting ist häufig der größte einzelne Hebel, weil es ganz am Anfang der Ladekette steht. Liefert der Server das HTML-Dokument verzögert aus, ist die TTFB hoch, und diese Verzögerung vererbt sich auf jede nachfolgende Ressource. Selbst ein perfekt optimiertes Frontend kann das nicht mehr aufholen. Typische Bremsen sind überlastete Shared-Hosting-Pakete, veraltete PHP-Versionen, fehlende OPcache-Konfiguration und zu knapp bemessener Arbeitsspeicher. In vielen Projekten (Projekterfahrung) ließ sich die TTFB durch gezieltes Server-Tuning oder einen Umzug um 50 bis 70 Prozent senken, was unmittelbar alle Core Web Vitals verbessert. Oft genügt schon ein Wechsel auf eine aktuelle PHP-Version mit aktiviertem OPcache und ein passend dimensionierter Cache. Im Erstgespräch prüfen wir, ob Ihr aktuelles Hosting der Engpass ist.
- Braucht meine Website ein CDN? Ein Content Delivery Network lohnt sich vor allem dann, wenn Ihre Besucher geografisch verstreut sind. Das CDN hält statische Ressourcen wie Bilder, CSS und JavaScript auf Servern in vielen Ländern vor und liefert sie vom jeweils nächstgelegenen Standort aus. Der Effekt ist eine kürzere Distanz und damit eine geringere Latenz, was sich besonders bei der LCP-Ressource bemerkbar macht. Für eine regionale Website mit überwiegend deutschen Besuchern und einem Server in Deutschland ist der Zusatznutzen begrenzt, hier bringen Caching und Bildoptimierung meist mehr. Für internationale Websites oder Shops mit weltweiter Kundschaft kann ein CDN die Ladezeit für entfernte Besucher um 40 bis 60 Prozent verkürzen (Projekterfahrung). Wir empfehlen ein CDN also nicht pauschal, sondern bewerten in der Performance-Analyse, ob Ihre Besucherverteilung es rechtfertigt.
- Was bringen Bildformate wie WebP und AVIF? Moderne Bildformate liefern bei gleicher sichtbarer Qualität deutlich kleinere Dateien als die klassischen Formate JPEG und PNG. WebP spart gegenüber JPEG typischerweise 25 bis 35 Prozent (Google, 2023), AVIF erreicht sogar Einsparungen von 40 bis 50 Prozent. Da Bilder auf den meisten Websites den mit Abstand größten Anteil am übertragenen Datenvolumen ausmachen, ist das einer der wirkungsvollsten Einzelschritte für einen besseren LCP. Entscheidend ist die saubere Umsetzung: Wir richten automatisierte Bildpipelines ein, die jedes hochgeladene Bild in den passenden Formaten und in mehreren responsiven Größen erzeugen und per srcset ausliefern. Ältere Browser erhalten automatisch ein kompatibles Fallback. So lädt jedes Gerät genau die Variante, die es braucht, ohne überdimensionierte Dateien. Mehr dazu auf der Seite zur Frontend-Optimierung.
- Wie wirkt sich JavaScript auf die Ladezeit aus? JavaScript ist eine der häufigsten Performance-Bremsen, weil es teurer ist als sein Dateigewicht vermuten lässt. Jedes Skript muss heruntergeladen, geparst, kompiliert und ausgeführt werden, bevor die Seite vollständig bedienbar ist, und das Parsen blockiert dabei den Main-Thread. Synchron eingebundene Skripte verzögern zusätzlich das Rendern. Besonders ärgerlich ist ungenutzter Code, der zwar geladen, aber nie gebraucht wird und trotzdem Bandbreite und Rechenzeit kostet. Wir gehen das systematisch an: Coverage-Analyse zur Identifikation toten Codes, Code-Splitting, damit jede Seite nur ihre eigenen Skripte lädt, Tree-Shaking zum Entfernen ungenutzter Funktionen sowie das Verschieben unkritischer Skripte hinter das erste Rendern. Das verbessert nicht nur den LCP, sondern auch den INP, weil weniger lange Tasks die Interaktivität blockieren. Details auf der Seite zur Frontend-Optimierung.
- Was ist der Unterschied zwischen HTTP/2 und HTTP/3? Beide Protokolle beschleunigen die Übertragung gegenüber dem alten HTTP/1.1, lösen aber unterschiedliche Probleme. HTTP/2 brachte Multiplexing, also mehrere parallele Anfragen über eine einzige Verbindung, statt für jede Datei eine neue zu öffnen. Das beseitigt einen großen Teil des früheren Verbindungs-Overheads. Ein Schwachpunkt bleibt jedoch: Geht ein Paket verloren, stockt die gesamte TCP-Verbindung (Head-of-Line-Blocking). HTTP/3 setzt auf das QUIC-Protokoll über UDP und löst genau dieses Problem, denn ein Paketverlust blockiert nur den betroffenen Stream, nicht alle. Außerdem ist der Verbindungsaufbau schneller. Den größten Gewinn merken Nutzer auf instabilen Mobilfunkverbindungen. Wir konfigurieren Ihren Server im Rahmen der Server-Optimierung so, dass er beide Protokolle anbietet und jeder Besucher automatisch die schnellste verfügbare Variante nutzt.
- Kann ich Performance-Optimierung selbst durchführen? Einen Teil ja. Grundlegende Maßnahmen wie das Komprimieren von Bildern, das Entfernen ungenutzter Plugins, das Aktivieren von Browser-Caching oder das Aktualisieren der PHP-Version lassen sich mit etwas technischem Grundverständnis selbst umsetzen und bringen schon spürbare Verbesserungen. Diese ersten Schritte empfehlen wir jeder Website-Betreiberin. Komplexer wird es bei Server-Konfiguration, Critical-CSS-Extraktion, JavaScript-Refactoring, Datenbank-Tuning oder dem Auflösen von INP-Problemen, denn hier braucht es Spezialwissen und das Risiko, dabei SEO oder Funktion zu beschädigen, ist real. In unserer Erfahrung erzielen Unternehmen das beste Ergebnis, wenn sie die Grundoptimierung selbst erledigen und für die anspruchsvollen Maßnahmen einen spezialisierten Partner hinzuziehen. Gern beraten wir Sie im Erstgespräch, wo die Grenze sinnvoll verläuft.
Plattform-spezifische Fragen
- Welche Performance-Probleme treten bei WordPress besonders häufig auf? WordPress-Seiten leiden meist an einem wiederkehrenden Muster. Die häufigsten Bremsen sind: zu viele aktive Plugins, die jeweils eigene CSS- und JavaScript-Dateien auf jeder Seite laden, auch wenn sie dort nicht gebraucht werden, unkomprimierte und nicht skalierte Bilder, fehlende oder falsch konfigurierte Caching-Plugins, veraltete PHP-Versionen sowie aufgeblähte Page-Builder, die hunderte Kilobyte zusätzliches HTML und CSS erzeugen. Hinzu kommen über Jahre gewachsene Datenbanken voller verwaister Metadaten, Transients und Beitragsrevisionen. In einem typischen WordPress-Projekt (Projekterfahrung) reduzieren wir die Zahl der HTTP-Requests um 40 bis 60 Prozent und die Gesamtseitengröße um mehr als die Hälfte, ohne Funktionen zu opfern. Der Schlüssel ist das selektive Laden von Assets, ein sauber konfigurierter Server-Cache und eine aufgeräumte Datenbank. Welche Maßnahmen bei Ihrer Seite den größten Effekt haben, zeigt die Performance-Analyse.
- Wie optimiert man die Performance eines Shopware-Shops? Shopware CE bringt eigene Performance-Stellschrauben mit, die sich von einer klassischen Website unterscheiden. Zentral sind: die Elasticsearch-Konfiguration für schnelle Produkt- und Facettensuche, das HTTP-Cache-Warming, damit häufig aufgerufene Kategorie- und Produktseiten bereits im Cache liegen, schlanke Twig-Templates für kurze Render-Zeiten und ein korrekt eingestellter Varnish-Reverse-Proxy, der fertige Seiten aus dem Arbeitsspeicher ausliefert. Dazu kommen shop-typische Themen wie die Anzahl der Plugins, die Generierung der Bildvarianten (Thumbnails) und die Datenbank-Performance bei großen Katalogen mit vielen Varianten. Gerade bei Lastspitzen, etwa zu Kampagnenstart, entscheidet die Cache-Strategie über Erreichbarkeit und Conversion. Auf unserer Fachseite zur Shopware-Performance gehen wir detailliert auf diese Themen ein, und für Shops mit hohem Bestellaufkommen lohnt ein Blick auf unsere Lösungen für E-Commerce.
- Können auch JavaScript-Frameworks wie React oder Vue optimiert werden? Ja, und gerade hier liegt oft großes Potenzial. Single-Page-Applications auf Basis von React, Vue, Svelte oder Angular kämpfen typischerweise mit drei Problemen: einem großen initialen JavaScript-Bundle, langsamem Rendern im Browser und schlechter Indexierbarkeit, weil der eigentliche Inhalt erst per JavaScript entsteht. Das drückt vor allem LCP und INP. Wir setzen an mehreren Stellen an: Server-Side Rendering (SSR) oder Static Site Generation (SSG), damit der Inhalt sofort als HTML ausgeliefert wird, Code-Splitting auf Routenebene, Tree-Shaking, Lazy Loading von Komponenten und schlanke Hydration-Strategien, die nur die wirklich interaktiven Teile aktivieren. Bei bestehenden Apps ohne SSR prüfen wir auch eine Migration auf moderne Meta-Frameworks. Für SaaS-Anwendungen beschreiben wir den Ansatz auf einer eigenen Seite genauer.
- Wie unterscheidet sich die Optimierung für mobile Geräte? Mobile Optimierung ist kein Nebenschauplatz, sondern der Hauptmaßstab, weil Google den Mobile-First-Index verwendet und für die Bewertung die mobile Version Ihrer Seite heranzieht. Mobilgeräte haben zudem schwächere Prozessoren und oft instabilere Netze als Desktop-PCs, sodass dieselbe Seite dort spürbar langsamer ist. Konkret heißt das: JavaScript-Bundles müssen klein bleiben, denn das Parsen dauert auf Mobilgeräten ein Vielfaches der Desktop-Zeit. Bilder werden in responsiven Größen ausgeliefert, damit ein Smartphone keine Desktop-Auflösung herunterlädt. Touch-Interaktionen müssen ohne Verzögerung reagieren, um gute INP-Werte zu erzielen, und das Layout muss ohne Sprünge laden, damit der CLS niedrig bleibt. Wir testen jede Optimierung deshalb konsequent unter gedrosselten Mobilbedingungen, nicht nur am schnellen Bürorechner. Mehr dazu in der Performance-Analyse.
- Kann Performance-Optimierung SEO-Probleme verursachen? Ja, wenn sie unsachgemäß umgesetzt wird. Genau das ist ein Grund, warum wir nicht blind Standard-Plugins aktivieren. Typische Risiken sind: zu aggressives Lazy Loading, das den Googlebot daran hindert, Inhalte und Bilder zu sehen, das Verschieben von JavaScript, durch das strukturierte Daten erst nach dem ersten Crawl entstehen, URL-Änderungen durch eine CDN-Konfiguration ohne saubere Weiterleitungen sowie übermäßiges Caching, das veraltete Inhalte ausliefert. Wir behandeln SEO daher als feste Nebenbedingung jeder Maßnahme, nicht als nachträgliche Prüfung. Nach der Umsetzung kontrollieren wir mit den offiziellen Google-Werkzeugen, ob Inhalte weiterhin indexierbar sind, strukturierte Daten korrekt erkannt werden und keine Weiterleitungsketten entstanden sind. So bleibt der Performance-Gewinn ein reiner Gewinn, ohne ihn an anderer Stelle wieder einzubüßen. Bei Fragen dazu hilft das Erstgespräch.
- Muss mein Shop während der Optimierung offline gehen? Nein, ein Online-Shop verdient an jeder Minute Erreichbarkeit, deshalb arbeiten wir bewusst ohne pauschale Abschaltung. Alle Änderungen entstehen zunächst in einer Staging-Umgebung, einer Kopie Ihres Shops, wo wir sie ausgiebig testen und die Wirkung messen. Erst nach erfolgreicher Validierung übertragen wir sie auf die Live-Umgebung. Die meisten Maßnahmen, etwa Cache-Konfiguration, Bildoptimierung oder CSS-Anpassungen, lassen sich völlig ohne Downtime einspielen. Nur für tiefe serverseitige Änderungen, die einen Dienst-Neustart erfordern, planen wir ein kurzes Wartungsfenster in einer verkehrsarmen Zeit, typischerweise nachts oder am frühen Morgen, und stimmen den Termin vorab mit Ihnen ab. So bleibt das Risiko für Umsatz und Shop-Performance minimal.
Kosten und Projektablauf
- Was kostet eine professionelle PageSpeed-Optimierung? Die Investition richtet sich nach Umfang und Komplexität, deshalb arbeiten wir mit transparenten Rahmen statt mit Pauschalpreisen. Eine gezielte Optimierung einer einzelnen Landingpage oder eines klar abgegrenzten Problems beginnt im unteren vierstelligen Bereich. Ein vollständiges Audit mit Umsetzung aller identifizierten Maßnahmen für eine mittelgroße Website bewegt sich im mittleren vierstelligen Bereich. Komplexe Shop-Systeme mit tiefer Server-, Cache- und Frontend-Optimierung können im höheren vierstelligen bis fünfstelligen Bereich liegen, je nach Katalogtiefe und Plugin-Landschaft. Wichtig ist die Gegenrechnung: Schon wenige Prozentpunkte mehr Conversion oder ein paar Ranking-Positionen amortisieren die Investition häufig innerhalb weniger Monate. Eine realistische Budgetindikation für Ihren konkreten Fall erhalten Sie im kostenfreien Erstgespräch, nachdem wir Ihre Website kurz angesehen haben.
- Wie läuft ein Performance-Optimierungsprojekt typischerweise ab? Jedes Projekt folgt einem klaren, nachvollziehbaren Ablauf. Es beginnt mit einer umfassenden Performance-Analyse: Wir messen den Ist-Zustand aller relevanten Metriken in Labor und Feld, identifizieren die größten Engpässe und erstellen einen nach Wirkung priorisierten Maßnahmenplan. Sie wissen also von Anfang an, was wir warum tun. In der Umsetzungsphase arbeiten wir die Maßnahmen vom größten Hebel abwärts ab, jede Änderung wird zuerst in einer Staging-Umgebung getestet und gemessen, bevor sie live geht. Zum Abschluss erhalten Sie einen Bericht mit Vorher-Nachher-Vergleich aller Metriken, damit der Erfolg belegbar ist. Auf Wunsch richten wir anschließend ein laufendes Monitoring ein, das Regressionen früh erkennt. Beispiele für unseren Projektansatz finden Sie auf der Referenzseite.
- Bieten Sie auch laufende Performance-Überwachung an? Ja. Performance ist kein Zustand, den man einmal herstellt und dann vergisst, deshalb bieten wir Monitoring-Pakete an, die Ihre Core Web Vitals und weitere Metriken kontinuierlich im Blick behalten. Dazu gehören tägliche synthetische Tests, die laufende Auswertung der CrUX-Felddaten, automatische Benachrichtigungen bei Verschlechterungen und regelmäßige Reports mit konkreten Handlungsempfehlungen. Besonders sinnvoll ist das für Websites und Shops, die regelmäßig aktualisiert werden, denn ein neues Plugin, ein eingebundenes Marketing-Skript oder eine Design-Änderung können die Performance unbemerkt verschlechtern. Mit Monitoring fällt eine solche Regression innerhalb von Stunden auf, statt erst Wochen später über sinkende Rankings. Welcher Überwachungsumfang zu Ihrer Website passt, klären wir gern im Erstgespräch.
- Wie messe ich den Erfolg einer Performance-Optimierung? Erfolg muss messbar sein, sonst ist er Behauptung. Wir belegen ihn auf zwei Ebenen. Die technischen Kennzahlen vergleichen wir vorher und nachher: die Core Web Vitals (LCP, INP, CLS), den PageSpeed-Score, die TTFB, die Gesamtseitengröße und die Anzahl der HTTP-Requests. Diese Werte lassen sich objektiv und reproduzierbar erheben. Wichtiger sind langfristig die Geschäftsmetriken, die sich nach einigen Wochen zeigen: eine niedrigere Absprungrate, längere Verweildauer, mehr Seiten pro Sitzung und eine bessere Conversion-Rate, oft begleitet von verbesserten Rankings bei relevanten Suchbegriffen. Jedes Projekt schließt mit einem dokumentierten Bericht ab, der alle messbaren Verbesserungen transparent aufschlüsselt. Unseren Mess- und Arbeitsansatz erläutern wir auch auf der Seite Über uns.
- Gibt es wiederkehrende Kosten nach der Optimierung? Die einmalige Optimierung selbst verursacht keine Pflichtkosten danach, die erzielten Verbesserungen bleiben Ihnen erhalten. Sie sind also nicht in ein Abomodell gebunden, um schnell zu bleiben. Wir empfehlen dennoch ein optionales Monitoring, weil Website-Performance kein statischer Zustand ist: Neue Inhalte, Plugin-Updates, CMS-Upgrades oder veränderte Drittanbieter-Skripte können die Werte schleichend verschlechtern. Diese Pakete werden monatlich abgerechnet und lassen sich jederzeit anpassen. Viele Kunden wählen alternativ quartalsweise Performance-Reviews, bei denen wir den aktuellen Stand bewerten und bei Bedarf gezielt nachjustieren. Welche Variante für Sie sinnvoll ist, besprechen wir unverbindlich im Erstgespräch.
- Kann die Optimierung in Phasen aufgeteilt werden? Ja, ein phasenweiser Ansatz ist häufig die wirtschaftlich klügste Variante, weil er die Investition über mehrere Monate verteilt und früh Ergebnisse liefert. Phase eins konzentriert sich auf die wirkungsvollsten Maßnahmen mit dem größten Hebel, typischerweise Server-Konfiguration, Bildoptimierung und Critical CSS. Schon hier werden die Verbesserungen messbar. Phase zwei adressiert fortgeschrittene Themen wie JavaScript-Refactoring, ausgefeilte Caching-Strategien und das Management von Drittanbieter-Skripten. Phase drei umfasst die Feinabstimmung der Core Web Vitals und die Einrichtung eines langfristigen Monitorings. Der Vorteil: Nach jeder Phase entscheiden Sie auf Basis konkreter Zahlen, ob und wie weit es weitergeht. Den passenden Phasenschnitt für Ihr Budget legen wir gemeinsam im Erstgespräch fest.
Caching, Komprimierung und Auslieferung
- Was ist der Unterschied zwischen Browser-Cache und Server-Cache? Beide Caches beschleunigen die Auslieferung, setzen aber an verschiedenen Stellen an. Der Browser-Cache speichert Ressourcen wie Bilder, CSS und JavaScript lokal auf dem Gerät des Besuchers. Ruft derselbe Nutzer eine weitere Seite auf, lädt der Browser diese Dateien direkt aus dem lokalen Speicher, ohne den Server überhaupt zu kontaktieren. Gesteuert wird das über HTTP-Header wie Cache-Control. Der Server-Cache dagegen hält vorab gerenderte HTML-Seiten oder das Ergebnis teurer Datenbankabfragen auf dem Server vor, sodass sie auch neuen Besuchern sofort ausgeliefert werden können. Beide Ebenen ergänzen sich: Der Server-Cache beschleunigt den ersten Aufruf, der Browser-Cache jeden weiteren desselben Besuchers. Im Rahmen der Server-Optimierung stimmen wir beide so aufeinander ab, dass Inhalte schnell und trotzdem aktuell bleiben.
- Was ist Brotli-Komprimierung und warum ist sie besser als Gzip? Brotli ist ein von Google entwickelter Komprimierungsalgorithmus, der speziell auf Web-Inhalte zugeschnitten ist und ein vortrainiertes Wörterbuch typischer HTML- und CSS-Muster mitbringt. Gegenüber dem älteren Gzip erreicht er bei textbasierten Ressourcen wie HTML, CSS und JavaScript eine 15 bis 25 Prozent bessere Komprimierung (Google, 2023). Kleinere Übertragungsgrößen bedeuten direkt kürzere Ladezeiten, besonders auf langsamen Mobilverbindungen. In der Praxis ist die Umstellung risikoarm, weil alle modernen Browser Brotli vollständig unterstützen. Wir konfigurieren den Server so, dass er Brotli als bevorzugten Algorithmus aushandelt und Gzip als Fallback für seltene ältere Clients bereithält. So profitiert jeder Besucher automatisch von der bestmöglichen Komprimierung, ohne dass etwas an den Inhalten geändert werden muss. Mehr dazu auf der Seite zur Server-Optimierung.
- Wie funktioniert ein Reverse Proxy wie Varnish? Ein Reverse Proxy sitzt vor dem eigentlichen Webserver und hält komplette HTML-Seiten im Arbeitsspeicher vor. Ruft ein Besucher eine bereits gecachte Seite auf, liefert der Proxy sie direkt aus dem RAM aus, ohne dass PHP ausgeführt oder die Datenbank überhaupt angefragt wird. Das senkt die TTFB auf wenige Millisekunden, selbst bei aufwendig generierten dynamischen Seiten, und entlastet gleichzeitig den Server bei Lastspitzen. Varnish ist deshalb besonders wirkungsvoll für Shopware-Shops mit vielen Kategorie- und Produktseiten, die sich nur selten ändern. Die Herausforderung liegt im sauberen Cache-Invalidieren: Eine Preisänderung oder ein leerer Lagerbestand muss sofort durchschlagen, während alles andere im Cache bleibt. Genau diese Regeln konfigurieren wir projektspezifisch, damit Geschwindigkeit nicht zulasten der Aktualität geht.
- Was bedeutet Critical CSS und wie wird es implementiert? Critical CSS ist der minimale Satz an CSS-Regeln, der nötig ist, um den sofort sichtbaren Bereich einer Seite (Above the Fold) korrekt darzustellen. Normalerweise muss der Browser zuerst die komplette externe CSS-Datei laden und verarbeiten, bevor er überhaupt etwas zeichnen darf, das blockiert das Rendern. Wird das kritische CSS stattdessen direkt inline ins HTML eingebettet, kann der Browser den sichtbaren Bereich sofort darstellen. Das restliche, nicht sofort benötigte CSS wird asynchron nachgeladen. Umgesetzt wird das über eine automatisierte Extraktion: Spezialisierte Werkzeuge analysieren, welche Regeln der sichtbare Bereich für verschiedene Bildschirmgrößen tatsächlich braucht. Das Ergebnis ist ein deutlich schnellerer First Contentful Paint und meist auch ein besserer LCP. Diese Technik ist Teil unserer Frontend-Optimierung und besonders bei umfangreichen CSS-Frameworks lohnend.
- Wie gehe ich mit Third-Party-Scripts um, die die Performance bremsen? Skripte von Drittanbietern wie Analyse-Werkzeuge, Chat-Widgets, Marketing-Pixel und Social-Media-Embeds gehören zu den hartnäckigsten Performance-Bremsen, weil Sie ihren Code nicht selbst kontrollieren und er oft den Main-Thread blockiert. Sie sind außerdem eine häufige Ursache für schlechte INP-Werte und plötzliche Layout-Sprünge. Wir gehen in drei Schritten vor. Erstens inventarisieren wir jedes eingebundene Skript und bewerten seinen echten geschäftlichen Nutzen, denn vieles läuft nur aus Gewohnheit mit. Zweitens entfernen wir, was nicht mehr gebraucht wird. Drittens optimieren wir den Rest: verzögertes Laden erst nach der ersten Nutzerinteraktion, Self-Hosting wo möglich, sowie Fassaden, die für Chat-Widgets oder Embeds zunächst nur ein leichtes Vorschaubild zeigen und das schwere Skript erst beim Klick laden. So bleibt der Nutzen erhalten, ohne die Frontend-Performance zu opfern.
- Wie stelle ich sicher, dass die Performance nach der Optimierung stabil bleibt? Eine optimierte Website kann mit der Zeit wieder langsamer werden, das ist normal und kein Zeichen schlechter Arbeit. Regressionen entstehen meist durch neue Inhalte, Plugin-Updates oder nachträglich eingebundene Drittanbieter-Skripte, oft ohne dass es im Tagesgeschäft auffällt. Um die Stabilität zu sichern, empfehlen wir drei Bausteine: ein automatisiertes Monitoring, das die Core Web Vitals laufend misst und bei Verschlechterung alarmiert, ein Performance-Budget, das maximale Seitengrößen und Skript-Volumen verbindlich festlegt, sowie regelmäßige Reviews im Quartalsrhythmus. So fällt eine Regression innerhalb von Stunden auf und lässt sich beheben, bevor sie sich in den Felddaten und damit in den Rankings niederschlägt. Welcher Umfang sinnvoll ist, klären wir gern im Erstgespräch.
Frage nicht dabei?
Schreiben Sie uns — wir antworten persönlich und unverbindlich.