Jit-Browser Bahagi ng Jit-4 platform EN-CA |
Jit-Browser logo

Anumang website - anumang oras - mula sa anumang wika PATUNGO SA IYONG WIKA.

Isang browser sa loob ng iyong browser na ginagawang nababasa ang buong web sa iyong wika

Bawat browser ay may marka. Ito ang sa amin. Isang browser sa loob ng isang browser.

Ang gulong ay nagdadala ng bawat kariton habang ito ay lumilipat sa bagong web.
Ang mga spok ay ang mga hawakan ng Web2 na nagpapanatili sa web na gumagana.
Ang axle ay ang nagbubuklod sa mga spok sa kariton.
Ang Jit-Browser ay ang bagong fitting ng axle na nagpapanatili sa iyong kariton na matatag,
hindi kailanman naiwan habang ang digital na Oregon at Santa Fe Trail ay patuloy na gumagalaw.

Isang browser sa loob ng iyong browser - palaging may paraan pasulong, sa anumang wika.
Ang "panalo" ay ang landas na nakikita mo kapag hindi ka kailanman sumusuko".

Web 4 bilang isang subsystem ng browser, hindi lamang isang script

Dito inilarawan namin kung ano ang nangyayari kapag ang aming patent-pending na code ay tumatakbo kasama ang iChrome Browser layout engine, ang JavaScript engine nito, at ang network stack, sa halip na mabuhay bilang "isa pang script" sa pahina. sa loob ng aming server - o sa iyong server - o sa browser ng kliyente.

β Mahusay na headless capture ngayon. Mabilis na headless capture bukas. Lightning-fast na layer ng browser kung isasama sa mga browser tulad ng Chrome o HarmonyOS.

Ano ang ginagawa ng Jit-Browser sa simpleng wika

Ang Jit-Browser ay isang headless browser pipeline na
na na-activate kapag ang isang pahina mula sa anumang website ay hiniling / bago ito maihatid gamit ang aming proprietary decision rules.

  • Nag-launch ng isang tunay na Chrome engine sa loob ng isang container
  • Naglo-load ng eksaktong pahinang iyon na eksaktong tulad ng gagawin ng isang user (HTML, CSS, JS, fonts, images)
  • Nag-iinject ng aming patent-pending na JS code mula sa api.jit-tr.com
  • Isinasagawa ang aming JS code sa lugar (halimbawa upang ES-419 at Ai/AEO)
  • Kinuha ang huling binagong DOM bilang isang static na HTML snapshot
  • Ipinapadala ang static na HTML snapshot na iyon

Sa aming site - o sa iyo - o sa loob ng isang browser.

Ito ang parehong arkitektura na ginagamit ng Jit-TR sa mga tunay na site, ngunit tumatakbo ng headless, na may mga timing logs na nagpapakita kung saan eksakto napupunta ang oras.

Isang capture, hakbang-hakbang

1. Container + Chrome Simulan ang Docker, simulan ang headless Chrome, ikabit ang Puppeteer.
Karaniwang gastos: mga 8–15 segundo sa isang malamig na pagsisimula.
2. Pag-load ng pahina I-load ang HTML, CSS, JS bundles, fonts, at mga imahe para sa target na site.
Karaniwang gastos: mga 8–15 segundo para sa mga mabibigat na site.
3. Jit API boot I-inject ang Jit API code, pumili ng wika (halimbawa ES-419), at i-initialize.
Karaniwang gastos para sa buong/unang pagkakataon / integrasyon: mga 1–3 segundo. Karaniwang gastos para sa mas kaunti sa 10 edits: mga 0.01 segundo.
4. Daloy / mga click helper Opsyonal: tanggapin ang cookie banner, i-click ang “load more”, o mag-scroll upang ipakita ang nilalaman.
Ang gastos ay nakasalalay sa daloy, kadalasang nasa paligid ng 0.01 segundo.
5. Screenshot at HTML dump Opsyonal na kumuha ng buong pahinang screenshot at isulat ang isinalin na HTML sa disk.
Kadalasang nasa paligid ng 0.01 segundo bawat isa.
6. Mga safety waits Maikling nakatakdang paghihintay upang matiyak na natapos na ang lahat ng async na pagsasalin at mga pag-update ng DOM.
Kadalasang nasa paligid ng 0.1 segundo kabuuan.

Sa kabuuan, ang malamig na pagkuha ng isang malaking site ay umaabot sa paligid ng 5–15 segundo. Karamihan sa mga iyon ay ang gastos ng pagsisimula ng isang bagong browser engine sa loob ng isang container.

