Gwtar: Statisches und effizientes Single-File-HTML-Format

 (gwern.net)
1 Punkte von GN⁺ 2026-02-17 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Single-HTML-Archivdateiformat, das von Webbrowsern effizient per Lazy Loading geladen werden kann und trotz Einbettung aller Assets gleichzeitig statisch, einzeln und effizient ist
  • Verbindet hinter einem HTML- und JavaScript-Header das ursprüngliche HTML und die Assets in Tarball-Form, wobei JS über HTTP-Range-Requests nur die benötigten Teile lädt
  • Bestehende Formate wie SingleFile oder MHTML sind zwar statisch und bestehen aus einer einzelnen Datei, aber ineffizient; Gwtar löst dieses Problem
  • Funktioniert nur mit Standard-Browserfunktionen ohne zusätzliche serverseitige Konfiguration; in einigen Umgebungen wie Cloudflare wird dafür der MIME-Typ x-gwtar verwendet
  • Sichert bei großen HTML-Seiten gleichzeitig Langzeitarchivierbarkeit und Zugänglichkeit und eignet sich damit für langfristiges Web-Archiving und die Aufbewahrung reproduzierbarer Forschungsmaterialien

Überblick über Gwtar

  • Gwtar ist ein neues Polyglot-Archivformat, das aus einer einzigen HTML-Datei besteht und bei dem der Browser per HTTP-Range-Request nur die benötigten Teile lädt
    • Wird auf Gwern.net zur Bereitstellung großer HTML-Archive verwendet
  • Das JS im HTML-Header bricht den Download der gesamten Datei ab und lädt nur die benötigten Assets per Teilanforderung (Range Request) nach
  • Dadurch liefert der Server nur eine einzige HTML-Datei aus, während der Nutzer nur die tatsächlich benötigten Assets herunterlädt
  • Sämtliche Funktionen sind mit Standard-Browserfunktionen umgesetzt und sichern so zukünftige Kompatibilität

Das dreifache Dilemma von HTML-Archiven

  • HTML-Archive hatten bisher die Einschränkung, dass sie nur zwei von drei Eigenschaften zugleich erfüllen konnten: Statisches Verhalten, eine einzelne Datei und Effizienz
    • Beispiel: SingleFile ist statisch und einzeln, aber ineffizient; WARC ist statisch und effizient, aber keine einzelne Datei
    Anzeige
  • Mit SingleFile erzeugte Snapshots liefern vollständige statische Seiten, binden aber alle Assets per Base64 inline ein, wodurch die Dateigröße auf mehrere hundert MB anwachsen kann
  • Selbst wenn Nutzer nur einen Teil der Seite ansehen, müssen sie die gesamte Datei herunterladen, was ineffizient ist
  • Gwern.net trennte zur Lösung dieses Problems die Assets mit deconstruct_singlefile.php, verlor damit jedoch die Eigenschaft der Einzeldatei

Technischer Ansatz von Gwtar

  • Mithilfe von HTTP-Range-Requests können selektiv nur Teile einer Datei heruntergeladen werden
  • Verwendet eine verkettete Archivstruktur, bei der hinter HTML + JS-Header ein Tarball angehängt wird
  • Mit dem JS-Befehl window.stop() wird der Download nach dem Header abgebrochen, und nur die benötigten Assets werden angefordert
  • Der Browser rendert die Datei wie normales HTML, während das JS Asset-Anfragen abfängt und in Range-Requests umwandelt

Erstellung und Implementierung

  • Mit dem PHP-Skript deconstruct_singlefile.php lässt sich SingleFile-HTML in Gwtar umwandeln
    • Unterstützt Re-Kompression von JPG/PNG/GIF sowie das Hinzufügen von PAR2-FEC-Daten (Forward Error Correction)
  • Der Browser lädt nach Ausführung des JS nur die benötigten Assets per Range-Request; ist JS deaktiviert, wird stattdessen die gesamte Datei heruntergeladen
  • Standardbasiert, daher keine Serverkonfiguration oder zusätzliche Software erforderlich; außerdem lässt sich die einzelne Datei wieder in Multi-File-HTML zurückverwandeln

