LiteRT.js: Google's High-Performance Web AI Inference Engine, Explained

LiteRT.js: Google's High-Performance Web AI Inference Engine, Explained

Google has released LiteRT.js, a JavaScript binding of its on-device inference library LiteRT (formerly TensorFlow Lite), built to run machine learning and AI models directly inside a web browser. The pitch is straightforward: take the same optimized, cross-platform runtime that already powers on-device AI on Android, iOS, and desktop, and make it available to web developers with the same performance characteristics — enhanced user privacy, zero server inference costs, and latency low enough for real-time experiences.

For teams that already ship .tflite models on mobile, LiteRT.js is positioned as a smoother deployment path to the web than the JavaScript-kernel approach of TensorFlow.js. For everyone else, it's a new option for building AI features — text generation, object detection, audio processing — that run entirely client-side, with no round-trip to a server for every inference call.

Table of Contents
  1. Why this is different from TensorFlow.js
  2. How LiteRT.js benefits web developers
  3. 1. PyTorch conversion and tailored quantization
  4. 2. Native hardware acceleration across CPU, GPU, and NPU
  5. Performance and real-world impact
  6. See it in action
  7. Ultralytics YOLO object detection
  8. Monocular depth estimation
  9. 4x image upscaling
  10. Getting started with LiteRT.js
  11. What's next

Why this is different from TensorFlow.js

Earlier web AI runtimes like TensorFlow.js relied on JavaScript-based kernels, which left meaningful performance on the table compared to native, platform-specific implementations. LiteRT.js instead compiles Google's actual native runtime — the same one used on mobile and desktop — down to WebAssembly, so the browser gets the real optimizations rather than a JavaScript reimplementation of them.

That runtime targets hardware acceleration through three backends: XNNPACK for CPU inference, ML Drift for GPU inference via WebGPU, and an upcoming NPU path through the WebNN API (currently experimental in Chrome and Edge). The initial release ships with the @litertjs/core npm package and a collection of live demos to try before integrating anything.

How LiteRT.js benefits web developers

LiteRT.js

Because LiteRT.js shares a unified stack with LiteRT on other platforms, web applications automatically inherit the same performance work, quantization improvements, and hardware optimizations Google ships for Android, iOS, and desktop — rather than a separately-maintained, perpetually-behind web port. Two capabilities stand out for developers evaluating it.

1. PyTorch conversion and tailored quantization

With LiteRT Torch, PyTorch models convert to the LiteRT format in a single step, ready to take advantage of browser-based hardware acceleration immediately. Google publishes a getting-started guide for the conversion flow.

For further size and speed gains, the AI Edge Quantizer lets you configure quantization schemes per layer rather than uniformly across the whole model — trading precision only where the model can afford it, which tends to preserve output quality better than blanket quantization. There's a worked example colab showing the technique on a real model.

2. Native hardware acceleration across CPU, GPU, and NPU

  • CPU: XNNPACK, Google's optimized on-device CPU library, with multi-thread support and a relaxed-SIMD build for extra throughput.
  • GPU: ML Drift driving WebGPU, which Google positions as its leading on-device GPU acceleration path, now brought to the browser.
  • NPU: the WebNN API (experimental in Chrome and Edge) targets dedicated neural processing units for power-efficient, ultra-low-latency inference where the hardware supports it.
LiteRT.js architecture overview
LiteRT.js architecture overview.
Read also:

Performance and real-world impact

Google benchmarked LiteRT.js against existing web AI runtimes across classical computer vision and audio-processing models. The headline result: LiteRT.js outperformed other web runtimes by up to 3x across both CPU and GPU inference.

LiteRT.js performance comparison chart
Benchmarks were conducted on a 2024 Apple MacBook Pro with M4 Apple Silicon in a controlled browser environment. Individual results will vary with local GPU capability, thermal throttling, and browser driver optimization.

Google also compared three execution backends directly — CPU via XNNPACK, WebGPU, and WebNN via Apple CoreML — across popular AI model types. For latency-sensitive work like object tracking, audio transcription, or image manipulation, routing inference through the GPU or NPU (WebGPU or WebNN) delivered a 5–60x speedup over standard CPU execution.

Classical model performance benchmark chart
Benchmarks were conducted on a 2024 Apple MacBook Pro with M4 Apple Silicon in a controlled browser environment. Individual results will vary with local GPU capability, thermal throttling, and browser driver optimization.

See it in action

Demo source code is available on the LiteRT GitHub repository and via Ultralytics. A few of the live demos:

Ultralytics YOLO object detection

Ultralytics, the company behind the widely-used YOLO (You Only Look Once) family of real-time object detection and image segmentation models, now ships official LiteRT export support directly in its Python package. That means deploying Ultralytics YOLO models to mobile, edge, and the browser is a matter of a few lines of code, from export straight through to runtime.

Monocular depth estimation

Depth Anything turns a standard webcam feed into an interactive 3D point cloud in real time. Running the Depth-Anything-V2 model through LiteRT.js on WebGPU, the demo calculates per-pixel depth and maps the video into a responsive 3D space, live in the browser.

