HTTP/2, HTTP/3 und Minifizierung: Lohnt sich Minifizierung noch?

HTTP/2 und HTTP/3 ändern den Weg der Dateien, nicht ihre Größe. Messungen zu Größe, Kompilierzeit und Bundling zeigen, was Minifizierung noch bringt.

22.10.2026

15 Min. Lektüre

Teilen Sie diesen Artikel:

HTTPMinimierungKompressionLeistungBündeln

HTTP/2 hat den Weg der Dateien geändert, nicht ihre Größe

Eine Behauptung kehrt immer wieder: Seit HTTP/2 Anfragen bündelt, müsse man weder minifizieren noch Dateien zusammenfassen. Die Hälfte stimmt. Das Protokoll hat die Kosten vieler kleiner Anfragen beseitigt. Es hat aber kein einziges Byte aus einer JavaScript-Datei entfernt, und der Browser muss jede davon weiterhin laden, entpacken und kompilieren. Dieser Leitfaden trennt, was HTTP/2 und HTTP/3 geändert haben, von dem, was unberührt blieb. Die Zahlen stammen aus drei Tests vom 22. Oktober 2026 (dem Benchmark-Datensatz von FastMinify, einem Paket mit 644 Modulen und einem Kompiliertest in V8). Dazu kommen die RFCs und die Browser-Dokumentation, die im Text genannt werden. Zur Kompression lesen Sie unseren GZIP- und Brotli-Leitfaden.

HTTP/2 und HTTP/3 ändern, wie Anfragen transportiert werden, nicht die Größe der Dateien darin.

Bei 10 nicht minifizierten JavaScript-Bibliotheken entfernt die Minifizierung noch immer etwa die Hälfte der gzip- und Brotli-Bytes.

Bei CSS sinkt der Gewinn nach der Kompression auf etwa 6 %, das Argument ist dort schwächer.

644 winzige Module lassen sich 2,4-mal schlechter komprimieren als derselbe Code in einer Datei.

V8 hat die minifizierten Bibliotheken 7 % bis 37 % schneller kompiliert, auf einem schnellen Laptop sind das 0,1 bis 1,2 ms je Bibliothek.

Server Push, Domain-Sharding und eine einzige Datei für die ganze Website sind die Gewohnheiten, die Sie ablegen sollten.

Was die Protokolle geändert haben und was nicht

HTTP/2 transportiert viele Anfragen über eine Verbindung

HTTP/2 (RFC 9113, Juni 2022) transportiert viele Anfragen und Antworten gleichzeitig über eine einzige Verbindung. Mit HTTP/1.1 öffnete ein Browser meist sechs Verbindungen je Host und stellte den Rest in eine Warteschlange. Deshalb haben Teams Dateien zusammengefügt, Bild-Sprites gezeichnet und Ressourcen auf mehrere Hostnamen verteilt.

Verbesserungen

Multiplexing erlaubt einer Seite, Dutzende Dateien anzufordern, ohne auf eine freie Verbindung zu warten.

HPACK komprimiert wiederkehrende Header, sodass Cookies und User-Agent nicht bei jeder Anfrage vollständig gesendet werden.

Der alte Baum der Stream-Prioritäten gilt als veraltet. RFC 9218 ersetzt ihn durch einen Priority-Header (Dringlichkeit von 0 bis 7 und ein Flag für inkrementelle Auslieferung).

RFC 9113 hält fest, dass das Head-of-Line-Blocking auf TCP-Ebene nicht behandelt wird. Ein verlorenes Paket hält weiterhin alle Streams der Verbindung auf.

HTTP/3 behält die Semantik und tauscht den Transport

HTTP/3 (RFC 9114, Juni 2022) behält das HTTP-Modell bei, läuft aber über QUIC statt über TCP. Ein verlorenes Paket hält nur noch den betroffenen Stream auf, während es bei HTTP/2 alle Übertragungen der Verbindung aufhält.

Verbesserungen

Die Header-Kompression wechselt von HPACK zu QPACK, das für Streams entworfen ist, die in beliebiger Reihenfolge eintreffen können.

