HeadlessChrome101 : Comment Jit-Browser transforme Chrome en un navigateur multi-fonction complet – Couche navigateur-serveur
Ceci est un guide en langage simple sur ce que fait Jit-Browser avec Chrome sans tête, comment il utilise le runtime propriétaire Jit-TR, et ce qui est encore nécessaire pour faire de cela une fonctionnalité de navigateur de première classe au lieu d'un simple script.
D'un simple outil de capture d'écran à Jit-Browser
Nous avons commencé avec un petit outil en ligne de commande : getpage https://example.com page.png. Il a lancé Chrome dans un conteneur Docker, a pris une capture d'écran de example.com rendu à partir de la page, et a quitté.
Preuve de concept utile. Chaque appel était un démarrage à froid. Il ne savait rien sur la traduction, les sessions ou l'état. C'était juste une caméra sans tête.
Jit-Browser est la prochaine étape. Il utilise toujours Chrome réel, mais maintenant :
- Il enregistre ce qui se passe à l'intérieur de la page.
- Il injecte le script Jit-TR comme couche de traduction.
- Il peut suivre des flux simples comme les bannières de cookies ou les menus déroulants.
- Il capture le HTML entièrement traduit, pas seulement une capture d'écran.
Cette page explique ce pipeline afin que vous puissiez voir que nous ne faisons pas de gestes. Nous montrons comment une couche multilingue au niveau du navigateur peut réellement fonctionner.
Le pipeline Jit-Browser en 6 étapes
À un niveau élevé, chaque capture suit la même séquence.
-
Lancez Chrome réel (sans tête) à l'intérieur de Docker.
Nous utilisons Puppeteer (pptr.dev) pour démarrer le même moteur qui alimente les navigateurs normaux, mais sans fenêtre visible. Pas de parseur personnalisé, pas de rendu faux. -
Appliquez des cookies ou un état de connexion (si configuré).
Pour les démos qui nécessitent une session connectée, nous rejouons vos cookies. Pas de force brute, pas de devinette de mot de passe, pas de scraping de comptes que nous ne contrôlons pas. -
Chargez la page cible exactement comme un utilisateur.
HTML, CSS, JavaScript, polices, images. Nous attendons quenetworkidle2(https://pptr.dev/api/puppeteer.page.waitfornetworkidle) afin que les bundles lents et les polices puissent finir de se charger. -
Injectez le snippet Jit-TR comme une couche.
Nous ajoutons une balise script pointant vers notre code de runtime en attente de brevet – par exemple :. Le module de runtime Jit-TR parcourt le DOM exposé (document.head et document.body), envoie la charge utile extraite à notre (ou n'importe quel) serveur pour être traitée, reçoit les résultats (traduction, amélioration ou nouvelle information), réécrit le texte visible, et ajoute de nouvelles couches de signification par-dessus l'original. Les seules restrictions qui existent sont simples : les scripts peuvent être augmentés, mais de nouvelles instructions ne peuvent jamais interférer avec les propres scripts du site. Cela est généralement mis en œuvre en utilisant des instances deMutationObserverpour surveiller les changements pertinents dans le DOM, appliquer des mises à jour en petits patches ciblés, et éviter de toucher à toute logique d'application existante ou à des gestionnaires d'événements. -
Exécutez des flux optionnels : cookies, clics et défilement.
Les pages réelles ont souvent besoin d'une ou deux actions : fermer une bannière de cookies, ouvrir un menu, faire défiler pour charger plus d'offres. Jit-Browser peut exécuter un script de flux simple afin que ces éléments soient visibles avant la capture. -
Capturez la sortie augmentée.
Nous sauvegardons :- Le HTML entièrement modifié pour l'hébergement ou l'audit.
- Une trace de timing pour identifier les goulets d'étranglement potentiels.
C'est le cœur de notre HeadlessChrome101. C'est le modèle mental de la façon dont un navigateur pourrait traiter de nouvelles ou existantes données comme une couche intégrée à l'intérieur de n'importe quel navigateur.
Pourquoi cela n'est pas juste un script jouet
Jit-Browser est important car il prouve qu'une couche au niveau du navigateur peut être construite avec les mêmes éléments que les fournisseurs de navigateurs utilisent déjà chaque jour, et que cette couche peut héberger en toute sécurité une interaction client-serveur complète avec n'importe quel service externe, y compris notre propre runtime Jit-TR. C'est aussi le point où nous ajoutons des améliorations conscientes du SEO telles que rel="alternate" hreflang="..." liens et enrichis sitemap.xml entrées. En pratique, cela signifie que nous pouvons exposer des informations augmentées à l'intérieur de régions HTML non perturbatrices comme éléments à gauche ou à droite de la page existante, ou en utilisant des modales JavaScript qui ajoutent des choix de langue et SmartSearch sans interférer avec la mise en page ou les scripts originaux.
-
Moteur Chrome réel.
Tout fonctionne sur Chrome lui-même - juste sans la fenêtre visible. Si cela fonctionne dans Chrome pour vos visiteurs, cela fonctionne dans Jit-Browser. -
Conscient de la politique de sécurité du contenu.
La plupart des sites verrouillent les scripts avec CSP. En mode sans tête, nous pouvons utiliser lesetBypassCSP(true)(https://pptr.dev/api/puppeteer.page.setbypasscsp) pour injecter Jit-TR dans l'environnement de capture. Nous ne demandons à aucun site de production d'affaiblir ses politiques de sécurité. -
Chronométrage et journalisation complets.
Nous enregistrons les temps de lancement, les temps de chargement des pages, le démarrage de Jit-TR, les étapes du flux et la capture. Vous pouvez voir où vont les millisecondes et ce que Jit-TR fait réellement sur la page. -
Séparation du script et de la couche.
Aujourd'hui, Jit-TR peut être "juste un script" que vous ajoutez à un site. Dans Jit-Browser, nous le traitons comme une couche stable qui fonctionne toujours. C'est très proche de la façon dont un fournisseur de navigateur pourrait l'intégrer nativement.
Ce que l'API Jit-TR résout déjà
La partie difficile n'est pas Chrome sans tête. La partie difficile est de transformer de manière fiable des pages web en direct et désordonnées en versions multilingues sûres. Notre runtime propriétaire à api.jit-tr.com fait déjà ce travail.
Aujourd'hui, le runtime API gère :
-
Sélection de la langue.
Il lit des paramètres commejittr=ES-419, normalise les cas particuliers et enregistre la langue choisie, par exemple :[Jit-TR] Langue choisie → ES-419. -
Extraction du DOM, traduction et réécritures sémantiques.
Le runtime parcourt le DOM réel de Chrome, extrait uniquement le texte visible, construit une charge utile de traduction structurée et écrit les résultats dans la page. Tous les cas particuliers difficiles sont automatiques : séquences d'emoji, entités HTML, règles de ponctuation et d'espacement, chaînes de langues mélangées, et commutation de gauche à droite / droite à gauche. Il réécrit également les blocs de script spécifiques à la langue — y compriset d'autres balises de données structurées — garantissant que chaque langue dispose de métadonnées correctes, indépendantes et mises en cache pour les moteurs de recherche et les systèmes d'IA. -
Comportement du client.
Il rend des drapeaux de langue, respecte les racines non sécurisées et fonctionne aussi prudemment que possible avec des applications à page unique et des frameworks.
Tout cela fonctionne déjà sur les sites Jit-TR aujourd'hui. Jit-Browser le réutilise simplement dans un environnement sans tête contrôlé.
Ce qui est encore nécessaire pour une fonctionnalité de navigateur native
Ce qui est encore nécessaire pour une fonctionnalité de navigateur native
Pour transformer Jit-Browser en une fonctionnalité intégrée du navigateur, personne n'a besoin d'un miracle - juste la capacité de placer un petit ensemble de changements bien définis que les moteurs de navigateur comprennent déjà.
Pour transformer Jit-Browser en une fonctionnalité intégrée du navigateur. Ce n'est pas un miracle, juste un petit ensemble de changements que les navigateurs comprennent déjà.
-
Un crochet natif dans le moteur.
Aujourd'hui, nous simulons cela en injectant un script depuis Chrome sans tête. Une véritable intégration donnerait à Jit-TR un emplacement de traduction dédié afin qu'il puisse lire et écrire du texte DOM au bon moment dans le pipeline de rendu. -
Une manière standard d'exprimer l'intention linguistique.
Nous utilisons déjà?jittr=LANGet des cookies. Une solution au niveau du navigateur pourrait respecter les paramètres de langue du navigateur et les choix des utilisateurs comme "traduire toujours ce site en ES-419". -
Un cadre clair de sécurité et de confidentialité.
Les règles concernant le texte pouvant quitter l'appareil, la durée de mise en cache et la manière dont les sites ou les utilisateurs peuvent se désinscrire doivent être claires et documentées. Une mise en œuvre native à l'intérieur du navigateur peut en fait être plus sûre que des scripts ad hoc.
Exemple : HarmonyOS en ES-419
Voici un exemple concret du pipeline en action.
Nous appelons :
getpageJtrBrowser \
"https://www.harmonyos.com/" \
"jittr=ES-419" \
null \
"ES-419/index.php"
Jit-Browser :
- Lance Chrome sans tête à l'intérieur de Docker.
- Charge
https://www.harmonyos.com/. - Injecte le snippet Jit-TR avec le paramètre ES-419.
- Laisse Jit-TR traduire le texte chinois visible en espagnol (Amérique latine).
- Sauvegarde le résultat sous
ES-419/index.php.
Le site HarmonyOS n'a pas besoin de changer. Du point de vue de l'utilisateur, il semble que le site prenne simplement en charge sa langue.
Pourquoi cette page existe
HeadlessChrome101 est un résumé qui montre :
- Nous utilisons de vrais moteurs de navigateur et de vraies règles CSP.
- Nous avons déjà un runtime de traduction propriétaire fonctionnel.
- L'écart restant pour une fonctionnalité de navigateur native est petit et bien défini.
Si vous construisez des navigateurs, des systèmes d'exploitation ou de grandes plateformes et que vous souhaitez une couche multilingue universelle qui respecte votre modèle de sécurité, nous sommes prêts à en parler. Le code existe. Le comportement est mesurable. La prochaine étape est le partenariat.