Eine Website die nach dem Launch langsam ist, obwohl alles optimiert wurde – meistens sind Third-Party Scripts der Übeltäter. Chat-Widgets, Marketing-Pixel, Cookie-Banner, Heatmap-Tools und Social-Buttons laden von externen Servern und blockieren das Rendering. Google misst das und bewertet es im Core Web Vitals-Score.
Was Third-Party Scripts sind
Third-Party Scripts sind JavaScript-Code der von externen Servern geladen wird – nicht Ihrem eigenen. Sie kommen von:
Analytics und Tracking: Google Analytics, Google Tag Manager, Facebook Pixel, LinkedIn Insight Tag, Hotjar, Microsoft Clarity
Chat und Support: Intercom, Drift, Zendesk Chat, Tawk.to, LiveChat
Marketing: HubSpot Tracking, Salesforce Pardot, Mailchimp Forms, Calendly-Widgets
Social Media: Facebook Like-Button, Twitter-Embeds, Instagram-Feed-Plugins
Technisch: Cookie-Consent-Manager (Cookiebot, OneTrust), A/B-Testing (Google Optimize, Optimizely)
Laut WebPageTest-Analysen sind Third-Party Scripts für 35–50 % der gesamten Ladezeit auf typischen Business-Websites verantwortlich – oft mehr als alle eigenen Assets zusammen.
Wie Third-Party Scripts Core Web Vitals beeinflussen
LCP (Largest Contentful Paint):
Scripts die synchron im <head> geladen werden, blockieren das Rendering. Das Hero-Bild oder die Headline – das LCP-Element – kann nicht gerendert werden bis das Script geladen ist.
TBT/INP (Total Blocking Time / Interaction to Next Paint): Schwere Scripts (Facebook Pixel, HubSpot) führen zu langen JS-Ausführungszeiten. Der Browser ist blockiert, Nutzereingaben werden verzögert verarbeitet.
CLS (Cumulative Layout Shift): Scripts die Elemente nach dem Laden in die Seite einfügen (Chat-Widgets, Cookie-Banner) verschieben bestehende Inhalte → CLS-Schaden.
Die schlimmsten Übeltäter
Facebook Pixel: Lädt ~100KB JavaScript, blockiert den Main Thread. Immer asynchron laden, nicht synchron im <head>.
Google Tag Manager mit vielen Tags: GTM selbst ist klein, aber ein schlecht konfigurierter Tag Manager der 15 Tracking-Tags lädt ist katastrophal. Regelmäßiges Tag-Audit notwendig.
Chat-Widgets: Intercom und Drift laden 300–500KB JavaScript beim ersten Besuch. Für viele B2B-Websites eine der größten Performance-Bremsen.
Hotjar/FullStory: Session-Recording-Tools laden erhebliche Script-Mengen. Nur auf Seiten aktivieren wo Sie aktiv Daten auswerten.
Schriftarten von Google Fonts (externe Version): Zwei Extra-Requests, externe DNS-Auflösung. Lokal hosten ist besser (auch DSGVO).
Analysieren Sie mit Chrome DevTools Network-Tab oder WebPageTest welche Scripts wie lange laden. Filtern Sie nach „Third Party" und sortieren nach Größe. Überraschung: Oft ist ein Widget das „nur kurz" integriert wurde der größte Performance-Killer.
Scripts optimieren ohne sie zu entfernen
Nicht jedes Script kann entfernt werden. Aber fast jedes kann besser eingebunden werden:
Async und Defer:
<!-- Blockierend (schlecht): -->
<script src="https://example.com/widget.js"></script>
<!-- Nicht-blockierend (besser): -->
<script src="https://example.com/widget.js" async></script>
<!-- oder -->
<script src="https://example.com/widget.js" defer></script>async lädt parallel, führt sofort aus wenn fertig.
defer lädt parallel, führt erst nach HTML-Parsing aus.
Lazy Loading für nicht-kritische Scripts:
<!-- Script erst laden wenn Nutzer scrollt: -->
<script>
window.addEventListener('scroll', function() {
var script = document.createElement('script');
script.src = 'https://widget.example.com/chat.js';
document.head.appendChild(script);
}, { once: true });
</script>Google Tag Manager Firing Rules: Tags nur auf Seiten feuern wo sie gebraucht werden – nicht global auf jeder Seite.
Welche Scripts wirklich notwendig sind
Kritische Überprüfung des Script-Inventars:
| Script | Wirklich nötig? | Alternative |
|---|---|---|
| Google Analytics 4 | Meist ja | Via GTM, asynchron |
| Facebook Pixel | Nur wenn FB-Ads aktiv | Entfernen wenn keine Ads |
| Hotjar | Nur in Analyse-Phasen | Zeitweise aktivieren |
| Live-Chat | Branchenabhängig | Lazy Load nach 3 Sek. |
| Social-Buttons | Selten | Link statt Widget |
Websites die Third-Party-Scripts auf das Minimum reduzieren und verbleibende Scripts asynchron laden, verbessern ihren TBT-Score (Total Blocking Time) im Schnitt um 300–500ms – genug für eine Verbesserung von „Verbesserungsbedarf” auf „Gut” in PageSpeed Insights.
Mehr zu Performance finden Sie in unserem Artikel über render-blocking Ressourcen.