HeadlessChrome101: Como o Jit-Browser Transforma o Chrome Numa Camada de Navegador–Servidor de Multi-Função
Este é um guia em linguagem simples sobre o que o Jit-Browser faz com o Chrome headless, como utiliza o runtime proprietário Jit-TR e o que ainda é necessário para tornar isso uma funcionalidade de navegador de primeira classe em vez de apenas mais um script.
De uma simples ferramenta de captura de ecrã ao Jit-Browser
Começámos com uma pequena ferramenta de linha de comando: getpage https://example.com page.png. Ela iniciou o Chrome num container Docker, tirou uma captura de ecrã do example.com renderizado a partir da página e saiu.
Prova de conceito útil. Cada chamada era um arranque a frio. Não sabia nada sobre tradução, sessões ou estado. Era apenas uma câmara headless.
O Jit-Browser é o próximo passo. Ele ainda usa o Chrome real, mas agora:
- Regista o que acontece dentro da página.
- Injeta o script Jit-TR como uma camada de tradução.
- Pode seguir fluxos simples como banners de cookies ou menus suspensos.
- Captura o HTML totalmente traduzido, não apenas uma captura de ecrã.
Esta página explica esse pipeline para que você possa ver que não estamos a fazer promessas vazias. Estamos a mostrar como uma camada multilíngue a nível de navegador pode realmente funcionar.
O pipeline do Jit-Browser em 6 passos
A um alto nível, cada captura segue a mesma sequência.
-
Lançar o Chrome real (headless) dentro do Docker.
Usamos o Puppeteer (pptr.dev) para iniciar o mesmo motor que alimenta navegadores normais, mas sem uma janela visível. Sem parser personalizado, sem renderização falsa. -
Aplicar cookies ou estado de login (se configurado).
Para demonstrações que precisam de uma sessão autenticada, reproduzimos os seus cookies. Sem força bruta, sem adivinhação de senhas, sem scraping de contas que não controlamos. -
Carregar a página alvo exatamente como um utilizador.
HTML, CSS, JavaScript, fontes, imagens. Esperamos pornetworkidle2(https://pptr.dev/api/puppeteer.page.waitfornetworkidle) para que pacotes lentos e fontes possam terminar de carregar. -
Injetar o snippet Jit-TR como uma camada.
Adicionamos uma tag de script apontando para o nosso código de runtime com patente pendente – por exemplo:. O módulo de runtime Jit-TR percorre o DOM exposto (document.head e document.body), envia a carga extraída de volta para o nosso (ou qualquer) servidor para ser processada, recebe os resultados (tradução, melhoria ou nova informação), reescreve o texto visível e adiciona novas camadas de significado sobre o original. As únicas restrições que existem são simples: scripts podem ser aumentados, mas novas instruções nunca podem interferir com os próprios scripts do site. Isto é tipicamente implementado usandoMutationObserverinstâncias para observar mudanças relevantes no DOM, aplicar atualizações em pequenos patches direcionados e evitar tocar em qualquer lógica de aplicação existente ou manipuladores de eventos. -
Executar fluxos opcionais: cookies, cliques e rolagem.
Páginas reais frequentemente precisam de uma ou duas ações: fechar um banner de cookies, abrir um menu, rolar para carregar mais ofertas. O Jit-Browser pode executar um script de fluxo simples para que esses elementos sejam visíveis antes da captura. -
Capturar a saída aumentada.
Nós salvamos:- O HTML totalmente modificado para hospedagem ou auditoria.
- Um rastreio de tempo para identificar potenciais gargalos.
Esse é o núcleo do nosso HeadlessChrome101. É o modelo mental de como um navegador poderia tratar dados novos ou existentes como uma camada embutida dentro de qualquer navegador.
Por que isso não é apenas um script de brinquedo
O Jit-Browser é importante porque prova que uma camada a nível de navegador pode ser construída com as mesmas peças que os fornecedores de navegadores já usam todos os dias, e que essa camada pode hospedar com segurança uma interação completa cliente-servidor com qualquer serviço externo, incluindo o nosso próprio runtime Jit-TR. É também o ponto onde adicionamos melhorias conscientes de SEO, como rel="alternate" hreflang="..." links e enriquecidos sitemap.xml entradas. Na prática, isso significa que podemos expor informações aumentadas dentro de regiões HTML não disruptivas como elementos à esquerda ou à direita da página existente, ou usando modais JavaScript que incorporam escolhas de idioma e SmartSearch sem interferir com o layout ou scripts originais.
-
Motor real do Chrome.
Tudo funciona no próprio Chrome - apenas sem a janela visível. Se funciona no Chrome para os seus visitantes, funciona no Jit-Browser. -
Consciente da Política de Segurança de Conteúdo.
A maioria dos sites bloqueia scripts com CSP. Em modo headless, podemos usar osetBypassCSP(true)(https://pptr.dev/api/puppeteer.page.setbypasscsp) para injetar Jit-TR dentro do ambiente de captura. Não exigimos que nenhum site de produção enfraqueça as suas políticas de segurança. -
Tempos e registos completos.
Registamos os tempos de lançamento, os tempos de carregamento da página, o arranque do Jit-TR, os passos do fluxo e a captura. Você pode ver para onde vão os milissegundos e o que o Jit-TR realmente faz na página. -
Separação de script e camada.
Hoje, o Jit-TR pode ser "apenas um script" que você adiciona a um site. No Jit-Browser tratamos isso como uma camada estável que está sempre em execução. Isso está muito próximo de como um fornecedor de navegador poderia integrá-lo nativamente.
O que a API do Jit-TR já resolve
A parte difícil não é o Chrome sem cabeça. A parte difícil é transformar de forma fiável páginas web ao vivo e desordenadas em versões seguras e multilíngues. O nosso runtime proprietário em api.jit-tr.com já faz esse trabalho.
Hoje, o runtime da API lida com:
-
Seleção de idioma.
Lê parâmetros comojittr=ES-419, normaliza casos extremos e regista o idioma escolhido, por exemplo:[Jit-TR] Idioma escolhido → ES-419. -
Extração de DOM, tradução e reescritas semânticas.
O runtime percorre o DOM real do Chrome, extrai apenas o texto visível, constrói uma carga útil de tradução estruturada e escreve os resultados de volta na página. Todos os casos extremos difíceis são automáticos: sequências de emoji, entidades HTML, regras de pontuação e espaçamento, strings em línguas mistas e alternância de Direita para Esquerda / Esquerda para Direita. Também reescreve blocos de script específicos de idioma — incluindoe outras tags de dados estruturados — garantindo que cada idioma tenha metadados corretos, independentes e em cache para motores de busca e sistemas de IA. -
Comportamento do cliente.
Renderiza bandeiras de idiomas, respeita raízes inseguras e atua da forma mais segura possível com aplicações de página única e frameworks.
Tudo isso já está em funcionamento em sites Jit-TR hoje. O Jit-Browser simplesmente reutiliza isso em um ambiente sem cabeça controlado.
O que ainda é necessário para uma funcionalidade nativa do navegador
O que ainda é necessário para uma funcionalidade nativa do navegador
Para transformar o Jit-Browser em uma funcionalidade integrada do navegador, ninguém precisa de um milagre - apenas a capacidade de implementar um pequeno conjunto bem definido de alterações que os motores de navegador já entendem.
Para transformar o Jit-Browser em uma funcionalidade integrada do navegador. Isso não é um milagre, apenas um pequeno conjunto de alterações que os navegadores já entendem.
-
Um gancho nativo no motor.
Hoje simulamos isso injetando um script do Chrome sem cabeça. Uma verdadeira integração daria ao Jit-TR um slot de tradução dedicado para que ele possa ler e escrever texto do DOM no ponto certo do pipeline de renderização. -
Uma forma padrão de expressar a intenção de idioma.
Já usamos?jittr=LANGe cookies. Uma solução a nível de navegador poderia respeitar as configurações de idioma do navegador e as escolhas do usuário, como "traduzir sempre este site para ES-419". -
Uma estrutura clara de segurança e privacidade.
As regras sobre que texto pode sair do dispositivo, quanto tempo pode ser armazenado em cache e como sites ou usuários podem optar por não participar devem ser claras e documentadas. Uma implementação nativa dentro do navegador pode ser, na verdade, mais segura do que scripts ad-hoc.
Exemplo: HarmonyOS em ES-419
Aqui está um exemplo concreto do pipeline em ação.
Chamamos:
getpageJtrBrowser \
"https://www.harmonyos.com/" \
"jittr=ES-419" \
null \
"ES-419/index.php"
Jit-Browser:
- Lança o Chrome sem cabeça dentro do Docker.
- Carrega
https://www.harmonyos.com/. - Injeta o snippet do Jit-TR com o parâmetro ES-419.
- Permite que o Jit-TR traduza o texto chinês visível para espanhol (América Latina).
- Salva o resultado como
ES-419/index.php.
O site HarmonyOS não precisa mudar. Da perspectiva do usuário, parece que o site simplesmente suporta o seu idioma.
Por que esta página existe
HeadlessChrome101 é um resumo que mostra:
- Estamos usando motores de navegador reais e regras CSP reais.
- Já temos um runtime de tradução proprietário em funcionamento.
- A lacuna restante para uma funcionalidade nativa do navegador é pequena e bem definida.
Se você construir navegadores, sistemas operativos ou grandes plataformas e quiser uma camada multilíngue universal que respeite o seu modelo de segurança, estamos prontos para conversar. O código existe. O comportamento é mensurável. O próximo passo é a parceria.