Why LaTeX compilation feels fast in CorTeX

See how local compilation, package prefetching, checkpoints, and figure reuse shorten the path from an edit to a new PDF.

Compiling LaTeX requires an engine, document classes, packages, fonts, and a PDF viewer. CorTeX shortens the path from an edit to the new PDF by avoiding work that does not need to happen again.

The key distinction is between a cold compile and a warm compile. A cold compile may need to fetch tools and files. A warm compile can reuse much of that preparation.

These paths are automatic. You do not need to trade correctness for speed or maintain a second draft version of the paper.

To see the difference, open the temporary LaTeX paper, wait for the first PDF, then change one sentence near the end. Compare that update with the first compile. Your result depends on the project, browser, device, and cached files; the mechanisms below explain why those paths differ.

A short glossary#

• Engine: the TeX program, such as pdfLaTeX, that reads the source.
• TeX Live snapshot: the pinned collection of classes, packages, fonts, and tools used by a project.
• Cold compile: a compile that still needs engine or TeX files.
• Warm compile: a compile that can reuse preparation already in the browser.
• Checkpoint: a safe saved engine state from which a compatible later edit can resume.

The compiler runs beside your editor#

Ordinary LaTeX typesetting runs inside the browser. CorTeX uses wasmtex to package TeX engines as WebAssembly, a portable compiled format that modern browsers can run.

During a warm compile, the main TeX passes avoid an upload-compile-download trip to a remote server. Collaborative changes may still travel between coauthors, but typesetting does not have to wait for that journey. The editor and compiler read the same in-browser project files, including files loaded with \input or \include.

For a researcher, this means a routine prose or equation edit can update the preview without first uploading the whole manuscript to a compile server.

The first compile builds a reusable workbench#

A browser does not come with TeX Live installed. During a cold compile, CorTeX must load the selected TeX engine and fetch the packages, fonts, and format files used by the document. A conference template naturally needs more of this material than a one-page article.

These files come from an immutable TeX Live snapshot: a file at a particular address will not change unexpectedly. The browser can cache it safely, while the project remains tied to its selected TeX environment.

While the project remains open, CorTeX can keep using the prepared engine. After the tab closes, that engine stops, but downloaded TeX files may remain in the browser cache. Clearing browser data, cache eviction, or changing the project's TeX environment can make a later compile cold again.

CorTeX remembers which TeX files a project needs#

The engine must pause whenever the browser fetches a missing TeX file. When this happens one file at a time, network delay can outweigh typesetting time.

After a successful compile, CorTeX records the names of the TeX Live files the project used. These may include classes, packages, fonts, and format files. The record contains no paper text. When the project opens again, CorTeX can fetch the known set in parallel before the engine requests each file separately.

CorTeX still checks the current compile's needs, but prepares the files used last time in advance. Supported built-in templates begin with a tested list, so their first open can benefit.

CorTeX starts this preparation only when it is useful. It waits until the active workspace appears and avoids speculative downloads in a hidden tab, with data saving enabled, or on a very slow connection. A compile requested by the user always takes priority.

This optimization is most visible when reopening a package-heavy venue template: parallel preparation avoids discovering the same files one network request at a time.

A burst of typing becomes one useful compile#

Typing one word creates several changes within a fraction of a second. Running TeX for every letter would waste work and could let an older result replace a newer preview.

CorTeX collects a short burst of edits before compiling. If a newer request overtakes a compile already in progress, the older result cannot update the preview. If none of the inputs behind the last successful result changed, CorTeX can keep that PDF instead of compiling identical inputs.

The editor handles each keystroke first, then schedules source checks and PDF work separately. Compilation therefore does not block the editor's immediate response.

A checkpoint can resume near the edit#

For a compatible pdfLaTeX project, CorTeX can prepare a checkpoint near the cursor after a successful compile. A checkpoint stores the TeX engine's state.

If the next edit comes after that position and earlier input is unchanged, the engine can resume there and typeset the rest. It still creates a complete PDF; it does not join unverified page fragments.

CorTeX prepares the checkpoint during a short idle period after a successful compile, keeping that setup cost out of the next interactive compile. A new edit cancels preparation if it has not started.

The shortcut applies only when safe. Changes to setup commands, labels, citations, required files, the main document, the engine, or project structure may require a full compile. Some older environments do not support checkpoints. If CorTeX cannot prove that resuming is safe, it runs a full compile.

The practical consequence is that edits late in a stable manuscript are strong candidates for the shortest path. Revising the preamble or changing citations is expected to take the complete path.

Expensive figures can keep their own results#

TikZ and pgfplots figures are small programs that draw graphics during compilation. In a figure-heavy paper, drawing them again can take longer than typesetting the prose.

When TikZ externalization is enabled and safe, CorTeX compiles figures as separate jobs. TikZ's own content check then allows an unchanged figure to be reused after a text-only edit. Several figure jobs can run together when the device has enough memory.

Not every figure can be separated safely. Overlays and some custom environments need the full document context. CorTeX detects these cases and returns to a complete compile. It does the same after a failed figure job.

A few helper tools still use a server#

Some bibliography and index tools cannot run in the browser. When a document needs Biber or Xindy, CorTeX sends only that stage's required files to an isolated service. The main TeX passes still run locally, and CorTeX can reuse identical helper work. Compile and preview LaTeX explains how to select an engine and inspect these stages.

Those bounded helper inputs may contain bibliography, index, or necessary source data. They are the exception to the ordinary browser-local typesetting path; project files are not sent to a helper stage that the document does not request.

A fast path must still produce the right PDF#

Every optimization has a fallback to a complete compile. Cached files remain separate for each TeX environment. CorTeX reuses a result only when its source, required files, engine, and environment still match. An older compile cannot replace a newer preview. Correctness is a requirement for every fast path, not something traded away for speed.

What controlled measurements show#

An internal in-app worker trace on September 3, 2026 used a 24-page article on the qualified tl2026-20260826-4f5a814 profile. Compatible checkpoint resumes took roughly one tenth of the compiler time of that trace's full compile. The record did not preserve the browser version, device CPU and memory, or cache warmth needed to reproduce its absolute times, so it is mechanism evidence—not an end-user benchmark or speed promise. It also measured compiler work, not page load or the first painted PDF page. Results vary with the document, browser, device, cache, and network.

CorTeX separately measures compiler readiness, PDF production, and the first displayed PDF page. Its build limits the compiler code in the initial workspace download, so compiler speed does not make the editor slower to open.

What you may notice while writing#

The first compile may still take time, especially in a new browser or a file-heavy project. Browser compilation uses your device, so a large paper may compile more slowly on an older or low-memory computer. CorTeX limits parallel work on smaller devices and uses a complete compile whenever a shortcut is unsafe.

You can compare the paths yourself. Open a temporary LaTeX project, wait for the first PDF, change one sentence near the end, and watch the next compile. Then change a package in the preamble and compare the complete path. Your times will differ, but the cold-to-warm distinction should be visible.

Frequent setup, label, or citation changes can require more full runs, as can rebuilding many complex figures. For practical advice, see Keep LaTeX preview fast and Split a LaTeX project into files.

When comparing your own edits, record whether setup, source dependencies, or figures changed. That context makes a timing useful and helps the preview-speed guide identify the next practical check.