Fremde Skripte — du zahlst für die Langsamkeit anderer.

Was sie wirklich kosten.

Die letzte Zeile wird fast immer übersehen: Viele Werkzeuge laden nach dem Start weitere Dateien, teils von weiteren Servern. Aus einem eingebundenen Skript werden schnell sechs Anfragen an vier verschiedene Anbieter.

Besonders auf dem Handy wiegen die ersten beiden Zeilen schwer, weil die Verzögerung je Verbindung dort deutlich höher ist. Ein Skript, das am Schreibtisch kaum auffällt, kostet unterwegs spürbar Zeit (Mobil).

Die üblichen Verdächtigen.

Die ersten drei Zeilen machen auf vielen Websites zusammen den größten Posten aus — und bei allen dreien gibt es eine Lösung, die keine Funktion kostet.

Kosten messen.

1. Netzwerkanalyse öffnen und nach Domain gruppieren.
2. Fremde Domains zählen — wie viele verschiedene Anbieter?
3. Datenmenge je Anbieter ansehen.
4. Wasserfalldarstellung: Welcher Balken ist am breitesten?
5. Testweise blockieren und erneut messen — der ehrlichste Test.
6. Prozessor drosseln und die Ausführungszeit ansehen.

Schritt fünf ist der aussagekräftigste und wird selten gemacht: Die Entwicklerwerkzeuge erlauben es, einzelne Adressen zu blockieren. Lad die Seite einmal mit und einmal ohne den verdächtigen Dienst — die Differenz ist die Antwort, und sie überrascht regelmäßig.

Schritt zwei liefert die Zahl, die man dem Marketing zeigen kann: Wenn eine Seite Verbindungen zu zwölf verschiedenen Anbietern aufbaut, ist das ein Gesprächsanlass (Messen).

Auf Interaktion laden.

Der wirksamste Einzelhebel und oft die größte Verbesserung überhaupt. Statt den Dienst beim Seitenaufbau zu starten, wird zunächst nur ein Platzhalter gezeigt — und das eigentliche Werkzeug lädt erst, wenn jemand darauf klickt.

Funktioniert gut bei:

• Chat: ein Knopf statt des geladenen Widgets. Wer schreiben will, klickt ohnehin.
• Video: Vorschaubild mit Abspielknopf. Lädt erst beim Start (Videos einbinden).
• Karte: statisches Bild mit Hinweis „Karte laden“.
• Social-Media-Einbettungen: Zitat mit Link statt geladenem Beitrag.

Der Nebeneffekt ist angenehm: Das löst zugleich die datenschutzrechtliche Frage, weil ohne Klick keine Verbindung zum fremden Anbieter entsteht. Zwei Probleme, eine Lösung (Datenschutz bei Einbettungen).

Der Einwand lautet meist, dass weniger Leute das Werkzeug nutzen. Das stimmt teilweise — und muss man gegen die Besucher rechnen, die wegen der Ladezeit gar nicht erst ankommen.

Serverseitig lösen.

Für Dienste, die Daten liefern statt Funktion — Bewertungen, Öffnungszeiten, Produktdaten, Social-Media-Beiträge — gibt es eine bessere Lösung als das Widget: Die Daten werden serverseitig abgeholt, zwischengespeichert und als normaler Inhalt ausgegeben.

Das hat drei Vorteile: keine fremde Verbindung im Browser, keine Wartezeit für den Besucher, und die Inhalte stehen als Text in der Seite — also auch für Suchmaschinen lesbar, was bei einem Widget oft nicht der Fall ist.

Der Aufwand ist überschaubar: ein Abruf im Hintergrund, etwa stündlich, und eine Ausgabe im Theme. Bei Bewertungen und Öffnungszeiten lohnt das fast immer.

Das Einwilligungsbanner.

Ein eigener Abschnitt, weil es doppelt problematisch ist. Das Banner erscheint als Erstes und entscheidet darüber, ob die anderen Dienste laden dürfen — es sitzt also am kritischen Pfad.

Wenn es selbst von einem fremden Server geladen wird, wartet die Seite auf dieses Skript, bevor überhaupt etwas passiert. Das ist die ungünstigste denkbare Stelle für eine externe Abhängigkeit.

Was hilft: Die Banner-Lösung lokal einbinden statt von der Anbieterquelle. Viele Anbieter erlauben das. Dazu das Banner so bauen, dass es den Inhalt nicht verschiebt, sondern darüber schwebt — sonst kommt zur Wartezeit noch ein Layoutsprung (CLS).