Der Nutzen hängt vom Paketverlust ab. Wir haben ihn hier nicht gemessen und versprechen deshalb keinen Geschwindigkeitsgewinn.

Die Verbreitung ist real, aber schwer zu messen. Der Web Almanac 2024 zählte 7 % der Startseiten am Desktop und 9 % mobil, die in seinem Crawl über HTTP/3 geladen wurden. Sein Autor schätzt die tatsächliche Unterstützung eher auf 30 %.

Im selben Kapitel liefen 71 % der Desktop- und 70 % der mobilen Startseiten über HTTP/2. 85 % der Anfragen nutzten HTTP/2 oder HTTP/3.

Was keines der beiden Protokolle berührt

Beide Protokolle bewegen Bytes. Keines ändert, wie viele Bytes eine Datei hat, und keines analysiert Ihren Code.

Verbesserungen

Content-Encoding (gzip oder Brotli) funktioniert bei HTTP/1.1, HTTP/2 und HTTP/3 gleich.

Nach dem Entpacken hat der Browser den vollständigen Text des Skripts. Er muss alles analysieren und kompilieren, gleichgültig, über welches Protokoll es kam.

Server Push, gedacht zum Senden von Dateien vor der Anfrage, ist seit Chrome 106 standardmäßig abgeschaltet. Das Chrome-Team nennt schwache Ergebnisse (etwa 1,25 % der HTTP/2-Sites nutzten es) und empfiehlt 103 Early Hints.

103 Early Hints sendet nur Hinweise und überlässt dem Browser die Entscheidung. Der Web Almanac 2024 fand es auf 2,9 % der Desktop-Startseiten.

Was Minifizierung nach der Kompression noch spart

Wir haben den Minifizierungs-Benchmark von FastMinify (Ausgabe 2026-10) genutzt. Er misst nicht minifizierte Dateien öffentlicher Bibliotheken roh, mit gzip Stufe 9 und mit Brotli Qualität 11. Jede Zahl ist eine Summe über die Dateien einer Sprache. JavaScript läuft mit Terser 5.51.2 in den Standardeinstellungen, CSS mit CSSO und JSON mit JSON.stringify.

Verbesserungen

JavaScript, 10 Dateien: 5.637.983 Bytes roh und 1.142.675 mit gzip. Minifiziert 1.809.323 Bytes roh und 566.618 mit gzip, also 67,9 % und 50,4 % weniger.

Dasselbe JavaScript mit Brotli: 899.755 Bytes vorher und 484.012 nachher (46,2 % weniger).

CSS, 6 Dateien: 1.593.647 Bytes roh und 1.338.588 minifiziert (16,0 % weniger). Mit gzip 161.522 gegen 151.049 (6,5 % weniger). Mit Brotli 106.426 gegen 99.630 (6,4 % weniger).

JSON, 6 eingerückte Dateien: 14.199.411 Bytes roh und 7.747.070 minifiziert (45,4 % weniger). Der Gewinn beträgt 28,8 % mit gzip und 15,8 % mit Brotli.

Lesen Sie diese Zahlen als Obergrenze. Das Korpus ist nicht minifizierter Quelltext mit Kommentaren und Einrückung, und Ihre eigenen Dateien liegen darunter, wenn sie schon schlank sind.

644 Module oder eine Datei

Wir haben lodash-es 4.18.1 geladen, das 644 JavaScript-Module ausliefert. Jedes Modul haben wir mit esbuild minifiziert und mit gzip Stufe 9 und Brotli Qualität 11 komprimiert. Das ist ein Extremfall, denn kaum eine Seite lädt 644 Module, aber er zeigt den Mechanismus.

Verbesserungen

644 minifizierte Module wiegen 189.745 Bytes. Einzeln komprimiert ergeben sie 119.525 Bytes mit gzip und 99.805 mit Brotli.

Dieselben minifizierten Module in einer Datei komprimieren auf 50.361 Bytes mit gzip (58 % weniger) und 41.504 mit Brotli.

