WPO: qué es y cómo optimizar el rendimiento de tu web

El WPO (Web Performance Optimization) es el conjunto de técnicas que hacen que una web cargue rápido, responda sin retrasos y no se mueva mientras se usa. Se mide sobre todo con los Core Web Vitals de Google: LCP, INP y CLS. Una web veloz retiene más visitas, convierte mejor y posiciona con menos fricción.

La velocidad no es un adorno técnico. Cuando alguien toca un resultado en el móvil y la página tarda en aparecer, se va. Esa persona no vuelve a pensar en tu marca: simplemente pulsa atrás y elige al siguiente. Y Google lo sabe, porque las métricas de experiencia de página forman parte de las señales que usa para ordenar resultados parecidos.

En este artículo te cuento qué mide el WPO hoy, cómo diagnosticar una web paso a paso y qué acciones tienen más impacto. Lo explico desde lo que veo en auditorías: casi siempre el problema está en cuatro o cinco sitios, no en cien.

Qué es el WPO y por qué importa

El WPO nació como una disciplina de ingeniería: reducir el tiempo que pasa desde que el usuario pide una página hasta que puede usarla. Con los años ha dejado de medirse con un único número («tarda 3 segundos») y se mide con tres experiencias distintas: cuánto tarda en verse lo principal, cuánto tarda en reaccionar a un toque y si el contenido salta mientras carga.

Importa por tres motivos prácticos:

• Experiencia. Una web lenta frustra, y una frustrada se abandona antes de leer nada.
• Negocio. En una tienda o en un formulario de contacto, cada retraso se paga en ventas o en solicitudes perdidas.
• SEO. La velocidad no hará que un contenido flojo supere a uno excelente, pero entre dos páginas igual de relevantes puede inclinar la balanza, y además un sitio rápido se rastrea e indexa con menos coste.

Mi postura es esta: no persigo el 100 en PageSpeed por el 100. Persigo que los usuarios reales, en móviles normales y conexiones normales, tengan buena experiencia. Son cosas parecidas, pero no iguales.

Las métricas que debes conocer: Core Web Vitals

Google evalúa tres métricas con datos de usuarios reales y las considera «buenas» si se cumplen en el percentil 75 de las visitas:

El INP sustituyó al antiguo FID en marzo de 2024 y es más exigente, porque mide todas las interacciones de la visita y no únicamente la primera. Además de estas tres, conviene vigilar el TTFB (tiempo hasta el primer byte), que no es un Core Web Vital pero condiciona al LCP: si el servidor tarda en responder, todo lo demás llega tarde.

Puedes consultar la definición oficial de cada umbral en web.dev.

Cómo medir el rendimiento de tu web

Distingo siempre entre dos tipos de datos:

• Datos de campo: los que dejan los usuarios reales (informe CrUX). Son los que cuentan para Google.
• Datos de laboratorio: una simulación controlada (Lighthouse). Sirven para encontrar y corregir problemas, pero no equivalen a lo que vive tu público.

Las herramientas que uso:

1. PageSpeed Insights. Muestra arriba los datos de campo de los últimos 28 días y abajo el análisis de laboratorio con oportunidades concretas.
2. Search Console, informe de Core Web Vitals. Agrupa las URL por problema y por tipo de dispositivo. Es lo mejor para priorizar plantillas enteras en lugar de páginas sueltas.
3. Lighthouse en Chrome DevTools. Útil para probar cambios antes de publicarlos.
4. Pestaña Rendimiento y Red de DevTools. Para ver qué bloquea el hilo principal o qué recurso retrasa el LCP.

Si tu web tiene poco tráfico, es posible que no haya datos de campo suficientes. En ese caso te toca guiarte por el laboratorio y por el sentido común.

Acciones que más mejoran el WPO

1. Elige un hosting que responda bien

Un TTFB alto no se arregla con plugins. Si el servidor tarda más de 800 ms en responder de forma habitual, el problema está en el alojamiento, en la configuración de PHP o en una base de datos sin cuidar. Un hosting compartido muy barato con cientos de webs por servidor suele ser la causa. Elige un proveedor con servidores en Europa (o cercanos a tu público), PHP actual, HTTP/2 o HTTP/3 y caché a nivel de servidor.

2. Activa caché de página y de navegador

La caché evita que el servidor reconstruya la misma página en cada visita. Combina caché de página (en WordPress, un plugin o la propia caché del hosting), caché de objetos si hay base de datos pesada y cabeceras de caché largas para archivos estáticos. En vez de dejar la caché «una semana como máximo», como se decía hace años, hoy se configura por tipo de archivo: los estáticos con versión, un año; el HTML, el tiempo que permita tu contenido.

3. Usa una CDN

Una CDN guarda copias de tus archivos en servidores repartidos por el mundo y los sirve desde el más cercano al visitante. Si tu público es solo de una ciudad y tu servidor está en España, el beneficio es pequeño; si vendes a varios países, es muy grande. Además suele traer compresión, HTTP/3 y protección frente a ataques.

4. Optimiza las imágenes

Son la causa número uno de un LCP malo. Lo que hago siempre:

• Convertir a WebP o AVIF, con calidad ajustada a la vista.
• Servir el tamaño real con srcset: un móvil no necesita una imagen de 3.000 píxeles.
• No aplicar carga diferida (loading="lazy") a la imagen principal; a esa, darle fetchpriority="high".
• Fijar width y height para reservar el hueco y evitar saltos de diseño.

