How to Speed Up Vitest Tests: A Dev’s Guide to Faster Feedback

If you’re shipping code multiple times a day, waiting on sluggish test suites feels like death by a thousand cuts. Every second counts when you’re iterating fast or running CI/CD pipelines at scale. Vitest, the Vite-native testing framework, is already lightning-quick, but there’s always room to squeeze out more performance. I’ve spent enough late nights debugging slow test suites to know that small tweaks can make a big difference.

Here’s a practical guide to speeding up your Vitest tests, whether you’re coding locally or running tests in a CI pipeline. These tips come from real-world experience and will help you cut latency, tighten feedback loops, and maybe even enjoy writing tests a bit more.

Why Fast Tests Are a Big Deal

Slow tests kill momentum. Here’s why shaving seconds off your test suite matters:

• Faster iteration: Get feedback in seconds, not minutes, so you can stay in the flow.

• Fearless refactoring: Quick tests mean you’re more likely to run them often, catching issues early.

• Happier devs: Less waiting, more coding. Nobody likes staring at a spinning CI wheel.

• Lower costs: Faster tests burn less compute time in CI, saving money for teams at scale.

For teams building developer tools, this isn’t just nice-to-have, it’s a competitive edge. Faster tests let you ship features quicker, delight users, and stay ahead of the pack.

1. Ditch Watch Mode in CI with --run

Vitest’s default watch mode is awesome for local dev, but it’s overkill in CI. It keeps watching files and spinning up an interactive UI, which wastes time and resources. Instead, use the --run flag to execute tests once and exit.

vitest --run

Pro tip: Add --silent to cut down on log clutter and make CI output easier to parse.

vitest --run --silent

2. Parallelize Tests (But Don’t Overdo It)

Vitest runs tests in parallel by default, which is great, but you can hit bottlenecks with CPU-heavy tests or ones that touch shared resources like databases or files.

Fine-Tune Parallelism

Control the number of threads with --threads or --maxThreads to match your CI environment’s CPU limits:

vitest --threads 4

This prevents your tests from fighting over resources and slowing everything down.

Isolate Expensive Tests

For tests that can’t play nice in parallel (say, ones writing to a shared file), use test.serial() to run them one at a time:

test.serial('writes to file safely', async () => {
  // Your test code here
});

3. Run Only What’s Changed with --changed

When you’re deep in a coding session, running your entire test suite for every change is overkill. Use --changed to test only files affected by your latest git changes:

vitest --changed

This is a lifesaver for big projects with thousands of test files. It’s like telling Vitest, “Hey, just check what I touched.”

4. Focus with test.only and test.skip

When you’re debugging or building a new feature, zero in on specific tests with test.only() or describe.only():

test.only('handles the happy path', () => {
  // Your test code here
});

Just don’t forget to remove those .only calls before committing—nobody wants to be the dev who skips half the test suite in CI.

5. Split Tests by File Type

If your codebase mixes frontend (React, Vue, etc.) and backend code, consider splitting test runs into separate Vitest processes with tailored configs:

vitest --include src/frontend/**/*.test.ts
vitest --include

This lets you parallelize better and tweak settings for each test type, like skipping heavy plugins for backend tests.

6. Streamline Your Vite Config

Since Vitest is built on Vite, your Vite config can make or break test performance.

Ditch Unnecessary Plugins

Strip out Vite plugins you don’t need for testing, like image loaders or legacy browser support. Conditionally load plugins based on the environment:

plugins: import.meta.env.MODE === 'test' ? [] : [vue(), someHeavyPlugin()]

Lean on Vite’s Cache

Vitest loves Vite’s caching. Ensure it’s enabled and persists across CI runs to avoid rebuilding everything from scratch.

7. Mock Slow Dependencies

Network calls, file I/O, or database queries can drag tests down. Mock them ruthlessly with Vitest’s mocking tools:

vi.mock('axios', () => ({
  default: { get: vi.fn(() => Promise.resolve({ data: {} })) },
}));

This keeps your tests fast and focused by avoiding real external calls.

8. Precompile TypeScript for Speed

Vitest uses esbuild to handle TypeScript, which is fast, but you can go faster by precompiling your code with tools like tsup or swc. Also, set up your tsconfig.json for transpile-only mode:

{ "compilerOptions": { "isolatedModules": true } }

This skips type checking during tests (run that separately in your IDE or CI).

9. Slim Down Test Data

Heavy test data factories or fixtures that hit real systems can quietly tank performance.

Optimize Factories

Keep factories lean with only the fields you need. Cache expensive setup steps to reuse across tests:

const cachedUser = createUser();

beforeEach(() => {
  // Reuse cachedUser instead of creating a new one
});

10. Hunt Down Slow Tests

Vitest can help you spot sluggish tests. Use the verbose reporter to see what’s taking forever:

vitest --reporter

Or set a --slow threshold to flag tests taking longer than, say, 500ms:

vitest --slow 500

Pipe this to --reporter json for easy integration with CI dashboards.

Bonus: CI/CD Hacks

If you’re using GitHub Actions, GitLab CI, or similar, try these:

• Cache aggressively: Save node_modules and Vitest/Vite caches between runs.

• Shard tests: Split tests across multiple nodes with tools like vitest-split or knip.

• Fail fast: Use --bail to stop tests on the first failure, speeding up feedback.

• Matrix testing: Run test suites in parallel across different environments.

Here’s a quick GitHub Actions example:

- name: Run Vitest
  run

Final Thoughts

Take an afternoon to profile your tests, split them smartly, and mock out slow dependencies. It’s not glamorous, but the payoff is worth it. Whether you’re a solo coder or leading a 200-person dev team, tighter feedback loops lead to better code and less frustration.

All of these changes can speed up your tests, but at a certain point, your hardware and execution environment play a role as well. BuildPulse Runners can help by running your GitHub Actions jobs 2x faster, at half cost.