Viele B2B-Webflow-Websites werden nicht durch Design oder Hosting langsam, sondern durch Tracking-, Chat- und Marketing-Skripte. Dieser Beitrag zeigt, wie du Third-Party-Skripte sauber prüfst, verzögert lädst und consent-basiert steuerst.
Stell dir vor, du öffnest eine Website und der Browser arbeitet im Hintergrund gleichzeitig an zehn verschiedenen Aufgaben: Er lädt das HubSpot-Tracking, baut eine Verbindung zu Intercom auf, initialisiert den LinkedIn Insight Tag, fragt Hotjar-Daten ab und wartet auf die Antwort des Google Tag Managers. All das, bevor die eigentliche Seite vollständig aufgebaut ist.
Genau das passiert in vielen B2B-Webflow-Projekten – nicht aus Nachlässigkeit, sondern weil Skripte über Monate und Jahre hinweg von verschiedenen Personen eingebunden werden, ohne dass jemand das Gesamtbild im Blick hat. Das Ergebnis: eine Seite, die technisch solide aufgebaut ist, aber unter der Last der Drittanbieter-Skripte langsam wird.
Dieser Artikel zeigt, wie diese Skripte den Seitenaufbau beeinflussen, welche Einbindungsmethoden wirklich einen Unterschied machen – und wie Google Tag Manager als zentraler Steuerungspunkt dabei hilft, die Kontrolle zurückzugewinnen.
Wer zuerst verstehen möchte, wie Core Web Vitals grundsätzlich funktionieren und warum sie B2B-Conversions beeinflussen, findet dazu einen eigenen Artikel in unserem Magazin.
Die Liste der üblichen Verdächtigen ist in den meisten Projekten ähnlich:
Die entscheidende Frage vor jedem Skript: Wird es aktiv genutzt? In vielen Projekten finden sich Skripte, die vor Monaten eingebunden wurden und deren zugehörige Kampagne oder Tool längst abgelaufen ist.
Um zu verstehen, warum Third-Party-Skripte so viel Einfluss auf die Ladezeit haben, hilft ein kurzer Blick darauf, wie der Browser eine Seite verarbeitet.
Standardmäßig liest der Browser HTML von oben nach unten. Sobald er auf ein <script>-Tag trifft, hält er an, lädt das Skript herunter, führt es aus – und macht erst dann weiter. Das nennt sich render-blocking: Die Seite kann nicht vollständig aufgebaut werden, solange das Skript nicht abgearbeitet ist.
async lädt das Skript parallel zum HTML-Parsing herunter und führt es sofort aus, sobald es fertig geladen ist – unabhängig davon, ob das HTML fertig geparst wurde. Das ist sinnvoll für Skripte, die keine bestimmte Reihenfolge benötigen und keine Abhängigkeiten von anderen Skripten haben, etwa einfache Analytics-Tags.
<script async src="https://example.com/analytics.js"></script>defer ist häufig eine gute Wahl für Skripte, die nicht unmittelbar vor dem Seitenaufbau ausgeführt werden müssen. Bei GTM, Consent-Tools oder Tracking-Skripten mit früher Pageview-Messung sollte die Einbindung aber immer im konkreten Setup geprüft werden.
<script defer src="https://example.com/hubspot.js"></script>Die Faustregel: defer ist in den meisten Fällen die sicherere Wahl. async eignet sich für vollständig unabhängige Skripte. Kein Attribut zu setzen ist in fast keinem Fall die richtige Entscheidung.
Webflow bietet mehrere Stellen für Custom Code, die unterschiedliche Reichweiten haben:
Ein häufiger Fallstrick: Skripte, die in alten Formular-Setups, Chat-Widgets oder Cookie-Bannern stecken und nach einem Tool-Wechsel nie entfernt wurden. Sie laden still im Hintergrund mit, ohne dass jemand es bemerkt.
In Webflow gilt dieselbe Grundregel wie überall: Im <head> sollten nur Skripte landen, die zwingend vor dem Seitenaufbau ausgeführt werden müssen – etwa Consent Management Plattformen. Alle anderen Skripte ohne defer oder async hier zu platzieren, blockiert das Rendering.
Ein konkretes Beispiel für HubSpot in Webflow, eingebunden im Custom Code <head>-Bereich unter Project Settings:
<script defer src="//js.hs-scripts.com/XXXXXXX.js"></script>Das XXXXXXX wird durch die eigene HubSpot-Portal-ID ersetzt. Dadurch blockiert das Skript den initialen HTML-Aufbau weniger stark. Ob sich LCP, TBT oder INP verbessern, sollte anschließend gemessen werden. Wichtig: Bei Tools mit eigenen Einbindungsempfehlungen sollte geprüft werden, ob defer mit Formularen, Tracking-Funktionen oder Consent-Logik sauber zusammenspielt.
In vielen Projekten ist GTM der sinnvollste zentrale Steuerungspunkt für Tracking- und Marketing-Skripte – vorausgesetzt, der Container bleibt gepflegt und Consent-Signale sind sauber integriert. Der Vorteil von GTM: Über Tags und Trigger lässt sich steuern, wann ein Skript geladen wird – nicht nur ob. Die wichtigsten Trigger-Typen im Überblick:
Die wichtigste Erkenntnis: HubSpot, Intercom und Hotjar müssen nicht beim ersten Paint geladen sein. Mit dem Trigger Window Loaded warten sie, bis die eigentliche Seite vollständig aufgebaut ist. Das kann TBT reduzieren und frühe Interaktionen entlasten. Ob sich auch INP verbessert, hängt davon ab, wann und wie stark das jeweilige Skript den Main Thread belastet.
Für Chat-Widgets wie Intercom kann ein verzögerter Trigger besonders wirkungsvoll sein: Das Widget lädt zum Beispiel erst nach Scroll, nach einigen Sekunden oder nach einem Klick auf einen Chat-Button. Auf Seiten, auf denen der Chat nur selten genutzt wird, reduziert das unnötige Last beim ersten Seitenaufruf.
Eine Orientierung nach Skript-Typ hilft dabei, die richtige Strategie zu wählen:
Ein Aspekt, der bei der Skript-Optimierung häufig übersehen wird: Viele Third-Party-Skripte dürfen aus datenschutzrechtlichen Gründen erst nach einer aktiven Einwilligung des Nutzers geladen werden. Das betrifft insbesondere Tracking- und Marketing-Skripte wie den LinkedIn Insight Tag, HubSpot oder Hotjar.
Technisch bedeutet das: Die Skripte dürfen nicht beim Seitenaufruf geladen werden, sondern erst nachdem der Nutzer dem entsprechenden Zweck zugestimmt hat. Das lässt sich über die Kombination aus einer Consent Management Platform (CMP) und dem GTM Consent Mode realisieren.
Im GTM Consent Mode wartet ein Tag auf das Signal der CMP, bevor es feuert. Das setzt voraus, dass die CMP korrekt in GTM integriert ist und die entsprechenden Consent-Signale übergibt. Gängige CMPs wie Usercentrics oder Cookie Script bieten dafür native GTM-Integrationen.
Hinweis: Dieser Abschnitt gibt einen technischen Überblick und ersetzt keine rechtliche Beratung. Die konkreten Anforderungen sollten mit einem Datenschutzbeauftragten abgestimmt werden.
Bevor und nachdem du Skripte optimierst, lohnt sich ein Blick in die Netzwerk-Analyse – um zu verstehen, was sich verändert hat.
WebPageTest liefert das vollständige Wasserfall-Diagramm: Jede Ressource ist als horizontaler Balken dargestellt, der zeigt, wann sie angefordert wird, wie lange das Laden dauert und ob sie andere Ressourcen blockiert. Render-blocking-Skripte sind klar erkennbar, weil alle nachfolgenden Ressourcen erst nach ihnen beginnen.
Chrome DevTools Network-Tab ermöglicht eine schnelle Analyse im Browser direkt: Unter „Initiator" ist zu sehen, welches Skript welche weiteren Requests ausgelöst hat. Unter „Waterfall" wird die zeitliche Abfolge sichtbar. Der Filter auf „Script" zeigt ausschließlich JavaScript-Dateien und deren Ladedauer.
Besonders aussagekräftig sind LCP, INP und TBT. LCP zeigt, wann der Hauptinhalt sichtbar wird. INP zeigt, wie schnell die Seite auf Nutzerinteraktionen reagiert. TBT ist vor allem im Lab-Test hilfreich, um blockierende JavaScript-Arbeit sichtbar zu machen – und damit direkt den Einfluss von Skripten auf den Main Thread zu quantifizieren. Wer tiefer einsteigen möchte: Google PageSpeed Insights zeigt LCP, INP und CLS direkt auf Basis echter Nutzerdaten.
GTM hilft dabei, viele Skript-Probleme zu kontrollieren – vorausgesetzt, die Tags sind sauber konfiguriert und die Trigger sind bewusst gewählt. In vielen Projekten reicht das aus, um messbare Performance-Probleme zu reduzieren und einzelne Core-Web-Vitals-Werte zu verbessern.
Es gibt jedoch Situationen, in denen GTM allein nicht ausreicht. Wenn Skripte tief im Webflow Custom Code verankert sind, ohne Attribute eingebunden wurden und niemand mehr weiß, wozu sie gehören, ist eine systematische Bestandsaufnahme sinnvoller als punktuelle Korrekturen. Gleiches gilt für Projekte, bei denen der GTM-Container über Jahre gewachsen ist und Tags enthält, die längst nicht mehr aktiv sind.
Als erster Schritt empfiehlt sich eine ehrliche Bestandsaufnahme anhand dieser Checkliste:
In Projekten, bei denen diese Fragen keine klaren Antworten liefern, zahlt sich ein strukturierter Audit aus – eine vollständige Analyse aller eingebundenen Skripte, ihrer Notwendigkeit, ihrer Einbindungsmethode und ihres messbaren Einflusses auf die Ladezeit.
Third-Party-Skripte sind in B2B-Webflow-Projekten unvermeidlich, aber sie müssen nicht unkontrolliert laden. Mit einer sauberen Einbindung, defer für geeignete Skripte, GTM als zentralem Steuerungspunkt und bewusst gewählten Triggern lässt sich der Einfluss auf die Ladezeit deutlich reduzieren.
Der erste Schritt ist meistens der wirkungsvollste: eine ehrliche Bestandsaufnahme, welche Skripte überhaupt aktiv sind und welche davon seit Monaten ungenutzt mitladen. Wer dabei Unterstützung sucht, findet einen Überblick über unsere Webflow-Leistungen auf unserer Agenturseite.
Du möchtest wissen, welche Skripte deine Webflow-Website tatsächlich belasten? Im kostenlosen Webflow-Check prüfen wir, welche Tracking-, Chat- und Marketing-Skripte laden – und welche davon unnötig Performance kosten.
