zload: el gestor de plugins zsh que carga en 0.45 ms

En pocas palabras: Cason Adams creó zload, un gestor de plugins Zsh que arranca en 0.45 ms sin forks de subprocesos, contra 185 ms de Oh-My-Zsh, según su propio benchmark publicado el 29 de septiembre de 2026. Es compatible con plugins OMZ vía prefijo omz:.

Cason Adams, desarrollador independiente, publicó el 29 de septiembre de 2026 zload, un gestor de plugins para Zsh escrito 100% en Zsh puro que arranca en 0.45 ms sin forks de subprocesos, según el benchmark que él mismo publicó. La promesa es simple: la misma terminal, sin la lentitud de Oh-My-Zsh.

zload es un gestor de plugins zsh que reemplaza a Oh-My-Zsh sin que tengas que abandonar tus plugins favoritos. Compila los plugins activos en bytecode .zwc mapeado en memoria vía mmap, ordena la carga de forma automática (completions primero, tema después, utilidades en el medio, highlighting al final) y elimina los subprocesos que disparan git o uname cada vez que abrís una pestaña nueva.

¿Por qué Oh-My-Zsh vuelve lenta la terminal?

Oh-My-Zsh tarda porque suma tres problemas de arquitectura al mismo tiempo, según describe Adams en su artículo. Cada uno por separado ya frena el arranque; juntos, explican por qué abrir una pestaña nueva puede sentirse como esperar que cargue una página en 3G.

El primero es lo que él llama “fork bomb de subshells”: cada vez que el framework corre $(git ...) o $(uname) durante la inicialización, dispara un proceso hijo del sistema operativo. Spawnear procesos es caro, sobre todo en macOS y WSL. El segundo es el parseo secuencial: los scripts .zsh están en texto plano y el parser de Zsh los procesa desde cero en cada arranque, sin compilar nada. El tercero es el acoplamiento monolítico: si querés el plugin de git o el de extract, tenés que clonar y mantener todo el framework, aunque uses solo un par de los plugins que trae.

¿Qué es zload y cuánto tarda en cargar?

zload es un gestor de plugins zsh diseñado con invariantes de performance estrictas: arranque en caliente por debajo de 0.5 ms, cero forks de subprocesos y compilación automática a bytecode. Sourcear zload junto con 10 plugins activos toma 0.45 ms, según el benchmark en macOS con Apple Silicon publicado en el repositorio. Cubrimos ese tema en detalle en el origen de la convención que hizo famoso a Oh My Zsh.

¿Cómo logra eso? Bundlea y compila los plugins activos en wordcode nativo mapeado directo a memoria con mmap, en vez de forzar al parser a leer texto plano cada vez. También resuelve el orden de carga solo: completions primero, temas y prompts después, utilidades en el medio, syntax highlighting y autosugerencias al final. Vos no tenés que pensar en el orden del array de plugins, zload lo reordena.

¿Cuánto más rápido es zload frente a Antigen, Zinit y Oh-My-Zsh?

Con 10 plugins activos en macOS Apple Silicon, zload registró 0.45 ms y cero forks, mientras que Zinit llegó a 32.40 ms con 6 forks, Antigen a 68.20 ms con 14 forks y Oh-My-Zsh a 185 ms con 18 forks, según el benchmark publicado por Cason Adams.

Gestor de plugins	Arranque en caliente	Forks de subprocesos	Bytecode compilado
zload	0.45 ms	0 (cero)	Sí, nativo (.zwc)
Zinit	32.40 ms	6	Parcial
Antigen	68.20 ms	14	No, texto plano
Oh-My-Zsh	185.00 ms	18	No, texto plano

Ojo con un detalle: son cifras del propio autor del proyecto, no de una auditoría independiente. El README en GitHub muestra otra tabla con otros competidores (Antidote en 12 ms, Zinit Turbo en 28 ms, Oh-My-Zsh en 340 ms), lo cual sugiere que los números varían según qué plugins y qué máquina se usen para medir. Tomalo como una señal fuerte de que la arquitectura sin forks funciona, no como un benchmark reproducido por terceros.

