Wie bremsen Skripte von Drittanbietern Ihre Website? Pixel, Chat und Tags

Wir, Talha Aslan und Team, sehen bei Ladezeitanalysen immer wieder dasselbe Muster. Das Problem steckt selten im eigenen Code der Website. Stattdessen sammelt es sich in externem Code, den jemand vor Jahren eingebaut und dann vergessen hat. In diesem Leitfaden zeigen wir Schritt für Schritt, wie Sie messen, verzögert laden und aufräumen. Außerdem behandeln wir den heikelsten Punkt: wie Sie dabei Ihr Conversion Tracking nicht beschädigen.

Allgemeine Tipps zur JavaScript Optimierung finden Sie in unserem Beitrag JavaScript und Ladezeit. Hier geht es ausschließlich um Code, der von außerhalb Ihrer Domain kommt.

Welcher Code zählt als Drittanbietercode?

Die Regel ist einfach, denn sie hängt nur von der Herkunft ab. Kommt der Code von einem anderen Server als Ihrer eigenen Domain, handelt es sich um Drittanbietercode. Nehmen Sie zum Beispiel einen Shop auf example.com. Die Seite lädt ein Analysetag, zwei Werbepixel, eine Chatblase, ein eingebettetes Video und ein Bewertungswidget. Jedes dieser Elemente ist eine eigene externe Ressource.

Typische Gruppen sind:

• Werbepixel und Conversionpixel von Such und Social Media Plattformen.
• Analysetools und Heatmaps.
• Livechat, Supporttools und Chatbots.
• Der Container des Tag Managers mit allen enthaltenen Tags.
• Eingebettete Videos, Karten und Social Media Feeds.
• Tools für A/B Tests, Personalisierung und Cookie Einwilligung.

Allerdings ist nicht jedes externe Skript ein Problem. Manche bringen Umsatz, manche liefern Messdaten und manche erfüllen rechtliche Pflichten. Die eigentliche Frage lautet also: Deckt der Nutzen die Kosten bei der Ladezeit? Deshalb besteht der erste Schritt darin, sichtbar zu machen, was woher kommt.

Warum verursachen Skripte von Drittanbietern Netzwerkverzögerungen?

Jede neue Domain bedeutet für den Browser eine neue Verbindung. Zunächst löst er den Namen auf. Dann baut er eine sichere Verbindung auf. Erst danach fordert er die Datei an. Der Leitfaden von web.dev zum effizienten Laden von JavaScript aus fremden Quellen hält klar fest, dass Anfragen an viele verschiedene Server eine Seite verlangsamen.

Zudem kommen diese Skripte selten allein. Ein einzelnes Pixel zieht oft weitere Anfragen und zusätzliche Bibliotheken nach sich. Manchmal lädt es sogar eine zweite Kopie einer Bibliothek, die Ihre Website schon nutzt. Anders gesagt: Eine Installation aus einer Zeile kann im Hintergrund Dutzende Anfragen auslösen.

Ein weiteres Risiko ist ein langsamer externer Server. Lädt der Code synchron und antwortet die Gegenseite nicht, kann der Browser den Rest der Seite zurückhalten. Kurz gesagt bestimmt dann ein Server außerhalb Ihrer Kontrolle, wie schnell Ihre Seite öffnet. Daher verfolgen wir im Netzwerk zwei Ziele: weniger Domains und Ladevorgänge außerhalb des kritischen Pfads.

Was blockiert den Hauptthread?

Der Hauptthread des Browsers ist eine einzige Spur. Er zeichnet die Seite, führt Code aus und reagiert auf Klicks. Läuft ein Skript lange, bleibt diese Spur belegt. Tippt ein Nutzer in diesem Moment auf eine Schaltfläche, kann der Browser erst danach reagieren.

Drittanbietercode schadet hier auf zwei Arten. Erstens muss der Browser ihn nach dem Download analysieren und ausführen. Ein großes Chatwidget verbraucht in dieser Phase viel Rechenzeit. Zweitens hören viele Tags auf Klicks und Scrollbewegungen. Folglich läuft ihr Code bei jeder Interaktion neben Ihrem eigenen.