4x image upscaling

A Real-ESRGAN demo upscales images 4x entirely in the browser, working by upscaling 128×128-pixel patches to 512×512 and reassembling them into the final output image.

Getting started with LiteRT.js

Integrating LiteRT.js is meant to be straightforward whether you're starting fresh or migrating an existing TensorFlow.js pipeline — the library abstracts away hardware-level tuning so you can focus on the model and the UI around it. Here's the shape of loading, compiling with GPU acceleration, and running inference on a .tflite model:

import { loadLiteRt, loadAndCompile, Tensor } from '@litertjs/core';

await loadLiteRt('path/to/wasm/directory/');

const model = await loadAndCompile('path/to/your/model.tflite', { accelerator: webgpu });

const inputTypedArray = new Float32Array(1 * 3 * 244 * 244);
const inputTensor = new Tensor(inputTypedArray, [1, 3, 244, 244]);

const results = await model.run(inputTensor);

// results is a Tensor stored on GPU. To move it to CPU & convert to a
// typedArray:
const resultArray = (await results[0].moveTo('wasm')).toTypedArray();
emdashkits.com

Full setup instructions, more demos, and API reference live in the LiteRT.js documentation.

What's next

Google says the roadmap centers on deeper WebNN integration for native NPU performance, plus more optimized support for on-device generative AI in the browser. In the meantime, a few resources worth bookmarking:

The bigger picture here is less about any single benchmark and more about what becomes practical once a near-native inference runtime is a first-class citizen of the web platform: AI features that don't leak user data to a server, don't queue behind API rate limits, and don't add network latency to every interaction. For web developers who've been watching client-side AI mature on mobile from the sidelines, LiteRT.js is the clearest signal yet that the same capability is now landing in the browser.

Source: LiteRT.js, Google's high performance Web AI Inference — Google Developers Blog, by Ping Yu, Marko Ristić, Matthew Soulanille, and Chintan Parikh.

Share

Comments

Write a comment

Related Articles

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

July 16, 2026

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

July 16, 2026

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

TL;DR — A custom session-cookie login flow appeared to succeed on localhost (the OTP verified, the response looked fine) but every subsequent request to a login-gated page treated the visitor as logged out. Identical code worked fine on the live HTTPS site. The cookie's Secure attribute was hardcoded to true — and per the cookie spec, browsers never store or send a Secure cookie over a plain, non-HTTPS connection.

Table of Contents
  1. Diagnostic
  2. Root cause
  3. Fix
  4. Lessons learned

Diagnostic

Check the actual Set-Cookie response header and the browser's own cookie storage panel — on localhost over http://, the cookie is sent by the server but never actually stored by the browser.

Root cause

// before -- assumes the app is always served over HTTPS
setCookie("session", token, { secure: true, httpOnly: true });
emdashkits.com

A cookie config that quietly assumes "we're always on HTTPS" breaks the instant you test over plain HTTP, which local dev servers commonly are.

Read also:

Fix

// after -- derive secure from the actual request protocol
const isHttps = request.url.startsWith("https://");
setCookie("session", token, { secure: isHttps, httpOnly: true });
emdashkits.com

Lessons learned

  • Any Secure-flagged cookie needs to key off the real request scheme, not an assumption baked in once at cookie-creation time.
  • "Works in production, silently fails in local dev" is a strong signal to check cookie flags before anything else in an auth flow.
  • Check other cookies in the same codebase for the same hardcoded assumption — if one cookie has this bug, sibling cookies set the same way are worth auditing too.
Share
Previous Article

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Comments

Write a comment

Related Articles

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

July 16, 2026

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

July 16, 2026

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

TL;DR — GA4's gtag.js snippet was installed correctly, the page loaded with no visible JavaScript error, and GA4's real-time report still showed zero activity. The CMS's default Content-Security-Policy had no allowance for analytics domains and no config option to add one — so every request to Google's tracking endpoints was blocked at the browser level before it could fail loudly.

Table of Contents
  1. Diagnostic
  2. Root cause
  3. Lessons learned

Diagnostic

Check the browser's dedicated CSP violation reporting, not the regular console error list — CSP blocks are reported through their own channel, not thrown as normal script errors, so "no console errors" doesn't mean nothing was blocked.

Root cause

The CSP's script-src and connect-src directives had no entry for googletagmanager.com or google-analytics.com, and the CMS exposed no configuration surface to add one — the only way in was patching the CSP directives directly.

// patch-package: add analytics domains to the existing CSP directives
scriptSrc.push("https://www.googletagmanager.com");
connectSrc.push("https://www.google-analytics.com", "https://www.googletagmanager.com");
emdashkits.com
Read also:

Lessons learned

  • "No console errors" is not proof nothing was blocked — CSP violations live in their own reporting surface and are easy to miss if you're only scanning for red error text.
  • Before adding any third-party script tag to a site with a CSP already in place, check the CSP's directives first rather than assuming a silently-empty analytics dashboard means a snippet-installation mistake.
Share
Previous Article

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Next Article

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Comments

Write a comment

Related Articles

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

July 16, 2026

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

July 16, 2026

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)