Von esbuild gebündelt, mit aufgelösten Imports und minifiziert, wiegt die Bibliothek 97.292 Bytes, mit gzip 35.489 und mit Brotli 31.205.

Das mittlere Modul hat minifiziert 157 Bytes und nach gzip 143 Bytes. Eine so kleine Datei enthält kaum Wiederholungen, und die Kompression findet fast nichts.

Diese Summen blenden die 644 Anfragen selbst aus und die Zeit, die der Browser braucht, um Imports Ebene für Ebene zu entdecken.

Kompilierzeit in V8

Wir haben fünf Bibliotheken mit V8 kompiliert (Node 26.4.0 auf einem Apple M4 Max), einmal wie ausgeliefert und einmal mit Terser minifiziert. Der Test nutzt new vm.Script mit einer Quelle, die sich bei jedem Durchlauf ändert, um den Kompilier-Cache zu umgehen. Jeder Wert ist der Median aus 30 Durchläufen, danach der Median aus fünf solchen Serien.

Verbesserungen

lodash: 533 KiB ausgeliefert und 70 KiB minifiziert. Kompilierzeit 1,9 ms gegen 1,2 ms.

moment.js: 179 KiB und 61 KiB. 1,1 ms gegen 0,8 ms.

jQuery 4.0.0: 250 KiB und 77 KiB. 1,3 ms gegen 1,2 ms.

d3: 573 KiB und 272 KiB. 5,7 ms gegen 4,9 ms.

react-dom, Entwicklungs-Build: 1.155 KiB und 378 KiB. 6,0 ms gegen 4,8 ms.

Das ist nur die Kompilierung auf oberster Ebene, auf einem schnellen Rechner. Smartphones sind langsamer, und wir haben keines getestet. Das V8-Team schrieb 2019, dass V8 auf den meisten Verbindungen schneller analysiert, als die Datei lädt. Die übertragene Größe bleibt also der größere Hebel.

Was Sie 2026 behalten und was Sie ablegen sollten

Weitermachen

Diese Schritte lohnen sich bei jedem Protokoll.

Minifizieren Sie JavaScript, CSS, HTML und JSON vor der Kompression, mit dem JavaScript-Minifier, dem CSS-Minifier, dem HTML-Minifier und dem JSON-Minifier.

Liefern Sie Brotli an Clients, die es akzeptieren, und gzip an alle anderen, wie im GZIP- und Brotli-Leitfaden beschrieben.

Bündeln Sie zu wenigen Dateien je Route und trennen Sie Fremdcode vom eigenen Code. Entfernen Sie Code, den niemand aufruft (siehe Tree Shaking und Minifizierung).

Setzen Sie einen Inhalts-Hash in jeden Dateinamen und cachen Sie mit langem max-age und der Direktive immutable.

Binden Sie das kritische CSS direkt in die Seite ein. Laden Sie den Rest ohne Blockade des Renderings, wie im Leitfaden zum kritischen CSS beschrieben.

Senden Sie 103 Early Hints oder einen Preload-Link für die wenigen Dateien, die das erste Rendering braucht.

HTTP/1.1-Gewohnheiten zum Ablegen

Jede davon war mit sechs Verbindungen je Host sinnvoll. Manche kosten Sie heute etwas.

Ressourcen auf mehrere Hostnamen verteilen (Domain-Sharding).

Sich auf Server Push verlassen.

Ein Sprite-Bild nur anlegen, um die Zahl der Anfragen zu senken. Anfragen sind heute günstig, und ein geändertes Icon macht das ganze Sprite-Bild ungültig.

Alle Skripte der Website in einer Datei zusammenfassen.

Dateien als Base64-Data-URI einbetten, um eine Anfrage zu sparen.

Prüfen, was Ihr Server wirklich sendet

Welches Protokoll die Seite geliefert hat

Zwei schnelle Prüfungen geben die Antwort, und eine dritte erklärt, warum ein erster Besuch oft h2 zeigt.

