Astro Partytown für schnellere Skriptladung

Astro Partytown ist die Integration von Astro, um ausgewählte Drittanbieter-Skripte in einem Web-Worker anstelle des Hauptthreads auszuführen. Praktisch hilft es, Analysen, Werbung und andere externe Skripte davon abzuhalten, mit der Rendering-Arbeit Ihrer Seite zu konkurrieren.

Für Händler und Entwickler ist der Wert einfach: Wenn ein Skript nützlich, aber nicht entscheidend für die erste Interaktion ist, sollte es nicht erlauben, dass der Rest der Seite langsamer wird. Astro Partytown bietet Ihnen eine strukturierte Möglichkeit, diese Arbeit zu isolieren.

Wichtigste Erkenntnisse

• Drittanbieter-Skripte sind oft der erste Anlaufpunkt, wenn eine Seite schwerfällig wirkt, selbst wenn der Kernseiten-Code sauber ist.
• Astro Partytown ist besonders nützlich für Skripte, die das erste Rendering oder die sofortige Interaktion nicht steuern müssen.
• Die Integration installiert Partytown und macht es über Seiten hinweg verfügbar, was die Einrichtung erleichtert.
• Einige Skripte benötigen Weiterleitung oder Proxy, um auch nach der Verlagerung vom Hauptthread zu funktionieren.
• Leistungsgewinne sind nur relevant, wenn das Skript in echten Benutzerabläufen weiterhin korrekt funktioniert.

Was ist es?

Astro Partytown ist eine offizielle Astro-Integration, die Partytown in Ihrem Projekt aktiviert. Partytown ist eine lazy-loaded Bibliothek, die ressourcenintensive Drittanbieter-Skripte in einen Web-Worker verlagert, sodass sie vom Hauptthread ferngehalten werden. Das ist wichtig, weil der Hauptthread der Ort ist, an dem der Browser Rendering, Eingabereaktionsfähigkeit und einen Großteil der sichtbaren Arbeit der Seite behandelt.

Ein konkretes Beispiel ist ein Online-Shop, der auf jeder Seite Analysen, Tag-Manager und Werbe-Pixels lädt. Diese Skripte sind möglicherweise nützlich für Messungen, aber sie müssen nicht das Erscheinen des Produktgitters blockieren oder das erste Klicken eines Käufers verzögern. Mit Astro Partytown können Sie diese Skripte so laden, dass ihre Auswirkungen auf die Kernarbeit der Seite verringert werden.

Die Integration ist kein magischer Leistungsschalter. Es ist eine kontrollierte Methode, um Drittanbieter-Code anders zu behandeln als Ihren eigenen Seiten-Code. Diese Unterscheidung ist wichtig, denn Drittanbieter-Skripte sind oft der unvorhersehbarste Teil eines Stacks: Sie können von Anbietern aktualisiert werden, von Browser-APIs in spezifischen Weisen abhängen und sich je nach Ladeweise unterschiedlich verhalten.

In Astro hilft die Integration auch, die Einrichtung zu standardisieren. Anstatt auf jeder Seite eine Worker-Strategie manuell zu erstellen, verwenden Sie die Astro-Integration, sodass Partytown im gesamten Site verfügbar ist. Das erleichtert es, denselben Ansatz auf mehrere Vorlagen, Landing-Pages oder Inhaltsseiten anzuwenden, ohne dieselbe Verkabelung zu wiederholen.

Ein nützliches mentales Modell ist, dass Astro Partytown das Skript nicht entfernt; es ändert die Beziehung des Skripts zur geschäftigsten Spur des Browsers. Deshalb ist es besonders wertvoll für Skripte, die für das Geschäft wichtig, aber nicht entscheidend für den ersten Anstrich sind. Wenn die Hauptaufgabe des Skripts darin besteht, die Seite zu beobachten, zu messen oder zu bereichern, nachdem sie sichtbar ist, ist es oft ein besserer Kandidat als ein Skript, das sofort Tasten, Menüs oder Formularverhalten steuern muss.

Ein kurzer Definitionstest

Wenn Sie entscheiden, ob ein Skript in Partytown gehört, fragen Sie, ob das Skript tolerieren kann, leicht aus dem unmittelbaren Rendering-Pfad der Seite entfernt zu werden. Ein Tracking-Pixel, ein Tag-Manager-Container oder ein Anbieter-Widget, das initialisiert wird, nachdem die Seite sichtbar ist, passt oft gut. Ein Menücontroller, ein Formularvalidator, der sofort ausgeführt werden muss, oder ein Skript, das den kritischen UI-Zustand direkt verwaltet, ist in der Regel nicht geeignet.

