Cómo optimizar la velocidad web: guía para empresas

Para optimizar la velocidad de tu web, empieza por medir con datos de usuarios reales, localiza qué fase de la carga se retrasa (servidor, recursos o renderizado) y corrige primero lo que más pesa. Comprimir imágenes ayuda, pero rara vez es lo único que hay que hacer. En esta guía te explicamos el orden de trabajo que seguimos en una web corporativa o de ecommerce, qué umbrales conviene alcanzar y cuándo compensa pedir ayuda externa.

TL;DR

• Los umbrales de Google para una experiencia buena son LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, medidos en el percentil 75 de las visitas.
• Prioriza los datos de campo (usuarios reales) sobre las puntuaciones de laboratorio: Lighthouse sirve para diagnosticar, no para dar el veredicto.
• Antes de comprimir nada, mira el tiempo de respuesta del servidor (TTFB): si es lento, el resto de mejoras rinden poco.
• Tras un cambio, los datos de PageSpeed Insights tardan semanas en reflejarlo, así que no juzgues el resultado al día siguiente.
• Una web más rápida no garantiza el primer puesto, pero elimina fricción que cuesta visitas y conversiones.

Tabla de contenidos

• Qué significa realmente que una web sea rápida
• Paso 1: mide con datos de campo antes de tocar nada
• Paso 2: averigua qué parte de la carga falla
• Paso 3: empieza por el servidor y el hosting
• Paso 4: imágenes, fuentes y recursos del contenido principal
• Paso 5: JavaScript, CSS y terceros
• Un orden de prioridades que funciona
• Cómo lo vemos nosotros
• Cuándo conviene pedir ayuda profesional
• Qué hacemos en dobleO por la velocidad de tu web
• Preguntas frecuentes
• Fuentes

Qué significa realmente que una web sea rápida

“Rápida” no es un solo número. Google describe las Core Web Vitals como un conjunto de métricas que miden la experiencia real en tres facetas: velocidad de carga, interactividad y estabilidad visual. Cada una tiene su umbral:

Según la misma documentación de Google, una página cumple el estándar cuando el 75 % de las visitas alcanza el nivel bueno en las tres métricas a la vez. Es decir, no basta con que tu ordenador de oficina con fibra cargue la web en un segundo: lo que cuenta es la experiencia de la visita típica, incluida la del móvil con cobertura irregular.

Si quieres profundizar en cada métrica, tenemos una guía específica sobre Core Web Vitals y cómo mejorarlas y otra más básica sobre tiempos de carga y Core Web Vitals.

Velocidad y posicionamiento: expectativas realistas

La velocidad influye en el SEO, pero con matices. Google indica que alcanzar un estado “bueno” no garantiza posicionarse arriba: estas métricas son una base de calidad de experiencia, no un atajo. Perseguir una puntuación de 100 por obsesión suele ser mal negocio. El objetivo útil es que ninguna página importante (home, categorías, fichas de producto, landings de campaña) quede en zona roja.

Donde sí se nota casi siempre es en el negocio: una landing lenta encarece cada clic de pago y desperdicia el tráfico que has conseguido. Lo desarrollamos en nuestro artículo sobre cómo mejorar la tasa de conversión sin comprar más tráfico.

Paso 1: mide con datos de campo antes de tocar nada

El error más común es empezar a optimizar a ciegas. El orden correcto es medir, diagnosticar, corregir y volver a medir.

Datos de campo y de laboratorio

Los datos de campo provienen de usuarios reales y los de laboratorio de una simulación. Pueden divergir bastante por la red, el dispositivo y el comportamiento de cada visita. Por eso la guía de web.dev sobre medición de Web Vitals recomienda combinar ambos y dar prioridad al percentil 75 de los usuarios reales, usando herramientas como Lighthouse como apoyo para detectar problemas durante el desarrollo.

Qué herramienta usar para qué

• PageSpeed Insights: ofrece datos de laboratorio y de campo de una URL, tanto en móvil como en escritorio, con recomendaciones de mejora. Los datos de campo proceden del informe de experiencia de usuario de Chrome (CrUX) y se calculan sobre una ventana móvil de unas cuatro semanas, actualizada a diario.
• Search Console: el informe de Core Web Vitals agrupa las URL de tu sitio por estado, lo que te permite detectar plantillas problemáticas en lugar de páginas sueltas.
• Lighthouse en Chrome: útil para reproducir un problema concreto y comprobar si tu arreglo funciona antes de publicarlo.

No esperes resultados inmediatos

