PWA vs nativo en la práctica: cómo ofrecer rendimiento en cada uno

La discusión sobre "PWA o nativo" finaliza en el momento de tomar una decisión en la mayoría de los artículos. Pero para quienes construyen, la decisión es sólo el comienzo. Elegir la plataforma adecuada y ejecutarla mal produce el mismo resultado que elegir la incorrecta: un producto lento que el usuario abandona.

He visto PWA rápidas y PWA muy lentas. He visto aplicaciones nativas fluidas y aplicaciones nativas estancadas. La plataforma no garantiza el rendimiento; garantías de ejecución. Y cada enfoque tiene sus propios puntos de falla, sus propios obstáculos y sus propias prácticas de atención.

Este texto es para aquellos que ya lo han decidido y ahora necesitan cumplirlo. En lugar de comparar PWA y nativo en abstracto, me ocuparé de cómo mantener el rendimiento de cada uno en la práctica, dónde tiende cada uno a atascarse y qué hacer para que la velocidad llegue al usuario y se mantenga.

El rendimiento es lo que siente el usuario, no lo que muestra el gráfico

Antes de cualquier técnica, conviene alinear lo que importa. El rendimiento, para el usuario, no es un número de referencia. Es la sensación de que la aplicación responde. Es ver algo útil rápidamente, tocarlo y obtener una respuesta, no esperar con la pantalla congelada.

Esta distinción cambia la forma en que trabajamos. Optimizar métricas internas que el usuario no nota es un desperdicio. Optimizar el tiempo hasta la primera interacción útil, la fluidez de las respuestas y la ausencia de caídas es lo que retiene.

Tanto en PWA como en nativo, el gobernante es la percepción. Las técnicas cambian, pero el objetivo es el mismo: que el producto luzca rápido allá donde mire el usuario. Quien persiga eso, y no el bonito número, obtendrá mejores resultados.

En la práctica, ofrecer rendimiento en una PWA

El talón de Aquiles de PWA es el peso de la red. A medida que se ejecuta en el navegador, todo lo que carga, scripts, estilos, bibliotecas, pasa factura en el tiempo de apertura. El error más común es acumular dependencias hasta que la aplicación se ralentiza sin que nadie se dé cuenta de cuándo sucedió.

La primera práctica es mantener la aplicación optimizada. Cargue sólo lo necesario para la primera pantalla y posponga el resto. Rompe el código para que el usuario no descargue de golpe lo que sólo utilizará más adelante. Cada kilobyte recortado de la carga inicial aparece como velocidad percibida.

El segundo es dominar el caché del trabajador del servicio. Esto es lo que hace que PWA se abra instantáneamente en visitas posteriores y funcione sin conexión. Pero el caché mal configurado sirve contenido antiguo o impide que lleguen actualizaciones. En la práctica, definir estrategias por tipo de recurso, agresivas para lo que no cambia, validadas para lo que cambia y probar la actualización en cada entrega, para no encerrar al usuario en una versión antigua.

El tercero es medir con datos reales y en condiciones reales: conexión lenta, dispositivo modesto. Lo que vuela en la máquina del desarrollador puede rastrearse en el teléfono celular del usuario. El rendimiento de PWA se mantiene cuando la medición ingresa al flujo de entrega, no cuando depende de la impresión.

En la práctica, ofrecer rendimiento de forma nativa

Native tiene una ventaja de rendimiento pura, pero esto crea una falsa sensación de seguridad. La trampa aquí no es el peso de carga, sino el uso descuidado de los recursos del dispositivo: memoria, batería, trabajo en el hilo principal.

La primera práctica es proteger la fluidez de la interfaz. En versión nativa, cualquier operación intensa realizada en el hilo que dibuja la pantalla provoca un bloqueo visible. El trabajo pesado, el procesamiento, el acceso a datos y la creación de redes deben salir de este hilo para que la interfaz siga respondiendo. Los bloqueos al desplazarse y tocar casi siempre provienen de aquí.

El segundo es cuidar la memoria y los recursos. Las aplicaciones nativas que pierden memoria o acaparan recursos se degradan con el uso y se vuelven más lentas cuanto más tiempo permanecen abiertas. En la práctica, esto requiere disciplina a la hora de liberar lo que no se utiliza y probar la aplicación en sesiones largas, no sólo en inicios rápidos.

El tercero es respetar el dispositivo. El consumo excesivo de batería y datos no aparece en una prueba breve, pero destruye la reputación de la aplicación en el uso real y provoca su desinstalación. Medir el comportamiento de la aplicación a lo largo del tiempo, en diferentes dispositivos, es lo que separa a la nativa que se ve bien en la demostración de la nativa que mantiene la calidad en la vida del usuario.

El error que los hunde a ambos

Hay una trampa común a ambos enfoques, y es cultural antes que técnica: dejar la actuación para el final.

Los equipos que tratan la velocidad como un ajuste final, una vez que el producto está listo, descubren que el bajo rendimiento suele deberse a la arquitectura, no a los detalles. No se puede "optimizar más adelante" lo que se construyó sin pensar en la velocidad. Las ganancias de último momento son pequeñas; Los problemas estructurales son grandes.

La práctica que evita esto es incorporar el desempeño como criterio continuo. Mida temprano, establezca un techo aceptable de carga y respuesta y trate la regresión del desempeño como un defecto, no como una mejora opcional. Tanto en PWA como en nativo, la velocidad que queda es la que se cuidó desde el principio, entrega tras entrega.

Otro error compartido es no medir en condiciones reales. El dispositivo del desarrollador es potente y tiene una buena red. No el usuario. El rendimiento que sólo existe en el entorno de quienes lo construyen es una ilusión.

El desempeño como disciplina, no como un milagro

La lección que se aplica a PWA y nativa es la misma: el rendimiento no es un efecto de la plataforma, es el resultado de una ejecución cuidadosa y continua. La mejor elección tecnológica, ejecutada sin disciplina, produce un producto lento. Una elección modesta, ejecutada cuidadosamente, puede ofrecer una experiencia excelente.

En PWA, la disciplina se centra en el peso y el caché. En lo nativo, en el uso y fluidez de los recursos. En ambos, el enemigo es la complacencia: asumir que es rápido porque lo es para ti y descubrir tarde que no lo es para el usuario.

Quienes construyen para otras personas necesitan medir cómo experimentan el producto, no cómo aparece en el entorno de desarrollo controlado. Esta humildad, probar en el peor dispositivo, en la peor conexión, es lo que separa los productos que la gente usa de los que desinstalan.

La decisión entre PWA y los asuntos nativos. Pero la ejecución es igualmente importante y es donde la mayoría de los productos ganan o pierden. El desempeño es un trabajo diario y no existe una plataforma que pueda reemplazar este trabajo.