Diese Unterscheidung ist nützlich, da sie das Gespräch auf Benutzerwirkungen anstatt auf Anbieterkategorien fokussiert. “Analytik” ist nicht automatisch sicher, und “interaktiv” ist nicht automatisch unsicher. Die eigentliche Frage ist, ob das Skript an der ersten bedeutenden Interaktion teilnehmen muss oder ob es im Hintergrund arbeiten kann, ohne die unmittelbare Erfahrung des Benutzers zu ändern.

Warum es wichtig ist — geschäftliche und technische Auswirkungen

Der geschäftliche Fall für Astro Partytown beginnt mit der Benutzererfahrung. Wenn Drittanbieter-Skripte das Rendering verlangsamen oder die Benutzeroberfläche träge erscheinen lassen, neigen Besucher eher dazu, die Seite zu verlassen, bevor sie den Inhalt oder das Produkt erreichen, für das sie gekommen sind. Dies ist besonders relevant auf Händlerseiten, wo jede zusätzliche Sekunde das Browsing, das Hinzufügen zum Warenkorb und das Vertrauen beeinflussen kann.

Technisch ist der Hauptthread ein gemeinsames Engpass. Wenn zu viele Skripte dort konkurrieren, muss der Browser das Rendering der Seite, die Ereignisverarbeitung und die Skriptausführung gleichzeitig jonglieren. Die Verlagerung ausgewählter Drittanbieter-Skripte in einen Worker kann diesen Wettbewerb verringern. Das Ergebnis ist nicht nur ein schnellerer Benchmark in Isolation; es ist oft eine flüssigere Seite unter realen Browsing-Bedingungen.

Es gibt auch einen Wartungsaspekt. Wenn Teams wissen, welche Skripte als worker-freundlich behandelt werden und welche nicht, können sie bewusstere Entscheidungen über Anbieter und Tags treffen. Das hilft, das gängige Muster zu vermeiden, bei dem jedes neue Marketingskript ohne Leistungsüberprüfung zur Seite hinzugefügt wird.

Für Entwickler hat dies architektonische Auswirkungen. Astro ist bereits stark darin, standardmäßig weniger clientseitiges JavaScript auszuliefern, und Partytown passt gut zu diesem Modell. Es ermöglicht Ihnen, die Seite größtenteils servergerendert oder statisch zu halten und dennoch die Drittanbieter-Tools zu unterstützen, die Geschäftsteams oft benötigen. Wenn Sie bereits über Inselarchitektur nachdenken, ist Partytown ein weiteres Beispiel dafür, selektiv zu sein, wo Browserarbeit stattfinden sollte.

Es gibt auch einen Sekundärnutzen: eine bessere Skriptdisziplin. Wenn ein Team weiß, dass ein Anbieterskript auf die Kompatibilität mit einem Worker bewertet werden muss, ändert sich das Gespräch von “Können wir dieses Tag hinzufügen?” zu “Was kostet dieses Tag und was benötigt es, um zu funktionieren?” Das führt in der Regel zu klareren Implementierungsentscheidungen, weniger versteckten Abhängigkeiten und einem besseren Verständnis dafür, welche Skripte wirklich kritisch sind. In der Praxis kann das die Leistungsprüfungen umsetzbarer machen, da das Team Geschäftserforderlichkeiten von technischer Bequemlichkeit trennen kann.

Es hilft auch bei der Priorisierung. Nicht jede Seite benötigt dasselbe Drittanbieter-Stack, und nicht jedes Skript verdient dieselbe Lade-Strategie. Eine Homepage benötigt möglicherweise eine umfassende Analytics-Einrichtung, während eine Seite in der Nähe der Kasse möglicherweise nur die minimal erforderliche Messung für die Zuordnung benötigt. Astro Partytown bietet Teams eine Möglichkeit, diese Nuancen in der Implementierung zu bewahren, anstatt jede Seite in dieselbe skriptlastige Vorlage zu glätten.

Wie es funktioniert — erklären Sie den Mechanismus Schritt für Schritt

Astro Partytown funktioniert, indem es die Partytown-Laufzeit installiert und in Ihrer Astro-App verfügbar macht. Einmal aktiviert, werden Skripte, die für Partytown markiert sind, nicht auf die übliche Weise im Hauptthread ausgeführt. Stattdessen werden sie durch ein worker-basiertes Setup behandelt, das den primären Thread des Browsers freier für Rendering und Interaktion hält.