Si has mejorado la web y la puntuación no cambia, no es un fallo. Google explica en sus preguntas frecuentes de PageSpeed Insights que los datos no se actualizan en tiempo real: reflejan la experiencia de las últimas semanas. Anota la fecha de cada cambio y compara después de un ciclo completo.

Paso 2: averigua qué parte de la carga falla

Aquí está el cambio de enfoque que más resultados da. Optimizar el LCP se equipara a menudo con comprimir imágenes, pero según el análisis de web.dev sobre cómo optimizar el LCP, el peso del archivo no suele ser el cuello de botella principal. El retraso puede estar en cuatro sitios:

1. Tiempo hasta el primer byte (TTFB): el servidor tarda en responder.
2. Retraso en el inicio de la carga del recurso: el navegador descubre tarde la imagen o fuente principal.
3. Duración de la carga del recurso: aquí sí pesa el tamaño del archivo.
4. Retraso en el renderizado: algo (CSS, JavaScript) bloquea que el elemento se pinte.

Si aplicas la receta genérica sin saber cuál de las cuatro te afecta, el rendimiento de cada hora de trabajo cae rápido. Google recomienda además sopesar el coste de implementar cada regla frente al beneficio real en tu aplicación concreta, como señalan en las preguntas frecuentes de PageSpeed Insights: no todas las recomendaciones valen lo mismo en todas las webs.

Paso 3: empieza por el servidor y el hosting

Es la parte que más se olvida porque no se ve. Si el servidor responde tarde, el navegador no puede empezar a pintar nada. La propia guía de web.dev señala que, cuando el LCP es lento, conviene diagnosticar el TTFB: lógica de servidor lenta, cuellos de botella en la base de datos o falta de caché en el borde de la red suelen causar el retraso.

Como referencia práctica, la auditoría de Lighthouse sobre tiempos de respuesta del servidor falla cuando el navegador espera más de 600 ms por el documento principal. Si tu página supera esa cifra, antes de optimizar imágenes revisa:

• Caché de página y de servidor: servir una versión ya generada en lugar de construir la página con cada visita.
• Red de distribución de contenidos (CDN): acerca los archivos estáticos al visitante, algo relevante si vendes en España y también en Latinoamérica o Europa.
• Base de datos y consultas: en WordPress y en tiendas con muchos productos, las consultas pesadas y los plugins que las generan son un clásico.
• Versión de PHP y plan de hosting: un alojamiento compartido saturado limita cualquier otra mejora.

Rendimiento y seguridad van de la mano

Un sitio cargado de plugins antiguos o con el servidor mal configurado no solo va lento: también ofrece más superficie de ataque. El INCIBE lo trata en su dosier Protege tu Web, una buena referencia para revisar el alojamiento y el mantenimiento. Mientras limpias plugins, conviene revisar también qué scripts de analítica y marketing cargas, y que su uso cumpla el RGPD y la LSSI, un punto que en España no es opcional.

Paso 4: imágenes, fuentes y recursos del contenido principal

Una vez descartado el servidor, llega el turno de los recursos. Aquí sí funcionan las recomendaciones clásicas que repiten casi todas las guías:

• Formatos modernos como WebP o AVIF, con el tamaño real que se muestra en pantalla, no la foto original de 4000 píxeles.
• Carga diferida (lazy loading) para las imágenes que quedan fuera de la primera pantalla. La imagen principal (la que suele ser el LCP) no debe diferirse: al contrario, conviene que cargue cuanto antes.
• Dimensiones declaradas en el HTML para que el navegador reserve espacio y evites saltos de diseño que empeoran el CLS.
• Fuentes propias y limitadas: menos variantes de tipografía, y con una estrategia de carga que no deje el texto invisible.
• Vídeos incrustados: cargarlos solo cuando el usuario los pida, en vez de descargar el reproductor entero al entrar.

Tenemos una guía dedicada con ejemplos: cómo optimizar las imágenes de tu web.

Paso 5: JavaScript, CSS y terceros

El INP es la métrica donde más tropiezan las webs corporativas modernas, y casi siempre por exceso de JavaScript. Revisa:

• Scripts de terceros: chats, mapas de calor, píxeles de publicidad, pop-ups, widgets de reseñas. Cada uno compite por el hilo principal del navegador. Haz inventario y elimina lo que nadie consulta.
• Etiquetas en el gestor de etiquetas: con el tiempo se acumulan etiquetas que ya no sirven. Una auditoría de analítica ayuda a quedarte solo con lo que mide algo útil.
• CSS y JavaScript sin usar: temas y constructores visuales suelen cargar en todas las páginas código que solo usa una.
• Minificación y compresión: reducen el tamaño de HTML, CSS y JS, y la compresión del servidor (gzip o Brotli) lo complementa.
• Aplicaciones de una sola página (SPA): tienen particularidades al medir navegaciones internas; web.dev las recoge en su artículo sobre SPA y Core Web Vitals.