Die Lighthouse Dokumentation von Chrome beschreibt dazu eine eigene Prüfung zum Einfluss von Drittanbietercode. Sie markiert Seiten, auf denen Drittanbietercode den Hauptthread beim Laden insgesamt 250 Millisekunden oder länger blockiert. Mit neuen Lighthouse Versionen ändern sich Namen und Position solcher Prüfungen. Trotzdem bleibt die Logik gleich. Achten Sie also nicht nur auf die Dateigröße, sondern auch auf die Rechenzeit.

Wie stark beeinflussen Werbepixel die Ladezeit?

Einzeln betrachtet wirken Werbepixel klein. Allerdings lädt ein typischer Onlineshop Pixel mehrerer Plattformen, und jedes bringt seine eigene Bibliothek mit. Häufig steckt dasselbe Pixel zudem gleichzeitig im Seitencode und im Tag Manager. Dann leiden Ladezeit und Datenqualität zugleich.

Beispielszenario: Auf example.com hat jemand das Meta Pixel von Hand in die Themedatei kopiert. Dasselbe Pixel feuert außerdem über den Tag Manager. Folglich lädt der Browser den Code doppelt, und die Plattform zählt jeden Kauf zweimal. Dieses Problem der doppelten Zählung beschreiben wir im Beitrag zu doppelten Events bei Meta Pixel und Conversions API.

Pixel zu entfernen ist oft keine Option, denn die Kampagnenoptimierung braucht diese Daten. Das Ziel lautet deshalb: jedes Pixel aus einer Quelle, als einzige Kopie und zum passenden Zeitpunkt. Darüber hinaus bringt das Aussortieren alter Kampagnenpixel auf den meisten Websites den schnellsten Gewinn. Zum Beispiel kann das Pixel einer längst beendeten Kampagne unbemerkt bei jedem Besuch weiterlaufen.

Warum sind Chatwidgets so schwer?

Ein Chatwidget zeigt nicht nur eine Blase. Es bringt auch die Chatoberfläche, die Benachrichtigungslogik, manchmal Schriften und weitere Bibliotheken mit. Die Hinweise von web.dev zum Lazy Loading halten fest, dass die meisten Chatwidgets eine erhebliche Menge JavaScript herunterladen. Das kann das Laden der Seite und die Reaktion auf Eingaben spürbar beeinträchtigen.

Spannend ist allerdings Folgendes. Nur ein kleiner Teil der Besucher öffnet den Chat überhaupt. Trotzdem lädt der Browser das Widget bei jedem Seitenaufruf, für alle. Also zahlen alle die Kosten, während nur wenige profitieren.

Deshalb eignen sich Chatwidgets besonders gut für verzögertes Laden und das Fassadenmuster. Sie müssen den Chat nicht abschalten. Sie ändern lediglich, wann das echte Widget lädt. Konkret bleibt die Blase sichtbar, aber der eigentliche Code kommt erst, wenn der Nutzer mit der Maus darüberfährt oder klickt. Weiter unten erklären wir dieses Muster in einem eigenen Abschnitt. Zum Thema Lazy Loading allgemein lesen Sie unseren Beitrag Was ist Lazy Loading.

Warum ist der Effekt auf Smartphones größer?

Eine Last, die Sie am Desktop nicht bemerken, kann auf einem Smartphone der Mittelklasse deutlich bremsen. Denn Smartphoneprozessoren verarbeiten JavaScript langsamer, und mobile Verbindungen schwanken stärker. Daher empfiehlt der web.dev Leitfaden zum Aufspüren langsamer Skripte Messungen mit mobilem Profil und gedrosselter CPU.

Auch die Search Console zeigt Daten für Mobilgeräte und Desktop getrennt an. Zum Beispiel kann eine Vorlage am Desktop gut abschneiden und mobil wegen INP schwach bleiben. In diesem Fall sollten Sie zuerst die schweren externen Skripte prüfen, die auf jeder Seite laufen.