Der grundlegende Ablauf sieht so aus. Zuerst fügt Astro die Integration zu Ihrem Projekt hinzu. Dann werden Drittanbieter-Skripte, die von Partytown verwaltet werden sollen, mit dem entsprechenden Skripttyp gekennzeichnet. Danach leitet Partytown die Anfrage um und leitet das Skript durch seinen worker-basierten Mechanismus. Aus der Perspektive des Browsers existiert das Skript weiterhin und kann seinen Job weiterhin erledigen, aber es konkurriert nicht mehr so direkt mit der sichtbaren Arbeit der Seite.

Dieses Worker-Modell schafft eine wichtige Einschränkung: Code, der in einem Worker ausgeführt wird, hat nicht denselben direkten Zugriff auf das globale window-Objekt, den ein normales Skript hat. Einige Drittanbieter-Tools erwarten, Werte auf window zu lesen oder zu schreiben, daher bietet Partytown Weiterleitungsmechanismen, um diese Lücke zu schließen. In Astros Integration wird dies häufig mit der Option config.forward für Variablen wie dataLayer.push behandelt.

Ein zweiter Mechanismus ist die Anfrage-Proxying. Einige Skripte benötigen, dass ihre Netzwerk-Anfragen umgeschrieben oder über eine andere URL geleitet werden. Astro Partytown unterstützt dies durch config.resolveUrl(), das es Ihnen ermöglicht, anzupassen, wohin Anfragen gehen. Dies ist nützlich, wenn ein Anbieterskript einen bestimmten Host erwartet oder wenn Sie sich an ein Proxy-Setup anpassen müssen.

Was das in der Praxis bedeutet

Das Wichtige ist, dass Partytown nicht einfach “JavaScript beschleunigt” im vagen Sinne. Es ändert, wo die Arbeit geschieht. Das bedeutet, dass das Skript weiterhin geladen, weiterhin ausgeführt und weiterhin mit der Seite interagiert, aber der Browser behandelt es auf eine Weise, die weniger wahrscheinlich die Benutzererfahrung unterbricht.

Deshalb ist die Implementierung teilweise technisch und teilweise redaktionell. Sie müssen entscheiden, welche Skripte es wert sind, verschoben zu werden, welche Skripte eine spezielle Behandlung benötigen und welche Skripte im Hauptthread bleiben sollten, weil sie zu eng mit der Benutzeroberfläche gekoppelt sind.

Eine praktische Art, über den Mechanismus nachzudenken, besteht aus drei Ebenen. Die erste Ebene ist das Laden: Die Integration macht die Partytown-Laufzeit verfügbar. Die zweite Ebene ist das Routing: Berechtigte Skripte werden markiert, damit sie über den Worker-Pfad behandelt werden. Die dritte Ebene ist die Kompatibilität: Weiterleitungen und Proxying schließen die Lücken, wenn ein Anbieterskript Verhaltensweisen vom Browser erwartet, die ein Worker standardmäßig nicht bereitstellt. Wenn eine dieser Ebenen fehlt, kann das Skript möglicherweise geladen werden, sich aber nicht korrekt verhalten.

Es gibt auch einen zeitlichen Aspekt, den man verstehen sollte. Partytown wird lazy-loaded, was bedeutet, dass es darauf ausgelegt ist, zusätzliche Arbeit zu vermeiden, bevor die Seite sie benötigt. Das passt gut zu Astros allgemeiner Leistungsphilosophie: Halten Sie die anfängliche Erfahrung schlank und führen Sie zusätzliche Funktionen nur ein, wenn sie benötigt werden. Für Teams, die daran gewöhnt sind, jedes Anbieterskript sofort zu laden, kann allein dieser Wechsel eine überraschende Menge an Druck auf der frühen Seite verringern.

Anwendungsfälle — wo Teams dies tatsächlich anwenden

Der häufigste Anwendungsfall sind Analysen. Viele Seiten verlassen sich auf Anbieterskripte zur Verfolgung von Seitenaufrufen, Ereignissen oder Marketing-Zuordnung. Diese Skripte sind oft wichtig für das Geschäft, aber sie müssen selten das erste Rendern der Seite blockieren. Astro Partytown ist eine sinnvolle Lösung, wenn der Analytics-Stack wächst und die Seite schwerer wird, als sie sollte.

