Shopify Speed-Optimierung: Fiverr-Hack und die Risiken

Wer auf Freelancer-Plattformen wie Fiverr nach „Shopify Speed Optimization" sucht, findet Hunderte Angebote ab 10 €. Die Versprechen klingen verlockend: PageSpeed-Score von 20 auf 90+, Ladezeit halbiert, Core Web Vitals im grünen Bereich. Doch was steckt hinter diesen Angeboten?

Das Geschäftsmodell: Score-Manipulation statt echte Optimierung

Die Masche ist immer dieselbe: Ein Anbieter installiert ein Script in deinem Shopify-Theme, das den Google Lighthouse-Score künstlich aufbläst. Der Score steigt, du bist zufrieden, gibst 5 Sterne. Was du nicht siehst: Dein Shop ist für echte Besucher keinen Deut schneller geworden.

Denn Lighthouse testet unter synthetischen Bedingungen. Die Scripts erkennen, wann ein Test läuft, und verhalten sich dann anders als beim echten Nutzer. Das ist Cloaking – und von Shopify ausdrücklich verboten.

Was die Scripts technisch machen

Wir haben den Quellcode mehrerer betroffener Shops analysiert. Die Snippets sind öffentlich sichtbar im Seitenquelltext. Hier die häufigsten Tricks:

1. User-Agent-Erkennung (Lighthouse-Cloaking)

Das Script prüft, ob der Request von Lighthouse stammt. Wenn ja, werden Ressourcen nicht geladen:

User-Agent-Erkennung im Shopify-Theme

 1// ──────────────────────────────────────────────
 2// TRICK 1: User-Agent-Erkennung
 3// Prüft, ob der Besucher ein Lighthouse-Bot ist.
 4// Nur Bots bekommen die "optimierte" Version.
 5// ──────────────────────────────────────────────
 6
 7const ua = navigator.userAgent;
 8
 9// Lighthouse sendet "Chrome-Lighthouse" im User-Agent,
10// PageSpeed Insights sendet "PageSpeed"
11const isBot = ua.indexOf("Chrome-Lighthouse") > -1
12            || ua.indexOf("PageSpeed") > -1;
13
14if (isBot) {
15  // Alle Bilder auf lazy-loading setzen
16  // → Lighthouse zählt sie nicht zur Ladezeit
17  document.querySelectorAll("img:not([loading])").forEach(el => {
18    el.setAttribute("loading", "lazy");
19  });
20
21  // Flag setzen: Andere Scripts prüfen diesen Wert
22  // und laden Apps, Tracking etc. nicht
23  window.__blockThirdParty = true;
24}
25
26// Ergebnis: Bot sieht Score 95+, Kunde sieht Score 35

// ──────────────────────────────────────────────
// TRICK 1: User-Agent-Erkennung
// Prüft, ob der Besucher ein Lighthouse-Bot ist.
// Nur Bots bekommen die "optimierte" Version.
// ──────────────────────────────────────────────

const ua = navigator.userAgent;

// Lighthouse sendet "Chrome-Lighthouse" im User-Agent,
// PageSpeed Insights sendet "PageSpeed"
const isBot = ua.indexOf("Chrome-Lighthouse") > -1
            || ua.indexOf("PageSpeed") > -1;

if (isBot) {
  // Alle Bilder auf lazy-loading setzen
  // → Lighthouse zählt sie nicht zur Ladezeit
  document.querySelectorAll("img:not([loading])").forEach(el => {
    el.setAttribute("loading", "lazy");
  });

  // Flag setzen: Andere Scripts prüfen diesen Wert
  // und laden Apps, Tracking etc. nicht
  window.__blockThirdParty = true;
}

// Ergebnis: Bot sieht Score 95+, Kunde sieht Score 35

Effekt: Lighthouse sieht eine „schnelle" Seite, weil fast nichts geladen wird. Echte Besucher bekommen weiterhin die volle, unoptimierte Seite.

2. Aggressives Script-Deferring

Alle JavaScript-Dateien werden erst bei Interaktion geladen:

Aggressives Script-Deferring

 1// ──────────────────────────────────────────────
 2// TRICK 2: Aggressives Script-Deferring
 3// Kein einziges Script wird geladen, bis der
 4// Nutzer scrollt, klickt oder tippt.
 5// Lighthouse interagiert nie → sieht 0 KB JS.
 6// ──────────────────────────────────────────────
 7
 8// Drei Events überwachen — sobald eines feuert,
 9// werden ALLE Scripts auf einmal nachgeladen