Ein praktischer Tipp: Messen Sie nicht auf Ihrem schnellen Laptop. Nutzen Sie stattdessen ein mobiles Profil mit aktiver Drosselung. Wenn möglich, öffnen Sie die Seite zusätzlich auf einem echten Smartphone der Mittelklasse. Beobachten Sie dann, wann Chatblase, Cookiebanner und Werbeflächen erscheinen. Surfen die meisten Ihrer Nutzer mobil, treffen Sie Ihre Entscheidungen auf Basis des mobilen Ergebnisses. Kurz gesagt ersetzt ein sauberer Desktoptest nicht die echte mobile Erfahrung.

Wer im Team übernimmt welche Aufgabe?

Probleme mit externem Code sind oft eher organisatorisch als technisch. Das Marketing möchte Pixel. Der Support möchte einen Chat. Die Entwicklung soll für die Ladezeit geradestehen. Trotzdem sieht niemand das ganze Bild. Deshalb empfehlen wir, die Rollen von Anfang an klar zu verteilen.

• Marketing legt fest, welches Pixel welche Kampagne braucht und wann sie endet.
• Die Entwicklung verantwortet Lademethode, Verzögerung und Fassaden.
• Die Analyseverantwortlichen prüfen, ob Conversion Events vor und nach einer Änderung stimmig bleiben.
• Das SEO Team beobachtet Search Console Daten und Labormessungen.

So hängt die Entscheidung, ein Skript zu entfernen, nie an der Vermutung einer einzelnen Person. Zudem hat jede Änderung eine verantwortliche Person, sodass ein Rückbau leicht bleibt. In kleinen Teams übernehmen oft ein oder zwei Personen alle Rollen. Wichtig ist nur, dass die Rollen schriftlich festgehalten sind und jede Änderung im Protokoll landet.

Wie entsteht Ballast im Tag Manager?

Ein Tag Manager macht es leicht, Tags ohne Codeänderung hinzuzufügen. Mit der Zeit wird diese Bequemlichkeit allerdings zur Last. Kampagnen enden, Agenturen wechseln, Tests laufen aus, doch die Tags bleiben im Container. Die Grundeinrichtung beschreiben wir in unserer Anleitung zum Google Tag Manager. Hier geht es um die Performance.

Die Seite von web.dev zu Best Practices für Tags und Tag Manager nennt eine wichtige Beobachtung. Die Autoren sehen einen Zusammenhang zwischen der Größe von Tag Managern und schlechteren INP Werten. Dieselbe Quelle warnt außerdem, dass mehrere Container auf einer Seite erhebliche Performanceprobleme verursachen können.

Typische Quellen für Ballast sind:

• Ungenutzte Tags, Trigger und Variablen, die niemand gelöscht hat.
• Tags, die auf jeder Seite feuern, aber nur auf wenigen Seiten nötig sind.
• Große Bibliotheken, die über benutzerdefinierte HTML Tags kommen.
• Mehrere Container auf derselben Seite.

Kurz gesagt ist der Tag Manager selbst nicht das Problem. Das Problem ist ein unaufgeräumter Container ohne verantwortliche Person.

Wie schaden diese Skripte den Core Web Vitals?

Die Google Seite zu den Core Web Vitals nennt folgende Ziele: LCP innerhalb der ersten 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1. Was die einzelnen Kennzahlen bedeuten, erklären wir im Beitrag Core Web Vitals erklärt.

Skripte von Drittanbietern wirken auf jede Kennzahl anders:

• LCP: Externer Code im kritischen Pfad verzögert das Hauptbild oder die Überschrift.
• INP: Tags, die den Hauptthread belegen, verlangsamen die Reaktion auf Eingaben.
• CLS: Spät erscheinende Chatblasen, Werbeflächen und Banner verschieben das Layout.