Ein zweiter Anwendungsfall ist Werbung und Tag-Management. Werbeskripte können besonders teuer sein, da sie oft zusätzliche Netzwerk-Anfragen und zusätzliche Logik mitbringen. Wenn Ihre Seite mehrere Tags, Pixels oder Anbieter-Schnipsel ausführt, kann das Verschieben der geeigneten in einen Worker helfen, die Seite reaktionsschnell zu halten, während die geschäftlichen Werkzeuge, die Sie benötigen, erhalten bleiben.

Ein dritter Anwendungsfall sind inhaltsreiche oder kampagnenreiche Seiten, auf denen viele Skripte für Messungen, Personalisierungen oder eingebettete Dienste geladen werden. Diese Seiten haben oft viele externe Abhängigkeiten, aber nur eine kleine Menge an wirklich interaktiver Benutzeroberfläche. In dieser Situation kann Partytown Teil einer breiteren Strategie sein, um die Seite leichtgewichtig zu halten, ohne die Werkzeuge zu entfernen, auf die das Marketingteam angewiesen ist.

Ein weiteres Szenario ist eine Seite mit einem gemeinsamen Layout, das dieselben Drittanbieter-Skripte über viele Routen hinweg einfügt. In diesem Fall kann selbst ein bescheidener Seitenkosten sich summieren, da das Skript überall ausgeführt wird. Partytown ist nützlich, wenn das Team einen einzigen Integrationspunkt möchte, der das Standardverhalten über die gesamte Seite verbessert, anstatt separate Skriptlade-Logik in jeder Vorlage zu pflegen.

Sie können es auch als passend für “Hintergrundwert”-Skripte betrachten. Wenn ein Skript dem Geschäft hilft, indem es Daten sammelt, die Zuordnung ermöglicht oder einen Anbieter-Service betreibt, es jedoch nicht das Erste sein muss, was der Browser tut, ist es wert, für eine worker-basierte Ladeweise evaluiert zu werden. Das ist oft der Fall bei Marketingseiten, redaktionellen Seiten mit Werbeinventar und Produktseiten, die Messungen benötigen, aber keine sofortige skriptgesteuerte Interaktion.

Wo es nicht passt

Partytown ist nicht die richtige Antwort für jedes Skript. Wenn ein Skript sofortige, direkte Kontrolle über das DOM benötigt oder wenn es eng an eine benutzerdefinierte Interaktion gebunden ist, die im Hauptthread erfolgen muss, kann das Verschieben mehr Komplexität schaffen, als es beseitigt. Die richtige Frage ist nicht “Kann dieses Skript ausgelagert werden?”, sondern “Kann dieses Skript ausgelagert werden, ohne den Benutzerfluss zu brechen?”

Deshalb beginnen Teams in der Regel mit den lautesten Drittanbieter-Skripten. Die besten Kandidaten sind die, die nützlich, teuer und lose gekoppelt an die erste Interaktion sind.

Eine einfache Faustregel hilft hier: Verwenden Sie Astro Partytown, wenn das Skript wichtig, aber nicht dringend ist; vermeiden Sie es, wenn das Skript dringend und eng mit der sichtbaren Benutzeroberfläche gekoppelt ist. Diese Unterscheidung ist oft klarer, als zu versuchen, nur nach Anbieterkategorien zu urteilen. Zwei Analyseschritte können sich sehr unterschiedlich verhalten, und zwei Werbetags können sehr unterschiedliche Kompatibilitätsanforderungen haben.

Wie man es implementiert oder anwendet — praktische Anleitung

Der sauberste Weg, um zu beginnen, ist mit dem Astro-Integrations-Workflow. Astro unterstützt das Hinzufügen offizieller Integrationen durch seinen Einrichtungsprozess, und die Partytown-Integration ist so konzipiert, dass sie über Seiten hinweg aktiviert wird, anstatt ad hoc eingefügt zu werden. Das ist nützlich, da Drittanbieter-Skripte oft in Layouts, gemeinsamen Vorlagen und wiederverwendbaren Komponenten erscheinen.

Ein typischer Implementierungsablauf ist:

1. Fügen Sie die Partytown-Integration zu Ihrem Astro-Projekt hinzu.
2. Markieren Sie ein Drittanbieter-Skript mit type="text/partytown".
3. Testen Sie die Seite im Entwicklungs- oder Vorschau-Modus.
4. Überprüfen Sie die Entwicklertools des Browsers, um zu bestätigen, dass das Skript wie erwartet behandelt wird.
5. Fügen Sie Weiterleitungen oder Proxys nur hinzu, wenn das Skript dies erfordert.

