Qwik City: Bundles de Rendimiento Optimizado

Qwik City logra 28.60 kB en first-paint (42% menos que React) porque carga JavaScript bajo demanda, no en el primer clic. El total de 24 lazy chunks suma 44.92 kB. Eso no es un error de medición: es que Qwik no shipea la mayoría del código hasta que el usuario lo necesita.

¿Qué es Qwik City Port?

Qwik City Port es un proyecto que porte una aplicación portfolio completa a Qwik, un framework JavaScript que prioriza el lazy-loading de código. Viene siendo la entrada #7 en una serie de puertos donde se comparan frameworks midiendo el tamaño final del bundle. El equipo de sen-ltd (que mantiene el proyecto) levantó una portfolio app de referencia en GitHub, la compiló a Qwik, y lo comparó directamente contra React, Next.js, SvelteKit y otros.

Lo que rompió el formato habitual de la serie es que Qwik no se deja comparar con un solo número. Mientras React shipea 50 kB de JS en un único bundle, Qwik divide su código en 24 fragmentos separados que cargan bajo demanda (según dev.to/sendotltd). El primero llega en 28.60 kB, suficiente para que la página sea interactiva. El resto, 16.32 kB más, viaja con el usuario conforme hace cosas.

Los dos números de bundle explicados

Acá es donde la mayoría de la gente se confunde. Un framework tradicional te dice “mi bundle es 42 kB gzip”. Un número, listo. Qwik no puede hacer eso porque su arquitectura es literalmente “no shipar la mayoría del código en el primer clic”.

First-paint bundle: 28.60 kB. Ese es el JavaScript que viaja con el HTML inicial. Contiene el Qwikloader (aproximadamente 1 kB), las componentes renderizadas en servidor, y la serialización del estado. Nada más. Si el usuario abre la página y no hace nada, solo ese JavaScript se ejecuta. Eso te da una reducción del 42% contra React.

Total bundle: 44.92 kB. Ahí suman los 24 lazy chunks. Filtros, lógica de sorting, event handlers, todo lo que el usuario podría triggerear. Eso viaja con el usuario cuando interactúa, no al principio. Y aún así, el total sigue siendo 8% más chico que React.

Otros frameworks tienen números chicos porque mienten (no shipaen el hidrator, o vos tenés que verificar qué está incluido). Qwik dice dos números porque ambos son verdad y relevantes. Si le importa el Core Web Vital LCP, el primer número te interesa. Si querés saber el costo total de tu aplicación, el segundo. Tema relacionado: sin depender de APIs externas.

Resumabilidad: el cambio de paradigma que Qwik propone

Para entender por qué los números de Qwik se ven así, necesitás entender qué es resumabilidad. Olvidáte de hidratación.

La hidratación tradicional (React, Vue, Svelte) funciona así: el servidor renderiza HTML como string, el cliente recibe eso, carga TODO el JavaScript de la aplicación, re-ejecuta cada componente con el mismo estado que el servidor calculó, y recién entonces ata los event handlers. Es como si dijeras “renderizá esto que hago en el navegador también, pero solo para que el listener que metiste en el onClick funcione”.

La resumabilidad de Qwik es: el servidor renderiza HTML, pero también serializa todo el estado de cada componente directamente en el HTML como JSON. El cliente recibe eso, lo parsea, y cuando el usuario hace clic en algo, carga exactamente el JavaScript que ese click necesita. Nada más.

No necesitás re-ejecutar componentes que no vas a usar. Si la página tiene un dropdown, un filtro y una tabla, pero el usuario abre la página sin tocar nada, esos tres pedazos de código no se cargan. Cuando hace clic en el dropdown, se carga el dropdown logic. Después, el filtro. Después, la tabla. Uno a uno, bajo demanda.

Eso es resumabilidad. Retomás la ejecución exactamente donde la dejaste, sin replay.

Cómo funciona el lazy-loading granular en Qwik

