Astro-Entwickler in Köln

Auf den meisten Astro-Seiten steckt das meiste JavaScript nicht im eigenen Code, sondern in dem, was Dritte hineinreichen: Statistik, Karte, Video, Chat. Für Unternehmen in Köln stellen sich dazu zwei Fragen. Darf das Skript schon laden, und was kostet es die Seite an Reaktionszeit?

Auf dieser Seite beschreibe ich, wie ich Fremdskripte in Astro einbinde: erst nach Einwilligung, als Vorschau statt als sofortiges Embed, bei Bedarf im Web Worker und mit einer Messung, die den Verursacher benennt. Ich bin Einzelentwickler, arbeite remote und schriftlich, und die Gestaltung liefern Sie.

Foto: GeorgDerReisende, CC BY-SA 4.0, Wikimedia Commons.

#Was § 25 TDDDG für ein Skript bedeutet

Der Paragraf knüpft nicht an das Skript an, sondern an das, was es im Browser tut. Nach § 25 Abs. 1 TDDDG ist die Speicherung von Informationen in der Endeinrichtung oder der Zugriff auf dort gespeicherte Informationen nur zulässig, wenn der Endnutzer auf der Grundlage von klaren und umfassenden Informationen eingewilligt hat. Für beides verweist die Vorschrift auf die DSGVO.

Ausgenommen ist nach Abs. 2 unter anderem eine Speicherung, die unbedingt erforderlich ist, damit der Anbieter einen Dienst bereitstellen kann, den der Nutzer ausdrücklich gewünscht hat. Ob das auf einen Chat, eine Karte oder ein Video zutrifft, hängt vom Dienst und von dem ab, was er beim Laden tatsächlich ablegt oder ausliest. Das prüfe ich im Browser, nicht im Marketingtext des Anbieters, und halte das Ergebnis schriftlich fest. Die Rechtsberatung ersetzt das nicht.

Für die Technik folgt daraus ein einfacher Grundsatz: Ein Skript, für das eine Einwilligung nötig ist, darf nicht im HTML stehen, bevor sie vorliegt. Wie ein Banner nach einem WordPress-Umzug überhaupt entfällt oder bleibt, beschreibt die Seite zu Formularen und Einwilligung nach der Migration. Hier geht es um das, was danach kommt: Dienste von Dritten.

#Skripte erst nach der Einwilligung laden

Die Astro-Dokumentation zu Client-Skripten sagt: Astro verarbeitet ein <script> nur, wenn es kein anderes Attribut als src trägt. Verarbeitete Skripte werden zu Modulen, gebündelt und bei Bedarf eingebettet. Skripte aus public/ oder von einem fremden Server gehören laut Dokumentation mit is:inline und src eingebunden, was Bündelung und Optimierung überspringt.

Für ein einwilligungspflichtiges Skript heißt das: Es steht nicht als <script src> im Quelltext. Stattdessen lädt ein kleiner eigener Code das Fremdskript, sobald die Einwilligung vorliegt. Der Ereignisname ist mein eigener Entwurf, Ihre Consent-Lösung muss ihn auslösen:

<script is:inline>
  window.addEventListener('consent:statistik', () => {
    const s = document.createElement('script');
    s.src = 'https://statistik.example/skript.js';
    s.async = true;
    document.head.append(s);
  }, { once: true });
</script>

Drei Dinge gehören dazu. Erstens: Wer die Einwilligung widerruft, braucht einen Weg, das Skript wieder zu entladen oder die Seite neu zu laden. Zweitens: Die Entscheidung wird gespeichert, und auch diese Speicherung ist ein Fall für § 25, den die Datenschutzerklärung benennt. Drittens: Ein Dienst, der nach der Einwilligung weitere Skripte nachlädt, wird in der Prüfung mit allen Hosts erfasst, nicht nur mit dem ersten.

Welche Angaben die Datenschutzerklärung enthalten muss, wenn Videoplayer oder Social-Media-Plugins im Einsatz sind, nennt die LDI NRW in ihrem Muster für Datenschutzhinweise. Dort steht auch, dass der Link zu den Hinweisen von jeder einzelnen Seite aus mit einem Klick erreichbar sein muss.