Öffnen Sie in den Chrome DevTools das Network-Panel, klicken Sie mit der rechten Maustaste auf die Spaltenköpfe und aktivieren Sie Protocol. Die Spalte zeigt je Anfrage http/1.1, h2 oder h3.

Fordern Sie mit curl die Header einer Datei an und lesen Sie die erste Zeile. HTTP/2 200 heißt, die Verbindung nutzte HTTP/2.

Ein Server kündigt HTTP/3 mit einem alt-svc-Header an. Der Browser versucht HTTP/3 dann bei einer späteren Verbindung, deshalb läuft die erste Anfrage eines Besuchs oft über h2.

Am 22. Oktober 2026 hat fastminify.com eine curl-Anfrage über HTTP/2 beantwortet und HTTP/3 im alt-svc-Header angekündigt. Unser curl unterstützt kein HTTP/3, wir konnten also nur die Ankündigung lesen.

Ob die Antwort komprimiert ist und wie

Die Kodierung hängt vom Header ab, den der Client sendet. Testen Sie deshalb mit dem Header eines Browsers.

Fordern Sie die Datei einmal je Kodierung an, die Sie interessiert, dann mit dem vollständigen Browser-Header, und lesen Sie jedes Mal content-encoding.

Ein Server kann gzip antworten, obwohl der Client gzip und br anbietet. Vergleichen Sie, was für br allein und für den vollständigen Header zurückkommt.

Prüfen Sie, ob vary: Accept-Encoding vorhanden ist, damit ein Cache keinen Brotli-Body an einen Client liefert, der ihn nicht lesen kann.

Vergleichen Sie die übertragenen Bytes mit der dekodierten Größe. Der Codeabschnitt weiter unten enthält die curl-Befehle.

Fünf Fehler, die den Umstieg auf HTTP/2 überleben

Minifizierung weglassen, weil das Protokoll modern ist

Der Umstieg auf HTTP/2 oder HTTP/3 ist kein Grund, lesbaren Code auszuliefern. Das Protokoll hat keinen Einfluss darauf, was in der Datei steht.

Den Minify-Schritt aus dem Build entfernen, nachdem das CDN auf HTTP/2 umgestellt hat.

Kommentare, Einrückung und lange Namen in Produktion senden, weil die Kompression sich darum kümmere.

Nur auf einer schnellen Büroverbindung testen, wo die überflüssigen Bytes unsichtbar bleiben.

Ohne Minifizierung verdoppelt sich die gzip-Größe unserer 10 JavaScript-Dateien von 566.618 auf 1.142.675 Bytes.

Behalten Sie den Minify-Schritt und messen Sie seine Wirkung nach der Kompression, nicht davor.

Hunderte Module in Produktion ausliefern

Native Module und HTTP/2 machen es möglich, Quelldateien unverändert auszuliefern. Das V8-Team empfiehlt für Produktion weiterhin Bundling. Nicht gebündelt liefern Sie nur kleine Anwendungen mit unter etwa 100 Modulen aus.

Einen nicht gebündelten Abhängigkeitsbaum in Produktion ausliefern.

Anfragen im Network-Panel zählen und alles für gut halten, weil sie gebündelt übertragen werden.

Vergessen, dass Imports Ebene für Ebene entdeckt werden und ein tiefer Baum deshalb Round-Trips hinzufügt.

In unserem lodash-es-Test ergab die Kompression Modul für Modul 119.525 Bytes, wo eine Datei 50.361 ergab.

Bündeln Sie nach Route oder Funktion zu einer Handvoll Dateien und ergänzen Sie einen modulepreload-Hinweis für die kritischen Chunks.

Die ganze Website in eine Datei bündeln

Der umgekehrte Exzess ist genauso verbreitet. Ein Bundle für alle Seiten bedeutet, dass jedes Deployment den ganzen Cache entwertet und jede Seite Code lädt, den sie nie ausführt.

Eine einzige main.js für alle Routen.

Kein Inhalts-Hash in den Dateinamen, also kein langes Caching.

Fremdcode mit eigenem Code vermischt, sodass eine Korrektur von einer Zeile ein Framework neu lädt.

