Qué debe tener un frontend profesional y cómo estructurarlo

Un frontend no es «la parte bonita»

Para el usuario de su empresa, el frontend es el producto: ahí se pierde o se gana la cotización, el alta o el pago. Y sin embargo es de lo que menos se audita. Un sistema puede tener un backend impecable y un frontend que nadie puede mantener, que no se lee bien en un celular, que Google no entiende o que se rompe cada vez que cambia la marca.

Esta es la lista de lo que, a nuestro juicio, debe tener un frontend profesional, y por qué. No es una receta: es lo que conviene pedir a su equipo o a su proveedor, y cómo reconocer si lo tiene.

1. Componentes con una dirección, no una carpeta de «cosas»

Una interfaz profesional se construye con piezas pequeñas y reutilizables. La propia documentación de React lo plantea así: un componente debe ocuparse idealmente de una sola cosa, y si crece, se divide en subcomponentes.

Un vocabulario útil es el de Atomic Design (Brad Frost): átomos (botón, campo), moléculas (un campo con su etiqueta y su error) y organismos (un encabezado, un formulario completo). Lo extendemos con secciones y páginas cuando ayuda a gobernar el producto. Es una convención, no una ley. Lo que la vuelve valiosa es una sola regla: la dependencia fluye en una dirección. Una pieza básica no conoce las piezas de producto que la usan.

Y una disciplina que evita mucho gasto: abstraer tarde. Un patrón se vuelve componente compartido cuando ya se repitió y sus variantes se estabilizaron; abstraer antes suele costar más que un duplicado visible.

¿Sabe hoy qué pantallas cambian si mañana cambia el color principal de su marca?

2. Un sistema de diseño con tokens

Un token de diseño es, en la definición del grupo que trabaja su formato, información con un nombre legible: como mínimo, un par nombre y valor (por ejemplo, el color de texto principal). El principio es sencillo: el color, la tipografía y el espaciado no se escriben en el componente; se toman de un token. Cambiar la marca se vuelve cambiar un valor, no editar cada pantalla.

Una precisión honesta: el formato estándar de tokens del Design Tokens Community Group sigue siendo un borrador, y su propio texto pide no implementarlo todavía. Los tokens se pueden definir hoy en su sistema y exportarse cuando el estándar se estabilice.

3. Storybook, y qué se entrega con él

Un componente sin documentación es difícil de usar bien para quien no lo escribió. Storybook permite construir y revisar cada componente en aislamiento, con sus variantes y sus casos difíciles de alcanzar, y funciona como documentación que se genera a partir de las propias historias (su función de autodocumentación lo hace desde los metadatos del componente), de modo que se mantiene cerca del código; eso sí, vale lo que valgan las historias: deben reflejar el uso real. Para una empresa, lo importante es lo que recibe: un catálogo navegable que diseño, QA y negocio pueden abrir, y no una captura en un chat.

Cómo organizarlo para que sea un contrato —con jerarquía, estados y revisiones— lo explicamos aparte: Cómo estructurar un Storybook que sirva de contrato. Aquí solo la exigencia: un catálogo que depende de que alguien se acuerde de publicarlo se desactualiza; publíquelo automáticamente al aprobar cambios.

4. Pruebas en tres niveles, y por qué una sola no basta

• Unitarias y de componente (con Jest o su equivalente moderno), que comprueban lógica y comportamiento visible.
• De punta a punta (por ejemplo con Playwright), que recorren los flujos que pagan la cuenta: el alta, la cotización, el pago. Su guía de buenas prácticas pide probar lo que el usuario ve y no los detalles internos, y mantener cada prueba aislada de las demás.
• Accesibilidad y regresión visual. La captura comparada ayuda a detectar un cambio que nadie abrió, aunque la propia documentación de Playwright advierte que el renderizado varía según el sistema operativo, el navegador y el hardware, y por eso las referencias deben generarse en el mismo entorno donde se comparan.

Sobre accesibilidad, un límite que conviene decir en voz alta: según la documentación de Playwright, las pruebas automáticas detectan algunos problemas comunes, pero muchos solo se descubren con una revisión manual. Automatice lo que se pueda y reserve revisión humana, con teclado y lector de pantalla, para los flujos críticos.

El nivel que conviene exigir es WCAG 2.2 AA. Dos ejemplos concretos del estándar: el texto debe tener un contraste de al menos 4.5:1 (3:1 para texto grande), y los elementos que se tocan o se hacen clic deben medir al menos 24 por 24 píxeles CSS, salvo excepciones.

¿Cuántos de sus flujos críticos tienen una prueba que corre sola en cada cambio?

5. CI/CD del frontend: lo que se debe poder detener

El pipeline de un frontend es la forma de que la calidad no dependa de la buena voluntad de nadie. Como mínimo debe verificar estilo, tipos, pruebas y construcción, y revisar dependencias con vulnerabilidades conocidas (npm audit envía la descripción de las dependencias al registro y devuelve un reporte de vulnerabilidades conocidas; es un control útil, no un análisis de seguridad suficiente por sí solo). Cada paso puede detener la liberación; el detalle de cómo se arma un camino a producción está en Liberar sin miedo en su propia infraestructura.

Sobre el análisis de calidad, qué debe cumplir. La compuerta predeterminada de SonarQube Server, «Sonar way» (según su documentación actual; es la configuración de un producto, no una definición universal de calidad), pone cuatro condiciones sobre el código nuevo: sin problemas nuevos, puntos críticos de seguridad revisados, cobertura de al menos 80 % y duplicación de 3 % o menos. Lo valioso es la filosofía: no se trata de arreglar todo lo viejo, sino de no agregar deuda nueva. Y un matiz que nos importa: una compuerta apagada o que no se ejecuta no es lo mismo que una que pasa. Exija ver la corrida, no solo el color del tablero.

