Rethinking Fast Terminals: Misconceptions and Proper Measurement in Zsh Optimization

A debate over Zsh optimization methods is heating up among users. It started with an article by Mijndert Stuij titled “Life is too short for a slow terminal,” which introduced settings to reduce Zsh startup time to 30ms and attracted many readers. However, shortly after, Stuij published a correction, admitting errors in measurement methods, evaluation of plugin managers, and choice of recommended plugins, offering a detailed self-critique.

This article synthesizes the key points of Zsh optimization based on that correction. Rather than simply pointing out mistakes, it extracts broader lessons about performance measurement and tool selection criteria.

Error in Measurement Target

The core issue with the original article was its method of measuring startup time. Stuij had measured using the following command:

$ for i in {1..5}; do /usr/bin/time zsh -i -c exit; done

This command measures the total time to start an interactive shell and immediately exit. While many engineers would think of this as the first benchmark, as the tool zsh-bench points out, it is a metric that differs from the performance users actually experience.

What users wait for is the time until the prompt appears, the time until the first command executes, and subsequent delays per keystroke. These values are independent of total startup time. Depending on the configuration, a shell with a slower startup can feel faster in practice.

zsh-bench measures these experiential metrics. Specifically, it measures four items: first prompt display time, first command execution time, command latency, and input latency. Stuij himself stated that if he were to rewrite the measurement section, he would recommend zsh-bench.

More importantly, there is a mechanism called “instant prompt.” This displays a cached prompt immediately upon shell launch, allowing input without waiting for .zshrc to fully load. With this mechanism, the absolute value of startup time becomes almost irrelevant. Whether a shell takes 30ms or 300ms, with instant prompt the perceived startup time is nearly zero.

Misunderstanding of Plugin Managers

The original article generalized that plugin managers “add overhead” and criticized them for “performing dependency resolution at startup.”

Stuij acknowledged that he had extended claims applicable only to specific implementations to the entire category. For example, antidote compiles a list of plugins into a single static script. At startup, it simply loads the pre-generated file, with no resolution processing. This is essentially the same behavior as the “listing source lines” approach he had evaluated with his hand-crafted configuration.

In his correction, Stuij concluded that heavy frameworks performing dependency resolution at every startup are slow, but modern static-bundle managers are not slow and offer the advantage of automating update management.

Wrong Choice of Syntax Highlighter

Despite mentioning input latency in the article, Stuij recommended zsh-syntax-highlighting. This plugin re-highlights the entire buffer on every keystroke, causing noticeable lag on long command lines.

Stuij described this choice as “a little embarrassing.” He introduced Zsh-patina, a newer implementation worth noting, which uses a method that highlights only the differences, significantly improving performance on long command lines.

The Essence of Optimization

This series of corrections shows that shell optimization discussions depend on the choice of measurement metrics and an understanding of how tools work. Fixating on a single number like total startup time can lead to misjudging the actual user experience. It is essential to use tools that accurately capture the perceived experience, such as instant prompt and zsh-bench.

Moreover, the criticism that plugin managers add “overhead” is dangerous to generalize because implementations vary. Static-bundle types like antidote can be as efficient as or even more efficient than hand-written settings. As for syntax highlighters, the choice can drastically affect perceived speed.

Stuij’s correction is a good example of frankly admitting mistakes and actively incorporating community feedback. As he notes, “correction is more useful than defense,” this kind of self-critique provides valuable learning opportunities for readers.

Editorial View

Short-term Impact

This correction will likely prompt a review of benchmarking methods within the Zsh community. The shift from traditional time zsh -i -c exit measurements to evaluations considering zsh-bench and instant prompt will accelerate. Interest in modern tools like antidote and Zsh-patina is also expected to grow.

Long-term Perspective

Shell optimization discussions are likely to deepen from mere setting tuning to understanding tool choices and operating principles. Users will select tools based on knowing what they do internally, rather than using black-box optimization methods. This trend may extend to other development tools like different shells, editors, and terminal emulators.

A Question from the Editorial Team

In shell performance, should users truly prioritize absolute startup time, or perceived responsiveness? This question touches on a universal theme in software performance optimization. Are we losing sight of the actual user experience by becoming too focused on numerical targets?

References

• What I got wrong about fast terminals — Published June 8, 2026
• zsh-bench — Tool for measuring perceived performance