Velocidad de carga en WordPress y el límite que fija Google

La velocidad de carga de un WordPress no es una sensación subjetiva: Google la mide con tres métricas concretas y le pone nota a cada visita real, no a una foto de laboratorio. Para quien dirige una pyme o lleva el marketing sin equipo técnico, el problema no es saber que la web va lenta, sino qué la está frenando: las imágenes sin comprimir, los plugins acumulados con los años o un hosting barato elegido solo por precio. Esto es justo lo que mide Google y por dónde se empieza a corregirlo.

Google considera buena la velocidad de carga de un WordPress cuando el contenido principal aparece en 2,5 segundos o menos, la página responde a un clic en 200 milisegundos y nada se desplaza de forma inesperada mientras carga (CLS por debajo de 0,1), medido en el 75% de las visitas. Por debajo de esas cifras no hay penalización automática, pero sí peor experiencia frente a un competidor con contenido similar.

Los tres umbrales que miden el tiempo de carga

Google agrupa la velocidad de carga y la estabilidad de una página en tres métricas, documentadas como Core Web Vitals: LCP, INP y CLS. El LCP (Largest Contentful Paint) mide cuánto tarda en pintarse el elemento más grande visible al cargar -normalmente una imagen de cabecera o el titular- y se considera bueno por debajo de 2,5 segundos. El INP (Interaction to Next Paint) sustituyó al antiguo FID en marzo de 2024 y mide el tiempo entre un clic y la respuesta visible: el límite bueno son 200 milisegundos. El CLS (Cumulative Layout Shift) puntúa cuánto se desplazan los elementos mientras carga la página, con 0,1 como techo.

Un Core Web Vital «bueno» no es una media: Google exige que al menos el 75% de las visitas reales a una URL cumplan el umbral, separando móvil y escritorio. Una web rápida en el portátil de quien la diseñó y lenta en el móvil de un cliente real suspende igual.

Esos tres umbrales son los que aparecen en el informe de Search Console y deciden si una URL entra en la columna «buena», «mejorable» o «mala»: el mismo dato que usa Google internamente para evaluar la página.

La velocidad de carga no es lo único

Conviene situar esto antes de perseguir milisegundos: Google lo dice de forma explícita en su documentación sobre experiencia de página: «Google Search siempre busca mostrar el contenido más relevante, incluso si la experiencia de página no es excelente». Los Core Web Vitals entran en juego sobre todo como criterio de desempate entre páginas de relevancia similar, no como un factor que por sí solo adelante a un competidor con mejor contenido.

Esto importa especialmente en un blog de WordPress que lleva años sin tocarse, donde cuesta más desenterrar y desarrollar un buen contenido que optimizar dos segundos de carga. Con más del 40% de la web mundial corriendo sobre WordPress, según W3Techs, la velocidad por sí sola no diferencia nada: la diferencia la marca seguir publicando contenido útil mientras la web va razonablemente rápida, no sacrificar uno por el otro.

Plugins y temas que frenan el rendimiento

Un WordPress que lleva varios años en marcha suele arrastrar plugins que ya no se usan y temas sin actualizar. Cada plugin añade su propia hoja de estilos y su propio script, que el navegador descarga antes de que la página responda a nada. No es un problema de cantidad exacta -no hay un número mágico que convierta una web en lenta-, sino de peso acumulado: un plugin de formularios, otro de pop-ups y un tercero de redes sociales pueden sumar más JavaScript que el propio artículo.

Builders visuales y su coste en JavaScript

Los builders visuales como Elementor o Divi facilitan maquetar sin tocar código, pero construyen la página con capas de CSS y JavaScript propio que se suman a lo que ya carga el tema. Una landing hecha con columnas, iconos animados y varios widgets puede tardar el doble en volverse interactiva que la misma página escrita en HTML simple, porque el navegador tiene que montar toda esa estructura antes de que el clic responda, lo que empeora directamente el INP. Esto no significa prescindir del builder: significa limitar cuántos widgets con animación se apilan en una sola página y revisar si algún plugin adicional cubre una función que el tema ya tiene.

El hosting decide buena parte de la velocidad

El hosting fija un suelo que ningún plugin de caché compensa del todo: el tiempo que tarda el servidor en empezar a responder (TTFB) se suma siempre antes de que el navegador pinte nada, así que un servidor lento penaliza el LCP aunque la página esté bien optimizada. En un hosting compartido, además, ese tiempo varía según la carga de los demás sitios alojados en la misma máquina: la web puede ir bien un martes e ir lenta un lunes con más tráfico ajeno.