Andererseits empfiehlt Google gute Core Web Vitals für den Erfolg in der Suche, doch gute Werte allein garantieren keine Rankings. Wir sehen Ladezeitarbeit daher als Investition in Nutzererlebnis und Conversions, nicht als Rankingversprechen. Den größeren Zusammenhang erklärt unser Beitrag Wie beeinflusst die Ladezeit SEO.

Wie verfolgen Sie das Problem in der Search Console?

Der Core Web Vitals Bericht in der Search Console beruht auf echten Nutzerdaten, also Felddaten. Laut der offiziellen Hilfeseite fasst der Bericht ähnliche Seiten zu Gruppen zusammen. Der Status jeder Gruppe richtet sich nach ihrer schwächsten Kennzahl. Auf Englisch heißen die Stufen "Poor", "Need improvement" und "Good".

Bei Problemen durch externen Code zeigt sich oft ein typisches Zeichen. Alle Seiten mit derselben Vorlage verschlechtern sich gemeinsam. Läuft zum Beispiel das Chatwidget auf allen Produktseiten, kann die gesamte Gruppe der Produktseiten ein INP Problem zeigen. Dann prüfen Sie die Vorlage und die darauf laufenden externen Skripte, nicht einzelne Seiten.

Nach der Korrektur starten Sie auf der Detailseite des Problems die Validierung (im englischen Interface "Start Tracking"). Google beobachtet danach etwa 28 Tage lang, denn echte Nutzerdaten brauchen Zeit. Eine vollständige Einführung in das Tool bietet unsere Search Console Anleitung für Einsteiger.

Wie messen Sie Skripte von Drittanbietern einzeln?

Berichte zeigen Ihnen, dass ein Problem existiert. Sie verraten aber nicht, welches Skript es verursacht. Dafür brauchen Sie Labormessungen. Wir gehen in dieser Reihenfolge vor:

1. Führen Sie einen Lighthouse Test mit mobilem Profil durch und prüfen Sie die Abschnitte zu externen Ressourcen. Details finden Sie in unserem Beitrag zum Lighthouse Test.
2. Öffnen Sie in den Chrome DevTools das Network Panel. Klicken Sie mit der rechten Maustaste auf eine verdächtige Anfrage und wählen Sie "Block request URL".
3. Laden Sie die Seite mit Netzwerk und CPU Drosselung neu. Vergleichen Sie dann das Ergebnis mit der Version ohne Sperre.
4. Wiederholen Sie jede Messung mindestens dreimal und nutzen Sie den Median.
5. Tragen Sie den Unterschied in eine Tabelle ein: Skriptname, Domain und die veränderte Kennzahl.

Auch der web.dev Leitfaden zum Aufspüren langsamer Skripte empfiehlt diese Sperrmethode und den Median aus mindestens drei Messungen. Somit entscheiden Sie auf Basis eines gemessenen Unterschieds statt eines Bauchgefühls.

Welche Tools eine Website lädt, sehen Sie zusätzlich schnell mit unserem CMS Checker.

Wie erstellen Sie Schritt für Schritt ein Skriptinventar?

Bevor Sie Skripte von Drittanbietern messen, brauchen Sie eine Liste. Das Inventar bildet die Grundlage jeder Aufräumaktion. Ohne zu wissen, warum etwas da ist, können Sie nichts sicher entfernen.

1. Wählen Sie repräsentative Vorlagen wie Startseite, Kategorie, Produkt, Warenkorb und Dankeseite.
2. Listen Sie für jede Vorlage die externen Domains aus dem Network Panel auf.
3. Prüfen Sie, wie oft derselbe Code in Themedateien, Plugins und im Tag Manager vorkommt.
4. Ordnen Sie jedem Skript eine verantwortliche Abteilung zu: Marketing, Vertrieb, Support oder Entwicklung.
5. Notieren Sie den Zweck jedes Skripts in einem Satz. Welchen Bericht speist es, welche Entscheidung stützt es?
6. Fragen Sie nach der letzten Nutzung. Weiß das niemand, kommt das Skript auf die Kandidatenliste.