#Embeds als Vorschau: Facade und Click-to-load

Eine Facade ist nach web.dev ein statisches Element, das dem eingebundenen Dienst ähnelt, aber nicht funktioniert. Klickt der Nutzer darauf, lädt der echte Embed: Click-to-load verbindet Lazy Loading mit der Facade. web.dev nennt dafür zwei Zahlen: Viele beliebte Embeds bringen mehr als 100 KB JavaScript mit, teils bis zu 2 MB, und das Lazy Loading eines YouTube-Embeds kann auf der Startseite etwa 500 KB sparen.

Für Karten, Videos und Chat-Fenster hat das einen zweiten Nutzen, den die Performance-Seite nicht nennt: Die Vorschau ist der Ort, an dem Sie die Einwilligung einholen. Der Besucher sieht, was geladen wird, und die Anfrage an den Drittanbieter entsteht erst nach dem Klick. Das Muster in Astro ist klein:

<div class="video-vorschau" data-src="https://video.example/embed/ID">
  <button type="button">Video laden</button>
  <p>Beim Laden werden Daten an den Anbieter übertragen.</p>
</div>

<script>
  document.querySelectorAll('.video-vorschau').forEach((box) => {
    box.querySelector('button')?.addEventListener('click', () => {
      const f = document.createElement('iframe');
      f.src = box.dataset.src ?? '';
      f.title = 'Eingebettetes Video';
      box.replaceChildren(f);
    });
  });
</script>

Das Attribut loading="lazy" am Iframe genügt dafür nicht. web.dev beschreibt es als Hinweis an den Browser, das Laden aufzuschieben, und nennt es auch für Google-Maps-Iframes. Der Browser lädt den Iframe trotzdem, sobald er in die Nähe des sichtbaren Bereichs kommt, ohne dass jemand etwas bestätigt hat. Es hilft der Ladezeit, nicht der Rechtslage.

Der Hinweistext in der Vorschau, die Beschriftung des Buttons und das Aussehen kommen aus Ihrem Layout. Ich baue die Logik und die Zugänglichkeit: Der Button ist ein echter Button, per Tastatur erreichbar, und der Iframe bekommt einen Titel.

#Partytown: Skripte in den Web Worker

Die offizielle Astro-Integration installiert Partytown, eine Bibliothek, die laut Dokumentation ressourcenintensive Skripte in einen Web Worker verlagert, besonders Analyse- und Werbeskripte. Installiert wird mit npx astro add partytown, aktiviert ist sie danach auf allen Seiten. Ein vorhandenes Skript wandert in den Worker, indem sein Typ geändert wird:

<script type="text/partytown" src="fancy-analytics.js"></script>

Zwei Optionen aus der Dokumentation sind für Fremdskripte wichtig. Mit config.forward benennen Sie Variablen, die vom Worker an das Fenster weitergereicht werden, etwa dataLayer.push. Mit config.resolveUrl() lassen sich Anfragen über einen Proxy umleiten; die Funktion läuft im Service Worker, wird beim Senden an den Client serialisiert und darf deshalb nichts außerhalb ihres eigenen Gültigkeitsbereichs verwenden und nur in JavaScript geschrieben sein. Setzen Sie eine Eigenschaft sowohl in der Integration als auch in window.partytown, gilt die der Integration.

Partytown ändert den Ort der Ausführung, nicht die Rechtslage: Ein Skript im Worker braucht dieselbe Einwilligung wie eines im Hauptthread. Ob ein bestimmter Dienst im Worker richtig arbeitet, prüfe ich an diesem Dienst, nicht pauschal. Läuft er nicht, bleibt er im Hauptthread, und die Last wird anders begrenzt, etwa durch späteres Laden.

#async, defer und Verbindungen

Für die Reihenfolge nennt web.dev zwei Regeln. Ein Skript mit async läuft, sobald es fertig geladen ist, und kann das Parsen unterbrechen; es gehört dahin, wo ein früher Start wichtig ist. Ein Skript mit defer läuft erst nach dem vollständigen Parsen des HTML, in der Reihenfolge des Dokuments; web.dev nennt dafür weniger kritische Skripte wie einen Player unterhalb des sichtbaren Bereichs.

