Jit-Browser Teil der Jit-4-Plattform EN-CA |
Jit-Browser-Logo

Jede Website - jederzeit - aus jeder Sprache IN DEINE.

Ein Browser in deinem Browser der das gesamte Web in deiner Sprache lesbar macht

Jeder Browser hat ein Zeichen. Das ist unseres. Ein Browser in einem Browser.

Das Rad trägt jeden Wagen, während es in das neue Web migriert.
Die Speichen sind die Web2-Griffe, die das Web am Laufen halten.
Die Achse ist das, was die Speichen mit dem Wagen verbindet.
Jit-Browser ist die neue Achse, die deinen Wagen stark hält,
niemals zurückgelassen, während der digitale Oregon- und Santa Fe-Pfad weiterzieht.

Ein Browser in deinem Browser - immer ein Weg nach vorne, in jeder Sprache.
Der "Gewinn" ist der Weg, den du siehst, wenn du niemals aufgibst".

Web 4 als Browser-Subsystem, nicht nur als Skript

Hier beschreiben wir, was passiert, wenn unser patentiertes, anhängiges Code neben dem iChrome-Browser-Layout-Engine, seiner JavaScript-Engine und dem Netzwerk-Stack läuft, anstatt als "noch ein Skript" auf der Seite zu leben. innerhalb unseres Servers - oder deines Servers - oder im Browser des Clients.

β Große headless Erfassung heute. Schnelle headless Erfassung morgen. Blitzschnelle Browser-Schicht, wenn sie in Browser wie Chrome oder HarmonyOS integriert ist.

Was Jit-Browser in einfacher Sprache macht

Jit-Browser ist eine headless Browser-Pipeline, die
aktiviert wird, wenn eine Seite von irgendeiner Website angefordert wird / bevor sie geliefert wird unter Verwendung unserer proprietären Entscheidungsregeln.

  • Startet eine echte Chrome-Engine in einem Container
  • Lädt diese GENAU Seite genau so, wie es ein Benutzer tun würde (HTML, CSS, JS, Schriftarten, Bilder)
  • Injiziert unseren patentierten JS-Code von api.jit-tr.com
  • Führt unseren JS-Code an Ort und Stelle aus (zum Beispiel um ES-419 und Ai/AEO)
  • Erfasst das endgültig modifizierte DOM als statisches HTML-Snapshot
  • Lieferte dieses statische HTML-Snapshot

Auf unserer Seite - oder auf deiner - oder in einem Browser.

Es ist dieselbe Architektur, die Jit-TR auf echten Seiten verwendet, aber headless ausgeführt, mit Zeitprotokollen, die genau zeigen, wo die Zeit hingeht.

Eine Erfassung, Schritt für Schritt

1. Container + Chrome Starte Docker, starte headless Chrome, verbinde Puppeteer.
Typische Kosten: etwa 8–15 Sekunden bei einem Kaltstart.
2. Seitenladung Lade HTML, CSS, JS-Bündel, Schriftarten und Bilder für die Zielseite.
Typische Kosten: etwa 8–15 Sekunden für schwere Seiten.
3. Jit API-Start Injiziere den Jit API-Code, wähle Sprache (zum Beispiel ES-419) und initialisiere.
Typische Kosten für volle/erste Integration: etwa 1–3 Sekunden. Typische Kosten für weniger als 10 Bearbeitungen: etwa 0,01 Sekunden.
4. Flow / Klick-Helfer Optional: akzeptiere ein Cookie-Banner, klicke auf “mehr laden” oder scrolle, um Inhalte anzuzeigen.
Die Kosten hängen vom Fluss ab, oft etwa 0,01 Sekunden.
5. Screenshot und HTML-Dump Optional einen Screenshot der gesamten Seite machen und das übersetzte HTML auf die Festplatte schreiben.
Typischerweise etwa 0,01 Sekunden pro Stück.
6. Sicherheitswartezeiten Kurze feste Wartezeiten, um sicherzustellen, dass alle asynchronen Übersetzungen und DOM-Updates abgeschlossen sind.
Insgesamt typischerweise etwa 0,1 Sekunden.

Insgesamt dauert eine kalte Erfassung einer großen Website etwa 5–15 Sekunden. Der Großteil davon sind die Kosten für den Start einer neuen Browser-Engine in einem Container.

Das wird verringert, wenn Docker, headless Chrome und Puppeteer als Daemon aktiv bleiben.

Das VERSCHWINDET, wenn die Jit-API in einem Browser eingebettet ist!

Kalt vs warm vs native Browser-Schicht

Die gleiche Pipeline sieht sehr unterschiedlich aus, je nachdem, wo sie läuft:

