LaTeX editors: from edit to preview.
We measured the same synthetic projects in Tutki, Overleaf Free, TeXPage Free and CoCalc Free. Here are the warm-edit results, including the trials that did not produce an updated preview.
Two runs, four editors
Tutki and Overleaf were measured together on September 12. We added TeXPage and CoCalc on September 14–15, including edits visible on page 123 of a thesis. These dates use London time. We have not rerun Tutki and Overleaf alongside the additions, so this is not a controlled four-product comparison and we calculate no new speed ratios.
Tutki, Overleaf and TeXPage compiled automatically. CoCalc used a digit keypress followed by its Shift+Enter build shortcut. Its timings include that action. Tutki, Overleaf and TeXPage used pdfLaTeX with TeX Live 2026; CoCalc used pdfLaTeX with TeX Live 2025/Debian.
Results
Median seconds to a verified updated preview, followed by the observed minimum–maximum range. Counts show successful edits out of ten planned trials. A case stops at its first timed failure; the remaining edits are unattempted.
194 verified previews and 6 timed failures across both runs. Medians describe successful trials only. A small or incomplete sample is not equivalent to ten successful edits, and its median does not include failures as fabricated durations.
What we measured
Elapsed time from a keyboard edit to a changed, visible target-page PDF canvas, followed by two animation frames. The expected new marker must be present in that page’s text layer for competitor trials; Tutki’s downloaded PDFs were independently checked for the marker and page count. This approximates presentation, not physical screen scan-out.
The timer includes application scheduling, saving, transport, compilation and rendering, including Tutki’s 400 ms automatic compile delay. These are warm edits with reusable build state. Project setup, compiler provisioning and recovery are excluded. The page-123 case changes the thesis footer marker and verifies the updated last page, rather than the first page.
Failures and first builds
Overleaf’s bibliography setup and subsequent timed edit hit its compile limit. CoCalc reached the harness’s 75-second preview deadline in the plotting, vector, bibliography and page-123 cases. A preview deadline means the requested output was not observed in time; it does not establish a product-enforced compiler timeout. We retained the slow successful trials as well as the failures.
TeXPage’s page-123 trial also reached the preview deadline: the view had moved to page 100. An untimed scroll back to page 123 then revealed the updated marker without another edit or compile. The case did not keep the target page visible, so we record no successful visible-preview timing for it; this is not evidence of a compiler timeout.
Tutki’s initial bibliography build hit its 30-second compiler limit. A retry completed in 31.336 seconds end to end, followed by ten successful warm edits. TeXPage also displayed a 30-second Free-plan compile-timeout message during bibliography setup; a later compile succeeded and allowed ten warm trials. These results do not establish reliable first-build completion for that workload.
Conditions and sample size
- Headed Chrome 151 at 1440 × 900, on one machine and network, with no artificial throttling. Ordinary tools were running on the computer.
- The same synthetic source corpus was used throughout. Actual main.tex and refs.bib contents were verified; the page-123 case uses the same documented footer substitution in each editor.
- Edits replace a marker digit. Tutki and Overleaf used inserted text; the added editors used full digit key events. Each new edit followed the previous visible result without an added compiler-idle delay.
- The original five-edit blocks were counterbalanced: one Tutki block, two Overleaf blocks, then another Tutki block, with a separate bibliography timeout branch. Setup corrections meant the added products were run separately; do not treat the full expansion as counterbalanced.
- Tutki used a one-vCPU, 2 GB compiler VM in iad1, with shared read-only TeX Live storage and private project storage. The remaining app defaulted to lhr1. Of 60 warm builds, 58 used incremental uploads and two retained the full-source fallback.
Reading the landing-page chart
The bars show successful-preview medians from a zero baseline. The time scale changes with the selected project. A case with no successful preview has no bar and keeps its failure label and counts. Dates and compile methods are shown beside the chart; no percentage speedup is assigned to these separate measurement runs.
Limits of these results
These are small sequential samples from one browser, machine and network. They are not fleet percentiles, capacity guarantees, a regional survey or a controlled before/after experiment. Actual results depend on your project, network and build state. The suite does not establish a general startup time or isolate the effect of shared storage. TeXlyre and Papeeria were explored but remain qualification-only, without validated timing series.
Download the summarized results (CSV) · Download the results (JSON)