Para mejorar la velocidad de carga de tu web, primero mídela con PageSpeed Insights y mira las tres Core Web Vitals: LCP (cuánto tarda en verse el contenido principal), INP (cuánto tarda en responder a un clic) y CLS (cuánto se mueve la página mientras carga). Después actúa sobre lo que más pesa: servidor, caché, imágenes y JavaScript.
¿Sabes que puedes estar perdiendo visitas por lo lento que carga tu web? A veces dedicamos mucho tiempo al contenido o a las redes sociales y no miramos algo tan básico. En este post te explico cómo medirlo bien, cómo saber qué lo está frenando y qué arreglar primero.
Cómo saber si tu web carga lenta
Para saber si una web carga lenta, introduce su URL en PageSpeed Insights, la herramienta gratuita de Google, y mira el bloque superior: «Descubre lo que experimentan tus usuarios reales». Si la evaluación de las Core Web Vitals aparece como aprobada en móvil, la web carga bien para la mayoría de tus visitas. Si no, hay trabajo.
- Entra en PageSpeed Insights y pega la URL de una página importante (no solo la portada: prueba también una categoría, una ficha de producto o un artículo).
- Quédate en la pestaña Móvil. Es donde suelen estar los problemas.
- Mira primero los datos de usuarios reales (arriba) y después la puntuación de rendimiento y el diagnóstico (abajo).
Datos de campo y datos de laboratorio: cuál mirar
PageSpeed Insights enseña dos tipos de datos y es fácil confundirlos. Según la documentación de PageSpeed Insights, los datos de campo vienen de usuarios reales de Chrome durante los últimos 28 días, y los de laboratorio salen de una única carga simulada con Lighthouse en un dispositivo y una red fijos.
| Datos de campo | Datos de laboratorio | |
|---|---|---|
| De dónde salen | Usuarios reales de Chrome (informe CrUX), últimos 28 días | Una prueba simulada con Lighthouse |
| Para qué sirven | Saber cómo va la web de verdad | Encontrar la causa y probar los cambios al momento |
| Limitación | Tardan semanas en reflejar una mejora; hace falta tráfico suficiente | No representan a todos tus usuarios |
Si tu página no tiene visitas suficientes, PageSpeed Insights muestra los datos del dominio completo (el «origen») y, si tampoco los hay, solo verás los de laboratorio.
Qué significa la puntuación de 0 a 100
La nota de rendimiento es de laboratorio. Google considera buena una puntuación de 90 o más, mejorable de 50 a 89 y deficiente por debajo de 50, y la calcula como una media ponderada de varias métricas de Lighthouse. Cambia de una prueba a otra, así que no te obsesiones con un punto arriba o abajo.
Debajo de las métricas, el informe lista recomendaciones concretas, cada una con el ahorro estimado. Son el punto de partida para saber qué tocar.
Mi criterio en una auditoría: la nota sirve como termómetro, pero lo que decide si hay un problema son los datos de campo. Hay webs con una nota mediocre que aprueban las Core Web Vitals, y al revés.
Qué son las Core Web Vitals: LCP, INP y CLS
Las Core Web Vitals son las tres métricas con las que Google mide la experiencia de carga de una página con datos de usuarios reales: LCP mide la carga, INP la capacidad de respuesta y CLS la estabilidad visual. Una página las aprueba cuando el 75 % de sus visitas, en móvil y en ordenador, está dentro del umbral bueno de las tres.
Los umbrales son los que publica Google en web.dev:
| Métrica | Qué mide | Bueno | Deficiente |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Cuánto tarda en pintarse el elemento más grande de la pantalla (normalmente la imagen principal o el titular) | 2,5 s o menos | Más de 4 s |
| INP (Interaction to Next Paint) | Cuánto tarda la página en reaccionar cuando tocas, haces clic o escribes | 200 ms o menos | Más de 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto se desplaza el contenido de forma inesperada mientras carga | 0,1 o menos | Más de 0,25 |
Lo que queda entre «bueno» y «deficiente» es «necesita una mejora». Si lees guías antiguas verás otra métrica, FID: desde marzo de 2024 INP sustituye a FID como métrica de interactividad.
Dónde ver las Core Web Vitals de toda la web
PageSpeed Insights analiza una URL cada vez. Para verlas todas, abre el informe de Core Web Vitals de Google Search Console: agrupa las páginas con una experiencia parecida y las clasifica en buenas, que necesitan una mejora o deficientes, por separado en móvil y en ordenador.
Ese informe te dice qué plantillas fallan (por ejemplo, todas las fichas de producto) y con qué métrica. Así no arreglas URLs de una en una, sino tipos de página. Cuando corrijas algo, puedes pedir la validación: según la ayuda de Search Console, se abre un periodo de seguimiento de 28 días.
¿Tus Core Web Vitals salen en rojo y no sabes qué tocar primero? En una auditoría WPO medimos tu web con datos reales, localizamos qué frena cada plantilla y te dejamos las tareas ordenadas por impacto.
Qué frena cada métrica y cómo se arregla
Cada Core Web Vital tiene causas distintas: el LCP suele fallar por un servidor lento o una imagen principal pesada o mal priorizada; el INP, por exceso de JavaScript; y el CLS, por imágenes, anuncios o fuentes que no reservan su espacio. Identificar qué métrica falla te dice dónde buscar.
| Métrica | Causas habituales | Qué hacer |
|---|---|---|
| LCP | Servidor lento, sin caché, imagen principal pesada o con carga diferida, CSS y JavaScript que bloquean | Caché y CDN, imagen principal ligera y con prioridad alta, menos recursos bloqueantes |
| INP | Mucho JavaScript, scripts de terceros, páginas con demasiados elementos | Quitar scripts que no hacen falta, retrasar los no críticos, partir las tareas largas |
| CLS | Imágenes sin dimensiones, anuncios y banners que aparecen tarde, cambio de fuente | Indicar ancho y alto, reservar espacio, cargar bien las fuentes |
LCP alto: servidor, imagen principal y recursos que bloquean
El LCP se reparte en cuatro tramos: lo que tarda el servidor en responder (TTFB), lo que tarda el navegador en empezar a descargar el elemento principal, la descarga en sí y el pintado. La guía de web.dev para optimizar el LCP recomienda revisar los cuatro, porque arreglar solo uno a veces solo traslada el retraso a otro.
Dos fallos muy habituales:
- La imagen principal tiene carga diferida (
loading="lazy"). El navegador la deja para el final. Esa imagen nunca debe llevarla. - La imagen principal no está en el HTML, sino en un fondo de CSS o en un carrusel que se monta con JavaScript, y el navegador la descubre tarde.
La solución es que esté en el HTML y marcarla con prioridad alta:
<img src="portada.webp" alt="..." width="1200" height="600" fetchpriority="high">INP alto: demasiado JavaScript
El INP empeora cuando el navegador está ocupado ejecutando JavaScript y no puede atender al usuario. Los sospechosos habituales son los scripts de terceros (chats, mapas de calor, píxeles publicitarios, gestores de consentimiento de cookies) y los temas o constructores visuales que generan páginas con muchísimos elementos.
Un detalle: Lighthouse no puede medir el INP, porque en una prueba simulada nadie hace clic. En laboratorio se usa como referencia el TBT (tiempo total de bloqueo). El INP real solo lo ves en los datos de campo.
CLS alto: elementos que se mueven al cargar
¿Te ha pasado que vas a pulsar un botón y de repente baja porque ha cargado un banner? Eso es el CLS. Se corrige indicando el ancho y el alto de imágenes y vídeos, reservando el hueco de anuncios, avisos de cookies e incrustados, y evitando que el texto salte al cambiar la fuente provisional por la definitiva.
Cómo mejorar la velocidad de carga: 8 acciones por orden de impacto
Las acciones que más mejoran la velocidad de carga de una web son, por este orden: un servidor que responda rápido, caché y CDN, imágenes optimizadas, menos JavaScript de terceros y CSS sin sobrantes. Después vienen las fuentes, el tema y los plugins, y las redirecciones. El orden exacto en tu caso lo marca la métrica que falla.
| Acción | Mejora sobre todo | Dificultad |
|---|---|---|
| 1. Hosting y tiempo de respuesta | LCP | Media |
| 2. Caché y CDN | LCP | Baja o media |
| 3. Imágenes | LCP y CLS | Baja |
| 4. JavaScript de terceros | INP y LCP | Media |
| 5. CSS sin usar | LCP | Media o alta |
| 6. Fuentes web | CLS y LCP | Baja |
| 7. Tema y plugins | Las tres | Alta si hay que cambiar de tema |
| 8. Redirecciones | LCP | Baja |
1. Elige un hosting que responda rápido
La optimización empieza en el servidor. De nada sirve aligerar la página si el servidor tarda en dar la primera respuesta. Esa espera se mide con el TTFB (tiempo hasta el primer byte): no es una Core Web Vital, pero web.dev considera bueno un valor de 0,8 segundos o menos, y todo lo demás va detrás.
En lugar de fiarte del nombre del proveedor, pide datos: versión de PHP reciente, caché de servidor, HTTP/2 o HTTP/3, recursos garantizados y un soporte que responda cuando algo falla. Tienes los criterios en el post sobre cómo elegir el mejor hosting.
2. Activa la caché y usa una CDN
La caché de página guarda una copia ya generada de cada página para no tener que construirla en cada visita. Es, con diferencia, el cambio que más se nota en webs hechas con un gestor de contenidos. Una CDN (red de servidores repartidos por el mundo) sirve esa copia y los archivos estáticos desde un punto cercano al usuario.
Añade la caché de navegador, para que quien vuelve no descargue otra vez lo que ya tiene, y la compresión de texto (Brotli o gzip).
3. Optimiza las imágenes
Las imágenes suelen ser lo que más pesa en una página. Todos queremos fotos bonitas, pero una foto subida tal cual sale de la cámara puede arruinar la carga. Lo básico:
- Formatos modernos (WebP o AVIF) y compresión.
- El tamaño justo: no subas 3.000 píxeles de ancho para mostrar 800.
- Atributos
widthyheighten todas, para que no muevan el contenido. - Carga diferida (
loading="lazy") solo en las que quedan fuera de la primera pantalla, nunca en las que se ven nada más entrar.
El detalle de formatos, pesos y herramientas está en la guía de cómo optimizar imágenes para SEO y velocidad de carga.
4. Reduce el JavaScript de terceros
Cada herramienta que se instala «solo con pegar un código» añade JavaScript: analítica, chat, píxeles, pruebas A/B, vídeos incrustados. Haz inventario y pregunta por cada una: ¿se sigue usando? Lo que no, fuera. Lo que sí, cargado con defer o async, o solo cuando el usuario lo necesita (por ejemplo, el chat al pulsar el botón).
5. Elimina el CSS que no se usa
Muchos temas cargan en todas las páginas los estilos de toda la web. El CSS bloquea el pintado, así que cuanto más hay, más tarda en verse algo. Minificar (quitar espacios y comentarios) ayuda un poco. Lo que de verdad se nota es cargar en cada página solo el CSS que utiliza y dar prioridad al de la primera pantalla.
6. Cuida las fuentes web
Usa pocas familias y pocos pesos, en formato WOFF2 y alojadas en tu propio dominio. Con font-display: swap el texto se ve desde el principio con una fuente del sistema mientras llega la definitiva. Si el cambio provoca un salto visible, elige una fuente provisional de proporciones parecidas o precarga la principal.
7. Tema ligero y solo los plugins necesarios
La plantilla es una de las bases de la velocidad. Aplica la regla de «menos es más»: cada efecto, carrusel o animación que añades tiene un peso. Una estética llamativa impacta, pero piensa también en la utilidad y en la legibilidad.
Con los plugins pasa lo mismo. Hay uno para casi todo, pero ¿por qué ibas a tener los que no te hacen falta? No es tanto cuántos tienes como qué carga cada uno en las páginas públicas. Haz criba, y desactiva y borra los que no uses.
8. Evita las cadenas de redirecciones
Las redirecciones son necesarias cuando cambias una URL, pero cada salto es una petición más antes de que empiece a cargar la página. El problema son las cadenas (A lleva a B y B lleva a C) y los enlaces internos que siguen apuntando a la URL antigua. Enlaza siempre a la URL final y revisa también las de imágenes, CSS y JavaScript.
Cómo mejorar la velocidad de carga en WordPress
En WordPress, la velocidad de carga depende sobre todo de cuatro cosas: el hosting, un plugin de caché bien configurado, el tema (y el constructor visual, si lo hay) y los plugins que añaden scripts en todas las páginas. Con esas cuatro bajo control se resuelve la mayor parte de los problemas habituales de Core Web Vitals.
- Caché: un solo plugin de caché, no dos. Si tu hosting ya trae caché de servidor, usa la suya.
- Tema: los temas multipropósito y los constructores visuales generan mucho HTML, CSS y JavaScript. Compruébalo con una página de demostración del tema antes de comprarlo.
- Imágenes: WordPress añade carga diferida de forma automática. Comprueba que la imagen principal de cada plantilla no la lleve.
- Plugins: formularios, sliders y mapas suelen cargar sus archivos en toda la web aunque solo se usen en una página.
- Base de datos: revisiones, transients caducados y tablas de plugins borrados la hacen más lenta con el tiempo.
Si quieres ver el resto de la configuración, la tienes en la guía de SEO en WordPress.
Cómo mejorar la velocidad de una tienda online
En una tienda online, la velocidad se pierde sobre todo en tres sitios: las imágenes de producto, las aplicaciones o módulos que añaden scripts, y las páginas que no se pueden cachear (carrito, pago, área de cliente). Los listados de categoría con muchos productos y filtros son la plantilla que más conviene revisar.
- Shopify: el servidor no lo controlas, así que el margen está en el tema y en las aplicaciones. Cada app instalada añade código, y parte puede quedarse en el tema después de desinstalarla.
- WooCommerce: todo lo dicho para WordPress, más un hosting con recursos suficientes, porque carrito y pago no se sirven desde caché.
- PrestaShop: revisa los módulos enganchados a todas las páginas, la caché y las opciones de rendimiento del panel.
Mide siempre por plantilla: portada, categoría, ficha de producto y carrito. Aquí tienes más sobre SEO para ecommerce.
Qué herramientas usar para medir la velocidad de una web
Para medir la velocidad de una web bastan las herramientas gratuitas de Google: PageSpeed Insights para analizar una URL, el informe de Core Web Vitals de Search Console para ver toda la web y las herramientas para desarrolladores de Chrome para depurar. WebPageTest, GTmetrix y Pingdom Tools aportan pruebas desde otras ubicaciones y un desglose más detallado de la carga.
| Herramienta | Tipo de dato | Para qué la usamos |
|---|---|---|
| PageSpeed Insights | Campo y laboratorio | Diagnóstico rápido de una URL |
| Search Console (Core Web Vitals) | Campo | Ver qué grupos de páginas fallan y seguir la evolución |
| Chrome DevTools (Lighthouse y panel Rendimiento) | Laboratorio y tu propia sesión | Encontrar la causa exacta y probar cambios |
| WebPageTest | Laboratorio | Elegir ubicación, navegador y conexión; ver la cascada de peticiones |
| GTmetrix | Laboratorio (usa Lighthouse) | Informe visual y comparativas en el tiempo |
| Pingdom Tools | Laboratorio | Prueba rápida con el peso de la página, sus peticiones y una lista de mejoras |
WebPageTest es muy útil si tienes visitas de otros países, porque puedes lanzar la prueba desde allí. Si trabajas el SEO internacional, mide desde cada mercado y no solo desde España.
Para medir desde el navegador no hace falta instalar nada: Lighthouse y el panel Rendimiento vienen dentro de Chrome. Por eso, de las extensiones de Chrome para SEO que usamos, ninguna es ya de rendimiento.
Un consejo: elige una herramienta y unas condiciones y mide siempre igual. Comparar la nota de una con la de otra no sirve de nada.
La velocidad de carga, el SEO y las ventas
La velocidad de carga influye en el SEO, pero no es lo que más pesa. Google recomienda tener buenas Core Web Vitals y las incluye dentro de la experiencia de página que sus sistemas buscan premiar, sin atribuirles un peso concreto. Donde más se nota una web rápida es en los usuarios: esperan menos y abandonan menos.
La documentación de Google sobre Core Web Vitals y resultados de búsqueda lo plantea como una recomendación para tener éxito en la Búsqueda y ofrecer una buena experiencia. No promete posiciones. Una página lenta con el mejor contenido para una búsqueda puede seguir por delante de una rápida que no responde a lo que se busca.
Por eso yo no vendo la velocidad como un atajo para posicionar. La trato como lo que es: una condición para que el resto del trabajo (contenido, arquitectura, enlaces) rinda, y para que quien llega no se vaya antes de ver tu oferta.
¿Prefieres que lo revisemos con tu equipo de desarrollo? Trabajamos la velocidad dentro del SEO técnico de tu proyecto: priorizamos, explicamos cada cambio a quien lo implementa y comprobamos el resultado.
Preguntas frecuentes sobre la velocidad de carga web
¿No está tu pregunta? Escríbeme a alberto@ingenieroseo.com y te contesto en menos de 24 horas.
¿Cuánto debe tardar en cargar una página web?
Google no da un único tiempo de carga, sino tres umbrales: el contenido principal debe verse en 2,5 segundos o menos (LCP), la página debe responder a las interacciones en 200 milisegundos o menos (INP) y el contenido no debe desplazarse más de 0,1 (CLS). Se miden con usuarios reales y deben cumplirse en el 75 % de las visitas.
¿La velocidad de carga es un factor de posicionamiento en Google?
Google indica que las Core Web Vitals forman parte de la experiencia de página que sus sistemas de posicionamiento buscan premiar y recomienda tenerlas en buen estado, pero no les asigna un peso concreto. En la práctica, la relevancia del contenido pesa más. La velocidad ayuda sobre todo a que el usuario se quede y convierta.
¿Hace falta tener 100 en PageSpeed Insights?
No. La puntuación de PageSpeed Insights es una prueba de laboratorio y Google considera buena cualquier nota de 90 o más. Lo que conviene conseguir es aprobar las Core Web Vitals con datos de usuarios reales. Perseguir el 100 suele costar mucho más de lo que aporta.
¿Por qué PageSpeed Insights da peor nota en móvil que en ordenador?
Porque la prueba de móvil simula un teléfono de gama media con una conexión móvil, mientras que la de ordenador simula un equipo más potente con conexión por cable. La misma página tarda más en esas condiciones. Como la mayoría de las visitas suele llegar desde el móvil, es la nota que más conviene mirar.
¿Por qué mi web sigue saliendo lenta si ya la he optimizado?
Porque los datos de usuarios reales de PageSpeed Insights y de Search Console recogen los últimos 28 días. Una mejora publicada hoy se nota de inmediato en los datos de laboratorio, pero tarda varias semanas en reflejarse por completo en los datos de campo.
¿Has medido ya tu web? Si alguna métrica se te resiste o no sabes interpretar el informe, déjame un comentario y lo vemos.