Beispielszenario: Auf example.com ergibt das Inventar vierzehn externe Skripte. Vier davon haben keine verantwortliche Person, zwei gehören zu einer längst beendeten Kampagne. Diese Tabelle ist das Rohmaterial für den nächsten Schritt. Vor allem die Spalte ohne Verantwortliche zeigt die schnellsten Gewinne.

Welche Skripte entfernen Sie, welche laden Sie später?

Nach dem Inventar wählen Sie für jedes Skript eine von vier Optionen. Der Rat von web.dev ist eindeutig: Bringt ein Skript keinen klaren Mehrwert, entfernen Sie es. Für den Rest nutzen wir die folgende Tabelle als Entscheidungshilfe.

Die Tabelle ist ein Ausgangsrahmen, keine starre Regel. Auf einer B2B-Website kann der Chat zum Beispiel die wichtigste Quelle für Vertriebsgespräche sein. Dann wählen Sie die Verzögerungsmethode besonders sorgfältig.

Wie wählen Sie zwischen async und defer?

In der Praxis spielen die meisten Skripte von Drittanbietern für die Darstellung der Seite keine Rolle. Daher empfiehlt der web.dev Leitfaden für externe Skripte immer async oder defer, sofern ein Skript nicht zum kritischen Renderpfad gehört.

Der Unterschied kurz gesagt:

• async: Der Code lädt im Hintergrund und läuft, sobald er ankommt. Eine feste Reihenfolge gibt es nicht; das passt zu unabhängigen Tags.
• defer: Der Code lädt im Hintergrund, läuft aber erst nach dem Parsen der Seite und in fester Reihenfolge. Das ist sicherer für Skripte, die voneinander abhängen.

Allerdings enthält derselbe Leitfaden eine wichtige Warnung. Async allein verhindert nicht, dass viele Trackingskripte das Laden verlangsamen. Denn der Code lädt trotzdem und läuft weiterhin im Hauptthread. Anders gesagt verringert async die Blockade, beseitigt aber nicht die Kosten.

Deshalb sehen wir async und defer als ersten Schritt. Der eigentliche Gewinn entsteht, wenn Sie Code später auslösen, ihn nur dort laufen lassen, wo er nötig ist, und Überflüssiges löschen. Bietet Ihr Theme oder Plugin diese Einstellungen nicht, setzen Sie die Änderung gemeinsam mit Ihrer Entwicklung auf einer Testumgebung um.

Wie funktioniert das Fassadenmuster bei Chat und Video?

Eine Fassade ist ein sehr leichter Platzhalter, der wie das echte Widget aussieht, aber keine Funktion hat. Die Fassadendokumentation von Chrome beschreibt den Ablauf in drei Phasen:

1. Beim Laden der Seite holt der Browser statt des echten Widgets nur die leichte Fassade.
2. Fährt der Nutzer mit der Maus darüber, baut die Fassade vorab Verbindungen zu den externen Servern auf.
3. Klickt der Nutzer, ersetzt sich die Fassade durch das echte Widget.

Beispielszenario: Auf example.com ersetzt eine gleich aussehende Schaltfläche die Chatblase. Der Chatcode lädt erst, wenn der Besucher klickt. Somit tragen die vielen Besucher, die nie chatten, auch keine Kosten.

Das hat allerdings seinen Preis. Laut derselben Dokumentation fehlen Fassaden einige Funktionen des echten Widgets. Zum Beispiel erscheint ein Zähler für neue Nachrichten unter Umständen erst, wenn der echte Code geladen ist. Auch Autoplay bei verzögert geladenen Videos kann unzuverlässig sein. Hinweis: Die Seite erwähnt zudem, dass neuere Lighthouse Versionen die zugehörige Prüfung entfernt haben. Der Bericht schlägt Fassaden also eventuell nicht mehr vor, die Methode funktioniert aber weiterhin. Stützen Sie die Entscheidung daher auf Ihre eigene Sperrmessung.