Der erste Durchgang sollte minimal sein. Beginnen Sie nicht mit der Konfiguration jeder verfügbaren Option. Beginnen Sie mit einem Skript, das eindeutig ein Leistungs-Kandidat ist, wie z.B. einem Tag-Manager oder Analyse-Schnipsel. Wenn dieses Skript wie erwartet funktioniert, können Sie von dort aus erweitern.

Ein praktischer Entscheidungsworkflow

Bevor Sie ein Skript verschieben, stellen Sie drei Fragen. Erstens, muss dieses Skript das erste sichtbare Rendering beeinflussen? Zweitens, hängt es von window-basierter Kommunikation oder ungewöhnlicher Anforderungsbehandlung ab? Drittens, ist der geschäftliche Wert hoch genug, um die zusätzliche Validierungsarbeit zu rechtfertigen? Wenn die Antwort auf die erste Frage nein und die Antwort auf die dritte ja ist, ist das Skript ein starker Kandidat.

Wenn Sie bereits strukturierte Inhalte in Astro verwenden, kann es hilfreich sein, Skriptentscheidungen von Inhaltsentscheidungen zu trennen. Inhaltskollektionen halten Inhalte organisiert, während Partytown bei externen Ausführungskosten hilft. Sie lösen unterschiedliche Probleme, aber beide zielen darauf ab, die Seite einfacher nachvollziehbar zu machen. Für Teams, die inhaltsreiche Astro-Seiten erstellen, ist strukturierte Inhaltseinrichtung oft Teil derselben operativen Denkweise.

Konfigurationspunkte, die am wichtigsten sind

Die beiden Konfigurationsbereiche, die am häufigsten zur Sprache kommen, sind Weiterleitungen und Proxys. Weiterleitungen sind für Fälle gedacht, in denen das Skript erwartet, über Variablen auf window zu kommunizieren. Proxys sind für Fälle gedacht, in denen eine Anfrage umgeschrieben oder anders geleitet werden muss. Beide sind leistungsfähig, sollten aber nur verwendet werden, wenn das Skript sie tatsächlich benötigt.

Die Dokumente von Astro weisen auch darauf hin, dass der Debug-Modus verfügbar ist und oft in der Entwicklung oder Vorschau aktiviert ist, es sei denn, Sie deaktivieren ihn. Das ist nützlich, da es Ihnen hilft zu sehen, was die Integration tut, während Sie testen. In der Praxis ist der Debug-Modus ein Validierungswerkzeug und kein Produktionsmerkmal, das Sie standardmäßig aktiviert lassen.

Wenn Sie die Integration implementieren, hilft es auch, in derselben Reihenfolge zu testen, in der Ihre Benutzer die Seite erleben. Beginnen Sie mit der Startseite, dann den am häufigsten besuchten Landing-Pages und dann allen Vorlagen, die denselben Anbieter-Stack enthalten. Diese Reihenfolge fängt die sichtbarsten Regressionen frühzeitig ein und verhindert ein falsches Gefühl von Erfolg durch eine einzige risikoarme Seite.

Eine nützliche Implementierungsgewohnheit ist es, jede Skriptentscheidung in klarer Sprache zu dokumentieren: was das Skript tut, warum es benötigt wird, ob es worker-sicher ist, und welche spezielle Behandlung es erfordert. Dieser kleine Eintrag wird später wertvoll, wenn ein Marketer ein neues Tag hinzufügt, ein Anbieter sein Snippet aktualisiert oder ein Entwickler verstehen muss, warum ein Skript im Hauptthread belassen wurde, während ein anderes verschoben wurde.

Häufige Fehler und Fallstricke

Der häufigste Fehler besteht darin, Astro Partytown als universelle Leistungsfixierung zu behandeln. Das ist es nicht. Es hilft bei berechtigten Drittanbieter-Skripten, wird jedoch langsame Vorlagen, übergroße Bilder, schlechte Inhaltsstruktur oder übermäßigen clientseitigen Anwendungs-Code nicht lösen. Wenn die Seite aus anderen Gründen bereits schwerfällig ist, kann Partytown möglicherweise nur einen Teil des Problems angehen.

Ein weiterer Fehler besteht darin, Skripte zu verschieben, ohne zu überprüfen, wie sie kommunizieren. Einige Skripte sind auf window-Variablen, benutzerdefinierte Ereignisse oder anbieter-spezifische Anforderungsmuster angewiesen. Wenn Sie diese Abhängigkeiten nicht berücksichtigen, kann das Skript geladen werden, sich jedoch nicht korrekt verhalten. Deshalb existieren Weiterleitungen und Proxys, und warum sie als Teil der Implementierung behandelt werden sollten, nicht als optionale Extras.