Der Modul-Leitfaden von v8.dev merkt an, dass nicht gebündelte Dateien bei Folgebesuchen mit warmem Cache schneller laden können.

Trennen Sie Fremdcode vom eigenen Code, benennen Sie Dateien nach Inhalts-Hash und liefern Sie sie mit langem max-age und immutable aus.

HTTP/1.1-Behelfe beibehalten

Mehrere Gewohnheiten waren nur mit sechs Verbindungen je Host sinnvoll. Unser Base64-Leitfaden beschreibt den Größenaufschlag von Data-URIs.

Ressourcen auf die Hosts cdn1, cdn2 und cdn3 verteilen. Das gibt die einzelne Verbindung auf, auf der Multiplexing beruht, und fügt DNS- und Handshake-Aufwand hinzu.

Sich auf HTTP/2 Server Push verlassen, den Chrome seit Version 106 standardmäßig nicht mehr unterstützt.

Bilder als Base64-Data-URI einbetten, was sie um etwa 33 % vergrößert und getrenntes Caching von der Seite unmöglich macht.

Liefern Sie Ressourcen von einem Host. Nutzen Sie 103 Early Hints oder einen Preload-Link für kritische Dateien und behalten Sie Bilder als Dateien.

Von HTTP/3 erwarten, eine schwere Seite zu retten

HTTP/3 verbessert, wie sich eine Verbindung nach Paketverlust erholt. Es macht eine Seite nicht kleiner.

HTTP/3 im CDN aktivieren und die Performance-Arbeit auslassen.

Einen kürzeren Largest Contentful Paint erwarten, obwohl die Ursache ein 1-MB-Skript ist.

Nur prüfen, ob die Protokoll-Spalte h3 zeigt.

Sehen Sie HTTP/3 als kostenlose Verbesserung für unzuverlässige Netze und halten Sie Ihr Byte-Budget ein.

Vier Behauptungen über HTTP/2, HTTP/3 und Dateigröße

HTTP/2 macht Minifizierung überflüssig

Die Behauptung behandelt einen schnelleren Transport, als würde er die Nutzlast verkleinern.

Falsch. Bei unseren 10 JavaScript-Dateien hat die Minifizierung 50,4 % der gzip-Bytes und 46,2 % der Brotli-Bytes entfernt. HTTP/2 ändert keines dieser Bytes.

Gzip und Brotli erledigen schon die Arbeit der Minifizierung

Kompression und Minifizierung überschneiden sich, wirken aber auf Verschiedenes. Kompression entfernt Wiederholung. Minifizierung entfernt, was das Programm nie brauchte.

Bei CSS stimmt das teilweise, bei JavaScript nicht. Gzip allein verkleinert unser JavaScript auf 20 % der Größe, und die Minifizierung halbiert den Rest noch einmal. Bei CSS bringt der zweite Schritt 6,5 %.

Mit HTTP/2 sollte man nie bündeln

Multiplexing hat die Grenze für parallele Anfragen aufgehoben, nicht die anderen Kosten einer Datei.

Überwiegend falsch. Das V8-Team empfiehlt für Produktion weiterhin Bundling. Unser Test mit 644 Modulen zahlt 2,4-mal mehr gzip-Bytes als derselbe Code in einer Datei. Unter etwa 100 Modulen ist eine Auslieferung ohne Bundle vertretbar.

HTTP/3 macht eine langsame Seite schnell

HTTP/3 löst ein Netzwerkproblem, den Paketverlust auf einer gemeinsamen Verbindung.

Es ändert weder die Byte-Zahl noch die Kompilierzeit. Es hilft am meisten dort, wo Pakete verloren gehen. Messen Sie auf Ihren eigenen Seiten, bevor Sie einen Gewinn erwarten.

Mit FastMinify minifizieren und messen

Minifizieren und vergleichen

Der JavaScript-Minifier, der CSS-Minifier, der JSON-Minifier und der HTML-Minifier laufen in Ihrem Browser und zeigen die Originalgröße und die Ausgabegröße.