Ito ay nawawala kung ang Docker, headless Chrome, at Puppeteer ay nananatiling aktibo bilang isang daemon.

Ito ay NAGLALAKBAS kung ang Jit API ay nakasama sa isang Browser!

Malamig vs mainit vs katutubong layer ng browser

Ang parehong pipeline ay mukhang napakaiba depende sa kung saan ito tumatakbo:

Malamig na headless run (ngayon)

  • Simulan ang Docker para sa bawat pagkuha
  • Simulan ang Chrome headless para sa bawat pagkuha
  • I-reload ang lahat ng assets bawat oras
  • I-inject ang Jit-TR at isalin

Karaniwan: 25–35 segundo para sa isang HarmonyOS na pagkuha.

Mainit na “sleep mode” container

  • Gamitin muli ang isang pangmatagalang container
  • Gamitin muli ang isang solong Chrome instance
  • Gamitin muli ang naka-cache na CSS, JS, fonts, at mga imahe
  • Baguhin lamang ang isinalin na HTML

Karaniwan: 8–12 segundo kapag mainit para sa parehong pahina.

Katutubong subsystem ng browser

  • Walang Docker sa lahat
  • Walang hiwalay na proseso ng Chrome
  • Gamitin muli ang built-in na cache ng browser
  • Ang Jit-TR ay tumatakbo sa loob ng engine bilang isang multilingual layer

Incremental overhead: milliseconds, hindi segundo.

Ang Jit-Browser ay isang makatotohanang demo kung paano ang isang built-in na multilingual layer ay magiging kung ang mga browser ay nagbigay dito ng upuan sa tabi ng layout, JS, at ang network stack.

Sample timing trace mula sa isang tunay na pagkuha

Ito ang hitsura ng isang tunay na headless timing trace kapag kumukuha ng HarmonyOS sa ES-419:

[URL] Page URL para sa pagkuha: 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
        

Ginagawa ng trace na napakalinaw: ang mabagal na bahagi ay hindi ang pagsasalin, ito ay ang malamig na pagsisimula ng isang buong browser stack sa isang container. Ilipat ang parehong lohika sa browser engine, at karamihan sa gastos na iyon ay nawawala.

Malalim na detalye

Paano ang “Warm Mode” ay nagpapabilis sa Jit-Browser

Ang demo ngayon ay naglo-load ng bawat pahina sa mahirap na paraan:

  • Simulan ang Docker
  • Simulan ang Chrome headless
  • I-load ang site ng sariwa
  • I-inject ang Jit-TR
  • Isalin at kunin
  • Isara ang lahat muli

Ito ang katumbas ng pagsasara ng isang laptop, pag-on muli, pagbubukas ng browser, at pagbisita sa isang site para sa bawat solong pahina. Ang malamig na pagkuha ay umaabot sa humigit-kumulang 25–35 segundo sa karaniwang hardware.

Warm Mode (“Sleep Mode”)

Sa halip na i-reboot ang lahat, ang Jit-Browser ay maaaring panatilihing tumatakbo ang isang mainit na headless Chrome sa background:

  • Nananatiling buhay ang Docker container
  • Ang Puppeteer at Chrome ay nananatiling naka-load
  • Ang mga tab ay nananatiling bukas o maaaring gamitin muli
  • Ang cache ng browser ay nananatiling mainit (mga font, CSS, JS, mga imahe)

Bawat bagong kahilingan ay nagiging halos instant kumpara sa malamig na boot:

  • Walang pagsisimula ng Docker
  • Walang pagsisimula ng Chrome
  • Ang naka-cache na mga asset ng HarmonyOS o Huawei ay naglo-load mula sa disk
  • Tanging ang isinalin na HTML ang nagbabago

Ang mga warm-mode na capture ay karaniwang bumababa mula sa humigit-kumulang 30 segundo hanggang sa paligid ng 8–12 segundo.

Bakit ito mahalaga

Ang mga browser ay mayroon nang mga katutubong layer para sa:

  • Pagpapatupad ng JavaScript
  • Pag-layout ng HTML
  • Network stack
  • Accessibility tree
  • GPU rendering

Ang Jit-TR ay kumikilos tulad ng isang nawawalang katutubong layer: isang multilingual na layer. Ipinapakita ng Warm Mode kung gaano kabilis ito kung ang pagsasalin ay tumakbo sa loob ng browser engine nang direkta sa halip na bilang isang panlabas na script.