Ein dritter Fallstrick ist die Überkonfiguration zu früh. Teams fügen manchmal Weiterleitungsregeln oder Proxy-Logik hinzu, bevor sie bewiesen haben, dass das Skript diese tatsächlich benötigt. Das macht das Debugging schwieriger. Beginnen Sie mit der kleinsten funktionsfähigen Einrichtung und fügen Sie dann nur die Konfiguration hinzu, die das Skript verlangt.

Schließlich sollten Sie nicht davon ausgehen, dass ein Skript sicher ist, nur weil es häufig verwendet wird. Analyse- und Werbeanbieter werden häufig genutzt, aber jede Implementierung kann sich je nach Tag, Seite und Browser unterschiedlich verhalten. Testen Sie die genauen Seiten, auf denen das Skript am wichtigsten ist: Start-, Produkt-, Kollektions-, Landing- und kassenahe Seiten, falls relevant.

Ein weiterer subtiler Fehler besteht darin, zu vergessen, dass Anbieterskripte sich im Laufe der Zeit ändern. Ein Skript, das heute funktioniert, kann nach einem Update des Anbieters, einer neuen Tag-Konfiguration oder einer Änderung des Browserverhaltens fehlschlagen. Deshalb sollte Partytown Teil eines kontinuierlichen Überprüfungsprozesses sein, nicht eine einmalige Einrichtungsaufgabe. Wenn das Marketingteam ein neues Pixel hinzufügt oder einen Tag-Manager-Container austauscht, muss die Worker-Konfiguration möglicherweise erneut überprüft werden.

Ein verwandtes Problem besteht darin, anzunehmen, dass Erfolg in der Entwicklung Erfolg in der Produktion garantiert. Der Entwicklungsmodus kann nachsichtig sein, und der Vorschaumodus kann immer noch von den tatsächlichen Verkehrsbedingungen abweichen, insbesondere wenn Cookies, Zustimmungswerkzeuge oder regionsspezifisches Anbieter-Verhalten beteiligt sind. Wenn ein Skript geschäftskritisch ist, testen Sie es im gleichen Zustimmungsstatus, den Seitenvorlagen und Gerätetypen, die Ihre Besucher tatsächlich verwenden.

Best Practices und schnelle Checkliste

Der beste Weg, Astro Partytown zu nutzen, ist selektiv. Behandeln Sie es als Leistungswerkzeug für spezifische Drittanbieter-Skripte, nicht als Pauschalrichtlinie für ganz JavaScript. Das hält die Einrichtung verständlich und erleichtert das Troubleshooting, wenn etwas unerwartet reagiert.

Ein guter Implementierungsprozess ist es, mit einem Skript zu beginnen, das Verhalten zu validieren und dann zu erweitern. Wenn das Skript geschäftskritisch für Marketing oder Messung ist, testen Sie es in denselben Vorlagen und Browsern, die Ihre Benutzer tatsächlich verwenden. Wenn es nur auf bestimmten Seiten benötigt wird, laden Sie es nicht überall, nur weil die Integration das leicht macht.

Schnelle Checkliste:

• Identifizieren Sie Drittanbieter-Skripte, die teuer, aber nicht render-kritisch sind.
• Fügen Sie die Astro Partytown-Integration einmal auf Projektebene hinzu.
• Markieren Sie berechtigte Skripte mit type="text/partytown".
• Überprüfen Sie das Verhalten in der Entwicklung und Vorschau, nicht nur in lokalen Annahmen.
• Verwenden Sie Weiterleitungen nur für Skripte, die window-basierte Kommunikation benötigen.
• Verwenden Sie Proxy nur, wenn die Anfragen eines Skripts umgeschrieben werden müssen.
• Halten Sie den Debug-Modus für das Troubleshooting, und deaktivieren Sie ihn, wenn Sie fertig sind.
• Testen Sie nach Updates des Anbieterskripts erneut, da sich externer Code ändern kann.
• Bevorzugen Sie die kleinste mögliche Konfiguration, die das Skript funktionsfähig hält.
• Überprüfen Sie zuerst die am häufigsten besuchten Seiten, damit Sie die größten Benutzerwirkungsrisiken frühzeitig erfassen.

Verwandte Begriffe und weiterführende Literatur

• Astro Themes
• Astro Themes