Datei einfügen oder ablegen

Fügen Sie den Quelltext in das Eingabefeld ein oder legen Sie eine Datei ab. Wählen Sie bei JavaScript die Komprimierungsstufe (konservativ, normal oder aggressiv).

Das Panel Komprimierung lesen

Das Panel zeigt Originalgröße, Ausgabegröße und den eingesparten Anteil in Prozent. Es sind unkomprimierte Größen. Vergleichen Sie sie mit den Rohwerten in diesem Artikel, nicht mit dem, was übertragen wird.

Die Console-Option prüfen

Der JavaScript-Minifier entfernt standardmäßig console-Aufrufe und debugger-Anweisungen (Optionen „Konsole entfernen“ und „Debugger entfernen“). Schalten Sie beides ab, wenn Ihr Code darauf angewiesen ist.

Mehrere Dateien vor dem Minifizieren zusammenfügen

Die Seiten der Minifier für JavaScript, CSS, HTML, XML, SVG und SQL haben eine Schaltfläche „Concat-Dateien“. Sie fügt die gewählten Dateien zusammen und minifiziert das Ergebnis.

Concat-Dateien öffnen

Wählen Sie auf der Minifier-Seite „Concat-Dateien“ und fügen Sie Ihre Dateien hinzu. Ziehen Sie sie in die Reihenfolge, in der sie laufen müssen.

Zusammenfügen und minifizieren

Starten Sie „Verketten und minimieren“. Bei JavaScript verbindet das Werkzeug die Dateien mit einem Semikolon in einer eigenen Zeile, damit eine Datei die nächste nicht verschluckt. Danach minifiziert es das Ganze. Imports löst es nicht auf. Für einen echten Abhängigkeitsgraphen nutzen Sie Ihren Bundler (siehe Online-Minifier und Build-Tools).

Die Messungen mit eigenen Dateien nachvollziehen

Protokoll und Kodierung mit curl prüfen

curl -I sendet eine HEAD-Anfrage, und einige Server antworten darauf anders als auf ein GET. Ersetzen Sie die URL durch eine Ihrer Dateien.

Einfaches Beispiel

# Die erste Zeile zeigt HTTP/2 oder HTTP/3
curl -sI https://example.com/app.js | head -n 1

# Ist HTTP/3 angekündigt? Suchen Sie einen alt-svc-Header
curl -sI https://example.com/app.js | grep -i alt-svc

# Vom Server gewählte Kodierung: br allein, dann der Browser-Header
curl -sI -H 'Accept-Encoding: br' https://example.com/app.js | grep -i content-encoding
curl -sI -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/app.js | grep -i content-encoding

# Übertragene Bytes, dann dekodierte Bytes
curl -s -H 'Accept-Encoding: gzip' -o /dev/null -w '%{size_download}\n' https://example.com/app.js
curl -s --compressed https://example.com/app.js | wc -c

Rohe, gzip- und Brotli-Größe mit Node messen

Speichern Sie das Skript als size.mjs. Es nutzt gzip Stufe 9 und Brotli Qualität 11, die Einstellungen des Benchmarks.

Einfaches Beispiel

import { readFileSync } from 'node:fs'
import { gzipSync, brotliCompressSync, constants } from 'node:zlib'

const file = process.argv[2]
const buf = readFileSync(file)
const gzip = gzipSync(buf, { level: 9 }).length
const brotli = brotliCompressSync(buf, {
  params: {
    [constants.BROTLI_PARAM_QUALITY]: 11,
    [constants.BROTLI_PARAM_SIZE_HINT]: buf.length,
  },
}).length

console.log(`${file}: raw ${buf.length}, gzip ${gzip}, brotli ${brotli}`)

Verwendung

node size.mjs dist/app.js
node size.mjs dist/app.min.js

Viele Dateien mit einer Datei vergleichen

Das misst nur die Kompression. ES-Module auf diese Weise zusammenzufügen ergibt kein lauffähiges Skript. Nutzen Sie es auf einem Ordner, um die Kosten winziger Dateien zu sehen.