¿Es compatible zload con los plugins de Oh-My-Zsh?

Sí, zload entiende de forma nativa el prefijo omz:, así que no necesitás tener Oh-My-Zsh instalado para seguir usando sus plugins. Declarás algo como omz:git o omz:plugins/docker en tu array de plugins y zload se encarga del resto. Más contexto en otro proyecto que también busca optimizar el entorno Linux.

Cuando ve ese prefijo, clona solo el repositorio de Oh-My-Zsh una vez, en ~/.local/share/zload/plugins/_omz, y provee shims livianos para las funciones helper que suele usar la gente, como current_branch o los decoradores de git en el prompt. También incluye automáticamente las dependencias necesarias, por ejemplo lib/git.zsh para que funcione omz:git, sin arrastrar el resto del framework que nunca ibas a usar.

¿Cómo migrar el .zshrc de Oh-My-Zsh a zload?

La migración consiste en tres pasos según la documentación oficial: clonar el repo, agregar una línea de source al inicio del .zshrc y declarar el array de plugins con sintaxis nativa de Zsh. Nada de instaladores pesados ni de reescribir configuraciones a mano.

Primero clonás con git clone --depth 1 https://github.com/casonadams/zload.git ~/.zload. Después sourceás ~/.zload/zload.zsh arriba de todo en tu .zshrc, antes de cualquier otra cosa. Por último declarás tus plugins en un array y se lo pasás a la función zload, algo como plugins=(omz:git omz:extract zsh-users/zsh-autosuggestions); zload "${plugins[@]}". Para los plugins pesados como nvm, podés sumar --on nvm,node,npm y que se cargue recién cuando invoques esos comandos; para syntax highlighting, --defer lo pospone hasta que el prompt ya se dibujó. Ya lo cubrimos antes en herramientas que priorizan la velocidad en Mac.

¿Te conviene migrar? Cuatro criterios antes de decidir

No todas las terminales se benefician igual de este cambio. Antes de tocar el .zshrc de la máquina de laburo, conviene cruzar estos cuatro puntos, que salen de lo que el propio proyecto documenta:

• ¿Cuántas terminales abrís por día? Si vivís con una sola pestaña abierta toda la jornada, la diferencia entre 0.45 ms y 185 ms no se siente. Si en cambio saltás entre paneles de tmux, sesiones SSH o proyectos todo el rato, la cuenta cambia.
• ¿Trabajás en macOS o WSL? El propio autor aclara que spawnear procesos es particularmente caro en esos dos entornos, así que ahí el ahorro de “cero forks” pesa más que en un Linux nativo ya optimizado.
• ¿Ya usás Zinit en modo turbo? Según la tabla del README, Zinit ya compila parcial y anda en el orden de 28-32 ms. Si eso ya te resulta imperceptible en el uso diario, el salto a zload va a ser menor que si venís de Oh-My-Zsh puro.
• ¿Cuántos plugins activos tenés? El benchmark mide 10 plugins simultáneos. Con dos o tres, cualquier gestor anda rápido; la ventaja de zload se nota más cuando la lista crece.

Ejemplo hipotético (ilustrativo, no un dato medido): pensá en alguien que administra servidores y abre, digamos, 40 terminales nuevas en un día de laburo, entre sesiones SSH y paneles de tmux. Con Oh-My-Zsh a 185 ms por apertura, esas 40 aperturas suman unos 7.4 segundos de espera acumulada en el día. Con zload a 0.45 ms, el total ronda los 18 milisegundos. La diferencia agregada en segundos absolutos es chica, pero se siente en la fricción de cada apertura individual, que es justamente el problema que el autor dice haber resuelto.