Leistung und Kompatibilität

  • Wenn Range-Requests nicht unterstützt werden, wird die gesamte Datei heruntergeladen; gzip/Brotli-Kompression kann die Geschwindigkeit dann verbessern
  • Cloudflare entfernt den Range-Header bei text/html-Antworten, daher setzt Gwern.net den MIME-Typ auf x-gwtar, um dies zu umgehen
  • Lokale Dateiansicht ist nicht möglich :
    • Das gilt ebenso für SingleFileZ, da Browser-Sicherheitsrichtlinien (CORS usw.) JS-Anfragen blockieren
    • Das wird zwar bedauert, aber als akzeptabler Trade-off betrachtet; lokales Browsing lässt sich durch Umwandlung in Dateien ohne JS-Abhängigkeit lösen
    Anzeige

Erweiterte Funktionen

  • Am Ende einer Gwtar-Datei können zusätzliche Binärdaten angehängt werden, z. B. FEC, Signaturen oder Metadaten
  • Mit PAR2 ist eine Wiederherstellung bei teilweiser Dateibeschädigung möglich
  • Durch Einfügen einer GPG-Signatur in Form eines HTML-Kommentars ist Integritätsprüfung möglich
  • Für künftige Versionen sind Asset-Hash-Prüfung, automatisches Prefetching, eingebaute Kompression und Unterstützung mehrerer Seiten geplant

Einsatzmöglichkeiten

  • Geeignet für große HTML-Seiten oder reproduzierbare wissenschaftliche Forschung mit Forschungsdatensätzen (z. B. SQLite3)
  • Datenbanken können direkt im Browser per Range-Request geladen und analysiert werden
  • Wird als Web-Archivierungsformat vorgeschlagen, das Langzeitarchivierbarkeit und Zugänglichkeit zugleich sichert