10const triggers = ["scroll", "click", "touchstart"];
11
12triggers.forEach(event => {
13  document.addEventListener(event, loadEverything, {
14    once: true   // Nur einmal auslösen
15  });
16});
17
18function loadEverything() {
19  // Alle Scripts haben data-src statt src —
20  // der Browser ignoriert sie komplett
21  document.querySelectorAll("script[data-src]").forEach(el => {
22    el.src = el.dataset.src;  // Jetzt laden
23  });
24
25  // Problem: 20-40 Scripts laden gleichzeitig.
26  // Der Shop friert beim ersten Klick ein.
27}

// ──────────────────────────────────────────────
// TRICK 2: Aggressives Script-Deferring
// Kein einziges Script wird geladen, bis der
// Nutzer scrollt, klickt oder tippt.
// Lighthouse interagiert nie → sieht 0 KB JS.
// ──────────────────────────────────────────────

// Drei Events überwachen — sobald eines feuert,
// werden ALLE Scripts auf einmal nachgeladen
const triggers = ["scroll", "click", "touchstart"];

triggers.forEach(event => {
  document.addEventListener(event, loadEverything, {
    once: true   // Nur einmal auslösen
  });
});

function loadEverything() {
  // Alle Scripts haben data-src statt src —
  // der Browser ignoriert sie komplett
  document.querySelectorAll("script[data-src]").forEach(el => {
    el.src = el.dataset.src;  // Jetzt laden
  });

  // Problem: 20-40 Scripts laden gleichzeitig.
  // Der Shop friert beim ersten Klick ein.
}

Effekt: Lighthouse interagiert nicht – sieht eine Seite ohne JS. Für echte Nutzer: Beim ersten Klick friert alles ein, weil Dutzende Scripts gleichzeitig laden.

3. CLS-Manipulation

CLS-Manipulation

 1// ──────────────────────────────────────────────
 2// TRICK 3: CLS-Manipulation
 3// Elemente werden unsichtbar gemacht, damit
 4// sie beim Laden keinen Layout-Shift erzeugen.
 5// CLS-Score sinkt — aber auf Kosten der UX.
 6// ──────────────────────────────────────────────
 7
 8// Schritt 1: Sofort beim Laden alle markierten
 9// Elemente komplett verstecken
10document.querySelectorAll("[data-defer-render]").forEach(el => {
11  el.style.opacity = "0";    // Unsichtbar
12  el.style.height = "0";     // Kein Platz im Layout
13  el.style.overflow = "hidden";
14});
15
16// Schritt 2: Nach dem Load-Event alles einblenden.
17// Lighthouse misst CLS nur während des Ladens —
18// was danach passiert, zählt nicht mehr.
19window.addEventListener("load", () => {
20  setTimeout(() => {
21    document.querySelectorAll("[data-defer-render]").forEach(el => {
22      el.style.opacity = "1";
23      el.style.height = "auto";
24    });
25  }, 100);  // 100ms Delay als Sicherheitspuffer
26});
27
28// Ergebnis: Der Nutzer sieht eine leere Seite,
29// die sich plötzlich mit Inhalt füllt.

// ──────────────────────────────────────────────
// TRICK 3: CLS-Manipulation
// Elemente werden unsichtbar gemacht, damit
// sie beim Laden keinen Layout-Shift erzeugen.
// CLS-Score sinkt — aber auf Kosten der UX.
// ──────────────────────────────────────────────

// Schritt 1: Sofort beim Laden alle markierten
// Elemente komplett verstecken
document.querySelectorAll("[data-defer-render]").forEach(el => {
  el.style.opacity = "0";    // Unsichtbar
  el.style.height = "0";     // Kein Platz im Layout
  el.style.overflow = "hidden";
});

// Schritt 2: Nach dem Load-Event alles einblenden.
// Lighthouse misst CLS nur während des Ladens —
// was danach passiert, zählt nicht mehr.
window.addEventListener("load", () => {
  setTimeout(() => {
    document.querySelectorAll("[data-defer-render]").forEach(el => {
      el.style.opacity = "1";
      el.style.height = "auto";
    });
  }, 100);  // 100ms Delay als Sicherheitspuffer
});

// Ergebnis: Der Nutzer sieht eine leere Seite,
// die sich plötzlich mit Inhalt füllt.

Der Nutzer sieht eine leere Seite, die sich plötzlich füllt. Das „löst" CLS – und erzeugt gleichzeitig neuen.

4. Cross-Store Script-Loading (die neueste Methode)

Der raffinierteste Trick: Die Hack-Scripts liegen nicht mehr im eigenen Theme, sondern werden von einem komplett fremden Shopify-Shop geladen. Im Quellcode betroffener Shops findet man Zeilen wie diese:

Cross-Store Script-Loading im Quellcode

 1<!-- ──────────────────────────────────────────── -->
 2<!-- TRICK 4: Cross-Store Script-Loading          -->
 3<!-- Scripts liegen NICHT im eigenen Theme,        -->
 4<!-- sondern auf fremden Fake-Shopify-Shops.       -->
 5<!-- Kein async, kein defer — synchron geladen.    -->
 6<!-- ──────────────────────────────────────────── -->
 7
 8<!-- Fake-Shop 1: (Name anonymisiert) -->
 9<script src="https://fake-shop-a.myshopify.com/cdn/shop/t/1/assets/asyncLoadG.js"></script>
10<script src="https://fake-shop-a.myshopify.com/cdn/shop/t/1/assets/component-9.9.9.js"></script>
11<script src="https://fake-shop-a.myshopify.com/cdn/shop/t/1/assets/network-9.0.19.js"></script>
12
13<!-- Fake-Shop 2: (Name anonymisiert) -->
14<script src="https://fake-shop-b.myshopify.com/cdn/shop/t/1/assets/network-1.0.0.js"></script>

Diese Fake-Shops sind keine echten Shops – sie existieren nur als Hosting-Plattform für die Hack-Scripts. Wir haben den dreifach obfuskierten Code decodiert. Das steckt tatsächlich drin:

Decodiert: asyncLoadG.js

 1// ──────────────────────────────────────────────
 2// asyncLoadG.js (nach Decodierung)
 3// Originalcode ist Base64 + URL-Encoding
 4// + String.fromCharCode() verschlüsselt
 5// ──────────────────────────────────────────────
 6
 7// Plattform-Erkennung: "Linux x86_64" = Lighthouse-Server
 8var platform = String.fromCharCode(110,97,118) + "igator";
 9// → ergibt "navigator" — versteckt vor Scannern
10
11if (window[platform].userAgent.indexOf("X11") !== -1
12    && window[platform].userAgent.indexOf("GTmetrix") !== -1) {
13  // GTmetrix erkannt → Seite komplett neu schreiben
14}
15
16// ACHTUNG: document.open() wird IMMER aufgerufen,
17// nicht nur bei Bot-Erkennung — Race Condition!
18document.open();  // Löscht den gesamten DOM

// ──────────────────────────────────────────────
// asyncLoadG.js (nach Decodierung)
// Originalcode ist Base64 + URL-Encoding
// + String.fromCharCode() verschlüsselt
// ──────────────────────────────────────────────

// Plattform-Erkennung: "Linux x86_64" = Lighthouse-Server
var platform = String.fromCharCode(110,97,118) + "igator";
// → ergibt "navigator" — versteckt vor Scannern

if (window[platform].userAgent.indexOf("X11") !== -1
    && window[platform].userAgent.indexOf("GTmetrix") !== -1) {
  // GTmetrix erkannt → Seite komplett neu schreiben
}

// ACHTUNG: document.open() wird IMMER aufgerufen,
// nicht nur bei Bot-Erkennung — Race Condition!
document.open();  // Löscht den gesamten DOM

Decodiert: component-9.9.9.js

 1// ──────────────────────────────────────────────
 2// component-9.9.9.js (nach Decodierung)
 3// MutationObserver der ALLE neuen DOM-Knoten
 4// manipuliert, sobald ein Bot erkannt wird
 5// ──────────────────────────────────────────────
 6
 7const observer = new MutationObserver((mutations) => {
 8  mutations.forEach(mutation => {
 9    mutation.addedNodes.forEach(node => {
10
11      // IFRAME: src entfernen → nicht laden
12      if (node.tagName === "IFRAME")
13        node.removeAttribute("src");
14
15      // IMG: ab Bild 20 forced lazy-loading
16      if (node.tagName === "IMG" && imgCount++ > 20)
17        node.loading = "lazy";
18
19      // LINK (CSS): href entfernen → Styles nicht laden
20      if (node.tagName === "LINK")
21        node.removeAttribute("href");
22
23      // SCRIPT: src entfernen + Typ ändern → nicht ausführen
24      if (node.tagName === "SCRIPT") {
25        node.removeAttribute("src");
26        node.type = "text/lazyload";  // Browser ignoriert das
27      }
28    });
29  });
30});
31
32// Überwacht den GESAMTEN DOM-Baum
33observer.observe(document.documentElement, {
34  childList: true,
35  subtree: true
36});

