JavaScript mit Terser Verkleinern
Verkleinern Sie Ihr JavaScript mit Terser, um die Dateigröße zu reduzieren und Ihre Website zu beschleunigen.
Ihr Quellcode bleibt auf dem Gerät
Nichts, was später zu löschen wäre
Für proprietären Code gebaut
Läuft in jedem modernen Browser
So funktioniert es
- 1
JavaScript einfügen
Ein Modul, ein Skript oder ein Ausschnitt, der vor dem Ausliefern kleiner werden soll.
- 2
Ergebnis prüfen
Vergleichen Sie die Größen und lesen Sie die Hinweise, bevor Sie etwas ersetzen.
- 3
Ausgabe kopieren
Nehmen Sie sie in eine Build-Ausgabe, eine Vorlage oder ein Inline-Skript-Tag.
Warum dieses Tool
Sichere lokale Umbenennung
Nur Bindungen, deren sämtliche Verweise das Werkzeug sieht, werden gekürzt — genau das hält die Ausgabe funktionsfähig.
Größen vorher und nachher
Die rohe Ersparnis neben dem, was daraus nach Komprimierung wird — das ist die Zahl, die zählt.
Syntaxfehler gemeldet
Ungültige Eingabe nennt die Stelle des Scheiterns, statt Ausgabe zu erzeugen, die beim Laden bricht.
Kommentare weg, Direktiven bleiben
Lizenzköpfe und `"use strict"` überleben, denn sie stillschweigend zu entfernen ändert Verhalten oder verletzt eine Lizenz.
Nichts wird hochgeladen
Der Code wird in Ihrem Browser verarbeitet, proprietärer Quellcode erreicht also nie einen Server.
Kostenlos, ohne Konto
Keine Anmeldung, kein Wasserzeichen, keine Obergrenze für die Menge.
Die Ersparnis stammt vom Umbenennen, nicht vom Löschen von Leerzeichen
Leerraum und Kommentare zu entfernen ist der sichtbare und der kleinere Teil. Der Großteil der Verringerung in einer echten Datei stammt vom Kürzen: Jede lokale Variable, jeder Parameter und jeder Funktionsname wird durch ein oder zwei Zeichen ersetzt, sodass `calculateTotalPrice` zu `t` wird und eine beschreibende Codebasis zusammenfällt. Dort sitzt auch das gesamte Risiko. Ein Verkleinerer kann eine Bindung nur dann sicher umbenennen, wenn er jede Stelle sieht, an der auf sie verwiesen wird — was für alles gilt, dessen Gültigkeitsbereich innerhalb einer Funktion liegt. Einen Verweis, der aus einer Zeichenkette stammt, sieht er nicht, und genau diese Verweise brechen. Diese eine Unterscheidung zu verstehen erklärt jeden Verkleinerungsfehler, dem Sie begegnen dürften, und sagt Ihnen, wo zu schauen ist, wenn verkleinerter Code scheitert und das Original läuft.
Was nicht umbenannt werden darf, und warum das Werkzeug es nicht erkennt
Die gefährlichen Fälle haben dieselbe Gestalt: ein Name, der als Text an einer Stelle steht, die der Verkleinerer nicht als Code liest. Eine Eigenschaft als `obj["someKey"]` anzusprechen und sie anderswo `obj.someKey` zu schreiben bedeutet, dass eine Form umbenannt wird und die andere nicht. Objektschlüssel, die zu einer JSON-Nutzlast aus einer API passen müssen, sind dasselbe Problem — benennen Sie den Schlüssel um, und die Anfrage passt nicht mehr zum Server. Ältere Frameworks zur Abhängigkeitsinjektion lesen Parameternamen, um zu entscheiden, was einzusetzen ist; deshalb war das Verkleinern einer AngularJS-Anwendung ohne den Annotationsschritt ein berühmter Weg, sie vollständig zu zerlegen. Alles, was `Function.name` oder einen Klassennamen zur Laufzeit prüft, samt mancher Serialisierungs- und Protokolllogik, ist ebenso ausgesetzt. Praktische Regel: Namen, die eine Grenze überschreiten — Netzwerknutzlast, Vorlage, Zeichenkettensuche — müssen in Anführungszeichen stehen und unangetastet bleiben.
Quellzuordnungen machen die Ausgabe debugbar und können Ihren Code preisgeben
Verkleinerter Code liefert eine Aufrufliste, die auf Zeile 1, Spalte 48.000 zeigt — nutzlos. Eine Quellzuordnung ist die übliche Abhilfe: eine getrennte Datei, die Positionen der Ausgabe auf das Original zurückführt, sodass der Browser den geschriebenen Code zeigt. Erzeugen Sie sie — die Alternative ist blindes Debuggen im Betrieb. Zu planen ist, wo die Zuordnung liegt. Sie enthält Ihren ursprünglichen Quellcode, meist samt der entfernten Kommentare, und liegt sie an einem öffentlich erreichbaren Pfad, auf den ein Kommentar am Ende Ihres Bündels verweist, kann sie jeder abrufen und Ihren unverkleinerten Code lesen. Bei Open Source in Ordnung, sonst eine echte Offenlegung. Die üblichen Antwort: Zuordnungen an den Fehlerdienst hochladen und nicht öffentlich ausliefern oder auf authentifizierte Anfragen beschränken.
Verkleinern ist keine Verschleierung und schützt nichts
Es gehört klar gesagt, denn der Glaube ist verbreitet: Namen zu kürzen verbirgt keine Logik. Verkleinerter Code lässt sich mit jedem Formatierer in einem Schritt neu einrücken, und auch ohne die Namen bleiben Struktur, Zeichenketten, API-Endpunkte und Algorithmus vollständig lesbar. Wer Ihren Client-Code verstehen will, wird es tun — in Minuten. Das zählt, weil es zu echten Fehlern führt: ein API-Schlüssel, der ins Bündel eingecheckt wird in der Annahme, Verkleinerung verberge ihn, oder ein clientseitig geprüftes Funktionsflag, das als Zugriffskontrolle behandelt wird. Muss ein Code oder Wert geheim bleiben, darf er überhaupt nicht in einen Browser gelangen; die einzige verlässliche Grenze ist Ihr Server. Bewusste Verschleierer existieren, erhöhen den Aufwand etwas, kosten erheblich an Größe und Geschwindigkeit — und ändern diesen Schluss nicht.
Komprimierung auf der Leitung leistet das meiste, was der Verkleinerung zugeschrieben wird
Verkleinerung als Bandbreitenersparnis zu verkaufen ist ein Jahrzehnt veraltet, denn alles wird heute mit gzip oder brotli ausgeliefert, und diese Verfahren sind ausgerechnet in dem sehr gut, was Verkleinerung entfernt. Wiederholter Leerraum und lange wiederholte Kennungen komprimieren auf fast nichts; eine verkleinerte und eine formatierte Datei unterscheiden sich nach der Komprimierung deshalb oft weit weniger als davor — weshalb die zählende Größe die komprimierte ist und dieses Werkzeug beide zeigt. Verkleinerung verdient ihren Platz aus zwei anderen Gründen: weniger Quellcode heißt weniger, was der Browser parsen und übersetzen muss, bevor etwas läuft — auf Mobilgeräten messbar; und die Bytes sind auch vor der Komprimierung kleiner. Doch wenn Sie wählen, wo Sie Aufwand in die Bündelgröße stecken, schlägt das Entfernen unbenutzten Codes das Kürzen von Namen mit deutlichem Abstand.
Warum lokales Verkleinern bei dieser Art Text zählt
Die Eingabe eines Verkleinerers ist Quellcode, und Quellcode ist das, was ein Unternehmen am wenigsten veröffentlichen will. Er trägt Ihre Endpunktadressen, die internen Funktions- und Modulnamen, die Kommentare, die erklären, wofür ein Behelf da ist, gelegentlich einen Schlüssel, der dort nicht hingehört, und die Struktur eines Systems, dessen Entwurf echte Arbeit gekostet hat. Eine proprietäre Datei in einen gehosteten Verkleinerer einzufügen sendet all das an Dritte — im Tausch gegen eine Größenreduktion, die Sie lokal hätten haben können. Dieses Werkzeug verarbeitet den Code auf der Seite und überträgt nichts, nachprüfbar im Netzwerk-Tab der Entwicklerwerkzeuge — und für die eine Textart, die buchstäblich geistiges Eigentum Ihres Arbeitgebers ist, ist das die vernünftige Voreinstellung.
Häufige Fehler, die Sie vermeiden sollten
- `obj.someKey` und `obj["someKey"]` für dieselbe Eigenschaft mischen. Eine Form wird umbenannt, die andere nicht — nach dem Verkleinern zeigen beide nicht mehr auf dasselbe.
- Schlüssel umbenennen, die zu einer Netzwerknutzlast passen müssen. An eine API gesandte oder von ihr empfangene Objektschlüssel vergleicht der Server als Zeichenketten — setzen Sie sie in Anführungszeichen.
- Zur Laufzeit auf Parameter- oder Funktionsnamen bauen. Abhängigkeitsinjektion nach Parameternamen und Logik, die `Function.name` liest, brechen — genau diese Namen ersetzt das Kürzen.
- Quellzuordnungen an einen öffentlichen Pfad veröffentlichen. Eine Zuordnung enthält Ihren Originalcode samt entfernter Kommentare — laden Sie sie zum Fehlerdienst statt sie neben das Bündel zu legen.
- Verkleinerung für Schutz halten. Verkleinerter Code lässt sich in einem Schritt neu einrücken, und Zeichenketten, Endpunkte und Algorithmus bleiben lesbar — nichts Geheimes darf in einen Browser.
Im Vergleich
| Kriterium | Dieses Werkzeug | Online-Verkleinerer | Eine Build-Kette |
|---|---|---|---|
| Quellcode an einen Server gesendet | Nie | Meistens ja | Nein |
| Komprimierte Größe gezeigt | Ja | Selten | Mit einer Erweiterung |
| Einrichtung nötig | Keine | Keine | Konfiguration |
| Entfernt unbenutzten Code | Nein | Nein | Ja |
| Konto oder Anmeldung | Nicht nötig | Manchmal verlangt | Nicht nötig |
| Preis | Kostenlos | Kostenlos / Bezahltarife | Kostenlos |
Funktionen
Kennungen kürzen
Lokale Variablen- und Funktionsnamen werden gekürzt — daraus stammt der größte Teil der Verringerung.
Leerraum und Kommentare entfernen
Alles, was der Parser ignoriert, fällt weg, auch die Zeilenumbrüche, die die Datei lesbar machen.
Komprimierungsbewusste Größen
Verkleinerte und komprimierte Größe, denn nur die zweite erreicht die Nutzerin.
Moderne Syntax unterstützt
Klassen, Pfeilfunktionen, Template-Literale, optionale Verkettung und Modulsyntax werden verstanden.
Verträgt große Dateien
Ganze Bündel werden ohne Upload und ohne Größenobergrenze verkleinert.
Umgekehrtes Formatieren
Auch ein Verschönerungsmodus, denn minimierten Fremdcode zu lesen ist ein häufiges Bedürfnis.
Nichts zu installieren
Kein Build-Werkzeug, keine Laufzeitumgebung, keine Abhängigkeiten — es läuft auf der Webseite.
Bereit für Arabisch und RTL
Vollständige Oberfläche in acht Sprachen, darunter Arabisch von rechts nach links.
Standardmäßig sicher
Über HTTPS ausgeliefert, ohne Inhaltsverfolgung und ohne Upload an Dritte.
Wer es nutzt
Frontend-Entwicklung
Ein eigenständiges Skript verkleinern, das keinen Build-Schritt durchläuft.
Web-Performance
Verkleinerte und komprimierte Größe vergleichen, um zu sehen, wo die Ersparnis wirklich liegt.
Wer Fremdcode liest
Mit der Verschönerungsrichtung eine verkleinerte Bibliothek lesbar genug machen, um ihr zu folgen.
Wer ein Skript einbettet
Einen kleinen Ausschnitt auf eine Größe bringen, die sich in eine Seite einfügen lässt.
Häufig Gestellte Fragen
Nein. Alles läuft lokal im Browser — Ihr Text wird nie hochgeladen, gespeichert oder geteilt.
Ja — komplett kostenlos, ohne Konto und ohne Limits.