Wird ein Skript wie oben per Code angelegt, ist async meist die passende Wahl, weil nichts im Dokument auf seine Reihenfolge wartet.

Zwei Hinweise aus demselben Artikel helfen bei Verbindungen. <link rel="preconnect"> lohnt nur für Hosts, die sicher gebraucht werden, denn laut web.dev schließt der Browser Verbindungen, die zehn Sekunden ungenutzt bleiben. Und ein einwilligungspflichtiger Host bekommt kein preconnect vor der Einwilligung, weil schon der Verbindungsaufbau eine Anfrage an den Anbieter ist. Selbst gehostete Skripte sparen DNS-Abfragen und erlauben eigene Caching-Header, haben aber laut web.dev den Nachteil, dass sie veralten. Ob der Anbieter das Selbsthosten erlaubt, klären Sie vorab.

Auf der Ebene der Sicherheitsheader gehört jeder Host, den ein Skript nachlädt, in die Content Security Policy. Die Umsetzung zeigt die Seite zu Sicherheitsheadern. Welche Teile einer Seite überhaupt Skript bekommen, wenn eine Komponente nur beim Sichtbarwerden hydratisiert, beschreibt die Seite zu Astro Islands. Formulare sind ein eigenes Thema, das die Seite zu Formularen mit Astro Actions behandelt.

#Wie sich Fremdskripte auf die INP auswirken

web.dev misst mit der INP die Latenz aller Klicks, Taps und Tastatureingaben während eines Besuchs. Bis 200 Millisekunden gilt als gut, über 500 Millisekunden als schlecht, bewertet am 75. Perzentil der Feldwerte, getrennt nach Mobil und Desktop. Die Schwellen stehen auch auf der Seite zu den Core Web Vitals.

Fremdskripte belasten die INP, wenn sie den Hauptthread beschäftigen, während jemand klickt. Wie stark, hängt vom Dienst und vom Gerät ab. Gemessen wird in zwei Schritten, wie web.dev beschreibt:

1. CrUX zuerst. PageSpeed Insights zeigt die Feldwerte einer Adresse, mobil und Desktop. Sie sagen, ob ein INP-Problem besteht, aber nicht, woher es kommt.
2. Attribution danach. Die Variante web-vitals/attribution der Bibliothek liefert mit onINP das Zielelement der Interaktion als CSS-Selektor, die Art der Interaktion, die Phasen Eingabeverzögerung, Verarbeitung und Darstellung sowie Long-Animation-Frame-Einträge. Jeder Eintrag enthält scripts mit Aufrufer und sourceURL, und damit lässt sich sagen, ob eigener Code oder ein Fremdskript die Zeit gekostet hat.

Eine Grenze nennt web.dev selbst: Bei Cross-Origin-Iframes lässt sich die INP in JavaScript teils nicht messen. Ein Chat im Iframe taucht in den Werten also womöglich nicht auf, selbst wenn er die Seite stört. Die Messung ohne und mit dem Dienst, nacheinander und mit gleichem Gerät, gehört deshalb zum Bericht.

Auch die Messung selbst gehört in die Prüfung: Sendet die Seite Messwerte an einen Endpunkt, steht dieser in der Datenschutzerklärung, und es wird geklärt, ob dabei etwas im Endgerät gespeichert wird.

#Köln: Karten aus eigenen Daten

Für Karten gibt es auf Kölner Seiten eine Alternative zum Kartenanbieter: Das Portal Offene Daten Köln stellt offene Verwaltungsdaten der Stadt und von Partnern bereit, maschinenlesbar, und viele Datensätze sind direkt über eine API abrufbar. Als Beispiele nennt die Startseite ein Baumkataster und Bebauungspläne. Ob ein Datensatz Ortsangaben enthält und unter welchen Bedingungen Sie ihn nutzen dürfen, steht in seiner Beschreibung und in den Nutzungsbedingungen des Portals.

Für Astro bedeutet das: Die Daten werden beim Build abgeholt und als statische Karte oder Liste ausgegeben. Dann entsteht keine Anfrage an einen Kartenanbieter. Ob das reicht, hängt davon ab, was Ihre Besucher mit der Karte tun. Eine Anfahrtsskizze braucht keine Kartenkacheln im Browser. Eine Suche mit Zoom braucht sie.

