Für fast jedes Problem in einer Webanwendung gibt es eine fertige JavaScript-Bibliothek. Mit Node.js holst du sie per npm install ins Projekt, und sie steht mit Versionsnummer in der package.json. Noch schneller geht es mit einem Link zu einem Content Delivery Network (CDN) wie unpkg oder jsDelivr, eingebunden in einem <script>-Tag:
<script src="https://unpkg.com/paket@latest/dist/paket.min.js"></script>Eine Zeile im Footer, und die Bibliothek ist da. Meistens jedenfalls.
Was @latest bedeutet
Entscheidend ist der Teil @latest in der URL. Damit überlässt du dem CDN, welche Version es ausliefert: immer die neueste. Das klingt verlockend, denn so bekommst du automatisch die aktuellste, optimierte und sicherste Version der Bibliothek.
Schwierig wird es, wenn diese neueste Version einen Fehler hat, den die Tests der Entwickler nicht gefunden haben. Sobald sie veröffentlicht ist, liefert das CDN sie aus, und deine Besucher laden sie, ohne dass du irgendetwas geändert hast. Im schlimmsten Fall funktioniert deine Anwendung danach nicht mehr. Ein Werkzeug, das JavaScript-Fehler meldet, kann dich alarmieren, eine Garantie ist das nicht. Dasselbe passiert, wenn eine neue Hauptversion mit inkompatiblen Änderungen zur „latest“ wird.
Wie es uns passiert ist
Wir haben das auf die harte Tour gelernt. Wir hatten einen Artikel mit einem Link zu einer unserer Webanwendungen veröffentlicht, die wir wenige Tage vorher gründlich getestet hatten. Kurz danach erschien eine fehlerhafte Version einer der eingebundenen Bibliotheken, und Teile der Anwendung waren nicht mehr benutzbar. Wer dann nicht mehr weiß, welche Version vorher lief, darf jede Bibliothek einzeln von Hand prüfen.
Feste Versionen statt @latest
Sicherer ist ein CDN-Link mit einer bestimmten Version, die nachweislich funktioniert:
<script src="https://unpkg.com/paket@1.2.3/dist/paket.min.js"></script>Ein Update ist dann Handarbeit: Link anpassen, neue Version testen, veröffentlichen. Dafür ändert sich nichts an deiner Anwendung, ohne dass du davon weißt, und das Risiko, dass Besucher eine kaputte Seite sehen, sinkt deutlich.
Eine feste Version erlaubt noch etwas: Mit Subresource Integrity (SRI) schreibst du den Inhalt der Datei als Hash fest. Weicht die geladene Datei davon ab, führt der Browser sie nicht aus, auch dann nicht, wenn jemand die Datei beim CDN selbst manipuliert hat. Mit @latest geht das nicht, weil sich der Inhalt jederzeit ändern darf.
<script src="https://cdn.jsdelivr.net/npm/paket@1.2.3/dist/paket.min.js"
integrity="sha384-HASH" crossorigin="anonymous"></script>Was das mit Nachhaltigkeit zu tun hat
Eine Datei mit fester Version ändert sich nie. Sie kann deshalb lange im Cache des Browsers bleiben und muss bei wiederholten Besuchen nicht erneut übertragen werden. Bei @latest muss das CDN erst herausfinden, welche Version gerade gemeint ist. Wie groß der Unterschied ist, zeigen die Antworten der beiden CDNs (Stand Oktober 2026):
| Anfrage | unpkg | jsDelivr |
|---|---|---|
paket@latest |
Weiterleitung auf die konkrete Version, im Browser 60 Sekunden gecacht | im Browser 7 Tage gecacht |
paket@1.2.3 |
im Browser 1 Jahr gecacht | im Browser 1 Jahr gecacht, als unveränderlich markiert |
Bei unpkg kostet @latest also bei fast jedem Besuch eine zusätzliche Anfrage, bevor die eigentliche Datei kommt. Bei jsDelivr ist es andersherum, aber nicht besser: Ein Besucher kann bis zu eine Woche lang eine alte Version aus seinem Cache verwenden, während ein neuer Besucher schon die neueste bekommt. Ist die neueste Version kaputt und wird repariert, erreicht die Korrektur manche Besucher erst Tage später. Welche Version gerade wo läuft, weißt du nicht.
Lange galt außerdem das Argument, eine Bibliothek vom CDN liege beim Besucher schon im Cache, weil eine andere Webseite sie bereits geladen hat. Das stimmt nicht mehr: Chrome, Firefox und Safari trennen ihren Cache inzwischen pro Webseite. Jede Seite lädt die Datei also selbst, nur eben von einem fremden Server, mit eigener DNS-Abfrage und eigener verschlüsselter Verbindung.
Und bei jedem dieser Abrufe erfährt der CDN-Betreiber die IP-Adresse deiner Besucher. Warum das datenschutzrechtlich nicht egal ist, haben wir in Cookie-Consent oder Cookie-Nonsens? beschrieben.
Nachhaltig ist auch, was nicht plötzlich kaputtgeht. Eine Anwendung, die über Jahre stabil läuft, braucht keine hektischen Notfall-Einsätze und keine Fehlersuche, bei der erst einmal rekonstruiert werden muss, welche Version wann lief.
Oder gleich selbst hosten
Die sparsamste Datei ist die, die gar nicht geladen wird. Bevor du eine Bibliothek einbindest, lohnt sich also die Frage, ob du sie wirklich brauchst oder ob ein paar Zeilen eigener Code reichen. Mehr dazu, warum große Frameworks eine Seite schwerer machen als nötig, steht in unserem Artikel zu klimafreundlichen Webseiten.
Brauchst du sie, kannst du die Datei mit fester Version auf deinen eigenen Server legen und mit deinem übrigen Code bündeln. So machen wir es auf unserer Seite: Bibliotheken laden wir von keinem CDN, CSS und JavaScript bündelt und minimiert Hugo beim Bauen, ganz ohne npm-Pakete. Das einzige externe Skript ist das unserer cookiefreien Statistik, das direkt vom Anbieter kommt.
Wie schwer deine eigene Seite ist und wie viele Anfragen sie an fremde Server stellt, zeigt dir unsere Web-Analyse.
Updates im Blick behalten
Feste Versionen heißen nicht, dass du für immer bei einer Version bleibst. Auch alte Versionen bekommen irgendwann Sicherheitslücken. Lass dich deshalb über neue Versionen deiner Abhängigkeiten benachrichtigen, zum Beispiel über „Watch“ und dann „Custom“ und „Releases“ im GitHub-Repository der Bibliothek. Kommt eine neue Version, testest du sie und erhöhst danach die Versionsnummer im Link. Bei Projekten mit package.json erledigen Dependabot oder Renovate das per Pull Request.
Nur @latest solltest du in einem Link, den echte Besucher laden, nicht verwenden.