Und prüfen, ob die Einwilligung tatsächlich wirkt: Ein Banner, das erscheint, während im Hintergrund schon alles lädt, kostet Tempo und erfüllt seinen Zweck nicht.

Tracking und Marketing.

Hier sammelt sich über die Jahre am meisten an. Auf vielen Websites laufen Werkzeuge, die vor drei Jahren für eine Kampagne eingebaut und nie entfernt wurden.

1. Vollständige Liste erstellen — was läuft tatsächlich?
2. Je Werkzeug fragen: Wer sieht die Daten an, wann zuletzt?
3. Entfernen, was niemand nutzt.
4. Zusammenfassen, wo ein Werkzeug mehrere ersetzen kann.
5. Nachrangig laden, was bleibt.
6. Serverseitige Erfassung erwägen, wo möglich.

Punkt zwei ist die unangenehme Frage und die wirksamste: Ein Werkzeug, dessen Auswertung seit einem Jahr niemand geöffnet hat, kostet Tempo und bringt nichts (Analytics).

Schriften.

Ein Sonderfall, weil Schriften besonders früh gebraucht werden. Von fremder Quelle geladen kosten sie Namensauflösung und Verbindungsaufbau genau in dem Moment, in dem der erste Text erscheinen soll.

Lokal ausliefern löst das vollständig: Die Verbindung steht bereits, die Datei kommt sofort. Und die alte Hoffnung, die Schrift sei schon von einer anderen Website her vorhanden, trifft nicht mehr zu — der Zwischenspeicher der Browser arbeitet heute pro Website getrennt.

Das ist die Maßnahme mit dem besten Verhältnis von Aufwand und Wirkung in diesem ganzen Bereich (Schriften optimieren).

Wenn ein Dienst ausfällt.

Der Fall, an den niemand denkt und der am meisten Schaden anrichtet. Ein fremder Server, der nicht antwortet, lässt den Browser warten — bis zur Zeitüberschreitung, und die kann zehn Sekunden und länger betragen.

Je nach Einbindung steht die Seite in dieser Zeit. Bei einem blockierend eingebundenen Skript erscheint gar nichts, bis die Wartezeit abgelaufen ist.

Zwei Gegenmittel: Skripte nachrangig laden, damit sie den Aufbau nicht blockieren (Blockierende Dateien). Und die Einbindung so bauen, dass die Seite ohne den Dienst funktioniert — ein Chat, der nicht lädt, ist ärgerlich; eine Seite, die deshalb weiß bleibt, ist ein Ausfall.

Prüfen lässt sich das, indem man den Dienst in den Entwicklerwerkzeugen blockiert und die Seite neu lädt. Was dann passiert, erleben deine Besucher an dem Tag, an dem der Anbieter Probleme hat.

Entscheidungshilfe.

1. Brauchen wir das Werkzeug? Die erste und wirksamste Frage.
2. Wer sieht die Daten an? Wenn niemand: weg.
3. Geht es serverseitig? Dann so.
4. Geht es auf Klick? Dann so.
5. Lässt es sich lokal einbinden? Dann so.
6. Kann es nachrangig laden? Mindestens das.
7. Funktioniert die Seite ohne? Muss sie.

Diese Reihenfolge nach jedem neuen Werkzeug durchzugehen, hält eine Website über Jahre schnell. Ohne sie sammelt sich an, und nach drei Jahren fragt sich jemand, warum die Seite langsam geworden ist, obwohl niemand etwas gemacht hat.

Wenn du nicht weiterkommst.

Wenn du wissen willst, was die eingebundenen Werkzeuge deine Besucher tatsächlich kosten. Ich messe deine Seite mit echten Nutzerdaten statt mit einem einzelnen Test, sortiere die Befunde nach Wirkung und behebe die, die zählen: Ladezeit optimieren. Dauerhaft begleitet die WordPress-Wartung — damit neue Inhalte die Werte nicht wieder kaputt machen.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich mache Websites schneller — und zwar messbar, nicht gefühlt. Das heißt: erst messen, dann die zwei oder drei Stellen beheben, die tatsächlich den Unterschied machen, dann noch einmal messen.

Was ich nicht mache: eine Punktzahl schönrechnen. Es gibt Tricks, mit denen ein Testwerkzeug hundert Punkte zeigt, während die Seite für echte Besucher gleich langsam bleibt. Das ist Selbstbetrug, und ich sage dir, wenn jemand dir so etwas verkauft hat.

Ich arbeite mit dem, was du hast — Theme, Plugins, Hoster. Ein Neubau ist manchmal die ehrlichere Antwort, und dann sage ich das auch, statt monatelang an einer Seite zu optimieren, die grundsätzlich falsch gebaut ist.