Kurz gesagt: Nicht jede installierte Shopify-App ist harmlos. Einige schleusen große JavaScript-Bundles, viele API-Requests oder mehrere Widgets in den kritischen Rendering-Pfad — und verlangsamen damit LCP, TTI und letztlich deine Conversion-Rate. Ein strukturiertes Audit zeigt genau, welche Apps den größten Overhead verursachen und wie du durch Deaktivieren, Ersetzen oder gezielte Optimierung messbare Performance-Gewinne erzielst. ⏱️ 11-min read
Dieser Leitfaden beschreibt einen ganzheitlichen Audit-Ansatz: von der Bestandsaufnahme über Messmethoden und Bewertungs-Kriterien bis hin zu einer praktischen Schritt-für-Schritt-Checkliste, einer Workshop-Agenda und Empfehlungen für Monitoring-Automatisierung. Praxisnahe Beispiele und konkrete Maßnahmen helfen dir, den Shop nachhaltig schlanker zu machen — ohne notwendige Funktionen zu opfern.
1. Bestandsaufnahme: Vollständige Liste der Apps, Funktionsbereiche und Baseline-Metriken
Der erste Fehler vieler Shops ist, ohne Übersicht zu optimieren. Beginne mit einer vollständigen Inventur: Exportiere die Liste aller installierten Apps aus dem Shopify-Admin, notiere Hauptfunktionen, welche Theme-Dateien verändert wurden und welche Seiten (Homepage, Produktseite, Checkout) betroffen sind. Gruppiere Apps nach Funktionsbereichen — z. B. Tracking, Reviews, UGC, Promotions, Versand/Checkout, Suche, Personalisierung — und markiere offensichtliche Doppelungen (z. B. zwei unterschiedliche Popup-/Lead-Gen-Tools).
Parallel legst du eine Baseline für Core Web Vitals und andere Kennzahlen fest. Führe mehrere Labortests mit Lighthouse und WebPageTest durch (mobil und Desktop, mit Netzwerk-Throttling wie „Fast 3G“ und CPU-Throttling), und sammle Feld-Daten (Real User Monitoring) wenn möglich. Notiere LCP, TTI, CLS, TTFB, Seitengewicht und Anzahl der Requests. Dokumentiere außerdem die Ladezeit vor und nach dem Laden jeder App, indem du in Chrome DevTools die Netzwerk-Requests filterst oder in einer Staging-Umgebung einzelne Apps temporär deaktivierst.
Konkrete Zielsetzung ist wichtig: Formuliere messbare Ziele wie „LCP < 2,5 s auf Mobil bei Fast 3G“ oder „TTI um 30 % reduzieren“. Weise Rollen zu: Wer misst, wer ändert Theme-Code, wer kommuniziert mit den App-Providern. Ohne klare Verantwortlichkeiten werden Audits oft fragmentarisch und Erfolge sind schwer nachweisbar.
Beispiel: In einem mittelgroßen Shop identifizierten wir 18 Apps. Nach Gruppierung zeigten sich fünf Hauptverdächtige — ein Popup-Tool, zwei Tracking-Apps (marketing + analytics), ein UGC-Widget und ein Personalisierungsdienst. Die Baseline: Mobil-LCP 4,2 s, TTI 6,8 s. Diese Baseline diente später als Referenz für schrittweise Deaktivierungen.
2. Messmethoden: Lighthouse, PageSpeed Insights, WebPageTest und Script-Sizing
Messung ist das Herzstück eines Audits. Nutze eine Kombination aus Labordaten (Lighthouse, WebPageTest, GTmetrix) und Felddaten (Chrome User Experience Report, wenn verfügbar, oder eigenes RUM-Setup). Lighthouse liefert einen schnellen Überblick über Core Web Vitals und zeigt potenzielle Render-Blocker. WebPageTest ergänzt mit detaillierten Wasserfall-Diagrammen und ermöglicht das genaue Timing einzelner Requests. GTmetrix ist praktisch für historische Vergleiche und differenzierte Testprofile.
Wichtig ist: Miss nicht nur die Gesamtseite, sondern isoliert auch scriptspezifische Auswirkungen. In Chrome DevTools lässt sich im Network-Tab nach Domains filtern — so siehst du, welche Requests von app-Domains kommen. Zusätzlich kannst du in DevTools unter „Coverage“ nicht-genutzten Code identifizieren oder mit dem Performance-Tab die Main-Thread-Events analysieren. Miss die Script-Größe (Bytes) pro App, die Anzahl der Requests und ob Ressourcen synchron laden oder asynchron/deferrt.
Für valide Ergebnisse wiederhole Tests zu verschiedenen Tageszeiten und auf verschiedenen Endgeräten. Nutze Throttling (z. B. Architektur „Fast 3G“ + 4× CPU-Slowdown) für realistische Mobil-Szenarien. Ergänze mit einem einfachen A/B-Szenario: Seite mit allen Apps vs. Seite mit einer App deaktiviert — dies isoliert den direkten Einfluss. Manche Tools (SpeedCurve, Calibre) automatisieren tägliche Tests und liefern Trends; Lighthouse CI lässt sich in CI/CD-Pipelines einbinden.
Praktischer Tipp: Exportiere Lighthouse-Reports als JSON und halte diese als Baseline fest. So kannst du später automatisiert Unterschiede auswerten. Bei der Script-Analyse notiere Domain, Pfad, Größe, Content-Type und Ladezeit. Diese Daten bilden die Grundlage für Priorisierung und Entscheidung, welche App zuerst geprüft oder entfernt wird.
3. Ursachenanalyse: Wie Apps verlangsamen — API-Calls, Script-Größe und Doppelungen
Apps verlangsamen Shops auf unterschiedlichen Wegen. Die häufigsten Ursachen sind: umfangreiche Third-Party-JavaScript-Bundles, viele asynchrone oder synchrone API-Aufrufe während des Page-Load, mehrere Widgets, die gleichzeitig DOM-Manipulationen vornehmen, sowie redundante Bibliotheken (mehrere Versionen von jQuery, Chart-Libraries etc.). Rendering-Blocker entstehen vor allem dann, wenn Scripts im Head synchron geladen werden oder CSS von Drittanbietern den kritischen Pfad blockiert.
Ein systematischer Ansatz zur Ursachenanalyse kombiniert Wasserfall-Analysen mit Request-Zählungen: Zähle Netzwerk-Requests pro App, identifiziere große Payloads und prüfe die Reaktivität auf Nutzerinteraktionen (TTI/Total Blocking Time). Schaue zudem auf Caching-Header: Werden Ressourcen mit Cache-Control und lange Ablaufzeiten ausgeliefert oder immer wieder neu geladen? Nutze die DevTools, um festzustellen, ob Libraries mehrfach geladen werden — oft passiert das, wenn verschiedene Apps dieselbe Bibliothek in unterschiedlichen Versionen einbinden.
Bewerte außerdem, ob eine Funktion serverseitig statt clientseitig erfolgen kann. Produktbewertungen beispielsweise lassen sich oft serverseitig rendern oder per AJAX nachladen, statt mehrere Widgets im initialen Render-Pfad zu platzieren. Gleiches gilt für Tracking: Mehrere Tracking-Apps können redundante Calls auslösen. Ein konkretes Beispiel: Eine Marketing-Tracking-App schlug in einem Audit sofort mit 120 KB JS und 6 zusätzlichen Requests pro Seitenaufruf zu Buche; durch Konsolidierung und Entfernung reduzierten wir die Requests um 40 %.
Zuletzt prüfe Abhängigkeiten: Manche Apps laden zentrale Bibliotheken gemeinsam; in anderen Fällen dagegen bringen sie eigene Versionen mit. Wenn Bibliotheken geteilt werden können, erspart das Netzwerklast. Wenn nicht, sind Workarounds wie das Hosten gemeinsamer Bibliotheken im eigenen CDN oder serverseitiges Rendering zu prüfen. Dokumentiere jede Ursache mit Priorität (Impact x Aufwand), damit die Optimierungsarbeit zielgerichtet startet.
4. Priorisierung und Entscheidungsprozess: Behalten, Ersetzen oder Deaktivieren
Nach Analyse folgt die Entscheidung. Erstelle eine Prioritätenmatrix: Spalte A beschreibt den Performance-Impact (hoch/mittel/gering), Spalte B den geschäftlichen Nutzen (z. B. Umsatzbeitrag, rechtliche Relevanz), Spalte C den Implementierungsaufwand und Spalte D mögliche Alternativen. Apps mit hohem Performance-Impact und geringem Business-Nutzen sind primäre Kandidaten für Entfernung.
Teile die Maßnahmen in drei Kategorien ein: Behalten (kritisch, geringer Impact), Ersetzen (Funktion kann durch native Features oder schlankere Apps abgedeckt werden) und Deaktivieren (nicht genutzte oder doppelte Apps). Plane schrittweise Deaktivierungen in Phasen: Phase 0 — Backup & Staging, Phase 1 — Remove low-value/high-impact Apps, Phase 2 — Replace redundant functions durch native Lösungen, Phase 3 — Feintuning und Monitoring.
Wichtig: Teste jede Deaktivierung isoliert und vergleiche Metriken mit der Baseline. Dokumentiere die Ergebnisse: z. B. „Popup-App deaktiviert → LCP −0,6 s, TTI −1,2 s; Conversion unverändert“. In einem Beispielfall aus dem Feld führte die Entfernung einer blockierenden Popup-App zu einer durchschnittlichen Seitenladezeit-Reduktion von 30 % und einer Conversion-Steigerung von 10–12 % innerhalb eines Monats.
Kommunikation ist ein weiterer Schlüssel: Informiere Marketing, Customer Support und Stakeholder über geplante Änderungen und biete Übergangslösungen an (z. B. ein Theme-basiertes Newsletter-Formular statt eines externen Popup-Tools). Lege außerdem Rollback-Pläne fest — falls eine entfernte App doch notwendig ist, muss eine schnelle Wiederherstellung möglich sein. So verhinderst du, dass kurzfristige Performance-Gewinne langfristig in Support-Kosten umschlagen.
5. Konkrete Optimierungen: Lazy Loading, Defer/Async, CDN und Theme-Optimierung
Nach Priorisierung folgen konkrete Optimierungen. Beginne mit einfachen Feldern, die großen Impact haben: setze defer oder async für Nicht-UI-kritische Scripts, lade Widgets via IntersectionObserver nur, wenn sie sichtbar werden (lazy loading), und verschiebe nicht dringend benötigte Scripte ans Ende des Body. So vermeidest du, dass Third-Party-Code den initialen Render-Pfad blockiert.
Ein weiterer Hebel ist das Hosting wichtiger Assets im eigenen CDN oder auf der eigenen Domain. Viele Apps liefern Schriften, Bilder oder große Bibliotheken von Fremddomains, was kombiniert mit fehlendem Caching zu wiederholten Downloads führt. Durch das Hosten getrennter, gecachter Assets sinkt die Anzahl der Roundtrips und verbessert TTFB und LCP. Stelle zudem sicher, dass HTTP/2 oder HTTP/3 genutzt wird, damit Ressourcendownloads parallelisiert werden können.
On-Theme-Optimierungen sind essenziell: Bündle und minifiziere CSS/JS-Dateien, entferne ungenutzte CSS-Regeln und nutze kritisches CSS-Inline-Loading für Above-the-Fold-Inhalte. Vermeide Inline-JavaScript, das Main-Thread blockiert. Für Widgets und UGC erwäge serverseitiges Rendern oder verzögertes Nachladen (via AJAX), sodass der sichtbare Seitenaufbau nicht auf externe Antworten wartet.
Praxisbeispiel: Durch Lazy-Loading von Reviews-Widgets und das Deferrt von Marketing-Skripten reduzierte ein Shop seine Initial-Payload um 220 KB und die Anzahl der Blocking-Requests um 7. LCP sank um 0,9 Sekunden, die TTI verbesserte sich deutlich. Solche Maßnahmen sind oft low-hanging fruits und sollten früh im Optimierungsplan stehen.
6. Monitoring und kontinuierliche Audits: Automatisierung und Reportings
Performance ist kein einmaliges Projekt, sondern ein laufender Prozess. Richte ein Monitoring-Setup ein, das sowohl synthetische Tests (Lighthouse CI, WebPageTest Cron, SpeedCurve) als auch RUM-Daten (z. B. via Google Analytics RUM-Metriken oder einem spezialisierten Tool) kombiniert. Tägliche oder wöchentliche Checks mit historischen Trends zeigen Regressionen frühzeitig.
Automatisierungsempfehlung: Integriere Lighthouse CI in deine CI/CD-Pipeline, sodass bei jedem Theme-Release automatisch ein Performance-Report erstellt wird. Nutze Skripte, die Lighthouse-Reports in JSON exportieren, differenziere nach Seitenvorlagen (Homepage, PDP, PLP) und poste zusammengefasste KPIs in Slack oder als E-Mail an Stakeholder. Tools wie SpeedCurve oder Calibre bieten Dashboards und Alarme bei KPI-Verschlechterungen.
Monitoring sollte auch App-spezifische Metriken erfassen: Script-Größe pro App, Anzahl der Requests von Drittanbietern, Fehlerraten von API-Calls. Erstelle automatisierte Reports, die quartalsweise eine vollständige App-Überprüfung auslösen: Sind neue Apps installiert worden? Haben App-Updates den Payload erhöht? Solche Audits lassen sich teilweise automatisieren, benötigen aber eine manuelle Prüfung bei signifikanten Änderungen.
Wartungstipps: Plane vierteljährliche Re-Audits, halte Changelogs für Theme- und App-Änderungen, und erstelle ein einfaches Dashboard mit LCP, TTI, TTFB, Seitengewicht und Anzahl Requests. So werden Performance-Regressions sichtbar bevor die Conversion leidet. Dokumentiere alle Optimierungen, inklusive Messmethodik, damit Erfolge und Rückschritte nachvollziehbar bleiben.
7. Audit-Workshop: Checkliste, Zeitplan und Verantwortlichkeiten
Ein Audit-Workshop bringt Teammitglieder zusammen und beschleunigt Entscheidungen. Agenda-Vorschlag (halbtägig bis eintägig): 1) Einführung und Zieldefinition (KPIs, erwartete Verbesserungen), 2) Vorstellung der Inventur und der Baseline-Metriken, 3) Live-Analyse anhand von Lighthouse- und Waterfall-Daten, 4) Priorisierung und Entscheidung über erste Maßnahmen, 5) Aktionsplan mit Verantwortlichkeiten und Timings.
Eine praxisnahe Checkliste für den Workshop umfasst: App-Inventur prüfen, Quick-Wins identifizieren (z. B. remove unused apps), request-count per app notieren, Script-sizes messen, DOM- und Main-Thread-Analyse durchführen, Caching-Header prüfen, und zu klären: Gibt es rechtliche oder businesskritische Abhängigkeiten? Verteile Aufgaben nach Rollen: Product/Marketing definiert Geschäftsanforderungen, Devs testen Deaktivierung im Staging, Ops setzt CI-Tools auf und Reporting-Owner trackt KPIs.
Setze klare Zeitfenster: Für Quick-Wins (z. B. deaktivieren einer Popup-App, asynchrones Laden eines Scripts) plane 1–2 Tage; für komplexere Migrationen (z. B. Ersetzen einer integrierten Tracking-Lösung oder Server-Side-Rendering von UGC) rechne mit 2–6 Wochen inklusive Testing. Dokumentiere außerdem Akzeptanzkriterien: z. B. „Keine Regressions im Checkout, Core Web Vitals verbessern sich um mindestens 15 %“.
Nach dem Workshop folgt ein verbindlicher Aktionsplan mit Milestones, Verantwortlichen und Rollback-Strategien. Kommuniziere Änderungen an Stakeholder außerhalb des Workshops und lege fest, wann die Ergebnisse erneut gemessen und im Team präsentiert werden — typischerweise nach 7 Tagen und nach 30 Tagen, um kurzfristige und mittel- bis langfristige Effekte zu erfassen.
8. Empfohlene Tools und Integrationstipps für wiederkehrende Audits
Die richtigen Werkzeuge erleichtern Audits enorm. Eine empfehlenswerte Toolchain umfasst: Lighthouse / PageSpeed Insights für Core Web Vitals, WebPageTest für Wasserfall-Analysen, GTmetrix zur Trendanalyse, Shopify Theme Inspector zur Identifikation versteckter App-Skripte und SpeedCurve oder Calibre für kontinuierliches Monitoring. Ergänze diese Tools mit RUM-Lösungen (z. B. Google Analytics RUM-Metriken oder spezialisierte Anbieter) für echte Nutzerdaten.
Für Entwickler sind Lighthouse CI und WebPageTest API nützlich, um Tests zu automatisieren. Lege ein Repository an, in dem Lighthouse-Reports gespeichert werden, und integriere Alerts bei Verschlechterungen. Der Shopify Theme Inspector hilft, Skripte zu finden, die direkt in Theme-Templates injiziert wurden — das ist besonders wertvoll, weil viele App-Deinstallationen Snippets im Theme hinterlassen, die weiterhin Ressourcen laden.
Integrationstipps: Automatisiere Baseline-Tests vor jeder Theme-Änderung; setze Deploy-Checks in der CI, die eine Mindestschwelle für LCP/TTI fordern. Richte Alerts ein (Slack/Email) bei Überschreitung kritischer KPIs. Dokumentiere außerdem, welche Apps manuell geprüft werden müssen, weil sie API-Zugriffe haben, die nicht per einfachem Test abgedeckt werden (z. B. Lager-Sync oder externe Payment-Integrationen).
Zum Abschluss: Mache Performance-Audits zur Routine. Tools unterstützen, doch ohne klare Prozesse, Verantwortlichkeiten und regelmäßige Reviews bleiben Optimierungen punktuell. Mit einer Kombination aus Inventur, Messmethoden, Priorisierung, technischen Maßnahmen und kontinuierlichem Monitoring kannst du den App-Overhead nachhaltig reduzieren und so Ladezeiten, Nutzererlebnis und Conversion-Rate gleichzeitig verbessern.
Kurze Audit-Checkliste (zum Kopieren)
- Exportiere alle installierten Apps und gruppiere nach Funktion.
- Lege Baseline-Metriken fest (LCP, TTI, CLS, TTFB, Request-Count).
- Führe Labortests (Lighthouse/WebPageTest) + RUM durch.
- Identifiziere Top-Impact Apps (Requests, Script-Size, Blocking).
- Priorisiere: entfernen, ersetzen, optimieren.
- Implementiere Quick-Wins: defer/async, lazy loading, CDN-Hosting.
- Automatisiere Tests (Lighthouse CI) und plane vierteljährliche Re-Audits.
Wenn du möchtest, erstelle ich dir gern eine angepasste Audit-Vorlage für deinen Shop (inkl. Excel/CSV-Template für App-Inventar und eine Lighthouse-Checkliste), oder wir planen gemeinsam eine Workshop-Agenda mit konkreten Zeitfenstern und Verantwortlichkeiten. Sag mir kurz, wie viele Apps dein Shop aktuell hat und ob ein Staging vorhanden ist — dann mache ich einen konkreten Plan.
