JavaScript Ladezeit: Wann Skripte Ihre Website ausbremsen

Ein Interessent tippt auf Ihr Suchergebnis. Die Seite erscheint, er tippt auf das Menü — und nichts passiert. Er tippt noch einmal, fester, immer noch nichts. Beim dritten Versuch geht er zurück zu Google und öffnet den nächsten Treffer.

Dieser Moment ist fast immer dasselbe Problem: JavaScript. Und die JavaScript Ladezeit ist einer der wenigen technischen Punkte, bei denen ein Unternehmer ohne Fachkenntnisse sehr genau mitreden kann — weil man das Ergebnis mit dem eigenen Daumen prüfen kann.

Dieser Beitrag erklärt, was JavaScript auf einer Website überhaupt tut, warum jedes zusätzliche Skript Zeit kostet und welche Bausteine man in den allermeisten Fällen ersatzlos streichen kann.

Was JavaScript auf einer Website tut

Eine Website besteht aus drei Schichten. Das HTML liefert die Struktur und die Bedeutung der Inhalte, die Gestaltungsregeln bestimmen das Aussehen — und JavaScript ist die dritte Schicht: das Verhalten. Alles, was auf eine Handlung des Besuchers reagiert, läuft darüber.

Typische Aufgaben sind ein Menü, das sich auf dem Handy aufklappt, eine Bildergalerie mit Vor- und Zurück-Knöpfen, ein Formular, das eine falsch geschriebene E-Mail-Adresse bemängelt, oder ein Kalender zur Terminauswahl. Ohne JavaScript wäre eine Seite nicht unbrauchbar, aber statisch.

Der entscheidende Unterschied zu den beiden anderen Schichten: JavaScript wird nicht einfach angezeigt, es wird ausgeführt. Das Gerät des Besuchers muss die Anweisungen herunterladen, lesen und abarbeiten. Und das kostet Zeit — nicht auf Ihrem Rechner, sondern auf dem Handy Ihres Kunden.

JavaScript und Ladezeit: warum jedes Skript Zeit kostet

Man stellt sich das Laden einer Seite gern als einen einzigen Vorgang vor. Tatsächlich ist es eine Kette. Jedes Skript muss angefordert, übertragen und dann verarbeitet werden. Liegt es auf einem fremden Server, kommt noch der Umweg dorthin dazu — inklusive Namensauflösung und Verbindungsaufbau.

Dazu kommt ein Punkt, den man leicht übersieht: Übertragung und Verarbeitung sind zwei verschiedene Kosten. Eine Datei kann klein sein und trotzdem das Gerät beschäftigen, weil sie viel zu berechnen hat. Bei einem aktuellen Rechner merkt man davon nichts. Bei einem drei Jahre alten Handy im Mobilfunknetz sehr wohl.

Genau deshalb sind Messungen vom eigenen Bürorechner aus wertlos. Die Frage ist nie „lädt es bei mir schnell“, sondern „lädt es bei einem durchschnittlichen Besucher schnell“.

„Die Seite ist da“ und „die Seite reagiert“ sind zwei Dinge

Das ist der wichtigste Gedanke dieses Beitrags. Eine Seite kann vollständig sichtbar sein und trotzdem tot. Der Text steht da, die Bilder sind geladen, alles sieht fertig aus — aber im Hintergrund arbeitet das Gerät noch die Skripte ab. In dieser Lücke gehen Klicks ins Leere.

Für den Besucher ist das schlimmer als eine ehrlich langsame Seite. Eine Seite, die sichtbar noch lädt, gibt ihm ein Signal zu warten. Eine Seite, die fertig aussieht und nicht reagiert, wirkt kaputt.

Google misst genau diese beiden Dinge getrennt: wie lange es dauert, bis der größte sichtbare Inhalt erscheint, und wie schnell die Seite auf eine Eingabe antwortet. Als gut gelten ein Wert bis 2,5 Sekunden für das Erscheinen und bis 200 Millisekunden für die Reaktion. Was hinter diesen Werten steckt, steht in unserer Erklärung der Core Web Vitals, der drei Zahlen von Google.

Die typischen Bremsklötze

Fast immer stammt der größte Teil der Wartezeit nicht aus der eigentlichen Website, sondern aus Zusatzdiensten, die im Laufe der Jahre eingebaut wurden. Diese fünf finden wir am häufigsten:

• Chat-Fenster. Die kleine Sprechblase unten rechts ist oft der schwerste Baustein der ganzen Seite. Sie lädt eine komplette Anwendung nach — für eine Funktion, die auf vielen Unternehmensseiten nie genutzt wird, weil niemand am anderen Ende sitzt.
• Tracking und Statistik. Besucherzähler, Wärmebild-Werkzeuge, Werbenetzwerk-Pixel. Jedes davon ist ein zusätzlicher Server, der befragt werden will — und jedes davon braucht in Europa eine Einwilligung, also zusätzlich ein Zustimmungsfenster, das ebenfalls Skript ist.
• Werbebanner und eingebettete Fremdinhalte. Ein eingebettetes Video oder eine Kartenansicht bringt die halbe Technik des fremden Anbieters mit auf Ihre Seite.
• Schriftarten von fremden Servern. Sie kosten eine zusätzliche Verbindung, verzögern die Textanzeige und übertragen dabei die Adresse des Besuchers an einen Dritten.
• Effekt-Bibliotheken. Große Programmpakete, die eingebunden wurden, damit ein Element beim Scrollen sanft einblendet. Der Zweck ist dekorativ, der Preis ist real.