Wie verschlanken Sie Ihren Tag Manager?

Der Tag Leitfaden von web.dev zeigt einen klaren Weg zum Aufräumen. In unseren Analysen gehen wir in dieser Reihenfolge vor:

1. Pausieren oder löschen Sie ungenutzte Tags, statt sie mit Triggerausnahmen zu blockieren. Entfernen Sie danach auch die zugehörigen Trigger und Variablen.
2. Lösen Sie nicht wesentliche Tags erst nach Window Loaded aus. Laut Quelle gilt: Je früher ein Tag feuert, desto größer ist sein Einfluss auf die Performance.
3. Grenzen Sie Triggerbedingungen ein, damit jedes Tag nur auf den nötigen Seiten läuft.
4. Nutzen Sie pro Seite nur einen Container.
5. Bevorzugen Sie nach Möglichkeit Vorlagen statt benutzerdefinierter HTML Tags.
6. Geben Sie jedem Tag eine verantwortliche Person und eine kurze Beschreibung.

Begrenzen Sie außerdem den Zugriff. Laut web.dev kann jeder mit Zugang zum Tag Manager JavaScript auf der Website ergänzen. Entfernen Sie also regelmäßig alte Agenturkonten, ehemalige Mitarbeitende und ungenutzte Nutzer. Das hilft der Sicherheit und der Ladezeit.

Diese Schritte wirken klein. In einem überladenen Container kann das Ergebnis dennoch deutlich ausfallen. Testen Sie trotzdem jede Änderung im Vorschau und Debugmodus, bevor Sie sie veröffentlichen.

Wie räumen Sie auf, ohne das Conversion Tracking zu beschädigen?

Das größte Risiko bei Ladezeitarbeit ist der Verlust von Umsatzdaten und Leaddaten. Verschieben Sie ein Pixel auf den falschen Zeitpunkt oder an den falschen Trigger, sieht die Werbeplattform keine Conversions mehr. Deshalb verbinden wir das Aufräumen immer mit einem Trackingplan.

1. Halten Sie zunächst fest, welche Events geschäftskritisch sind: Kauf, Formularversand, Suche oder Anruf per Klick.
2. Vermerken Sie im Inventar, welches Skript und welcher Trigger jedes Event senden.
3. Notieren Sie vor jeder Änderung die Eventzahlen der letzten zwei Wochen.
4. Testen Sie die Änderung im Vorschaumodus und prüfen Sie, ob die Events weiterhin ankommen.
5. Vergleichen Sie nach dem Livegang einige Tage lang die Eventzahlen mit dem früheren Zeitraum.

Eine wichtige Regel: Bevor Sie Conversion Tags auf späte Trigger wie Window Loaded verschieben, stellen Sie sicher, dass der Nutzer zu diesem Zeitpunkt noch auf der Seite ist. Sonst verlieren Sie womöglich Conversions von Nutzern, die schnell abspringen.

Auch die Cookie Einwilligung gehört dazu. Welche Tags auf eine Einwilligung warten müssen, erklären wir im Beitrag Ist Google Consent Mode v2 Pflicht. Das Aufräumen darf diese Einstellungen nicht beschädigen.

Helfen Preconnect und Selbsthosting?

Trotzdem sind manche externe Skripte wirklich notwendig und müssen früh laden. Dann lohnt es sich, die Verbindungszeit zu verkürzen. Der web.dev Leitfaden nennt zwei Hinweise für den Browser. Mit DNS Prefetch lösen Sie den Domainnamen früh auf. Mit Preconnect bauen Sie die sichere Verbindung schon vorab auf.

Allerdings kann es nach hinten losgehen, wenn Sie diese Hinweise für jede externe Domain setzen. Dann beschäftigt sich der Browser mit Verbindungen, die er vielleicht nie braucht. Wir empfehlen sie deshalb nur für ein oder zwei externe Domains, die die Seite in den ersten Sekunden tatsächlich benötigt.