6. SEO y lectura por IA: que el contenido sea rastreable y verificable

Si su sitio es público, su contenido importante debe ser accesible para un buscador y, cuando es relevante, para asistentes de IA. Hay que verificarlo sobre el HTML que realmente se entrega y se renderiza, no suponerlo. Google recomienda títulos únicos y descriptivos y descripciones propias de cada página, y advierte que si el contenido importante queda oculto detrás de JavaScript, puede no entenderse. La guía de web.dev sobre estrategias de renderizado explica el compromiso: el renderizado estático al construir ofrece los mejores tiempos de respuesta, aunque escala mal con muchas URL únicas; el del lado del cliente exige vigilar el peso del JavaScript.

Sobre esa base, tres prácticas: datos estructurados en JSON-LD (el formato que Google recomienda por ser el más fácil de mantener a escala), una dirección canónica por página para evitar duplicados y, si hay varios idiomas, la indicación de las versiones alternas por idioma (son dos mecanismos distintos). Y una propuesta, llms.txt, que ofrece a los agentes un resumen del sitio en Markdown. No es un estándar oficial: es una propuesta abierta de la comunidad, y los distintos agentes de IA se comportan de formas distintas, así que no hay un requisito universal como el de los buscadores. La mejor condición es que estas revisiones sean parte de la construcción y no una lista que alguien recuerda al final.

7. Rendimiento: se mide con lo que vive el usuario

Google define tres señales de experiencia, evaluadas en el percentil 75 de las cargas de página, segmentadas entre móvil y escritorio. Se miden con el uso real de sus usuarios; una prueba en una sola máquina orienta, pero no sustituye esa medición:

• LCP (qué tan rápido aparece lo principal): 2.5 segundos o menos.
• INP (qué tan rápido responde a un toque o a una tecla): 200 milisegundos o menos.
• CLS (cuánto se mueve el contenido mientras carga): 0.1 o menos.

Dos ideas de ingeniería sostienen esas cifras. La primera, no cargar de entrada lo que no se usa de entrada: React permite dividir el código y cargar un componente solo cuando se necesita.

// Ilustrativo, tomado de la documentación de React (lazy + Suspense).
const VistaPrevia = lazy(() => import('./VistaPrevia.js'));

<Suspense fallback={<Cargando />}>
  <VistaPrevia />
</Suspense>

La segunda, no aplicar esa idea a lo que el usuario ve primero: según web.dev, nunca debe cargarse de forma diferida la imagen candidata a LCP, porque se retrasa justo lo que mide esa señal.

8. Seguridad: el navegador es territorio hostil

Todo lo que llega al navegador es público; ningún secreto vive ahí. Dos ideas centrales:

• XSS. React escapa por omisión lo que se pinta, pero ofrece una vía de escape, dangerouslySetInnerHTML, que su propia documentación llama peligrosa: con contenido no confiable es trivial introducir una vulnerabilidad. OWASP recomienda sanitizar con una librería especializada, y advierte que ninguna técnica sola previene el XSS.
• Defensa en profundidad. Una política de seguridad de contenido (CSP) restringe lo que el código de la página puede hacer (de dónde carga recursos y a dónde se conecta, entre otras cosas) y ayuda contra XSS y clickjacking. MDN es claro: no sustituye a la sanitización; se usa además de ella.

Y una regla simple de criterio: no deje en el navegador, legible por cualquier script, credenciales reutilizables ni datos sensibles. Y no olvide que la validación del cliente nunca sustituye a la del servidor: la autorización se decide siempre del lado del servidor.

9. Después de liberar: resiliencia y observabilidad

Un frontend profesional supone que algo va a fallar. Cada llamada a un servicio tiene sus estados de cargando, vacío, error y reintento, y un fallo se muestra, no se esconde detrás de una pantalla en blanco. Y alguien debe enterarse del error antes de que lo reporte el cliente: errores del navegador capturados con contexto mínimo y sin datos personales, y las señales de rendimiento de la sección 7 vigiladas con usuarios reales. Si el sitio carga etiquetas de analítica o de terceros, también son código: pesan en el rendimiento y deben estar dentro del presupuesto.

También conviene acordar qué se soporta: navegadores, dispositivos modestos y redes lentas. Un sistema de diseño, por último, necesita dueño, versiones y una forma de retirar componentes sin romper a quien los usa.

Qué evidencia pedir antes de aprobar

Para un comité, un frontend se aprueba con evidencia, no con una demostración. Pida: el catálogo de componentes publicado; el reporte de las pruebas de la última liberación, con su conteo leído del resumen; el resultado de la compuerta de calidad con la condición que falló, si falló; la revisión de accesibilidad con la parte manual; las señales de rendimiento con datos reales; y quién autoriza una excepción y cómo queda registrada.

Lo que casi todo equipo pospone

Dos cosas: las pruebas de punta a punta de todos los flujos críticos, y que una falla de accesibilidad detenga la publicación en lugar de solo avisar. Un control que no puede detener un cambio es una sugerencia. Lo decimos porque negarlo no lo arregla, y porque es justo lo que conviene preguntarle a cualquier equipo, incluido el suyo.

Cierre

Un frontend profesional no se reconoce por su apariencia el día del estreno, sino por lo que soporta después: un cambio de marca, un auditor, un celular modesto, un buscador, un atacante. Cuando eso falla, el costo no es técnico: son ventas perdidas, retrabajo y una auditoría difícil de superar. En Hábil somos expertos en esto. Construimos el frontend de su producto con componentes gobernados, sistema de diseño, pruebas, accesibilidad, rendimiento y seguridad revisados en cada cambio, y podemos empezar contrastando su recorrido digital prioritario con esta lista.