El mecanismo es elegante. El servidor serializa el estado, el cliente tiene un Qwikloader diminuto (1 kB) que sabe qué component lanzar cuando vea un evento.

Triggers para cargar código:

• Click: Usuario toca un botón, link, input.
• Scroll: Elemento entra en viewport.
• Visible task: Componente está visible pero no interactúa (ej: carrusel de autoplay).

Cuando triggereas uno de esos eventos, Qwik busca en el HTML qué componente está asignado a eso (usa atributos data), carga el chunk relevante, y lo ejecuta contra el estado ya serializado. Sin re-renderizado, sin replay de componentes padres, sin volver a inicializar todo. Sobre eso hablamos en consideraciones de privacidad en repositorios.

Eso es lo que mata el overhead. La mayoría de los framework JS envía el rendereador (React, Vue, etc), los componentes, el estado, y todo se re-ejecuta. Qwik envía solo lo que se usa. El framework en sí está optimizado para no Re-ejecutar.

Comparativa: Qwik vs React vs otros frameworks

La tabla muestra lo que está pasando. Qwik no compite en “tamaño de bundle compilado”. Compite en “cuánto código llega al navegador antes de que el usuario pueda interactuar”. Eso es diferente.

React es más lindo de desarrollar (imperativo, familiar). SvelteKit es compilado (menos runtime). Solid es reactivity fine-grained. Pero ninguno te deja cargar componentes bajo demanda sin arquitectura adicional.

Ventajas reales de performance frente a React

El -42% en first-paint no es un typo. Es reproducible. La portfolio app de referencia en GitHub (sen-ltd/portfolio-app-qwik) es exactamente la misma en todos los puertos: mismo número de componentes, mismo estado, mismo CSS. Solo cambia el framework.

Por qué Qwik gana tanto:

• No shipea el hidrator de React (6-10 kB).
• No shipea lógica de componentes que no se usan en el viewport inicial.
• No ejecuta ciclos de vida de componentes no interactivos.
• El estado ya está parseado en memoria (no necesitás JSON.parse nuevamente).
• Los listeners están apuntados directamente en el HTML (data attributes), no en un event registry gigante.

El impacto en Core Web Vitals es real. LCP (Largest Contentful Paint) mejora porque hay menos JavaScript bloqueando el parser. CLS (Cumulative Layout Shift) mejora porque el DOM no cambia mientras se ejecuta código de hidratación. INP (Interaction to Next Paint) mejora porque el event handler ya está cargado.

Caso de uso: la portfolio app de referencia

Para que veas cómo se estructura esto en código real, mirá el repo (github.com/sen-ltd/portfolio-app-qwik). Es una portfolio típica: hero, proyecto list, filtro por categoría, modal de detalles.

La modal de detalles? Lazy chunk. El filtro? Lazy chunk. El hero? En el first-paint, pero sin event handlers hasta que los necesites. Eso es resumabilidad estructurada. Lo explicamos a fondo en herramientas modernas de desarrollo.

El desarrollo no es tan diferente a React. Escribís componentes, declarás “qué cosa carga este JavaScript”, y Qwik empaqueta todo automáticamente. Pero el resultado es muy diferente: el bundle se divide en piezas que viajan con el usuario conforme las usa.

Cuándo usar Qwik City en tu proyecto

Usalo si: Tenés aplicaciones con mucho JavaScript (ecommerce, dashboards, news sites). Tenés usuarios en conexiones lentas (Qwik fue diseñado para eso). Tus Core Web Vitals importan más que la experiencia de desarrollo.

No lo uses si: Necesitás 200 librerías npm de terceros (Qwik es más joven, el ecosistema es más chico). Tu equipo usa React intensamente y cambiar es un costo. Trabajás con static sites donde Next.js es overkill (Astro te queda mejor).

Comparalo con alternativas:

• Next.js: Más maduro, más librerías, pero más bundle. Hidratación selectiva con dynamic(), pero no llega a los números de Qwik.
• SvelteKit: Compilado (mejor que React), pero no lazy-loading granular. Ideal si querés alternativa a Next sin tanto overhead.
• Solid Start: Reactivity fine-grained, bundle chico, pero similar a Svelte en madurez. No es resumabilidad.
• Astro: Zero JavaScript por defecto. Ideal si necesitás sitios estáticos con islas de interactividad. Pero si tu app es 70% interactiva, no sirve.

Errores comunes al evaluar Qwik

Error 1: Comparar bundle total como si fuera un solo número

Algunos decen “Qwik es 44 kB, React es 50 kB, qué diferencia hay”. La diferencia es CUÁNDO se carga. 28 kB en first-paint vs 50 kB es enorme para LCP. El resto llega después, cuando lo usás.

Error 2: Pensar que Qwik es “solo para performance”

No. Es para performance, pero también cambia cómo pensás arquitectura. Necesitás ser más intencional sobre dónde pones lógica. Algunos desarrolladores eso lo aman (fuerza buen design). Otros lo odian (te quita “magia”).

Error 3: Asumir que es más lento de desarrollar

No necesariamente. Si ya pensás en code-splitting, lazy routes y componentes, Qwik es natural. Si trabajás en “renderizá todo en el servidor y después hidratá”, te cuesta cambiar mentalidad.

Preguntas Frecuentes

¿Qué es la resumabilidad exactamente?

Es serializar el estado de componentes en el HTML durante el servidor y recuperar ese estado en el cliente sin re-ejecutar el código del servidor. El JavaScript se carga bajo demanda, solo cuando se necesita, en lugar de todo de una vez. Eso mata la hidratación. En plataformas de control de versiones profundizamos sobre esto.

¿Por qué Qwik necesita dos números de bundle?

Porque el primero es lo que llega en el primer clic (28.60 kB), y el segundo es todo lo demás que viaja bajo demanda (44.92 kB total). Otros frameworks envían un solo número porque shipaen todo de una vez. Qwik no, así que necesita dos números para ser honesto.

¿Qwik es más rápido que React en ejecución?

Depende. En time-to-interactive, sí, mucho más rápido. En velocidad de ejecución del código ya cargado, es similar (ambos son eficientes). La gracia de Qwik es que no ejecuta código innecesario, no que lo ejecute más rápido.

¿Cuándo empieza a brillar Qwik?

Cuando tu aplicación tiene 300+ kB de JavaScript. En ese punto, cargar todo en first-paint es un desastre de LCP. Qwik divide eso en 20-30 chunks, y solo el primero (15-30 kB) viaja al principio. El resto, bajo demanda.

¿Es Qwik City un reemplazo para Next.js?

No directamente. Next.js es más maduro, tiene más librerías, y la mayoría de los desarrolladores lo conocen. Qwik es una alternativa para casos donde performance es crítica y estás dispuesto a cambiar de framework. No es reemplazo, es opción diferente.

Conclusión

Qwik City Port muestra que resumabilidad funciona en el mundo real. 28.60 kB en first-paint no es un benchmark artificial con solo CSS: es una aplicación completa, con JavaScript interactivo, con estado, con eventos, portada desde cero a Qwik.

Lo interesante es que eso no es un tradeoff donde ganás performance pero pierdes experiencia de desarrollo. Es otra forma de pensar la arquitectura. Separás lo que se carga inmediatamente de lo que se carga bajo demanda. Eso hace que tu JavaScript sea más eficiente.

Si priorizás Core Web Vitals (y deberías, porque Google paga atención), y tu aplicación tiene mucho JavaScript, Qwik vale la pena evaluarlo. No es magia, es arquitectura pensada desde cero para lazy-loading. Y los números lo demuestran.

Fuentes

• Qwik City Port: Two Bundle Numbers — Dev.to
• Portfolio App Qwik — GitHub Repository
• Qwik Framework — Official Site
• From Static to Interactive: Why Resumability is the Best Alternative to Hydration — Builder.io Blog
• Qwik: The Answer to Optimal Fine-Grained Lazy Loading — Dev.to