Lizenz und weitere Entwicklung

  • Dokumentation und Code von Gwtar sind als CC-0 Public Domain veröffentlicht
  • Für künftige Versionen (v2) werden verpflichtendes FEC, eingebaute Kompression, Unterstützung mehrerer Dokumente und verbesserte Deduplizierung geprüft

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-17
Hacker-News-Kommentare

  • Heute habe ich zum ersten Mal von window.stop() erfahren
    Diese Funktion stoppt, dass der Browser weitere Ressourcen lädt
    Die wichtigsten Browser unterstützen das schon seit über 10 Jahren (MDN-Dokumentation, Can I Use)
    Ein Anwendungsbeispiel ist in diesem Screenshot zu sehen
    Ausführlicher habe ich das in meinem Blogbeitrag beschrieben

    • Als SPA-Entwickler würde ich nicht sagen, dass das besser ist als APIs wie document.write oder window.open
      Wenn man aber in serverzentrierter Logik Downloads oder lazy-loading selbst implementieren will, könnte das ein interessanter Ansatz sein
      Abgesehen von Spezialfällen wie Initialisierungs- oder Redirect-Skripten ist es schwer, das zu empfehlen
    • Ich frage mich, ob das mit Claude Artifacts kompatibel wäre
      Ich veröffentliche Dateien über einen selbst gebauten Bundler, der sie als komprimierte Base64-Chunks bereitstellt, und das wirkt ähnlich
      Wenn das in solchen Single-File-Sharing-Umgebungen funktionieren würde, könnte die Plattform es vielleicht blockieren
    • Auch ich habe zum ersten Mal von dieser Funktion gehört
      In PHP gibt es eine ähnliche Funktion, __halt_compiler(); ich habe sie benutzt, um am Dateiende ohne Kommentare Dokumentation oder Daten einzufügen

  • Erst fand ich es interessant, dann zögerte ich, als ich sah, dass sich dieses Format nicht direkt als lokale Datei öffnen lässt
    Für ein Archivformat wäre lokaler Zugriff doch einer der zentralen Anwendungsfälle

    • Sehe ich genauso. Ich hatte gehofft, dass es wie asm.js neue Möglichkeiten eröffnet, indem es bereits im Browser vorhandene Funktionen nutzt
      Aber wenn es sich nicht direkt lokal öffnen lässt, geht viel von diesem Vorteil verloren (siehe das Konzept des backdoor pilot)
    • Vielleicht ließe sich das mit einem Viewer-Programm oder einem einfachen statischen HTML-Server lösen
    • Eigentlich ist HTML selbst schon ein hervorragendes Single-File-Format
      Bilder, CSS und JS lassen sich alle per data-uri inline einbetten, bei Fonts ist es genauso
      Es wäre vielleicht flexibler gewesen, wenn Textverarbeitungsformate HTML verwendet hätten
    • Mit einem Befehl wie python -m http.server lässt sich das lokal einfach lösen
      Das geht auch mit einem Claude-Befehl

  • Falls der Autor das liest: Ich hätte gern, dass das Archivformat ein BASE64-Screenshot-Feld, ein Beschreibungsfeld und einen ISO-Zeitstempel bekommt
    Ideal wäre außerdem, mehrere Versionen derselben URL speichern zu können und Deduplizierung von Assets zu haben

  • Ich verstehe nicht, warum der Autor WARC so negativ sieht
    Im Vergleich wirkt Gwtar eher komplexer und weniger flexibel

    • Allerdings kann WARC keine URL bereitstellen, die man im Browser einfach anklicken und direkt ansehen kann
    • Ein weiterer in den Kommentaren genannter Grund ist, dass WARC/WACZ zwar statisch und effizient sind, sich aber nicht direkt als einzelne Datei anzeigen lassen und eine separate, eher komplexe Installation wie WebRecorder benötigen

  • Mich würde interessieren, warum SingleFiles ZIP/HTML-Polyglot-Format als „statisch und einzeln, aber ineffizient“ bezeichnet wurde
    Ich würde gern wissen, worin die Ineffizienz im Vergleich zu Gwtar besteht

    • Mit Effizienz ist hier die Fähigkeit gemeint, nur die jeweils benötigten Assets teilweise herunterzuladen
      Entscheidend ist, ob der Browser statt der gesamten Datei per range request nur die benötigten Teile holen kann

  • Wirklich eine großartige Idee
    Ich denke, dass Single-File-HTML-Web-Apps die langlebigste Form von Software sind
    Beispiele, die ich gebaut habe, sind FuzzyGraph und HyperVault

  • Ich hatte auch schon überlegt, so etwas auf Service-Worker-Ebene umzusetzen
    Dabei würde die Seite unverändert bleiben und alle HTTP-Anfragen würden abgefangen
    Ähnlich wie bei window.stop() würde nur ein Teil des HTML geladen und der Rest als Asset-Blobs verarbeitet
    Wenn man den Service Worker selbst als dataURI einbettet, hätte man eine vollständige Single-File-Lösung

  • Interessant, aber ich verstehe nicht ganz, warum man bei einer lokalen Datei lazy load braucht
    Soll die Datei so groß werden? Oder will man einfach bereits vorhandene Implementierungen beibehalten?

    • In der Praxis geht es nicht um lokale Dateien, sondern um große Dateien auf einem HTTP-Server
      Um nicht alles über das Netzwerk laden zu müssen, braucht man range request, damit nur die benötigten Teile angefordert werden
      Natürlich ist es üblicher, das auf mehrere Dateien aufzuteilen, aber manchmal ist die Verwaltung einer einzelnen Datei praktischer
      Möglicherweise hängt das auch mit der Struktur von Gwerns MediaWiki-basierter Website zusammen

  • Früher habe ich auch einmal etwas Ähnliches gebaut — ein Projekt namens Zundler, das ein ziemlich hackiger Ansatz war
    Es funktioniert auch lokal, aber anfangs muss das gesamte Archiv entpackt werden

    • Das sieht nach einem statischen Single-HTML-Archiv wie SingleFileZ aus, das sich aber auch lokal leicht ansehen lässt
      Ich frage mich allerdings, wie dort die Sicherheitsbeschränkungen umgangen wurden
      In der Beschreibung wird nur Single-Origin erwähnt, daher ist es schwer, das ganz zu verstehen