Hosting compartido frente a hosting gestionado

Un hosting compartido genérico reparte CPU y memoria entre decenas o cientos de webs sin garantizar nada por encima del mínimo, y suele faltarle caché a nivel de servidor: cada visita ejecuta PHP y consulta la base de datos desde cero. Un hosting gestionado para WordPress, en cambio, incluye caché de página en el propio servidor, PHP actualizado y, casi siempre, una CDN que sirve las imágenes desde un punto cercano a quien visita la web. La diferencia suele rondar pocos euros al mes -una partida pequeña dentro del presupuesto técnico de cualquier pyme- pero se traduce en segundos reales de LCP que ningún plugin corrige por encima.

Imágenes sin optimizar, el error más habitual

Las imágenes sin optimizar son, con diferencia, el fallo más fácil de arreglar y el que más tarda en corregirse porque nadie vuelve atrás a comprimir fotos antiguas. Una imagen de cabecera subida directa desde una cámara puede pesar varios megabytes cuando el ancho real en pantalla no pasa de 1200 píxeles: ese peso de más se descarga igual, y suele ser precisamente el elemento que cuenta como LCP.

• Formato WebP o AVIF en lugar de JPEG o PNG, que recortan el peso del archivo sin perder calidad visible.
• Atributos width y height explícitos en cada imagen, para que el navegador reserve el espacio y no se mueva el resto del contenido -eso mide el CLS-.
• Carga diferida (lazy loading) en todo lo que queda por debajo de la primera pantalla, para no descargar fotos que nadie llega a ver.
• Una CDN que sirva las imágenes desde un servidor cercano a quien visita la web, en lugar de desde el origen único del hosting.

WordPress aplica lazy loading por defecto desde hace varias versiones, pero el formato y el peso del archivo siguen dependiendo de cómo se suba la imagen: eso no lo corrige ningún plugin si el original ya venía sobredimensionado.

Medir con PageSpeed Insights y Search Console

PageSpeed Insights y el informe de Core Web Vitals de Search Console miden cosas distintas y conviene no confundirlas. PageSpeed Insights ejecuta una prueba en el momento, con datos de laboratorio: sirve para diagnosticar qué elemento concreto pesa -una imagen, un script, el propio servidor- pero no refleja la experiencia real de cada visitante. El informe de Search Console usa datos de campo: el historial real de visitas de los últimos 28 días, agrupadas por tipo de página, el mismo origen que usa Google para evaluar el sitio.

Lo útil es cruzar los dos: Search Console dice qué grupos de URLs están mal -por ejemplo, todas las entradas del blog con una plantilla concreta- y PageSpeed Insights, al probar una de esas URLs, apunta a la causa exacta. Conviene incluir esta comprobación dentro de cualquier auditoría de contenido antes de reescribir nada: revisarlo una vez al mes basta para la mayoría de webs, y revisarlo después de cualquier cambio de plantilla es lo que de verdad evita sorpresas.

Preguntas frecuentes sobre velocidad de carga en WordPress

¿Cuánto debe tardar en cargar una página de WordPress?

El objetivo es que el contenido principal (LCP) aparezca en 2,5 segundos o menos en al menos el 75% de las visitas reales, medido por Google. Un WordPress con hosting gestionado, imágenes optimizadas y pocos plugins suele rondar entre 1,5 y 2,5 segundos; por encima de 4 segundos se considera malo.

¿Un plugin de caché soluciona la velocidad de carga por sí solo?

Ayuda, pero no sustituye lo demás. Un plugin de caché evita que cada visita ejecute PHP y consulte la base de datos desde cero, lo que mejora el tiempo de respuesta del servidor, pero no comprime imágenes sobredimensionadas ni reduce el JavaScript de los builders visuales o los plugins acumulados.

¿Afecta la velocidad de carga al posicionamiento si el contenido ya es bueno?

Afecta poco de forma directa: Google prioriza el contenido más relevante aunque la experiencia de página no sea perfecta. Los Core Web Vitals actúan como criterio de desempate entre páginas igual de relevantes, así que mejorarlos no sustituye a mejorar lo que dice el artículo.

¿Qué herramienta mide la velocidad de carga desde dentro de WordPress?

Desde WordPress 6.5, la pestaña de rendimiento en Herramientas > Salud del sitio da una primera foto del tiempo de respuesta del servidor. Para datos reales, lo fiable sigue siendo el informe de Core Web Vitals en Search Console, el mismo origen que usa Google al evaluar el sitio.

Fuente: web.dev (Google)