¿Cuándo dejar de optimizar la velocidad y centrarse en el contenido?
Optimizar la velocidad de una página web es importante, pero no todas las mejoras tienen el mismo valor. Llega un momento en el que reducir unas pocas milésimas de segundo deja de aportar beneficios perceptibles y conviene dedicar los recursos a mejorar el contenido, la experiencia de usuario y la conversión.
La optimización técnica debe estar al servicio de las personas. Si una página ya carga en menos de un segundo, probablemente el usuario no notará una mejora adicional por cambiar el orden de una fuente, retrasar unos milisegundos un archivo JavaScript o reprogramar una animación.
El límite práctico de la velocidad web
La velocidad influye en la experiencia de usuario y forma parte de los aspectos que Google recomienda cuidar en cualquier sitio web. Sin embargo, tener buenas métricas de rendimiento no garantiza por sí solo mejores posiciones: Google evalúa diferentes señales y la experiencia de página va mucho más allá de los Core Web Vitals.
Los principales Core Web Vitals son:
- LCP, que mide el tiempo que tarda en mostrarse el contenido principal. Google recomienda un valor inferior a 2,5 segundos.
- INP, que evalúa la capacidad de respuesta de la página y debería situarse por debajo de 200 milisegundos.
- CLS, que mide los cambios inesperados en el diseño y debería ser inferior a 0,1.
Estas métricas son útiles para detectar problemas reales. Pero también es necesario aplicar criterio. No tiene mucho sentido invertir días de trabajo para pasar de una carga de 0,8 segundos a otra de 0,7 si ese esfuerzo impide mejorar una página con un contenido mediocre, una mala navegación o una intención de búsqueda mal resuelta.
La pregunta no debería ser únicamente «¿podemos hacer que cargue más rápido?», sino también:
- ¿La mejora será perceptible para el usuario?
- ¿Afectará a los Core Web Vitals?
- ¿Mejorará la conversión?
- ¿Liberará recursos para otras páginas?
- ¿Compensa el tiempo y el coste de implementarla?
El problema de optimizar código ajeno
Uno de los mayores desafíos del trabajo de performance aparece cuando hay que revisar código creado por otros equipos. Cada programador desarrolla sus propios patrones: estructuras repetidas, librerías favoritas, formas concretas de organizar funciones y soluciones que reutiliza de un proyecto a otro.
Cuando se trabaja durante mucho tiempo con el mismo equipo, esos patrones se vuelven fáciles de reconocer. También se identifican rápidamente aquellos que generan problemas de rendimiento:
- Librerías completas para resolver una función pequeña.
- Scripts cargados en todas las páginas aunque solo se utilicen en una.
- Código duplicado.
- Dependencias antiguas que nadie se atreve a eliminar.
- Animaciones innecesarias.
- Funciones que bloquean el hilo principal.
- Archivos JavaScript que se cargan antes de que sean necesarios.
El problema es que detectar un patrón ineficiente no significa que el equipo vaya a cambiarlo. En muchos proyectos, el código no se mantiene así por desconocimiento técnico, sino por costumbre, presión de plazos o falta de presupuesto para refactorizarlo.
Decir que una parte del código está mal diseñada suele ser insuficiente. El equipo puede entender la explicación y, aun así, continuar trabajando de la misma manera en la siguiente página.
Una librería de 1,5 MB en cada proyecto
Un ejemplo especialmente llamativo es el de una empresa de programación que utilizaba una librería propia de JavaScript de aproximadamente 1,5 MB.
La librería contenía funciones desarrolladas y utilizadas en proyectos anteriores. Con el tiempo se había convertido en una especie de almacén general: cada nueva web incorporaba todo el código para evitar que los programadores tuvieran que buscar o reconstruir una función cuando la necesitaran.
El problema era evidente. En algunos proyectos la librería apenas se utilizaba y, en otros, buena parte del código permanecía sin ejecutar. Sin embargo, el archivo completo se añadía de forma sistemática a cada sitio web.
Enviar JavaScript que no se necesita tiene varios costes:
- Aumenta el número de bytes que el navegador debe descargar.
- Compite con el HTML, las hojas de estilo, las imágenes y las fuentes.
- Obliga al navegador a analizar, compilar y ejecutar código innecesario.
- Puede retrasar la interacción del usuario.
- Incrementa el uso de memoria y la actividad del hilo principal.
Herramientas como Lighthouse pueden identificar archivos con una cantidad significativa de JavaScript no utilizado, mientras que la pestaña Coverage de Chrome DevTools permite analizar qué parte del código se ejecuta realmente durante la carga.
Desde el punto de vista técnico, la solución podría pasar por dividir el código, aplicar carga diferida, eliminar funciones obsoletas o generar bundles específicos para cada página. Pero la solución técnica no siempre es la solución organizativa.
Si el equipo considera que revisar su librería implica «gastar» horas que no estaban presupuestadas, el problema continuará. En ese contexto, el optimizador puede documentar el impacto, proponer alternativas y priorizar las mejoras más rentables, pero no siempre puede cambiar la cultura de desarrollo.
No todo se arregla con más optimización
La optimización de rendimiento tiene un límite práctico. Después de eliminar recursos innecesarios, comprimir imágenes, mejorar la caché, reducir el JavaScript y resolver los problemas graves de renderizado, llega un momento en el que las siguientes mejoras son marginales.
Es posible seguir ajustando detalles:
- Cargar una fuente antes que otra.
- Retrasar la ejecución de un script.
- Reordenar una animación.
- Cambiar ligeramente el momento de aparición de un elemento.
- Reducir unas pocas décimas el tiempo de renderizado.
Estas acciones pueden ser útiles en páginas con problemas concretos, especialmente en dispositivos lentos o conexiones deficientes. Pero no deberían convertirse en un objetivo permanente si la experiencia ya es rápida y estable.
Una auditoría de rendimiento debe terminar con una lista priorizada, no con una obsesión por alcanzar una puntuación perfecta. La métrica debe ayudar a tomar decisiones, no sustituirlas.
Trabajar con programadores diferentes
Una de las ventajas de trabajar con nuevos equipos de desarrollo es que no repiten necesariamente los mismos patrones que el optimizador está acostumbrado a revisar.
Eso obliga a analizar cada proyecto desde otra perspectiva. En lugar de aplicar siempre las mismas correcciones, es posible descubrir:
- Una arquitectura más sencilla.
- Una forma más eficiente de cargar los recursos.
- Menos dependencias.
- Componentes mejor aislados.
- Soluciones que evitan JavaScript innecesario.
- Nuevas oportunidades para mejorar la accesibilidad y la experiencia móvil.
La experiencia del optimizador es valiosa, pero también puede generar sesgos. Si solo revisa proyectos construidos con las mismas herramientas y por los mismos equipos, corre el riesgo de buscar siempre los mismos problemas y aplicar siempre las mismas soluciones.
A veces, un código diferente permite encontrar una solución mejor que la simple corrección de los patrones habituales.
Después de la velocidad llega el contenido
Una vez resueltos los problemas técnicos importantes, el siguiente paso natural son los contenidos. Una página rápida que no responde a lo que busca el usuario seguirá teniendo dificultades para posicionarse y convertir.
En la era de la inteligencia artificial, publicar contenido correcto pero genérico ya no es suficiente. Los contenidos que pueden destacar deben aportar una combinación de:
- Información original.
- Experiencia real.
- Una respuesta clara a la intención de búsqueda.
- Ejemplos concretos.
- Una estructura fácil de consultar.
- Un punto de vista propio.
- Información adicional que ayude al lector a tomar una decisión.
La inteligencia artificial puede acelerar la investigación, la redacción y la organización de ideas, pero no sustituye automáticamente la experiencia ni la capacidad de aportar algo nuevo. Si todas las páginas responden de la misma manera, el usuario no tendrá motivos para elegir una sobre otra.
Por eso, después de optimizar el código conviene revisar preguntas más importantes:
- ¿El contenido responde realmente a la consulta?
- ¿Aporta información que no aparece en los resultados habituales?
- ¿Incluye datos, ejemplos o casos prácticos?
- ¿Está escrito para personas o solo para captar tráfico?
- ¿Ayuda al lector a avanzar hacia una acción?
- ¿Amplía la intención de búsqueda sin desviarse del tema?
La mejor estrategia es priorizar
La velocidad web sigue siendo una parte importante del SEO técnico, pero debe abordarse con sentido práctico. Primero hay que resolver los problemas que afectan claramente a la experiencia: páginas lentas, JavaScript excesivo, cambios de diseño, bloqueos de interacción o recursos que no deberían cargarse.
Después, hay que medir el impacto real de cada cambio. No todas las mejoras técnicas tienen el mismo valor y una puntuación perfecta en una herramienta no es el objetivo final.
Cuando una web ya funciona con rapidez, el mayor crecimiento puede encontrarse en otro lugar: mejores contenidos, una arquitectura más clara, una navegación más útil y una respuesta más completa a las necesidades del usuario.
Optimizar una página de 1,5 segundos a 0,9 puede ser una gran mejora. Intentar pasar de 0,8 a 0,7 puede ser irrelevante si, al mismo tiempo, el contenido no ofrece ninguna razón para quedarse.
Bibliografía:
- Google Search Central. “The role of page experience in creating helpful content”
https://developers.google.com/search/blog/2023/04/page-experience-in-search - Google Search Central. “Page experience”
https://developers.google.com/search/docs/appearance/page-experience - Google Search Central. “Understanding Core Web Vitals and Google search results”
https://developers.google.com/search/docs/appearance/core-web-vitals - Chrome for Developers. “Remove unused JavaScript”
https://developer.chrome.com/docs/lighthouse/performance/unused-javascript - web.dev. “Remove unused code”
https://web.dev/articles/remove-unused-code