#Prüfliste für Ihre Seite

#So läuft ein Projekt

1. Sie schicken mir die Adresse und die Liste der Dienste, die Ihr Team eingebunden hat oder einbinden will.
2. Ich lade die Seite ohne Zustimmung und mit Zustimmung und halte schriftlich fest, was in beiden Fällen geladen wird.
3. Sie erhalten einen schriftlichen Umfang mit Annahmen: welche Dienste hinter eine Einwilligung kommen, welche zur Vorschau werden, welche in den Worker.
4. Ich setze es auf einer Staging-Umgebung um. Texte und Layout der Einwilligungsabfrage liefern Sie.
5. Nach Ihrer Abnahme folgt die Veröffentlichung. Eine laufende Betreuung ist optional und läuft über Stundenpakete, die nicht in den Folgemonat übergehen.

Zum Start brauche ich Zugang zum Repository oder zum Hosting, die Liste der Dienste mit den Verträgen, soweit vorhanden, und die Person, die über die Datenschutzerklärung entscheidet.

#Häufige Fragen

#Muss ich Partytown einsetzen, wenn ich Skripte erst nach der Einwilligung lade?

Nein. Die Einwilligung entscheidet, ob ein Skript überhaupt geladen wird, Partytown entscheidet, in welchem Thread es danach läuft. Die Astro-Dokumentation beschreibt Partytown als Bibliothek, die ressourcenintensive Skripte in einen Web Worker verlagert. Das ersetzt keine Einwilligung nach § 25 TDDDG.

#Reicht loading=“lazy” an einem YouTube-Iframe, damit kein Cookie-Banner nötig ist?

Nein. web.dev beschreibt loading=“lazy” als Aufschub des Ladens, nicht als Einwilligung. Sobald der Iframe in die Nähe des sichtbaren Bereichs kommt, lädt der Browser ihn. Wo § 25 TDDDG eine Einwilligung verlangt, muss der Iframe erst nach dem Klick auf eine Vorschau entstehen.

#Wie finde ich heraus, welches Fremdskript meine INP verschlechtert?

Zuerst zeigen CrUX-Daten in PageSpeed Insights, ob ein INP-Problem besteht. Die Ursache liefert die Attribution-Variante der web-vitals-Bibliothek: Sie nennt das Zielelement der Interaktion und über Long Animation Frames die Skriptquelle. So lässt sich eigener Code von Fremdcode trennen.

#Brauche ich für Google Maps oder YouTube immer eine Einwilligung?

Das hängt davon ab, ob der Dienst beim Laden etwas im Endgerät speichert oder dort ausliest. Dann greift § 25 Abs. 1 TDDDG. Nur eine technisch erforderliche Speicherung für einen ausdrücklich gewünschten Dienst ist nach Abs. 2 Nr. 2 ausgenommen. Die Prüfung gehört vor die Einbindung und in Ihre Datenschutzerklärung.

#Kann ich Skripte von Dritten selbst hosten?

Ja, web.dev nennt das als Option: weniger DNS-Abfragen, eigene Caching-Header, HTTP/2 oder HTTP/3. Der Nachteil laut web.dev: Das Skript veraltet, weil automatische Aktualisierungen entfallen. Ob die Lizenz des Anbieters das Selbsthosten erlaubt, klären Sie vorab.

#Wie läuft das Projekt, und was brauche ich von Ihnen?

Sie schicken mir die Adresse der Seite und eine Liste der eingebundenen Dienste. Ich prüfe, was beim Laden geschieht, und schicke Ihnen eine schriftliche Einschätzung samt Umsetzungsvorschlag. Texte der Einwilligungsabfrage und das Layout liefern Sie, ich setze sie um.

#Ihre Anfrage

Senden Sie mir Ihre Anfrage über das Kontaktformular. Nennen Sie die Adresse Ihrer Seite, die eingebundenen Dienste, Ihr Ziel und den gewünschten Termin. Ich antworte schriftlich an Werktagen, und die erste Einschätzung kostet nichts.