Optimizar la velocidad de un sitio: un orden práctico de trabajo
El trabajo de velocidad tiene una forma de Pareto muy marcada: un puñado de arreglos explica casi toda la mejora en casi todos los sitios, y casi siempre son imágenes, respuesta del servidor y scripts de terceros.
Esta guía cubre en qué orden trabajar, cómo medir si un cambio ayudó y las optimizaciones que normalmente no compensan el esfuerzo.
Mida antes de cambiar nada#
Optimizar sin medir significa arreglar lo más fácil en vez de lo más lento. Dos mediciones y luego a trabajar.
- Consiga datos de campo de visitantes reales: el informe de Core Web Vitals en Search Console, o su propia monitorización.
- Ejecute una prueba de laboratorio en las tres plantillas más importantes, limitada a un móvil de gama media con 4G.
- Anote las cifras antes de empezar. Sin una referencia no puede saber si un cambio ayudó.
- Identifique el mayor recurso y la mayor petición bloqueante de cada plantilla.
- Anote el Time to First Byte aparte: si supera los 800 ms, ningún trabajo de frontend le salvará.
El orden que compensa#
Aproximadamente por mejora obtenida por hora de esfuerzo, para un sitio de contenido o presentación típico.
| Trabajo | Ganancia típica | Esfuerzo |
|---|---|---|
| Optimizar y dimensionar bien las imágenes | Grande | Bajo |
| Quitar scripts de terceros sin usar | Grande | Bajo; sobre todo es una tarea política |
| Activar caché y un CDN | Grande | Bajo |
| Arreglar CSS y JS que bloquean el renderizado | Medio a grande | Medio |
| Reducir el paquete de JavaScript | Medio a grande | Medio a alto |
| Arreglar consultas lentas de base de datos | Grande donde aplica | Medio |
| Optimizar la carga de fuentes | Medio | Bajo |
| Minificar y comprimir recursos de texto | Pequeño | Bajo; normalmente ya está activo |
| Microoptimizar selectores CSS | Insignificante | No compensa |
Imágenes: normalmente la mayor ganancia#
En casi todos los sitios las imágenes son la mayor parte del peso de página, y la mayoría se sirven varias veces más grandes de lo que se muestran. Es la mejora grande más barata que existe.
- Sirva WebP o AVIF; ambos tienen soporte amplio y suelen ser entre un 25 y un 50 % más pequeños que JPEG con calidad equivalente.
- Genere varios tamaños y use srcset con sizes para que los móviles descarguen archivos de tamaño móvil.
- Nunca sirva una imagen de 2000 px en un hueco de 400 px: este error concreto es extremadamente común.
- Cargue en diferido todo lo que esté bajo la línea de flotación, y nada por encima.
- Automatícelo en la compilación o en el CMS. Las imágenes optimizadas a mano dejan de estarlo la primera vez que sube una otra persona.
- Elimine los metadatos; el EXIF de cámara puede ocupar decenas de kilobytes por archivo.
La automatización es el punto clave. Una pasada de optimización puntual se degrada en meses según se añade contenido, y nadie lo nota hasta que el peso de página se ha duplicado.
Scripts de terceros y el servidor#
Son las dos áreas donde el problema suele ser organizativo más que técnico: nadie es dueño del gestor de etiquetas y nadie es dueño de la decisión de alojamiento.
| Problema | Qué hacer |
|---|---|
| Gestor de etiquetas con etiquetas desconocidas | Auditar cada etiqueta; borrar todo lo que nadie pueda justificar |
| Widget de chat cargando en todas las páginas | Cargar al interactuar, o solo donde haga falta soporte |
| Varias herramientas de analítica | Quedarse con una; cada una es un script completo y una conexión |
| Script de test A/B bloqueando el renderizado | Moverlo al servidor, o aceptar un parpadeo y cargarlo async |
| TTFB lento en alojamiento compartido | Añadir caché de página completa; subir de plan si persiste |
| Consultas de base de datos sin cachear | Cachear las costosas; añadir índices para las frecuentes |
| Sin CDN | Añadir uno: es el arreglo de latencia global más barato que existe |
Los scripts de terceros son la fuente más fiable de ralentizaciones inexplicables, porque cambian sin avisarle y están fuera de su proceso de despliegue.
Preguntas frecuentes
¿Cuál es un buen tiempo de carga?
Los objetivos útiles son los umbrales de Core Web Vitals más que una única cifra de carga: LCP por debajo de 2,5 segundos y Time to First Byte por debajo de 800 ms. El tiempo total de carga es una mala medida porque una página puede ser usable mucho antes de que termine cada recurso, e inutilizable mucho antes de eso en un dispositivo lento.
¿Un sitio más rápido aumenta las conversiones?
Por lo general sí, y el efecto es mayor donde las páginas están ahora lentas y los visitantes usan redes móviles. La ganancia de tres segundos a dos es mucho mayor que la de uno y medio a uno. Si su sitio ya es rápido, invierta el esfuerzo en contenido y claridad: el retorno es mejor.
¿Los plugins de caché lo resuelven todo?
Resuelven bien una cosa real —el trabajo repetido del servidor para la misma página— y pueden crear problemas nuevos, sobre todo con usuarios identificados, cestas y formularios. Además no hacen nada con imágenes sobredimensionadas ni con scripts de terceros, que suelen ser los problemas mayores. Útiles, no suficientes.
¿Merece la pena el renderizado en servidor por velocidad?
Si sus páginas hoy se renderizan solo en el navegador, sí: el renderizado en servidor o la generación estática eliminan un viaje completo antes de que aparezca el contenido, y de paso ayudan a la indexación. Si sus páginas ya son HTML servido, la pregunta no aplica: ya tiene el beneficio.
optimizar velocidad webvelocidad de páginarendimiento weboptimización de imágenescachécdn