Kalte headless Ausführung (heute)

  • Docker für jede Erfassung starten
  • Chrome headless für jede Erfassung starten
  • Alle Assets jedes Mal neu laden
  • Jit-TR injizieren und übersetzen

Typisch: 25–35 Sekunden für eine HarmonyOS-Erfassung.

Warmer „Schlafmodus“-Container

  • Einen langlebigen Container wiederverwenden
  • Eine einzelne Chrome-Instanz wiederverwenden
  • Zwischengespeicherte CSS, JS, Schriftarten und Bilder wiederverwenden
  • Nur das übersetzte HTML ändern

Typisch: 8–12 Sekunden einmal warm für dieselbe Seite.

Native Browser-Subsystem

  • Kein Docker überhaupt
  • Kein separater Chrome-Prozess
  • Den integrierten Cache des Browsers wiederverwenden
  • Jit-TR läuft innerhalb der Engine als mehrsprachige Schicht

Inkrementelle Überkopfkosten: Millisekunden, nicht Sekunden.

Jit-Browser ist eine realistische Demo, wie sich eine integrierte mehrsprachige Schicht verhalten würde, wenn Browser ihr einen Platz neben Layout, JS und dem Netzwerk-Stack geben würden.

Beispiel-Zeitverlauf von einer echten Erfassung

So sieht ein echter headless Zeitverlauf aus, wenn HarmonyOS in ES-419 erfasst wird:

[URL] Seiten-URL für die Erfassung: https://www.AnyWebsite/
[SNIPPET-URL] https://dev.api.jit-tr.com/?jittr=ES-419
[CSP] Bypassing page CSP for this capture session

[TIME] t0 start : +     0 ms
[TIME] t1 launch : +  6200 ms   (Δ launch =   6200)
[TIME] t2 goto   : + 17200 ms   (Δ page load = 11000)
[TIME] t3 inject : + 19250 ms   (Δ Jit-TR boot = 2050)
[TIME] t4 flow   : + 19260 ms   (Δ flow = 10)
[TIME] t5 shot   : + 20500 ms   (Δ shot = 1240)
[TIME] t6 html   : + 21550 ms   (Δ html = 1050)
[TIME] t7 done   : + 23550 ms   (Δ final wait = 2000)

[PAGE] log [Jit-TR] Language chosen → ES-419
[PAGE] log calling:https://dev.api.jit-tr.com/files/translateDocument.php
[PAGE] log calling setFlags
[PAGE] log calling setStore
[HTML] Writing to output/ES-419/index.php
        

Der Verlauf macht den Punkt sehr klar: Der langsame Teil ist nicht die Übersetzung, sondern der kalte Start eines vollständigen Browser-Stacks in einem Container. Bewege dieselbe Logik in die Browser-Engine, und die meisten dieser Kosten verschwinden.

Detaillierte Analyse

Wie „Warm Mode“ Jit-Browser schnell macht

Die heutige Demo lädt jede Seite auf die harte Tour:

  • Docker starten
  • Chrome headless starten
  • Die Seite frisch laden
  • Jit-TR injizieren
  • Übersetzen und erfassen
  • Alles wieder herunterfahren

Das ist das Äquivalent dazu, einen Laptop herunterzufahren, ihn wieder einzuschalten, den Browser zu öffnen und eine Website für jede einzelne Seite zu besuchen. Kalte Erfassungen dauern typischerweise etwa 25–35 Sekunden auf typischer Hardware.

Warmer Modus („Schlafmodus“)

Anstatt alles neu zu starten, kann Jit-Browser einen warmen headless Chrome im Hintergrund laufen lassen:

  • Docker-Container bleibt aktiv
  • Puppeteer und Chrome bleiben geladen
  • Tabs bleiben offen oder wiederverwendbar
  • Der Browser-Cache bleibt warm (Schriften, CSS, JS, Bilder)

Jede neue Anfrage wird im Vergleich zu einem kalten Boot nahezu sofort:

  • Kein Docker-Start
  • Kein Chrome-Start
  • Zwischengespeicherte HarmonyOS- oder Huawei-Ressourcen werden von der Festplatte geladen
  • Nur das übersetzte HTML ändert sich

Die Warm-Mode-Erfassungen sinken typischerweise von etwa 30 Sekunden auf etwa 8–12 Sekunden.

Warum das wichtig ist

Browser haben bereits native Schichten für:

  • JavaScript-Ausführung
  • HTML-Layout
  • Netzwerk-Stack
  • Zugänglichkeitsbaum
  • GPU-Rendering

Jit-TR verhält sich wie eine fehlende native Schicht: eine mehrsprachige Schicht. Der Warm Mode zeigt, wie schnell es sein könnte, wenn die Übersetzung direkt im Browser-Engine anstelle als externes Skript ausgeführt wird.