Immersive Translate High CPU or Lag? Site Allowlist and Translation Scope Checks

When Immersive Translate feels laggy or pins CPU, shrink translation scope before reinstalling: set site access to allowlisted hosts or “on click,” disable nonessential auto-translate, add noisy hosts to never-translate, and close extra tabs that are translating at once. Full-page bilingual mode scans the DOM and injects nodes—the wider the grant, the hotter the fan. If a short static article is fine and only a long page or SPA spins, stay on allowlist and trigger timing; gray icons or total silence belong on the not-working track.

People searching for Immersive Translate high CPU or lag usually still get translations—they just get heat, dropped frames, and sticky scrolling. That is a different layer from “click Translate, nothing happens,” which belongs in the not-working checklist. Unclear package lineage starts at the download page; Incognito-only or SPA-after-route oddities belong in the Incognito & SPA article. Overlap or covering text belongs in the bilingual display article. This post stays on local cost when scope and auto policies are too wide.

Lag/CPU vs not working

High-CPU / lag signals: Task Manager shows an elevated extension or tab process, the fan spins, scrolling sticks, but Translate still produces text (even if slowly).

Not-working signals: gray icon, no response, silence on every host, options will not open—that is load/conflict/permission territory in the not-working checklist.

Compare: a clean profile or other extensions disabled, Immersive Translate only, one short static English page, one manual trigger. Smooth on the short page and hot only on a long doc or admin SPA means scope and page weight—not a “broken” install.

Shrink scope before switching engines

Lag often sends people straight to DeepL / OpenAI. Custom engines change latency and style; scanning nodes and writing bilingual DOM still costs CPU. Order:

1. In extension details, change site access from “on all sites” to specific hosts or “on click.”
2. Turn off global open-and-translate style options if you enabled them; prefer on-demand clicks.
3. Manually translate one short static page and watch whether CPU drops.
4. Still slow with clear engine errors → open the custom-engine guide for keys and quota.

A trap I hit: auto-translate on all sites swept mail, docs, and design tools together; tab processes stayed high until auto was off.

Site allowlist and never-translate

Allowlists answer which hosts may inject. Never-translate answers which hosts must stay untouched. Use both—cleaner than toggling the whole extension.

• Only academic / docs hosts need bilingual reading → allowlist those hostnames.
• Internal admins, design tools, spreadsheets, dashboards → never-translate so cells and canvases are not rescanned.
• After edits, close and reopen old tabs; already-injected pages may finish one more pass under the old policy.

Allowlists are not a free pass: an allowed host with auto-translate can still peg CPU. Tighten the list, then decide auto vs manual per site.

Long pages, tabs, and SPA rescans

Same extension, very different cost:

• Short news vs documents/forums with huge node counts.
• One tab vs a dozen authorized tabs all auto-translating.
• Static one-shot scans vs SPAs that keep inserting nodes after routes or lazy loads.

Practical habits: collapse comments and side panels before translating; read long docs in chunks instead of auto-translating the whole library on open; on SPAs, wait for the main region to settle, then click Translate once. Lost bilingual text or repeated rescans after client routes: Incognito & SPA fixes.

Core bilingual triggers also sit in the webpage translation guide—prefer manual triggers over global auto when performance matters.

Engine wait vs local CPU

Split local spikes from network waits:

• High tab CPU, fan noise, scroll jank → local: DOM scan, bilingual inject, layout thrash.
• CPU modest, long spinner, occasional timeouts → network/engine; switch engines or try a hotspot, details in custom engines.

Quick A/B: same short page, built-in engine once, then a custom engine. Similar local cost → stop chasing engines and return to allowlist/auto policy. Only one key freezes the page with errors → engine track.

Vs install or Incognito faults

Avoid reinstall loops:

• Translations appear but the machine cooks → this article: shrink scope, allowlist, disable auto, fewer tabs.
• Text appears but overlaps, drifts, or covers → bilingual display fixes.
• Gray icon / silence everywhere → not-working checklist.
• Incognito-only or SPA-after-route oddities → Incognito & SPA.
• Clear key/quota/engine errors → custom engine.
• Unclear package source → verify on the download page, then retest.

Once it is stable, note which hosts stay on the allowlist and which must never auto-translate. Cheaper than reinstalling every time the fan spins.

FAQ

High CPU—reinstall?

Usually no. Tighten site access and auto-translate; compare a short static page. Total failure → not-working checklist.

Allowlist on, still laggy?

Yes. Long pages, lazy inserts, and many authorized tabs still cost CPU—switch to manual triggers and close extras.

Will a custom engine lower CPU?

Not reliably. Shrink scope first; engines mainly own latency and errors—see the custom-engine guide.

Only one SPA lags?

Dynamic nodes re-queue. Translate after the UI settles; use the SPA refresh-timing article.