TypeScript 7 Is “10x Faster.”

Project: https://github.com/yesimnoh/ts7-benchmark
Live dashboard: https://yesimnoh.github.io/ts7-benchmark/

TypeScript 7 is here.

And the number everyone remembers is 10x faster.

That is a big claim.

So, naturally, I wanted to make a small project and bother it with numbers. I built a benchmark that runs TypeScript 6 and TypeScript 7 against the same code, records the time and memory, and publishes the results to a live dashboard.

First, what changed in TypeScript 7?

TypeScript 6 and earlier ran on a compiler written in TypeScript and executed through JavaScript.

TypeScript 7 moves the compiler and language service to a native implementation written in Go.

This gives the compiler two important advantages:

• native execution
• shared-memory parallelism.

The official TypeScript 7 announcement reports major full-build improvements across large projects, with examples ranging from about 7.7x to 11.9x faster.

But “build performance” contains more than one thing.

There is parsing. There is type-checking. There is emitting output. There may also be multiple projects in a dependency graph.

My benchmark measures only one part:

tsc --noEmit

No JavaScript output. No bundling. No incremental build. No editor startup. Just type-checking.

That boundary matters.

The benchmark setup

I wanted the project to answer more than “Which command finished first?”

So I gave it four fixtures:

• Small synthetic: about 500 lines;
• Medium synthetic: about 15,000 lines;
• Large synthetic: about 120,000 lines;
• Real-world: the open-source validation library Zod, pinned to a specific commit.

The synthetic fixtures generate valid interfaces and generic functions at controlled sizes. They make the workload repeatable.

But synthetic code is still synthetic code. Real applications contain deeper generics, stranger inference paths, and decisions someone made at 4:57 p.m. on a Friday.

That is why I included Zod as well.

For each fixture, the benchmark runs:

• TypeScript 6 once as the baseline;
• TypeScript 7 with --checkers 1;
• TypeScript 7 with --checkers 4;
• TypeScript 7 with --checkers 8.

Each timing uses two warmup runs followed by hyperfine’s timed runs. Peak memory comes from GNU time -v.

The current results were produced with:

• TypeScript 6.0.3;
• TypeScript 7.0.2;
• a GitHub Actions Ubuntu runner;
• 4 CPU cores;
• about 16 GB of memory.

The machine is part of the result, not a footnote.

TypeScript 7 was 3–4x faster

Using TypeScript 7 with four checkers, the current mean results look like this:

Scroll horizontally to view every column on a small screen.

The synthetic fixtures stayed in a fairly narrow range.

Zod benefited more.

That makes sense. Zod relies heavily on complex generic types, so the type checker has more meaningful work to distribute. The important result is not that every codebase becomes exactly four times faster.

It is that the gain changes with the shape of the code.

Benchmarks enjoy context almost as much as developers do.

Then why does Microsoft report around 10x?

Because we measured different things.

The official figures cover full builds on large real-world repositories. My test isolates type-checking with --noEmit, uses one real-world fixture, and runs on a four-core CI machine.

So these two statements can both be true:

• TypeScript 7 can make full builds around 10x faster on some large projects.
• Type-checking alone was around 3–4x faster in my benchmark.

A benchmark number without its workload is just a confident-looking decimal.

The more useful question is not:

Is TypeScript 7 really 10x faster?

It is:

Faster at what, on which project, and on what machine?

--checkers: where the result became interesting

TypeScript 7 introduces the --checkers option.

It controls how many checker workers can process the program in parallel. The default is four.

Before TypeScript 7, type-checking was effectively one worker doing the job alone.

Now several workers can share it.

At least, until the hardware runs out of chairs.

The Zod results show this clearly:

Scroll horizontally to view every column on a small screen.

Moving from one checker to four helped.

Moving from four to eight did not.

The runner only has four CPU cores. Eight checker workers cannot all execute useful work at the same time, so the extra parallelism adds coordination and memory overhead instead of speed.

More workers do not automatically mean more performance.

Parallelism still has to negotiate with the machine underneath it.

On a runner with eight or more cores, the ceiling may move. That is a future benchmark I would like to add.

Speed has a memory bill

The checker count also changes memory usage.

For Zod, TypeScript 7 used approximately:

• 734 MB with one checker;
• 1,002 MB with four checkers;
• 1,222 MB with eight checkers.

TypeScript 6 used about 1,206 MB in the same fixture.

So one checker used much less memory, while eight checkers slightly exceeded the TypeScript 6 baseline without improving the execution time.

This is the trade-off. More checkers can reduce waiting time when enough cores are available. They also need more memory.

For a developer laptop, four may be a reasonable default.

For a memory-constrained CI runner, one may be the better deal.

The fastest setting is not always the cheapest setting.

Making the benchmark reproducible

I did not want this to become one screenshot from one successful run.

The repository pins both compiler versions and the exact Zod commit. It stores the raw timing and memory results, then merges them into a single summary.json file.

A scheduled GitHub Actions workflow runs the benchmark every week. It:

1. records the runner specification;
2. installs both compilers;
3. regenerates the synthetic fixtures;
4. runs every fixture and checker combination;
5. commits the new results;
6. deploys the dashboard to GitHub Pages.

The numbers can change.

The method should not quietly change with them.

What this benchmark does not prove

There are still clear limitations.

GitHub Actions runners are shared virtual machines, so absolute timings contain noise. The ratios and trends are more useful than one millisecond value.

The synthetic fixtures stress code volume, but they cannot reproduce the type patterns of every application.

There is only one real-world project in the current suite. And again, this benchmark measures type-checking only. It says nothing directly about emit time, incremental builds, bundling, or editor responsiveness.

That is not a reason to ignore the result.

It is a reason to label it correctly.

So, is TypeScript 7 faster?

Yes.

Clearly.

In this benchmark, TypeScript 7 reduced type-checking time by roughly three to four times. On the real-world Zod fixture, four checkers produced the best result on a four-core runner.

The famous 10x number was not wrong.

It was answering a broader question.

My benchmark asked a smaller one:

If I isolate type-checking, how much faster is TypeScript 7 here?

The answer was 3–4x.

Not as loud as 10x.

Still fast enough to change the developer experience. And now there is a dashboard that can keep checking.

Official TypeScript 7 announcement: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

More to explore

We Already Have LLMs. Why Does Jev Exist?

17 Sept 2026

3 Frontend RBAC Quiz: Would Your Permission Check Pass?

05 Sept 2026

5 Minutes into Frontend RBAC

05 Sept 2026

[In Gold Coast] Whale watching with Sea World Cruises

15 Sept 2026