Selbsthosting ist eine weitere Option. Laut derselben Quelle können Sie bei einem langsamen Drittanbieterserver erwägen, das Skript selbst zu hosten. Andererseits erhält der Code dann keine automatischen Aktualisierungen mehr, und Sie müssen Updates selbst verfolgen. Zudem erwarten manche Plattformen, dass ihr Code nur von ihren eigenen Servern lädt. Kurz gesagt passt diese Methode zu Teams, die den Wartungsaufwand übernehmen können.

Beispielszenario: Wie läuft eine Aufräumrunde auf example.com ab?

Der folgende Ablauf ist kein echter Kundenfall. Es handelt sich um ein Beispielszenario, das wir zur Veranschaulichung entworfen haben.

Angenommen, example.com ist ein Shop für Heimtextilien. In der Search Console steht die Gruppe der Produktseiten wegen INP auf "Need improvement". Das Team erstellt das Inventar und findet folgendes Bild. Zwei Werbepixel stecken sowohl im Theme als auch im Tag Manager. Eine Heatmap läuft auf jeder Seite. Das Chatwidget lädt überall, und ein alter A/B Test ist noch aktiv.

Danach geht das Team so vor:

• Es entfernt den doppelten Pixelcode aus dem Theme und behält nur die Version im Tag Manager.
• Dann löscht es den Code des beendeten A/B Tests.
• Die Heatmap beschränkt es auf zwei Kampagnenseiten.
• Anschließend stellt es das Chatwidget auf eine Fassade um.
• Schließlich testet es Kauf und Warenkorbereignis im Vorschaumodus.

Danach wiederholt das Team die Labormessungen und startet die Validierung in der Search Console. Das Ergebnis kennt niemand im Voraus, denn Felddaten stammen von echten Nutzern und brauchen Zeit. Weil der Prozess messbar und umkehrbar ist, bleibt das Risiko jedoch gering.

Wie schaffen Sie dauerhafte Ordnung bei Skripten von Drittanbietern?

Eine einmalige Aufräumaktion verpufft innerhalb weniger Monate, denn neue Kampagnen bringen neuen Code. Das eigentliche Ziel ist daher eine feste Routine. Diese einfachen Regeln empfehlen wir:

• Bevor jemand externen Code ergänzt, halten Sie Zweck, verantwortliche Person und Enddatum schriftlich fest.
• Prüfen Sie das Inventar jedes Quartal erneut.
• Geben Sie nur aktiven Teammitgliedern Zugang zum Tag Manager.
• Machen Sie nach jedem neuen Skript eine kurze Ladezeitmessung.
• Kontrollieren Sie den Core Web Vitals Bericht in der Search Console einmal im Monat.

Wenn Ihnen das allein zu viel ist, lösen wir dieses Problem auf Ihrer Website und behalten es im Blick. Im Rahmen unserer SEO Beratung erstellen wir das Inventar, räumen unter Schutz Ihres Trackingplans auf und berichten über die Ergebnisse. Rankings garantieren wir nicht. Wir machen aber die Ursachen einer langsamen Website sichtbar und beherrschbar.

Wo sollten Sie anfangen?

Skripte von Drittanbietern gehören zu jeder modernen Website. Sie alle zu entfernen ist weder möglich noch nötig. Entscheidend ist, dass Sie wissen, warum jedes einzelne da ist, und seine Kosten messen.

Für den Anfang genügen drei Schritte. Erstellen Sie das Inventar, messen Sie die schwersten Skripte per Sperrmethode und sortieren Sie Skripte ohne Verantwortliche aus. Danach laden Sie schwere Widgets wie Chat und Video verzögert, verschlanken den Tag Manager und testen bei jedem Schritt Ihre Conversion Events.

Möchten Sie, dass unser Team diese Arbeit für Sie übernimmt, fordern Sie über unsere Seite zur SEO Beratung ein Angebot mit Ihrer Websiteadresse an. Wir prüfen Ihre aktuellen Skripte und erstellen einen passenden Plan für Aufräumen und Monitoring.

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.