Wichtigste Takeaways
- Render-blocking Scripts hindern den Browser daran, deine Seite anzuzeigen, bis sie geladen sind.
- 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 listet die Scripts und Stylesheets auf, die das Rendering blockieren.
Um render-blocking Scripts in Shopify zu beheben, füge defer (Theme-Scripts) oder async (unabhängige Analytics-Scripts) zu den <script>-Tags im <head> deiner theme.liquid hinzu und entferne App-Scripts, die du nicht mehr nutzt.
Wenn ein Browser auf ein <script>-Tag in deinem HTML stößt, stoppt er, lädt das Script herunter, führt es aus und baut dann die Seite weiter auf. Wenn sich dieses Script in deinem <head> befindet, ist deine gesamte Seite eingefroren, während das Script lädt. Bei einer langsamen mobilen Verbindung ist diese Pause sichtbar — ein weißer Bildschirm, wo dein Shop sein sollte.
Dies nennt man „Parser Blocking“ oder „Render Blocking“ und es ist eines der gravierendsten Performance-Probleme, die du in Shopify beheben kannst.
Was verursacht Render-blocking Scripts in Shopify?
Script-Tags im <head> ohne async oder defer. Die häufigste Ursache. Scripts, die von Apps oder Anpassungen hinzugefügt werden, 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 das Rendern blockiert.
Drittanbieter-Analytics- und Marketing-Scripts. Google Tag Manager, Facebook Pixel und ähnliche Scripts werden oft im <head> platziert, weil es in deren Dokumentation so steht – aber sie sollten trotzdem async verwenden.
Der Unterschied zwischen async und defer
Beide verhindern Render-Blocking, aber sie verhalten sich unterschiedlich:
async: Das Script wird parallel heruntergeladen, während das HTML geparst wird. Es wird ausgeführt, sobald es fertig heruntergeladen ist – was das HTML-Parsing potenziell unterbricht. Nutze das für unabhängige Scripts, die nicht darauf angewiesen sind, dass das DOM fertig geladen ist (Analytics, Pixel).
defer: Das Script wird parallel heruntergeladen, während das HTML geparst wird. Es wird erst ausgeführt, nachdem das HTML vollständig geparst wurde, und zwar in der Reihenfolge des Dokuments. Nutze dies für Scripts, die mit dem DOM interagieren (Theme-Features, Produkt-Funktionen).
Kein Attribut (Standard): Das Script blockiert das HTML-Parsing komplett, während es herunterlädt und ausgeführt wird. Vermeide das für jegliche unkritischen Scripts im <head>.
Wie man Scripts in Shopify defer oder async hinzufügt
Schritt 1 – Dupliziere dein Theme.
Schritt 2 – Öffne die theme.liquid im Code-Editor.
Schritt 3 – Suche nach <script>-Tags im <head>-Bereich. Sie sehen so aus:
<script src="https://example.com/script.js"></script>Schritt 4 – Füge das passende Attribut hinzu:
<!-- Für Analytics/Pixel-Scripts: -->
<script src="https://analytics.example.com/script.js" async></script>
<!-- Für Theme-Funktions-Scripts: -->
<script src="{{ 'theme.js' | asset_url }}" defer></script>Wichtig: Füge nicht blind bei allen Scripts async hinzu. Wenn Script B von Script A abhängig ist, kann es passieren, dass Script B fehlschlägt, wenn Script A asynchron ist und Script B zuerst lädt.
Die Nutzung von Shopifys {% javascript %}-Blöcken in Sections
Die sauberste Lösung für Theme-Funktionalität: Packe JavaScript in Section-Dateien mit {% javascript %}-Tags, anstatt in globale theme.liquid-Scripts.
{% javascript %}
// Dieses JavaScript wird:
// 1. Automatisch mit anderem Section-JS gebündelt
// 2. Automatisch von Shopify per 'defer' verzögert
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 (deferred) geladen wird. So bleibt der Code der Section eigenständig (self-contained).
Render-Blocking im GTM beheben
Das Install-Snippet vom Google Tag Manager platziert ein <script>-Tag im <head>. Die Standard-Installation sieht so aus:
<script>
(function(w,d,s,l,i){...})(window,document,'script','dataLayer','GTM-XXXXX');
</script>Das ist bereits ein Inline-Script (ohne src), also funktionieren async/defer hier nicht auf die gleiche Weise. Das GTM-Snippet ist so konzipiert, dass es klein und schnell ist — das eigentliche Performance-Problem sind die Tags innerhalb deines GTM-Containers.
Stelle in GTM alle Tags so ein, dass sie bei „Window Loaded“ oder „DOM Ready“ feuern, anstatt bei „Page View“, es sei denn, sie müssen wirklich zwingend vor dem Rendern der Seite ausgeführt werden. Dadurch wird die Tag-Ausführung auf den Zeitpunkt verschoben, an dem die Seite bereits sichtbar ist.
Für den Rest der Speed-Checkliste, sieh dir an, wie du ein Shopify-Theme schneller machst.
Render-blocking Scripts identifizieren
PageSpeed Insights: Teste deine Shop-URL auf pagespeed.web.dev. PageSpeed Insights markiert diese als render-blocking Requests und listet jedes Script und Stylesheet nach URL auf.
Chrome DevTools — Performance-Tab: Zeichne einen Seitenaufruf auf. Achte im Flame-Chart darauf, ob Parse HTML-Events am Anfang der Timeline durch Evaluate Script-Events unterbrochen werden.
Shopify Theme Inspector: Zeigt, welche Liquid-Templates am langsamsten rendern. Für Script-bedingtes Blocking solltest du stattdessen PageSpeed Insights nutzen.
Und was ist mit Render-blocking CSS?
CSS ist von Natur aus render-blockierend – der Browser braucht das CSS, bevor er irgendwas rendern (malen) kann. Du kannst die Auswirkungen aber minimieren:
Kritisches CSS inline: Packe das CSS, das zum Rendern der Above-the-fold-Inhalte nötig ist, direkt inline in den <head>. Lade das restliche CSS asynchron mit <link rel="preload"> in Kombination mit onload.
Ungenutztes CSS entfernen: Weniger CSS-Regeln = schnellere Parse-Zeit.
Vermeide CSS @import in Stylesheets: Diese erzeugen blockierende Kaskaden-Anfragen.
Für die meisten Shopify-Stores sind die Gewinne aus CSS-Optimierungen kleiner als das Beheben von JavaScript-Blocking. Konzentriere dich also zuerst auf JavaScript.
FAQ
Sollte ich async oder defer zum Google Tag Manager Script hinzufügen?
Die Standardinstallation von GTM ist ein Inline-Script (ohne src) — async/defer lassen sich nicht direkt anwenden. Das GTM-Bootstrap-Snippet ist klein und schnell. Das eigentliche Performance-Problem sind die Tags in deinem GTM-Container. Setze die Tag-Trigger auf "Window Loaded" oder "DOM Ready" statt auf "Page View", damit sie erst nach dem kritischen Rendern feuern, nicht davor.
Warum verbessert das Deferren von Scripts meinen PageSpeed-Score nicht?
Drei häufige Gründe: (1) Das Script, das du mit defer versehen hast, war gar nicht render-blocking (bereits async oder below the fold), (2) andere render-blocking Ressourcen (CSS, Fonts) sind weiterhin der Flaschenhals, oder (3) die Total Blocking Time (TBT) wird von der Ausführung des Scripts dominiert, nicht nur vom Download — defer behebt keine langsame Ausführung, blockiert aber immerhin den Download nicht.
Kann ich Scripts ans Ende der Seite schieben, statt defer zu nutzen?
Ja — das Platzieren von Scripts vor </body> hat historisch gesehen ein ähnliches Non-Blocking-Verhalten erzeugt. 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 für die Wartbarkeit sauberer.
Macht das Deferren von Scripts Apps kaputt, die von jQuery oder anderen Libraries abhängen?
Möglicherweise. Scripts, die darauf angewiesen sind, dass eine Library bereits geladen ist, schlagen fehl, wenn die Library noch nicht vollständig ausgeführt wurde. Lösung: Verziere Scripts in der Reihenfolge ihrer Abhängigkeiten mit defer. Scripts mit defer werden in der Dokumentenreihenfolge ausgeführt — setze das Library-Tag an die erste Stelle. Scripts mit async können in beliebiger Reihenfolge ausgeführt werden; prüfe also Abhängigkeiten, bevor du async hinzufügst.
Wie finde ich render-blocking Scripts, die ich nicht selbst hinzugefügt habe?
PageSpeed Insights markiert diese als render-blocking Requests und listet jedes per URL auf. Scripts, die du nicht selbst hinzugefügt hast, stammen normalerweise von installierten Apps. Gehe zu Einstellungen → Apps, um herauszufinden, welche App das blockierende Script lädt — und deaktiviere Apps, die du nicht mehr nutzt. Das Entfernen von Apps ist die wirkungsvollste Maßnahme für die Performance. Um die Funktion ohne den Script-Ballast der App zu behalten, beschreibe Fudge, dem KI-Operator für Shopify-Shops, was die App macht, und er baut dir eine native Version direkt in dein Theme ein, die nur dort geladen wird, wo sie genutzt wird. Langsame Seiten gehören übrigens auch zu den Dingen, die Fudge überprüft, wenn er analysiert, wo Käufer abspringen.
