Wichtige Erkenntnisse
- Render-blocking Scripts verzögern die Anzeige deiner Seite im Browser — jede Millisekunde kostet Conversions.
- Lösung: Füge
deferoderasynczu nicht-kritischen<script>-Tags in der theme.liquid hinzu.- Shopifys
{% javascript %}-Tag in Sections bündelt und verzögert Scripts automatisch.- PageSpeed Insights und der Shopify Theme Inspector identifizieren beide Render-blocking Ressourcen.
Wenn ein Browser auf ein <script>-Tag in deinem HTML stößt, hält er an, lädt das Script herunter, führt es aus und setzt dann den Aufbau der Seite fort. Wenn sich dieses Script in deinem <head> befindet, ist die gesamte Seite eingefroren, während das Script geladen wird. Bei einer langsamen mobilen Verbindung ist diese Pause sichtbar — ein weißer Bildschirm dort, wo eigentlich dein Store sein sollte.
Dies wird als “Parser blocking” oder “Render blocking” bezeichnet und ist eines der wirkungsvollsten Performance-Probleme, die man in Shopify beheben kann.
Was verursacht Render-blocking Scripts in Shopify
Script-Tags im <head> ohne async oder defer. Die häufigste Ursache. Scripts, die durch Apps oder Anpassungen hinzugefügt wurden, enthalten oft ein einfaches <script src="..."> ohne eines der beiden Attribute.
Große Theme-JavaScript-Dateien, die synchron geladen werden. Einige ältere Themes laden ihr gesamtes JavaScript im <head>, was den Paint-Vorgang blockiert.
Analytics- und Marketing-Scripts von Drittanbietern. Google Tag Manager, Facebook Pixel und ähnliche Scripts werden häufig im <head> platziert, weil deren Dokumentation das so vorgibt — sie sollten aber dennoch async verwenden.
Der Unterschied zwischen async und defer
Beide verhindern das Render-blocking, verhalten sich aber unterschiedlich:
async: Das Script wird parallel zum HTML-Parsing heruntergeladen. Es wird ausgeführt, sobald der Download abgeschlossen ist — was das HTML-Parsing unterbrechen kann. Verwende dies für unabhängige Scripts, die nicht darauf angewiesen sind, dass das DOM bereit ist (Analytics, Pixel).
defer: Das Script wird parallel zum HTML-Parsing heruntergeladen. Es wird erst ausgeführt, wenn das HTML vollständig geparst ist, und zwar in der Reihenfolge des Dokuments. Verwende dies für Scripts, die mit dem DOM interagieren (Theme-Features, Produktfunktionalität).
Kein Attribut (Standard): Das Script blockiert das HTML-Parsing vollständig, während es heruntergeladen und ausgeführt wird. Vermeide dies für alle nicht-kritischen Scripts im <head>.
So fügst du defer oder async zu Scripts in Shopify hinzu
Schritt 1 - Dupliziere dein Theme.
Schritt 2 - Öffne theme.liquid im Code-Editor.
Schritt 3 - Suche nach <script>-Tags im <head>-Bereich. Diese sehen so aus:
<script src="https://example.com/script.js"></script>Schritt 4 - Füge das entsprechende Attribut hinzu:
<!-- Für Analytics/Pixel-Scripts: -->
<script src="https://analytics.example.com/script.js" async></script>
<!-- Für Theme-Funktionalitäts-Scripts: -->
<script src="{{ 'theme.js' | asset_url }}" defer></script>Wichtig: Füge nicht blindlings async zu allen Scripts hinzu. Wenn Script B von Script A abhängt, kann das Setzen von Script A auf async dazu führen, dass Script B fehlschlägt, falls Script B zuerst geladen wird.
Verwendung von Shopifys {% javascript %}-Blöcken in Sections
Die sauberste Lösung für Theme-Funktionen: Packe JavaScript mit {% javascript %}-Tags direkt in die Section-Dateien, anstatt in globale theme.liquid Scripts.
{% javascript %}
// Dieses JavaScript wird:
// 1. Automatisch mit anderem Section-JS gebündelt
// 2. Von Shopify automatisch verzögert (deferred)
// 3. Nur geladen, wenn die Section verwendet wird
document.querySelector('.my-section').addEventListener('click', function() {
// Section-spezifisches Verhalten
});
{% endjavascript %}Shopify kompiliert alle {% javascript %}-Blöcke der Sections in ein einziges optimiertes Bundle (shopify-section-*.js), das verzögert geladen wird. Dies ist die Architektur, die Shopify für die Theme-Entwicklung empfiehlt.
Behebung von GTM Render-blocking
Das Installations-Snippet des Google Tag Managers platziert ein <script>-Tag im <head>. Die Standardinstallation sieht so aus:
<script>
(function(w,d,s,l,i){...})(window,document,'script','dataLayer','GTM-XXXXX');
</script>Dies ist bereits ein Inline-Skript (ohne src), daher greifen async/defer hier nicht auf die gleiche Weise. Das GTM-Snippet ist darauf ausgelegt, klein und schnell zu sein — das eigentliche Performance-Problem sind die Tags innerhalb deines GTM-Containers.
Verwandt: Ein Shopify-Theme schneller machen.
Stelle im GTM alle Tags so ein, dass sie bei “Window Loaded” oder “DOM Ready” ausgelöst werden, anstatt bei “Page View”, es sei denn, sie müssen zwingend vor dem Rendern der Seite ausgelöst werden. Dadurch wird die Ausführung der Tags auf den Zeitpunkt verschoben, an dem die Seite bereits sichtbar ist.
Identifizierung von Render-blocking Scripts
PageSpeed Insights: Teste deine Store-URL unter pagespeed.web.dev. Suche unter “Empfehlungen” nach “Ressourcen beseitigen, die das Rendering blockieren”. Dort werden die spezifischen Scripts und Stylesheets aufgelistet, die das Problem verursachen.
Chrome DevTools — Tab Performance: Zeichne einen Ladevorgang der Seite auf. Suche im Flame-Chart nach Parse HTML-Events, die zu Beginn der Timeline durch Evaluate Script-Events unterbrochen werden.
Shopify Theme Inspector: Zeigt, welche Liquid-Templates am langsamsten rendern. Für scriptbezogenes Blocking solltest du stattdessen PageSpeed Insights verwenden.
Verwandt: Speed Up a Shopify Theme.
Was ist mit Render-blocking CSS?
CSS ist von Natur aus Render-blocking — der Browser benötigt CSS, bevor er etwas rendern kann. Aber du kannst die Auswirkungen minimieren:
Critical CSS inline: Füge das CSS, das für das Rendern von Above-the-fold-Content benötigt wird, als Inline-Code in den <head> ein. Lade den Rest deines CSS asynchron über <link rel="preload"> mit onload.
Entferne ungenutztes CSS: Weniger CSS-Regeln = schnellere Parse-Zeit.
Vermeide CSS @import in Stylesheets: Diese erzeugen kaskadierende, blockierende Requests.
Für die meisten Shopify-Stores fallen die Verbesserungen durch CSS-Optimierung geringer aus als durch die Behebung von JavaScript-Blocking. Konzentriere dich also zuerst auf JavaScript.
FAQ
Die Standardinstallation des GTM ist ein Inline-Skript (ohne src) — async/defer greifen hier nicht direkt. Das GTM-Bootstrap-Snippet ist klein und schnell. Das eigentliche Performance-Problem sind die Tags in deinem GTM-Container. Stelle Tag-Trigger auf "Window Loaded" oder "DOM Ready" anstatt auf "Page View", damit sie nach dem kritischen Rendern ausgelöst werden und nicht davor.
Drei häufige Gründe: (1) Das Skript mit defer war gar nicht render-blockierend (bereits async oder below the fold), (2) andere render-blockierende Ressourcen (CSS, Fonts) sind immer noch der Flaschenhals, oder (3) die Total Blocking Time (TBT) wird durch die Ausführung des Skripts dominiert, nicht nur durch den Download — defer löst keine langsame Ausführung, es verhindert nur das Blockieren beim Herunterladen.
Ja — das Platzieren von Skripten vor </body> hat in der Vergangenheit ein ähnliches nicht-blockierendes Verhalten erreicht. Moderne Best Practices bevorzugen jedoch defer, da es die Ausführungsreihenfolge beibehält und unabhängig davon funktioniert, wo das Tag im HTML platziert ist. Beides funktioniert; defer ist aber sauberer für die Wartbarkeit.
Möglicherweise. Skripte, die darauf angewiesen sind, dass eine Bibliothek bereits geladen ist, schlagen fehl, wenn die Bibliothek noch nicht fertig ausgeführt wurde. Lösung: Verzögere Skripte in der Reihenfolge ihrer Abhängigkeiten. Skripte mit defer werden in der Reihenfolge des Dokuments ausgeführt — setze das Bibliotheks-Tag also nach ganz oben. Skripte mit async können in beliebiger Reihenfolge ausgeführt werden; prüfe also die Abhängigkeiten, bevor du async hinzufügst.
PageSpeed Insights → Diagnose → "Render-blockierende Ressourcen beseitigen" listet jede blockierende Ressource nach URL auf. Skripte, die du nicht selbst hinzugefügt hast, stammen meist von installierten Apps. Überprüfe in den Einstellungen → Apps, welche App welches blockierende Skript lädt — und deaktiviere Apps, die du nicht mehr nutzt. Das Entfernen von Apps bringt meist den größten Performance-Boost. Um ein Feature ohne das zusätzliche Gewicht des App-Skripts zu behalten, beschreibe Fudge einfach, was die App macht, und lass dir eine native Version direkt in dein Theme einbauen.
Verwandt: CSS und JavaScript in Shopify minifizieren.
Verwandt: Nicht verwendeten Code in Shopify entfernen.