Las herramientas de desarrollo web que de verdad importan
Las listas de herramientas caducan rápido y rara vez ayudan a quien encarga un sitio web. Lo que perdura es el conjunto de *categorías* que usa un proyecto competente, y qué dice su ausencia sobre cómo irá el proyecto.
Esta guía cubre las categorías que importan, qué previene cada una y las preguntas que revelan si quien desarrolla trabaja así.
Las categorías no negociables#
No son preferencias. Un proyecto sin ellas acumula un riesgo que aflora en el peor momento, normalmente cuando algo se rompe y nadie puede decir qué cambió.
| Categoría | Qué previene | Pregunte |
|---|---|---|
| Control de versiones | Trabajo perdido, cambios inexplicables, no poder revertir | «¿En qué repositorio está el código y puedo tener acceso?» |
| Entorno de preproducción | Probar en producción | «¿Dónde reviso antes de que esté en línea?» |
| Despliegue automatizado | Una persona copiando archivos a mano un viernes a las seis | «¿Cómo llega un cambio a producción?» |
| Copias de seguridad | Pérdida total | «¿Cada cuánto, adónde y cuándo restauraron una por última vez?» |
| Monitorización de errores | Fallos silenciosos que nadie nota en semanas | «¿Cómo se enteran de que algo se ha roto?» |
| Monitorización de disponibilidad | Enterarse por un cliente | «¿A quién se avisa cuando el sitio se cae?» |
| Actualización de dependencias | Vulnerabilidades conocidas sin parchear | «¿Cómo se aplican las actualizaciones de seguridad?» |
La señal más potente es la respuesta a «¿cómo llega un cambio a producción?». Si implica arrastrar archivos a un cliente FTP, probablemente falte también todo lo demás de esta lista.
Herramientas de compilación y frontend#
Aquí es donde la moda se mueve más rápido y donde menos le importa a usted como cliente. Lo que importa es el resultado, no la herramienta que lo produjo.
- Un paso de compilación que minifique, empaquete y optimice recursos: el peso de página es un problema de conversión, no de pureza.
- Un flujo de imágenes que produzca formatos modernos y varios tamaños automáticamente. Las imágenes exportadas a mano nunca se mantienen al día.
- Un enfoque de CSS con sistema —variables, tokens, como se llame— en vez de acumular reglas puntuales.
- Solo el JavaScript que la página necesita. Un framework es una elección legítima para una aplicación y normalmente sobrecarga para un sitio de presentación.
- Soporte de navegadores definido por escrito. «Navegadores modernos» no es una especificación.
Herramientas de pruebas y calidad#
Las baterías de pruebas automatizadas completas rara vez se justifican en un sitio de marketing. Una pequeña dosis de automatización en las rutas que mueven dinero casi siempre sí.
- Comprobaciones automáticas solo en las rutas críticas: pago, registro, el formulario de contacto principal.
- Un presupuesto de rendimiento comprobado automáticamente: una cifra que hace fallar una compilación, no una esperanza.
- Análisis automático de accesibilidad en el canal de despliegue, sabiendo que detecta alrededor de un tercio de los problemas.
- Comprobaciones entre navegadores en los que su analítica muestra de verdad, no en una lista de todo.
- Un conjunto de contenido de preproducción que refleje longitudes reales, incluidas las incómodas.
Un presupuesto de rendimiento es la automatización de mayor valor para un sitio de contenido: sin él, el peso de página sube en silencio cada mes y nadie es responsable.
A qué debería tener acceso#
Independientemente de las herramientas que prefiera quien desarrolle, estas cuentas deberían estar a su nombre desde el primer día. Es muchísimo más fácil de arreglar en el arranque que cuando una relación ya ha terminado.
- Registrador del dominio, a nombre de su organización y con sus datos de facturación.
- Cuenta de alojamiento, con quien desarrolla añadido como usuario y no como propietario.
- Repositorio de código, con su organización como propietaria.
- Propiedades de analítica y Search Console.
- Cualquier servicio de terceros del que dependa el sitio: pago, correo, CDN, monitorización de errores.
- Una lista escrita de todo esto, guardada donde su equipo pueda encontrarla.
Preguntas frecuentes
¿Tengo que entender estas herramientas?
No, pero debería preguntar si existen y quién tiene acceso. Las preguntas de la tabla anterior las responde en una frase cualquier profesional competente, y la vacilación en las de despliegue y copias de seguridad es una señal real y no una cuestión de estilo.
¿Hace falta un framework de JavaScript?
Para una aplicación web, normalmente sí. Para un sitio de marketing o de contenido, normalmente no, y a menudo cuesta rendimiento sin beneficio, porque el navegador tiene que descargar y ejecutar un framework antes de mostrar texto que podría haber estado en el HTML. La pregunta correcta es qué problema resuelve en su sitio, y «es lo que usamos» no es una respuesta.
¿Qué es un presupuesto de rendimiento?
Un límite acordado —por ejemplo, menos de 200 KB de JavaScript y Largest Contentful Paint por debajo de 2,5 segundos en las plantillas principales— que se comprueba automáticamente y hace fallar la compilación al superarse. Funciona porque convierte el rendimiento de algo que todos consideran importante en algo que bloquea un despliegue.
¿Cómo sé si el sitio se está manteniendo?
Pida una nota mensual: qué se actualizó, qué se parcheó, cuál fue la disponibilidad y qué errores aparecieron. Si una cuota de mantenimiento no produce informe, es difícil distinguir el mantenimiento cuidadoso de la ausencia de mantenimiento, y normalmente se descubre durante un incidente.
herramientas desarrollo webstack desarrollo webcontrol de versionesentorno de preproducciónpresupuesto de rendimientocanal de despliegue