// ──────────────────────────────────────────────
// component-9.9.9.js (nach Decodierung)
// MutationObserver der ALLE neuen DOM-Knoten
// manipuliert, sobald ein Bot erkannt wird
// ──────────────────────────────────────────────

const observer = new MutationObserver((mutations) => {
  mutations.forEach(mutation => {
    mutation.addedNodes.forEach(node => {

      // IFRAME: src entfernen → nicht laden
      if (node.tagName === "IFRAME")
        node.removeAttribute("src");

      // IMG: ab Bild 20 forced lazy-loading
      if (node.tagName === "IMG" && imgCount++ > 20)
        node.loading = "lazy";

      // LINK (CSS): href entfernen → Styles nicht laden
      if (node.tagName === "LINK")
        node.removeAttribute("href");

      // SCRIPT: src entfernen + Typ ändern → nicht ausführen
      if (node.tagName === "SCRIPT") {
        node.removeAttribute("src");
        node.type = "text/lazyload";  // Browser ignoriert das
      }
    });
  });
});

// Überwacht den GESAMTEN DOM-Baum
observer.observe(document.documentElement, {
  childList: true,
  subtree: true
});

Decodiert: network-9.0.19.js (YETT Script-Blocker)

 1// ──────────────────────────────────────────────
 2// network-9.0.19.js (nach Decodierung)
 3// Missbraucht die Open-Source-Library "YETT"
 4// als Script-Blocker — 16+ Blacklist-Patterns
 5// ──────────────────────────────────────────────
 6
 7// Nur aktiv auf Linux x86_64 (= Lighthouse-Server)
 8if (navigator.platform === "Linux x86_64") {
 9
10  // Alles blocken, was den Score drückt:
11  YETT_BLACKLIST = [
12    /klaviyo/,           // E-Mail-Marketing
13    /photoswipe/,        // Bildergalerie
14    /swiper-bundle/,     // Slider/Karussell
15    /stamped/,           // Bewertungen
16    /extensions/,        // Shopify-Erweiterungen
17    /apps/,              // ALLE Shopify Apps (!)
18    /storefront/,        // Storefront API
19    /googletagmanager/,  // Google Tag Manager
20    /facebook/,          // Facebook Pixel
21    /boomerang/,         // Performance-Monitoring
22    // ... und 6 weitere Patterns
23  ];
24}
25
26// YETT überschreibt document.createElement()
27// und blockiert alle Scripts die matchen —
28// Payment-Buttons, Chat-Widgets, alles weg.

// ──────────────────────────────────────────────
// network-9.0.19.js (nach Decodierung)
// Missbraucht die Open-Source-Library "YETT"
// als Script-Blocker — 16+ Blacklist-Patterns
// ──────────────────────────────────────────────

// Nur aktiv auf Linux x86_64 (= Lighthouse-Server)
if (navigator.platform === "Linux x86_64") {

  // Alles blocken, was den Score drückt:
  YETT_BLACKLIST = [
    /klaviyo/,           // E-Mail-Marketing
    /photoswipe/,        // Bildergalerie
    /swiper-bundle/,     // Slider/Karussell
    /stamped/,           // Bewertungen
    /extensions/,        // Shopify-Erweiterungen
    /apps/,              // ALLE Shopify Apps (!)
    /storefront/,        // Storefront API
    /googletagmanager/,  // Google Tag Manager
    /facebook/,          // Facebook Pixel
    /boomerang/,         // Performance-Monitoring
    // ... und 6 weitere Patterns
  ];
}

// YETT überschreibt document.createElement()
// und blockiert alle Scripts die matchen —
// Payment-Buttons, Chat-Widgets, alles weg.

Warum so umständlich? Tarnung. Shopify-CDN-URLs sehen vertrauenswürdig aus und passieren Content Security Policies. Und der Anbieter kann den Code aller Kunden gleichzeitig aktualisieren, ohne in deren Themes eingreifen zu müssen.

Das echte Risiko geht weit über Score-Manipulation hinaus: Die Scripts sind synchron eingebunden (kein async/defer). Fällt der Fake-Shop aus, sehen deine Kunden eine weiße Seite. Und schlimmer: Wer auch immer den Fake-Shop kontrolliert, kann den Script-Inhalt jederzeit ändern – Kreditkartendaten abgreifen, Redirects einbauen, Crypto-Miner injizieren. Das ist eine selbst eingebaute Sicherheitslücke.

Warum Shopify das verbietet

Shopify hat in den Theme Store Requirements definiert, dass Themes keine Techniken einsetzen dürfen, die Benchmark-Tools täuschen:

User-Agent-Sniffing – Erkennung von Lighthouse/PageSpeed
Script-Injection-Hacks – Shopifys Ladelogik überschreiben
Cloaking – Unterschiedliche Inhalte für Bots vs. echte Nutzer

Worst Case: Shopify kann deinen Shop sperren. Den Anbieter wird das nicht interessieren – er hat seine 10 € und ist weg.

Die echten Konsequenzen

Schlechtere echte Performance: Mehr JavaScript als vorher.
Kaputter Warenkorb: Payment-Buttons und Chat-Widgets funktionieren nicht sofort.
Null SEO-Vorteil: Google nutzt CrUX-Daten, nicht den Lighthouse-Score.
Theme-Updates unmöglich: Jedes Update kann den Hack brechen.

Aber mal ehrlich: Braucht jeder Shop eine Speedoptimierung?

Nein. Und das sagen wir bewusst. Eine Optimierung lohnt sich vor allem bei wirklich verbasteltem Code – zu viele Apps, schlechte Snippets, oder eben solche Drittanbieter-Scripts.

Minimale Score-Verbesserungen sind selten das Problem. Google wertet die realen Ladezeiten echter Besucher, nicht den Lighthouse-Score. Wenn deine CrUX-Werte grün sind und dein Shop sich schnell anfühlt, investiere lieber in Conversion-Optimierung oder Content.

Faustregel: Eine Speedoptimierung lohnt sich, wenn echte Nutzer warten – also wenn deine CrUX-Daten rot sind oder der Shop auf Mobilgeräten spürbar hängt.

Woran du erkennst, ob dein Shop betroffen ist

Quellcode prüfen: Strg+U, suche nach „Lighthouse", „userAgent", „PageSpeed", „data-src" oder „atob(".
Fremde Shops im Code? Suche nach .myshopify.com im Quelltext. Taucht eine Domain auf, die nicht deine eigene ist? Dann lädt dein Shop fremden Code.
Echte Ladezeit messen: Vergleiche Lighthouse mit CrUX in der Search Console. Große Abweichung = Manipulation.
Theme-Code checken: Online Store > Themes > Code bearbeiten. Unbekannte Script-Blöcke in der theme.liquid?

Was echte Shopify-Speed-Optimierung bedeutet

Bildoptimierung: WebP/AVIF, richtige Dimensionierung, natives Lazy-Loading
App-Audit: Überflüssige Apps entfernen
Theme-Code-Review: Liquid optimieren, tote Sections raus
Third-Party-Management: Scripts priorisieren, nicht verstecken
CrUX-Monitoring: Echte Nutzerdaten, nicht synthetische Tests

Das kostet mehr als 10 € – aber es bringt tatsächlich etwas. Mehr zu unserer Shopify-Speedoptimierung →

Fazit

Eine Shopify-Speedoptimierung für 10 € ist keine Optimierung – es ist eine Täuschung. Wenn du ein solches Script hast: entferne es. Wenn du echte Performance willst: investiere in eine ehrliche Analyse.

Kostenlose Ersteinschätzung anfordern

Speed-Scripts für 10 € aus Fiverr und Upwork manipulieren nur den Lighthouse-Score, nicht die echte Shop-Performance — und verstoßen gegen Shopifys Theme-Store-Requirements.

Typische Tricks: User-Agent-Cloaking gegen Lighthouse, aggressives Script-Deferring, CLS-Manipulation, Cross-Store-Loading.
Risiko: Abstrafung durch Shopify, schlechte Core Web Vitals für echte Nutzer, versteckte Performance-Schulden.
Echte Shopify-Speed-Optimierung arbeitet an Theme-Code, Bildformaten und App-Ballast — nicht am Score.

Cookies 🍪

Shopify Speed-Optimierung für 10 €? Was Drittanbieter-Scripts wirklich mit deinem Shop machen

Das Geschäftsmodell: Score-Manipulation statt echte Optimierung

Was die Scripts technisch machen

1. User-Agent-Erkennung (Lighthouse-Cloaking)

2. Aggressives Script-Deferring

3. CLS-Manipulation

4. Cross-Store Script-Loading (die neueste Methode)

Warum Shopify das verbietet

Die echten Konsequenzen

Aber mal ehrlich: Braucht jeder Shop eine Speedoptimierung?

Woran du erkennst, ob dein Shop betroffen ist

Was echte Shopify-Speed-Optimierung bedeutet

Fazit

Das könnte euch auch interessieren

Shopifys Commerce Readiness Check: Schnelltest für AI-Sichtbarkeit, mehr nicht

Shopify AI Toolkit: Erfahrung nach einer Woche Praxis

Beitrag teilen