5. Comprime y reduce el código

La compresión Brotli (o Gzip como alternativa) reduce el peso de HTML, CSS y JavaScript. Después, minifica archivos, elimina CSS que no se usa y carga solo el JavaScript necesario en cada página. Cada script de más compite por el hilo principal y empeora el INP.

6. Controla los scripts de terceros

Chats, mapas, píxeles de publicidad, mapas de calor, widgets sociales: cada uno añade peticiones y trabajo. En las auditorías que hago, los terceros suelen explicar más lentitud que el propio sitio. Pregúntate si cada uno aporta más de lo que cuesta, cárgalos tarde (tras la interacción) y elimina los que nadie mira.

7. Reduce las peticiones y prioriza lo crítico

Con HTTP/2 ya no hace falta obsesionarse con unir todos los archivos, pero sí con no cargar lo que sobra. Precarga las fuentes y la imagen principal (preload), usa font-display: swap y limita las tipografías a dos familias.

8. Mantén todo actualizado

Núcleo, tema, plugins y versión de PHP actualizados suelen ser más rápidos y más seguros. Y revisa cada cierto tiempo qué plugins sobran: cada uno que se queda sin usar es peso muerto.

9. Cuida la base de datos

En WordPress, las revisiones infinitas, las opciones autocargadas y los restos de plugins eliminados engordan las consultas. Una limpieza periódica y un índice de objetos en memoria marcan diferencia en sitios con mucho contenido.

10. Diseña pensando en el móvil

La mayor parte del tráfico llega desde el móvil, con procesadores más modestos que tu ordenador. Un diseño ligero, sin animaciones pesadas ni sliders gigantes, es el mejor WPO posible. Lo que más rápido carga es lo que no se carga.

Cómo priorizar: empieza por el LCP, el INP o el CLS según el problema

• Si falla el LCP: mira el TTFB, la imagen principal y el CSS que bloquea el renderizado.
• Si falla el INP: revisa JavaScript pesado, terceros y eventos largos (menús, filtros, buscadores).
• Si falla el CLS: busca imágenes sin dimensiones, banners de cookies que empujan el contenido, anuncios sin hueco reservado y fuentes que cambian al cargar.

Trabaja una plantilla cada vez (portada, artículo, ficha de producto) y vuelve a medir. Los datos de campo tardan hasta 28 días en reflejar una mejora, así que no te desesperes si PageSpeed no cambia a las 24 horas.

Errores habituales en el WPO

• Instalar tres plugins de caché a la vez.
• Optimizar solo la portada y olvidar las páginas que reciben el tráfico.
• Obsesionarse con la puntuación de laboratorio y no mirar los datos de campo.
• Cargar con lazy load la imagen principal, que retrasa el LCP.
• Comprar una CDN para esconder un servidor lento.
• Quitar funciones útiles (formularios, analítica) solo por ganar décimas.

Mi recomendación sobre el WPO

Empezaría por tres cosas: medir con datos reales, arreglar el servidor y la caché, y limpiar imágenes y scripts de terceros. Con eso se resuelve la mayor parte de los casos sin tocar código. Si después sigue habiendo problemas de INP o de renderizado, entonces sí toca un trabajo técnico más fino, y para eso existe el SEO técnico.

Si la web ya funciona bien, no la rompas por conseguir el último punto. Mantén lo ganado, vigila el informe de Search Console una vez al mes y revisa tras cada cambio importante de tema o de plugins. Si quieres entender cómo se aplica a la caché del navegador, tienes mi guía sobre cómo especificar la caché de navegador en PageSpeed Insights, y si dudas de tu proveedor, mira cómo elegir un hosting barato de calidad.

Preguntas frecuentes sobre el WPO

¿Qué significa WPO?

Son las siglas de Web Performance Optimization, es decir, optimización del rendimiento web. Reúne todo lo que se hace para que una página cargue antes, responda mejor y sea estable visualmente, tanto en ordenador como en móvil.

¿La velocidad de carga influye en el posicionamiento?

Sí, aunque con matices. Google usa la experiencia de página como una señal entre muchas. No convierte una web mala en una líder, pero sí puede decidir entre dos páginas parecidas, y una web rápida retiene más visitas, lo que ayuda por otro camino.

¿Qué puntuación de PageSpeed necesito?

No hay una cifra mágica. Lo importante es que los datos de campo de LCP, INP y CLS estén en verde. Una web puede sacar 70 en laboratorio y pasar los Core Web Vitals, y al revés.

¿Cuánto tarda en notarse una mejora de WPO?

El efecto en la experiencia del usuario es inmediato, pero los datos de campo de Google se calculan sobre 28 días. Para comprobar el cambio en Search Console suelen hacer falta entre cuatro y seis semanas.

¿Es necesario usar una CDN?

No siempre. Si tu público está en una zona cercana al servidor y el sitio es ligero, aporta poco. Si vendes a varios países o tienes mucho tráfico, merece la pena por la distancia y por la protección extra.

¿Puedo optimizar el WPO sin saber programar?

En gran parte sí: caché, compresión de imágenes, limpieza de plugins y un buen hosting se resuelven sin tocar código. Los problemas de INP o de renderizado sí suelen requerir a alguien que conozca JavaScript y el tema de la web.