Si tu caso se parece más al de alguien que abre la terminal dos veces por día y no toca WSL ni sesiones remotas, es válido preguntarse si vale la pena el cambio ahora, o si conviene esperar a que haya más feedback de otros usuarios.

¿Qué está confirmado y qué no sobre zload?

Está confirmado que zload existe, es de código abierto bajo licencia MIT, y que su repositorio en GitHub documenta comandos como zload path, zload doctor --fix, zload lock y zload sync. También está confirmado que corrió una suite de 32 tests con ShellSpec, según el propio README del proyecto.

Lo que no está confirmado es el desempeño en configuraciones distintas a la del benchmark: Linux, WSL, o setups con decenas de plugins pesados. Tampoco hay una comparación hecha por un tercero independiente, así que antes de migrar en producción (tu laptop de laburo, ponele) conviene probarlo primero en una terminal aparte y medir vos mismo con algo simple como time zsh -i -c exit antes y después del cambio. Para más detalles técnicos, mirá guías para exprimir el hardware Apple en Linux.

Errores comunes al migrar de Oh-My-Zsh a zload

• Dejar restos del bloque viejo de Oh-My-Zsh: si no borrás las líneas export ZSH=... y source $ZSH/oh-my-zsh.sh, terminás cargando los dos sistemas a la vez y perdés toda la ganancia de velocidad.
• No usar –defer en syntax highlighting: declarar zsh-syntax-highlighting sin ese flag hace que el prompt espere a que cargue el plugin, cuando lo ideal es que aparezca después vía precmd.
• Clonar plugins a mano en vez de dejar que zload los gestione: genera rutas duplicadas y conflictos en el PATH que zload path ya resuelve con deduplicación automática.
• Esperar que zload traiga un prompt lindo de fábrica: es un cargador de plugins, no un tema. Si querés algo visual rápido hay que sumar por separado algo como zline o Powerlevel10k.

Preguntas Frecuentes

¿Qué es zload?

zload es un gestor de plugins para Zsh creado por Cason Adams, escrito 100% en Zsh puro, que compila los plugins en bytecode .zwc y elimina los forks de subprocesos durante el arranque de la terminal.

¿zload es compatible con los plugins de Oh-My-Zsh?

Sí. El prefijo omz: permite usar plugins como omz:git o omz:extract sin instalar el framework completo de Oh-My-Zsh, clonando solo el repositorio necesario una vez.

¿Necesito desinstalar Oh-My-Zsh para usar zload?

No hace falta desinstalarlo, pero sí borrar las líneas que lo cargan en tu .zshrc, porque si quedan activas los dos sistemas corren en simultáneo y perdés la ganancia de velocidad.

¿Cómo instalo zload por primera vez?

Clonás el repositorio con git clone --depth 1 https://github.com/casonadams/zload.git ~/.zload, agregás source ~/.zload/zload.zsh al inicio de tu .zshrc y declarás tu array de plugins antes de abrir una terminal nueva.

Conclusión

zload ataca un problema real de cualquiera que use Oh-My-Zsh hace años: la lentitud acumulada de un framework pensado para otra época de terminales. La propuesta técnica, cero forks y bytecode mapeado en memoria, tiene sentido y el mecanismo omz: resuelve el miedo más común a migrar, que es perder los plugins de siempre.

Dicho esto, las cifras de la comparación las puso el propio autor, así que antes de reemplazar tu setup en la máquina de laburo conviene probarlo en una terminal aparte, cruzarlo con los cuatro criterios de arriba (cuántas terminales abrís, si estás en macOS o WSL, si ya usás algo como Zinit turbo, cuántos plugins tenés activos) y medir vos con tu propia combinación de plugins. Si el resultado se acerca a lo que promete el benchmark, la migración toma menos de un minuto y no perdés nada en el camino.

Fuentes

• Repositorio oficial de zload en GitHub
• Artículo original de Cason Adams en dev.to
• Documentación técnica de zload
• Repositorio de zline, el prompt compañero de zload