Einfaches Beispiel

import { readdirSync, readFileSync } from 'node:fs'
import { join } from 'node:path'
import { gzipSync } from 'node:zlib'

const dir = process.argv[2]
const files = readdirSync(dir)
  .filter((name) => name.endsWith('.js'))
  .map((name) => readFileSync(join(dir, name)))

const oneByOne = files.reduce((sum, buf) => sum + gzipSync(buf, { level: 9 }).length, 0)
const asOneFile = gzipSync(Buffer.concat(files), { level: 9 }).length

console.log(files.length, 'files', { oneByOne, asOneFile })

Kompilierzeit in V8 messen

Das Skript kompiliert ein klassisches Skript, ohne es auszuführen. new Script akzeptiert keine ES-Module mit import oder export.

Einfaches Beispiel

import { readFileSync } from 'node:fs'
import { Script } from 'node:vm'

const source = readFileSync(process.argv[2], 'utf8')
const times = []

for (let i = 0; i < 33; i++) {
  // ein eindeutiger Kommentar am Ende umgeht den Kompilier-Cache
  const start = performance.now()
  new Script(`${source}\n//run${i}`)
  times.push(performance.now() - start)
}

times.splice(0, 3)
times.sort((a, b) => a - b)
console.log(`median ${times[Math.floor(times.length / 2)].toFixed(2)} ms`)

Weiter minifizieren und die HTTP/1.1-Gewohnheiten ablegen

HTTP/2 und HTTP/3 haben kleine Anfragen günstig gemacht. Große Dateien haben sie nicht klein gemacht. Minifizierung halbiert die komprimierte Größe von nicht minifiziertem JavaScript noch immer, spart bei CSS einige Prozent und verringert den Aufwand beim Kompilieren. Wertlos geworden ist das HTTP/1.1-Werkzeug aus vervielfachten Hostnamen, Push und riesigen Bundles. Minifizieren Sie, komprimieren Sie mit Brotli, bündeln Sie mit Maß und beurteilen Sie das Ergebnis nach den Bytes, die übertragen werden.

Minifizieren Sie Ihre Dateien im Browser

JavaScript-Minifier CSS-Minifier JSON-Minifier HTML-Minifier

Minifizieren Sie JavaScript, CSS, HTML und JSON weiterhin vor der Kompression.

Liefern Sie Brotli mit gzip als Rückfall aus und testen Sie, was Ihr Server für den Browser-Header wählt.

Bündeln Sie zu einer Handvoll gecachter Dateien je Route, weder zu einer Datei noch zu Hunderten.

Legen Sie Domain-Sharding und Server Push ab und nutzen Sie 103 Early Hints oder Preload für kritische Dateien.

Lesen Sie Gewinne nach der Kompression und auf der Leitung, und testen Sie auf einem langsamen Smartphone, bevor Sie einen Geschwindigkeitsgewinn melden.

Teilen Sie diesen Artikel

Teilen Sie diesen Artikel:

HTTP/2 hat den Weg der Dateien geändert, nicht ihre Größe

Was die Protokolle geändert haben und was nicht

Verbesserungen

Verbesserungen

Verbesserungen

Verbesserungen

Verbesserungen

Verbesserungen

Was Sie 2026 behalten und was Sie ablegen sollten

Prüfen, was Ihr Server wirklich sendet

Fünf Fehler, die den Umstieg auf HTTP/2 überleben

Vier Behauptungen über HTTP/2, HTTP/3 und Dateigröße

Mit FastMinify minifizieren und messen

Datei einfügen oder ablegen

Das Panel Komprimierung lesen

Die Console-Option prüfen

Concat-Dateien öffnen

Zusammenfügen und minifizieren

Die Messungen mit eigenen Dateien nachvollziehen

Einfaches Beispiel

Einfaches Beispiel

Verwendung

Einfaches Beispiel

Einfaches Beispiel

Weiter minifizieren und die HTTP/1.1-Gewohnheiten ablegen

Verwandte Artikel