Auffällig ist, was diese Punkte gemeinsam haben: Keiner davon ist Ihre eigene Website. Es sind Dienste anderer Firmen, die auf Ihrer Seite mitfahren — und über deren Geschwindigkeit Sie keinerlei Kontrolle haben. Fällt der fremde Server aus, wartet Ihr Besucher.

JavaScript Ladezeit senken: was man weglassen kann

Die ehrlichste Frage vor jedem Einbau lautet: Welche Entscheidung des Besuchers wird dadurch besser? Ein Terminkalender für eine Praxis verdient seine Ladezeit. Ein Effekt, bei dem Überschriften hereinfliegen, verdient sie nicht. Wie diese Abwägung bei bildlastigen Auftritten aussieht, zeigt der Beitrag über Portfolio-Websites für Kreative zwischen Bildqualität und Ladezeit.

Wir binden auf den Seiten, die wir bauen, bewusst keine externen Dienste ein: kein Tracking, keine Schriftarten von fremden Servern. Schriften werden mit der Seite ausgeliefert, statt bei einem Dritten abgeholt zu werden. Das spart Verbindungen und erspart nebenbei einen guten Teil der Datenschutz-Diskussion, weil keine Besucherdaten an Dritte abfließen.

Statt eines Chat-Fensters führen die Wege zu uns über WhatsApp und E-Mail. Das ist keine technische Sparmaßnahme, sondern eine Entscheidung: Der Kontaktweg soll dort funktionieren, wo Ihr Kunde ohnehin ist, ohne dass dafür auf jeder Seite eine fremde Anwendung mitlädt.

Vieles, was heute mit Skripten gelöst wird, geht auch ohne. Aufklappbare Abschnitte, sanftes Scrollen und einfache Bildergalerien beherrschen moderne Browser von sich aus. Das ist der Unterschied zwischen einer Seite, die schnell ist, und einer, die nachträglich schnell gemacht werden musste — ein Thema, das auch bei der laufenden Betreuung und SEO immer wieder auf den Tisch kommt.

Häufige Fragen

Kann man auf JavaScript ganz verzichten?

Vollständig selten, sinnvoll auch nicht. Eine Website ohne jede Interaktion ist möglich, aber ein aufklappbares Menü auf dem Handy ist nun einmal praktisch. Die Kunst liegt nicht im Verzicht, sondern in der Menge: nur das, was eine Aufgabe des Besuchers erleichtert, und nichts, was nur beeindrucken soll.

Wie erkenne ich selbst, ob meine Seite an Skripten hängt?

Machen Sie den Daumen-Test unterwegs im Mobilfunknetz, nicht im WLAN. Rufen Sie Ihre Startseite auf und tippen Sie sofort, sobald etwas sichtbar ist, auf das Menü. Reagiert nichts, obwohl die Seite fertig aussieht, haben Sie die Lücke gefunden. Zählen Sie dabei laut mit — mehr als drei Sekunden bis zur ersten Reaktion sind zu viel.

Bringt ein besserer Server etwas gegen lange Ladezeiten?

Nur für den ersten Teil der Kette. Ein schneller Server liefert die Seite früher aus, aber die Verarbeitung der Skripte findet auf dem Gerät des Besuchers statt. Wenn dort zwanzig fremde Dienste abgearbeitet werden müssen, hilft kein Hosting-Wechsel. Die Reihenfolge ist deshalb: erst wegräumen, dann optimieren.

Mein Chat-Fenster bringt aber Anfragen — soll ich es entfernen?

Wenn es nachweislich Anfragen bringt und jemand zeitnah antwortet, behalten Sie es. Prüfen Sie aber zwei Dinge: ob es erst nach dem Laden der Seite dazukommt statt sofort, und ob es auf dem Handy den Bedienknopf verdeckt. Ein Chat, der die Anfrage verhindert, die er ermöglichen soll, ist der schlechteste aller Fälle.

Was Sie jetzt tun können

Machen Sie eine Bestandsaufnahme dessen, was auf Ihrer Seite mitfährt: Chat, Statistik, Karten, Videos, Werbepixel, fremde Schriften. Schreiben Sie neben jeden Eintrag, wer im Haus ihn tatsächlich nutzt und wann er zuletzt einen Nutzen gebracht hat. Alles, wo die Antwort unsicher ist, kommt auf die Streichliste.

Dieselbe Prüfung lohnt sich für die Entwurfsphase: Eine Seite, die von Anfang an vom Handy her gedacht wird, sammelt gar nicht erst den Ballast an, den man später mühsam wieder abträgt.