Un orden de prioridades que funciona

Cuando auditamos una web, ordenamos las tareas por impacto probable frente a esfuerzo. Este es un esquema orientativo, no una cifra garantizada:

Cómo lo vemos nosotros

En nuestra experiencia, la velocidad web se trata mal cuando se convierte en un proyecto técnico aislado. Una puntuación verde que no cambia las visitas, los leads o las ventas es un trabajo a medias. Por eso integramos la analítica web en todo lo que hacemos: antes de optimizar, definimos qué páginas generan negocio y qué métrica de usuario las perjudica, y después comprobamos con datos si el cambio ha servido.

También somos prudentes con las recetas universales. Cada web tiene su cuello de botella, y una landing de campañas de pago no se trabaja como una tienda con miles de referencias. Preferimos una metodología flexible: diagnóstico, cambios pequeños y medibles, y mejora continua. Y hay un punto que los clientes agradecen: si una optimización cuesta mucho y aporta poco, lo decimos y la dejamos fuera.

— Santiago

Cuándo conviene pedir ayuda profesional

Puedes resolver muchas cosas tú mismo: comprimir imágenes, quitar plugins que no usas, activar la caché. Pero hay situaciones en las que delegar sale más barato que insistir:

• El TTFB es alto y no sabes si el problema es el hosting, la base de datos o el tema.
• El INP no baja porque el JavaScript depende de un constructor visual o de un desarrollo a medida.
• La web carga bien en laboratorio y mal en campo, y no sabes por qué.
• Vas a rediseñar o migrar y quieres que la velocidad se contemple desde el principio, no como parche posterior.

También importa el contexto del diseño: una buena experiencia de usuario y una web rápida se refuerzan entre sí, como recoge este artículo sobre el papel del diseño web en la experiencia y la interacción. Y si tu web es un activo de captación orgánica, la velocidad es una pieza más de una estrategia SEO completa, como explica este repaso de SEO en marketing digital para startups. Nosotros además lo conectamos con la experiencia del visitante en nuestro artículo de SEO y UX.

Qué hacemos en dobleO por la velocidad de tu web

En dobleO combinamos diseño y desarrollo web, analítica web y marketing de buscadores SEO, GEO y PPC. Eso nos permite diagnosticar la velocidad desde el dato (qué páginas importan, qué métrica falla), corregirla en el desarrollo y comprobar el efecto en tráfico y conversión. Si quieres que revisemos tu caso, puedes contactarnos desde dobleo.com y te contamos por dónde empezaríamos.

Preguntas frecuentes

¿Cuánto debería tardar en cargar una web?

Google no fija un único tiempo total, sino umbrales por métrica: LCP de 2,5 segundos o menos para el contenido principal, INP de 200 ms o menos y CLS de 0,1 o menos. Se evalúan en el percentil 75 de las visitas reales. Úsalos como objetivo mínimo para tus páginas clave.

¿Por qué PageSpeed Insights me da una nota baja si mi web va bien?

Porque la nota de laboratorio simula un dispositivo y una red concretos, y los datos de campo reflejan visitas reales, que pueden ser muy distintas. Prioriza el apartado de datos de campo y usa Lighthouse para localizar problemas, no como veredicto final. Además, los datos de campo tardan semanas en reflejar tus cambios.

¿Comprimir imágenes es suficiente para optimizar la velocidad?

No siempre. Si el cuello de botella es la respuesta del servidor o un JavaScript pesado, comprimir imágenes apenas moverá las métricas. Primero comprueba en qué fase se retrasa la carga y actúa sobre esa.

¿Mejorar la velocidad me hará subir en Google?

Puede ayudar, pero no es una garantía. Google indica que cumplir las métricas de experiencia no asegura las primeras posiciones; contribuye a las señales de calidad de página. Lo que sí suele mejorar es la experiencia del visitante y, con ella, las posibilidades de conversión.

Fuentes

• Understanding Core Web Vitals and Google search results
• Understanding Google Page Experience
• Getting started with measuring Web Vitals
• About PageSpeed Insights
• PageSpeed Insights FAQ
• Optimize Largest Contentful Paint
• Reduce server response times (Lighthouse)
• Protege tu Web (INCIBE)
• How SPA architectures affect Core Web Vitals

Recomendaciones

• Cómo Optimizar las Imágenes de tu Web
• ¿Cómo Optimizar una Landing page?