The headline numbers
| What you do | Jellyfin 10.11 | Lattice | Difference |
|---|---|---|---|
| Search as you type (each keystroke, “Blade Runner”) | 3,000–10,000 ms | under 7 ms | ~500–1,500× |
| Open an item’s details | 361 ms | 1.2–2.7 ms | ~130–300× |
| Next Up / Continue Watching | 184–473 ms | 1–13 ms | ~35–180× |
| “Latest” row | ~1,000 ms | ~6 ms | ~170× |
| Full library sync (Infuse library mode) | 3 min 20 s – 3 min 47 s | ~5 s warm, ~20 s cold | ~10–48× |
| Sync when nothing changed | full re-crawl, ~3.5 min | a few ms | — |
| Artwork for a phone’s full library | originals, ~530 KB avg | ~74% smaller | ~¼ the bytes |
1. Search that keeps up with your typing
In Infuse’s direct mode, every keystroke is a server search. On Jellyfin, each one scans the whole item table for the text you typed. Several are in flight at once, and they queue:
| Keystroke | Jellyfin | Lattice |
|---|---|---|
Bla | 3,295 ms | under 7 ms |
Blade | 9,464 ms | under 7 ms |
Blade R … Blade Runne | 10,107–10,204 ms each | under 7 ms |
Blade Runner 2049 | 3,206 ms | under 7 ms |
How: when a title is added, Lattice indexes every way you might start typing it (b, bl, bla, … blade r, …) into pre-sorted lists, and decides the ranking (exact title first, movies before episodes and so on) at the same time. A keystroke becomes one keyed read of about 24 entries. That costs the same for a 400-title library as for a 400,000-title one.
- p99 over HTTP, full response included: 6.8 ms for the captured keystrokes, 13.8 ms for random titles seen for the first time.
- 14 keystroke requests in flight at once: 25 ms in total.
- People search: 3–6 ms.
- Forgiving matching: accents fold, “&” matches “and”, “Rocky II” matches “rocky 2”, and “spider-man” matches “spiderman”.
2. A full library sync in seconds, not minutes
Infuse’s library mode crawls your entire library, 200 items per page:
| Jellyfin | Lattice | |
|---|---|---|
| Full crawl, ~40,000 items | 181–193 s server time; 3 min 20 s – 3 min 47 s wall clock | 4.0–4.8 s warm, ~19–22 s cold |
| Per page (200 items), p50 | 264–969 ms, grows with library size | ~15 ms, flat |
| Season pages, p99 | 5.9–7.9 s | 16–68 ms |
And when you tap sync with nothing changed:
- Jellyfin has no change feed of its own. InfuseSync is a plugin that tends to break on major Jellyfin releases, and on the 10.11 server we measured it wasn’t loaded at all. So every sync was a full re-crawl: about 3.5 minutes each time, and it pauses artwork caching while it runs.
- Lattice serves Infuse’s sync protocol natively from its journal. A sync asks “what changed since my checkpoint?” and gets exactly that, in milliseconds. Every change is delivered at least once, which closes two known data-loss bugs in the upstream plugin (InfuseSync issues #37 and #38).
3. It stays fast as your library grows
We ran both servers on the same machine, against the same libraries, at four sizes (the full Infuse crawl, warm):
| Library size | Jellyfin crawl | Lattice crawl | Jellyfin page p50 | Lattice page p50 |
|---|---|---|---|---|
| 100 | 0.34 s | 0.02 s | 47 ms | 1.9 ms |
| 1,000 | 1.9 s | 0.10 s | 132 ms | 14 ms |
| 10,000 | 20 s | 1.0 s | 300 ms | 15 ms |
| 40,000 | 193 s | 4.0 s | 969 ms | 15 ms |
Jellyfin’s crawl grows faster than the library: from 10,000 to 40,000 items, four times the items took 9.4 times as long, because each page costs more the further into the library it is (offset paging on SQLite). Lattice pages from a precomputed position, so every page costs the same and the crawl grows exactly with the library.
4. Artwork sized for the screen it’s going to
Infuse’s library mode fetches a poster and backdrop for every title. Jellyfin sends the full originals, averaging about 530 KB each:
- On the iPhone with artwork pre-cache on, a fresh library moved about 1 GB of artwork per ~1,000 titles.
- The Apple TV’s pass ran at about 15 images a second, about 64 Mbit/s of originals, for about 45 minutes.
- Fast scrolling outran it, showing blank tiles until the originals arrived.
Lattice pre-builds renditions for each class of device. The TV tier is backdrops up to 2160 px and posters up to 1000 px; the handheld tier is 1170 px and 600 px. It picks the right one per request: Apple TV gets TV, iPhone and iPad get handheld, browsers get originals. Measured across the real library, 55,457 images per tier:
| Tier | Images rebuilt | Bytes saved on those | Notes |
|---|---|---|---|
| TV (Apple TV) | 25,315 | 50% | the other 29,823 were already small and stay original |
| Handheld (iPhone, iPad) | 43,827 | 74% | about ¼ the bytes; the grid keeps up with your thumb |
On a real iPhone’s full artwork sync, Infuse fetched 45,731 images (9.17 GB) from Jellyfin in about 17 minutes and stored 5.73 GB. For those exact images, Lattice’s handheld renditions total 3.49 GB (38%), and the TV tier 5.23 GB (57%). Less transferred means less stored on the phone, too: a library-mode Infuse install grew from 253 MB (direct mode) to 995 MB, then to more than 1.57 GB as artwork filled in, all of it originals.
5. What doesn’t change
- Your apps. Infuse connects to Lattice exactly as it connects to Jellyfin: same login, same libraries, same playback.
- Your passwords. Lattice verifies Jellyfin’s own password format, so imported users sign in unchanged.
- Your watch history. It’s imported from Jellyfin. Resume points, watched state and Next Up matched exactly in testing (18/18, 16/16 and 148/148).
- Direct play. Files are served as they are, with the same byte-range behaviour Infuse relies on. Nothing is force-transcoded.
How we measured, and what’s still to come
- Jellyfin figures come from a production Jellyfin 10.11.10 server’s own request logs during real Infuse sessions on 14 and 15 October 2026, plus a same-host scale benchmark.
- Lattice figures come from replaying the same requests against Lattice running on a copy of the same library, and from the same scale benchmark on identical hardware for both servers. Percentiles are over repeated runs. “Cold” means a freshly started server process.
- One library. The real-library figures come from one household’s library of about 40,000 items; the scale test adds the four library sizes above. Your library, hardware and network will give different numbers.
- Server-side times. Still to come: the same Infuse sessions on the Apple TV and iPhone pointed at a live Lattice server. Those include Wi-Fi and the device’s own work, so on-device times will be higher than the server-side ones above. We’ll publish measured device times, transfers and storage as they arrive.
- Not a Lattice win: slow playback starts on MP4 files whose index sits at the end of the file. That’s a property of the file, not the server; it affected 90% of the MP4s in this library. Lattice remuxes such files to “faststart” when they’re added, which fixes it without re-encoding.
Initial library load
How long a brand-new library takes until every file is playable, measured on a separate benchmark machine with an SSD:
- Libraries: 1,000, 5,000 and 36,130 media files laid out like a real household library (the same movies, series and episodes), each file a short test clip with real header shapes (codecs, audio and subtitle tracks, chapters) at a realistic file size.
- Cold: every run starts from wiped server state and a new process, on the same machine, one server at a time.
- Jellyfin 10.11.10, “tuned”: the configuration that’s fair to Jellyfin, with the common workarounds applied and, for the fully dressed run, TheMovieDb enabled for every TV type. Jellyfin’s defaults finish slightly sooner with metadata off but leave TV episodes without metadata or art when TMDB is on, so they do less work.
- Two arms: TMDB off with full NFO files (time until every file is playable), and TMDB on (time until posters and metadata have all arrived, “fully dressed”). With TMDB on, Lattice’s NFOs carry only ids, and Jellyfin gets none, because a Jellyfin NFO switches off its online metadata lookup.
- Runs: medians of three, except single runs for Jellyfin at 36,130 files (it takes over three hours) and Jellyfin with TMDB on (to be polite to the TMDB API).
- Community figures on the home page are Jellyfin users’ own reports, linked to their sources; they are not our measurements, and hardware and settings vary.
Want to try it on your library? We’re choosing beta testers from the waitlist.
Join the waitlist