Un sitio web que convierte se basa en elecciones técnicas precisas, no en una acumulación de funcionalidades. Hemos seleccionado diez características concretas que separan un sitio eficaz de una vitrina estática, enfatizando los puntos que la mayoría de las guías pasan por alto: conformidad con la accesibilidad, presupuesto de rendimiento móvil y mantenibilidad del código.
1. Presupuesto de rendimiento JavaScript en móvil
El rendimiento en escritorio a menudo oculta la realidad del terreno. En móvil, el tiempo de análisis y ejecución de JavaScript representa el principal cuello de botella, mucho más que el peso de las imágenes.
Recomendamos establecer un presupuesto máximo de JavaScript por página desde la fase de diseño. Cada script de terceros (analítica, chat, píxel publicitario) consume una parte de este presupuesto. Sin esta disciplina, la acumulación rápidamente supera el umbral aceptable y degrada la Interacción hasta el Siguiente Pintado (INP), la métrica de Core Web Vitals que ha reemplazado al FID.
Recuperar un sitio rápido después del hecho cuesta más que establecer los límites desde el principio. Este principio se alinea con los consejos prácticos en Zone Webmaster que insisten en la necesidad de estructurar las elecciones técnicas antes del desarrollo.
2. Conformidad con el RGAA y la Ley Europea de Accesibilidad
Desde el 28 de junio de 2025, la Ley Europea de Accesibilidad se aplica a varios servicios destinados a los consumidores: comercio electrónico, banca, transporte, telecomunicaciones, libros digitales. Las microempresas se benefician de exenciones, pero la mayoría de los sitios comerciales están afectados.
En Francia, el RGAA 4.1.2 y sus 106 criterios distribuidos en 13 temáticas constituyen el referente operativo. La conformidad no se limita a añadir atributos alt en las imágenes. Exige una auditoría estructurada, la publicación de una declaración de accesibilidad y, según el estatus de la organización, un plan plurianual de mejora.
Integrar la accesibilidad desde el diseño (elección de contrastes, estructura de formularios, navegación con teclado) divide el costo en comparación con una remediación tardía.
3. Arquitectura de información probada antes del maquetado
El ordenamiento de tarjetas (card sorting) y la prueba de estructura (tree testing) son dos métodos rápidos para validar la estructura de un sitio antes de abrir Figma. Observamos aún demasiados proyectos donde la estructura reproduce el organigrama interno de la empresa en lugar de reflejar los recorridos reales de los visitantes.
Una prueba de estructura con una decena de participantes es suficiente para identificar los callejones sin salida de navegación. El costo es insignificante comparado con una reestructuración del menú después de la publicación.
4. Interacción hasta el Siguiente Pintado como métrica clave
El INP mide la reactividad global de una página teniendo en cuenta todas las interacciones del usuario, no solo la primera. Un botón que tarda varios cientos de milisegundos en reaccionar después de un clic degrada directamente la percepción de calidad.
Optimizar el INP implica dividir el JavaScript en tareas cortas (yield to main thread), reducir los re-renderizados DOM innecesarios y utilizar content-visibility para las secciones fuera de pantalla. Este trabajo se realiza a nivel de código, no en un generador de páginas.
5. Estrategia de contenido orientada a la intención de búsqueda
Publicar contenido sin un mapeo de intención genera tráfico no calificado. Cada página debe responder a una intención precisa: informativa, transaccional o de navegación.
En la práctica, esto significa que la página de inicio no debe competir con las páginas de categorías en las mismas consultas. La canibalización entre páginas es uno de los problemas SEO más frecuentes en los sitios de empresas de tamaño medio.
6. Datos estructurados Schema.org desde la V1
Los datos estructurados no son un bonus post-lanzamiento. Implementar las etiquetas Schema.org (Organization, Product, FAQ, BreadcrumbList) desde la primera versión permite acceder a los resultados enriquecidos en los motores de búsqueda sin deuda técnica que recuperar.
El marcado debe ser validado con la herramienta de prueba de resultados enriquecidos de Google, y luego monitoreado en la Search Console para detectar errores tan pronto como aparezcan.
7. Política de caché y CDN adaptada al perfil de tráfico
Un sitio vitrina con contenido actualizado mensualmente y un sitio de comercio electrónico con un catálogo dinámico no tienen la misma estrategia de caché. Recomendamos definir los encabezados Cache-Control por tipo de recurso:
- Archivos estáticos (CSS, JS, fuentes): caché de larga duración con fingerprinting en el nombre del archivo para forzar la invalidación al desplegar.
- Páginas HTML: caché de corta duración o stale-while-revalidate para servir contenido fresco sin espera del lado del visitante.
- Imágenes de producto: caché intermedia a través de CDN con purga manual posible al cambiar el visual.
8. HTTPS, encabezados de seguridad y Content Security Policy
El certificado TLS es un requisito desde hace años, pero los encabezados de seguridad HTTP siguen ausentes en la mayoría de los sitios profesionales. Content-Security-Policy, X-Content-Type-Options, Referrer-Policy y Permissions-Policy reducen la superficie de ataque sin impacto en el rendimiento.
Un escaneo con una herramienta como Mozilla Observatory revela en segundos los encabezados faltantes. La configuración se realiza a nivel del servidor o del CDN, no en el CMS.
9. Sistema de diseño documentado en lugar de maquetas fijas
Un sistema de diseño (componentes UI reutilizables, tokens de color, reglas de espaciado) garantiza la coherencia visual a lo largo del tiempo. Sin él, cada nueva página o funcionalidad se desvía del diseño inicial.
El sistema de diseño también facilita la colaboración entre los equipos de diseño y desarrollo. Los componentes documentados reducen los idas y venidas y aceleran las iteraciones después de la publicación.
- Tokens de color y tipografía centralizados en variables CSS o design tokens JSON.
- Biblioteca de componentes versionada (botones, tarjetas, formularios) con estados interactivos documentados.
- Reglas de espaciado y de cuadrícula aplicadas a través de utilidades coherentes, no valores arbitrarios.
10. Plan de mantenimiento y monitoreo post-lanzamiento
Un sitio web es un servicio, no un entregable fijo. Sin monitoreo activo, las regresiones de rendimiento y las vulnerabilidades de seguridad se acumulan silenciosamente.
El plan de mantenimiento cubre al menos las actualizaciones del CMS y sus extensiones, la supervisión de los Core Web Vitals a través de la Search Console, y una auditoría de accesibilidad anual para mantener la conformidad con el RGAA. Prever un presupuesto recurrente para este mantenimiento evita las reestructuraciones completas cada tres años.
Estas diez características no funcionan de manera aislada. Un sitio rápido pero inaccesible perderá una parte creciente de su audiencia legal. Un sitio accesible pero no mantenido acumulará vulnerabilidades. El rendimiento de un sitio web se mide por la solidez de su eslabón más débil.
