Durante mucho tiempo, la velocidad de una página web se trató como una cuestión secundaria. Mientras la web funcionara, mostrara sus contenidos y permitiera completar las acciones básicas, parecía suficiente.
Hoy esa forma de pensar ya no tiene demasiado sentido.
Los usuarios esperan que una página cargue rápido, responda al instante y mantenga sus elementos estables. Cuando esto no ocurre, la web transmite una sensación de lentitud, abandono y poca profesionalidad. Da igual que el diseño sea atractivo o que el servicio sea bueno: si el visitante tiene que esperar demasiado o no consigue pulsar un botón porque el contenido se mueve, la experiencia empieza mal.
En mi opinión, las Core Web Vitals son útiles precisamente porque convierten esas sensaciones en datos que se pueden medir. No se limitan a decir que una web es rápida o lenta. Analizan momentos concretos de la experiencia: cuándo aparece el contenido principal, cuánto tarda la página en responder y si el diseño permanece estable durante la navegación.
En WordPress, mejorar estas métricas requiere mirar más allá de una única herramienta. Las imágenes, el tema, los plugins, el código JavaScript, las fuentes, la caché y el servidor forman parte del mismo sistema.
Por eso, en esta guía no voy a recomendarte que instales un plugin y actives todas sus opciones. Primero veremos cómo medir, después cómo detectar la causa y, por último, qué soluciones tienen sentido en cada situación.
Qué son las Core Web Vitals y por qué importan en WordPress
Las Core Web Vitals, también llamadas Métricas web principales, son indicadores que permiten evaluar tres aspectos de la experiencia real de los usuarios: la velocidad con la que aparece el contenido principal, la capacidad de respuesta de la página y su estabilidad visual.
Actualmente, las tres métricas principales son Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift. Google recomienda obtener buenos resultados en las tres para ofrecer una experiencia de usuario adecuada, aunque también deja claro que una buena puntuación no garantiza por sí sola aparecer en las primeras posiciones de búsqueda.
De una sensación de lentitud a un problema que se puede medir
Cuando una persona dice que una web “va lenta”, puede estar describiendo problemas diferentes.
Quizá la página tarda en mostrar la imagen o el título principal. En ese caso, el problema podría estar relacionado con el LCP.
También puede suceder que el contenido aparezca rápidamente, pero que los botones, menús o filtros tarden en reaccionar. Ahí conviene analizar el INP.
En otras ocasiones, la web parece cargar rápido, pero los textos, banners y botones cambian de posición mientras el usuario intenta leer o interactuar. Ese comportamiento se refleja en el CLS.
Esta separación es importante porque cada problema necesita un tratamiento diferente. Reducir el peso de una imagen puede ayudar al LCP, pero probablemente no resolverá una interacción bloqueada por JavaScript. Del mismo modo, activar la caché puede mejorar la entrega inicial de la página, pero no evitará necesariamente que un aviso de cookies desplace todo el contenido.
Qué evalúa Google sobre la experiencia de una página
Las Core Web Vitals no evalúan si el contenido es bueno, si el diseño resulta atractivo o si la oferta comercial es competitiva. Se centran en aspectos técnicos que influyen en cómo se percibe y se utiliza la página.
Esto significa que deben entenderse como una parte del rendimiento general, no como una valoración completa de la web.
Una página puede tener buenos contenidos y ofrecer un servicio excelente, pero perder oportunidades si tarda demasiado en cargar. También puede obtener una puntuación elevada en una prueba de laboratorio y seguir siendo incómoda para determinados usuarios, dispositivos o conexiones.
Por qué mejorar el rendimiento tiene sentido más allá del SEO
Aunque normalmente se habla de Core Web Vitals dentro del SEO, su utilidad no depende únicamente de Google.
Una página rápida facilita que el usuario lea el contenido, consulte una tarifa, navegue por una tienda o complete un formulario. Una web estable evita pulsaciones accidentales. Una interacción rápida hace que el visitante perciba que la página funciona correctamente.
Desde mi punto de vista, ese es el verdadero objetivo: reducir obstáculos.
Si además estas mejoras ayudan a construir una mejor experiencia de página para los buscadores, perfecto. Pero perseguir una puntuación sin pensar en el visitante termina convirtiendo la optimización en un ejercicio técnico sin demasiado sentido.
Cuáles son las Core Web Vitals principales
Las tres métricas no miden lo mismo. Cada una se ocupa de un momento distinto de la experiencia.
LCP: cuánto tarda en aparecer el contenido principal
Largest Contentful Paint, o LCP, mide el tiempo que tarda en mostrarse el elemento de contenido más grande que aparece dentro de la zona visible de la página.
Ese elemento puede ser:
- Una imagen destacada.
- El banner principal.
- Una fotografía de producto.
- Un bloque de texto grande.
- El título principal.
- Una imagen de fondo.
- La portada de una landing page.
El LCP intenta representar el momento en el que el usuario siente que el contenido principal ya está disponible.
Una página puede empezar a mostrar el menú, el logotipo o el fondo rápidamente y, aun así, tener un LCP lento. Si el bloque principal sigue sin aparecer, el visitante tendrá la sensación de que la web no termina de cargar.
En WordPress, un LCP deficiente suele relacionarse con imágenes pesadas, sliders, constructores visuales, fuentes, hojas de estilo, recursos que bloquean el renderizado o una respuesta inicial lenta del servidor.
INP: cómo responde la página cuando el usuario interactúa
Interaction to Next Paint, o INP, mide la capacidad de respuesta de la página durante la visita.
Por ejemplo, analiza cuánto tiempo transcurre desde que una persona pulsa un botón hasta que el navegador muestra una respuesta visual.
Puede afectar a acciones como:
- Abrir el menú en un teléfono móvil.
- Desplegar una sección de preguntas frecuentes.
- Pulsar un botón de compra.
- Añadir un producto al carrito.
- Seleccionar un filtro.
- Abrir una ventana.
- Cambiar una variación de producto.
- Enviar un formulario.
El INP no se centra solo en la primera interacción. Evalúa las interacciones que se producen a lo largo de la visita y representa la capacidad de respuesta general de la página.
En WordPress, suele verse perjudicado por un exceso de JavaScript, tareas demasiado largas en el navegador, plugins que cargan código innecesario o herramientas externas como chats, píxeles publicitarios y sistemas de seguimiento.
CLS: por qué el contenido se mueve mientras carga
Cumulative Layout Shift, o CLS, mide la estabilidad visual.
Seguro que alguna vez has intentado pulsar un botón y, justo en ese momento, ha aparecido una imagen, un anuncio o un aviso que ha desplazado todo el contenido. Además de resultar molesto, puede provocar que pulses donde no querías.
El CLS intenta medir esos desplazamientos inesperados.
Las causas habituales incluyen:
- Imágenes sin dimensiones reservadas.
- Banners que aparecen tarde.
- Anuncios y contenidos incrustados.
- Avisos de cookies.
- Fuentes que cambian el tamaño del texto.
- Formularios insertados dinámicamente.
- Sliders.
- Cabeceras que cambian de altura.
- Elementos que aparecen sobre el contenido.
Las imágenes, los vídeos, los anuncios, los elementos incrustados y el contenido dinámico deben disponer de espacio suficiente antes de terminar de cargar. De lo contrario, obligan al resto de la página a desplazarse.
Qué valores deberían alcanzar LCP, INP y CLS
Google clasifica los resultados de las Core Web Vitals en tres grupos: buenos, mejorables y deficientes.
| Métrica | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|
| LCP | 2,5 segundos o menos | Más de 2,5 y hasta 4 segundos | Más de 4 segundos |
| INP | 200 milisegundos o menos | Más de 200 y hasta 500 milisegundos | Más de 500 milisegundos |
| CLS | 0,1 o menos | Más de 0,1 y hasta 0,25 | Más de 0,25 |
Para valorar el rendimiento general se utiliza el percentil 75. Explicado de forma sencilla, el objetivo es que al menos el 75 % de las visitas analizadas disfrute de una experiencia situada dentro del umbral recomendado. La evaluación se segmenta entre dispositivos móviles y ordenadores.
Cómo interpretar un resultado bueno, mejorable o deficiente
Un resultado “bueno” indica que la mayoría de los usuarios analizados están experimentando un rendimiento situado dentro del objetivo recomendado.
“Necesita mejorar” no significa que la web sea inutilizable. Indica que existe margen para reducir esperas, bloqueos o movimientos.
Un resultado “deficiente” merece una investigación prioritaria, especialmente cuando afecta a páginas importantes para el negocio.
No recomiendo interpretar los valores de forma aislada. Es más útil responder preguntas como estas:
- ¿Qué plantilla está afectada?
- ¿Ocurre en móvil, en ordenador o en ambos?
- ¿El problema aparece en datos reales o solo en una prueba?
- ¿Qué elemento provoca el resultado?
- ¿Cuánto esfuerzo requiere corregirlo?
- ¿Qué impacto tendrá la mejora?
Cómo medir las Core Web Vitals de una web WordPress
Medir correctamente es más importante que acumular herramientas.
No tiene sentido instalar varios plugins, modificar el tema y cambiar de servidor si todavía no sabemos qué métrica falla ni en qué páginas ocurre.
PageSpeed Insights para obtener una primera visión
PageSpeed Insights es un buen punto de partida porque puede mostrar dos tipos de información:
- Datos de usuarios reales procedentes de Chrome UX Report.
- Una prueba de laboratorio generada mediante Lighthouse.
Los primeros permiten observar cómo se ha comportado la web en condiciones reales. La prueba de laboratorio ayuda a reproducir problemas y presenta diagnósticos técnicos.
PageSpeed Insights combina información de campo procedente de CrUX con diagnósticos de Lighthouse, por lo que ambas partes del informe deben interpretarse por separado.
Cuando analices una página, no te quedes únicamente con el número grande que aparece en la parte superior. Revisa:
- El elemento identificado como LCP.
- Los cambios de diseño.
- El JavaScript que bloquea el hilo principal.
- Los recursos que retrasan el renderizado.
- Las imágenes demasiado grandes.
- Los scripts externos.
- El tiempo de respuesta inicial.
Search Console para analizar datos de usuarios reales
El informe de Métricas web principales de Search Console ayuda a detectar grupos de páginas con problemas basándose en datos de campo.
Es especialmente útil para conocer si el problema se limita a una página o afecta a un conjunto de plantillas.
Por ejemplo, puedes encontrar problemas que se repiten en:
- Todas las entradas del blog.
- Las fichas de producto.
- Las categorías.
- Las páginas creadas con una plantilla concreta.
- Determinadas páginas móviles.
Search Console no sustituye al diagnóstico técnico. Su función principal es ayudarte a localizar dónde existe el problema. Después tendrás que analizar URLs representativas con herramientas más específicas. Google recomienda utilizar su informe de Core Web Vitals para consultar el rendimiento real de las páginas.
Lighthouse y las pruebas de laboratorio
Lighthouse permite analizar una página en unas condiciones controladas. Es útil para:
- Repetir pruebas.
- Comparar cambios.
- Localizar oportunidades.
- Revisar recursos.
- Detectar problemas durante la carga inicial.
La ventaja del laboratorio es la repetibilidad. La limitación es que una única prueba no reproduce todas las conexiones, dispositivos, interacciones y situaciones reales de los visitantes.
Qué páginas conviene analizar además de la portada
Uno de los errores más habituales es medir únicamente la página de inicio.
En una web corporativa también revisaría:
- Una página de servicio.
- La página de contacto.
- Una landing page importante.
- Un artículo.
- Una categoría.
- Una página con formulario.
En una tienda online añadiría:
- Una ficha de producto.
- Una categoría.
- El carrito.
- El proceso de pago.
- Una página con filtros.
- Una página de cuenta.
Cada plantilla carga recursos diferentes. Una portada rápida no garantiza que el carrito, las fichas o los formularios funcionen igual de bien.
Cómo comparar los resultados antes y después
Antes de modificar nada, guarda:
- La URL analizada.
- La fecha.
- La puntuación de laboratorio.
- Los valores de LCP, INP y CLS disponibles.
- El elemento LCP.
- Las principales advertencias.
- Capturas del informe.
- Las condiciones de la prueba.
Después aplica un grupo pequeño de cambios y repite la medición.
No cambies diez cosas al mismo tiempo. Si el resultado mejora o empeora, necesitarás saber qué modificación lo ha provocado.
Datos de campo y datos de laboratorio: por qué no muestran siempre lo mismo
Los datos de campo y de laboratorio pueden ofrecer resultados diferentes sin que ninguno de los dos sea necesariamente incorrecto.
Qué reflejan los datos de usuarios reales
Los datos de campo representan visitas reales realizadas con diferentes:
- Dispositivos.
- Navegadores.
- Conexiones.
- Ubicaciones.
- Estados de caché.
- Formas de navegar.
Por esa razón, reflejan una experiencia más diversa. También necesitan acumular suficiente información y no reaccionan inmediatamente a cada cambio.
Para qué sirven las pruebas realizadas en un entorno controlado
Las pruebas de laboratorio se ejecutan en unas condiciones predeterminadas.
Son útiles para localizar causas porque permiten repetir un escenario parecido después de cada modificación. Sin embargo, no pueden reproducir todas las situaciones que experimentan los usuarios reales.
Por qué PageSpeed Insights puede ofrecer resultados distintos
Una prueba puede cambiar por:
- Variaciones en la respuesta del servidor.
- Recursos servidos desde caché.
- Scripts externos.
- Carga de terceros.
- Diferencias en la red.
- Procesos ejecutándose en el servidor.
- Cambios en el contenido.
Además, los datos de campo representan un periodo acumulado, mientras que el laboratorio muestra una ejecución concreta. Google explica que las diferencias entre ambos tipos de medición son normales y que deben utilizarse de forma complementaria.
Mi recomendación es utilizar el laboratorio para diagnosticar y los datos de campo para comprobar cómo está funcionando la web para usuarios reales.
Cómo diagnosticar qué está perjudicando las Core Web Vitals
La optimización debería empezar con un diagnóstico, no con la instalación de un plugin.
Identifica primero la métrica que está fallando
Si falla el LCP, pregunta:
- ¿Cuál es el elemento principal?
- ¿Cuándo comienza a descargarse?
- ¿Está comprimido?
- ¿Tiene lazy loading?
- ¿Lo retrasa el CSS?
- ¿El servidor responde tarde?
Si falla el INP:
- ¿Qué interacción es lenta?
- ¿Qué script se ejecuta?
- ¿Hay tareas largas?
- ¿Interviene un plugin?
- ¿El problema aparece en móvil?
- ¿Hay herramientas de terceros?
Si falla el CLS:
- ¿Qué elemento se desplaza?
- ¿Qué contenido aparece tarde?
- ¿Se ha reservado espacio?
- ¿Cambian las fuentes?
- ¿Interviene un banner?
- ¿Sucede después de hacer scroll?
Localiza el elemento, script o cambio de diseño responsable
No basta con saber que el LCP es lento. Hay que identificar el elemento concreto.
Tampoco basta con saber que el INP es deficiente. Necesitamos localizar qué interacción está bloqueada.
Las herramientas de desarrollo del navegador pueden mostrar:
- Solicitudes de red.
- Prioridad de los recursos.
- Tareas largas.
- Ejecución de JavaScript.
- Cambios de diseño.
- Archivos CSS.
- Scripts cargados por cada plugin.
En proyectos complejos, este paso puede requerir conocimientos técnicos, pero incluso un análisis básico ayuda a evitar cambios al azar.
Separa los problemas de WordPress de los problemas del servidor
Esta distinción resulta fundamental.
Los problemas de WordPress pueden proceder de:
- Plugins.
- Tema.
- Constructor.
- Imágenes.
- JavaScript.
- CSS.
- Consultas.
- Funciones dinámicas.
Los problemas del servidor pueden estar relacionados con:
- Recursos insuficientes.
- Saturación.
- Configuración de PHP.
- Caché de servidor.
- Base de datos.
- Almacenamiento.
- Procesamiento.
- Distancia geográfica.
WordPress está construido principalmente con PHP, obtiene información de la base de datos y genera contenido que el navegador puede interpretar. Por eso, tanto la configuración del software como el servidor influyen en el rendimiento.
Prioriza las mejoras según su impacto real
Yo empezaría por los problemas que:
- Afectan a más páginas.
- Perjudican a usuarios móviles.
- Bloquean acciones importantes.
- Tienen una solución clara.
- Pueden corregirse sin romper funcionalidades.
- Influyen en el contenido visible inicialmente.
Optimizar un icono pequeño mientras la imagen principal pesa varios megabytes no es una buena prioridad.
Cómo mejorar el LCP en WordPress
El LCP depende de varias etapas. El servidor debe responder, el navegador debe descubrir el recurso, descargarlo y mostrarlo.
Por eso, no existe una solución única.
Optimiza la imagen o el bloque principal de la página
Si el elemento LCP es una imagen:
- Ajusta sus dimensiones.
- Comprime el archivo.
- Utiliza un formato eficiente.
- Evita servir una imagen mucho mayor que el espacio disponible.
- Comprueba la versión móvil.
- Revisa si se utiliza como fondo CSS.
Una fotografía de 2500 píxeles no debería servirse sin necesidad en un espacio de 700 píxeles.
Si el LCP es texto, revisa:
- Las fuentes.
- El CSS.
- Los estilos del constructor.
- Los recursos que retrasan el renderizado.
- La forma en que se carga el bloque principal.
Evita aplicar carga diferida al elemento LCP
La carga diferida o lazy loading resulta útil para imágenes situadas más abajo en la página.
Sin embargo, aplicarla a la imagen principal puede retrasar su descarga. El navegador espera antes de solicitarla, aunque sea uno de los recursos más importantes.
La documentación de web.dev recomienda evitar loading="lazy" en la imagen LCP y, cuando corresponda, asignarle una prioridad elevada mediante fetchpriority="high".
Esto no significa que debas añadir prioridad alta a todas las imágenes. Si todo es prioritario, nada lo es.
Reduce los recursos que bloquean el renderizado
El navegador necesita procesar determinados archivos antes de mostrar la página.
Un exceso de CSS o JavaScript puede retrasar el contenido principal. Conviene revisar:
- CSS que no se utiliza.
- Estilos cargados por plugins.
- Librerías completas para una función pequeña.
- Scripts situados demasiado pronto.
- Archivos duplicados.
- Código cargado en páginas donde no se necesita.
La solución no consiste siempre en unir o minificar todos los archivos. En configuraciones modernas, combinar recursos puede aportar poco o incluso dificultar la depuración.
Revisa las fuentes y el CSS necesario para mostrar el contenido inicial
Las fuentes externas pueden retrasar la visualización del texto.
Algunas opciones son:
- Alojar las fuentes localmente cuando tenga sentido.
- Reducir familias y variantes.
- Precargar únicamente las fuentes críticas.
- Utilizar una fuente de sustitución compatible.
- Evitar cargar pesos que no se usan.
- Revisar
font-display.
No conviene precargar todas las fuentes. Cada recurso prioritario compite con otros elementos importantes.
Mejora el tiempo de respuesta del servidor
Si la respuesta inicial llega tarde, todos los recursos empiezan a cargarse tarde.
En ese caso, revisaría:
- El plan de hosting.
- La versión y configuración de PHP.
- La caché de página.
- La caché de objetos.
- La base de datos.
- Las consultas lentas.
- Las llamadas externas.
- Los procesos programados.
- Los límites de recursos.
La documentación oficial de WordPress incluye el hosting, la configuración de WordPress, la caché, la base de datos y el software del servidor entre los factores que deben considerarse al optimizar el rendimiento.
Comprueba si el tema o el constructor retrasan el contenido principal
Algunos diseños cargan:
- Sliders.
- Animaciones.
- Vídeos.
- Fondos.
- Capas.
- Fuentes.
- Iconos.
- Scripts.
- Estilos globales.
Todo ello puede retrasar el elemento principal.
Antes de sustituir el tema, comprueba si puedes simplificar la primera pantalla. Muchas veces, reducir un slider, eliminar una animación o sustituir un vídeo automático por una imagen ofrece una mejora más razonable que reconstruir toda la web.
Cómo mejorar el INP en WordPress
El INP se ve afectado cuando el navegador está demasiado ocupado para responder rápidamente.
Reduce el JavaScript que se ejecuta sin necesidad
No todo el JavaScript que carga una página es imprescindible.
WordPress puede acumular scripts procedentes de:
- Plugins.
- El tema.
- Constructores.
- Formularios.
- Analítica.
- Publicidad.
- Redes sociales.
- Mapas.
- Chats.
- Sistemas de consentimiento.
Cada archivo puede añadir trabajo al navegador. El problema no es únicamente cuánto pesa, sino cuánto tarda en descargarse, analizarse y ejecutarse.
Retrasa o limita los scripts de terceros
Los scripts externos tienen una particularidad: no controlamos completamente su funcionamiento.
Conviene revisar si realmente necesitas:
- Todos los píxeles.
- Varios sistemas de analítica.
- Widgets sociales.
- Mapas cargados desde el inicio.
- Chats en todas las páginas.
- Vídeos incrustados directamente.
- Herramientas de personalización.
En algunos casos pueden cargarse después de una interacción o únicamente en las páginas donde son necesarios.
No es correcto afirmar que una web es lenta porque tiene muchos plugins.
Diez plugins sencillos pueden generar menos trabajo que uno especialmente pesado.
Hay que medir:
- Qué scripts carga cada plugin.
- En qué páginas aparecen.
- Qué consultas realiza.
- Si añade llamadas externas.
- Si duplica funciones.
- Si ejecuta procesos en cada visita.
Las tareas largas de JavaScript pueden bloquear el hilo principal e impedir que el navegador muestre una respuesta rápida después de una interacción. Dividir el trabajo, reducirlo o retirarlo ayuda a mejorar la capacidad de respuesta.
No analices solo la carga inicial.
Prueba la web como lo haría un usuario:
- Abre el menú.
- Cambia de pestaña.
- Utiliza los filtros.
- Completa el formulario.
- Abre un desplegable.
- Añade un producto.
- Cambia una variación.
- Acepta las cookies.
Una página puede cargar rápido y responder mal después.
Revisa el carrito y las interacciones de WooCommerce
WooCommerce necesita actualizar información de precios, productos, stock, impuestos, carrito y sesión.
Antes de desactivar funciones, identifica qué interacción es lenta.
En ocasiones, el problema no está en WooCommerce en general, sino en:
- Un plugin de variaciones.
- Un filtro.
- Una extensión.
- Una pasarela.
- El tema.
- Un script de seguimiento.
- Una consulta.
- Una personalización.
Evita cargar los mismos recursos en todas las páginas
Un formulario de contacto no necesita cargar su código en cada artículo si solo aparece en una página.
Lo mismo ocurre con:
- Sliders.
- Galerías.
- Mapas.
- Reservas.
- Tablas.
- Comparadores.
- Filtros.
- Funciones de tienda.
La carga condicional de recursos puede reducir el trabajo del navegador, aunque debe aplicarse con cuidado para no romper dependencias.
Cómo reducir el CLS en WordPress
El CLS suele ser uno de los problemas más visibles para el usuario.
Define las dimensiones de imágenes, vídeos y contenidos incrustados
El navegador necesita saber cuánto espacio ocupará cada elemento antes de descargarlo.
Añadir dimensiones o reservar una proporción permite mantener estable el diseño.
Esto afecta a:
- Imágenes.
- Vídeos.
- Iframes.
- Mapas.
- Publicaciones sociales.
- Banners.
- Anuncios.
- Galerías.
La recomendación general es proporcionar atributos de anchura y altura o reservar el espacio necesario mediante CSS.
Cuando un banner aparece después de que el contenido ya se ha colocado, puede desplazar toda la página.
Las alternativas dependen del diseño:
- Reservar espacio.
- Utilizar un contenedor con altura mínima.
- Mostrar el elemento superpuesto cuando sea adecuado.
- Colocarlo más abajo.
- Evitar inserciones automáticas en la parte superior.
Los avisos de cookies merecen una revisión especial. Si cambian el tamaño de la cabecera o empujan el contenido, pueden generar desplazamientos importantes.
Evita que las fuentes modifiquen el tamaño del texto al cargar
Una fuente de sustitución puede ocupar un espacio diferente al de la fuente definitiva.
Cuando se produce el cambio, los títulos y párrafos pueden modificar su altura.
Para reducirlo:
- Elige una fuente alternativa parecida.
- Reduce el número de fuentes.
- Revisa
font-display. - Ajusta las métricas de la fuente de sustitución.
- Precarga solo las fuentes verdaderamente críticas.
Revisa cabeceras, sliders y bloques dinámicos
Los sliders son candidatos habituales a provocar CLS si las diapositivas no comparten dimensiones.
También conviene revisar:
- Cabeceras adhesivas.
- Barras promocionales.
- Contadores.
- Formularios.
- Mensajes.
- Productos recomendados.
- Bloques de valoración.
- Contenido personalizado.
Comprueba los cambios de diseño en móvil
Un diseño estable en ordenador puede moverse en móvil porque:
- Cambia el menú.
- Se apilan columnas.
- Aparece una barra inferior.
- Se modifica el banner.
- Las imágenes tienen otra proporción.
- Se insertan elementos adicionales.
Prueba la página completa, no únicamente la primera pantalla.
Cómo optimizar las imágenes de WordPress
Las imágenes suelen tener un impacto importante, pero no conviene reducir la optimización a convertir todos los archivos a un formato moderno.
Elige entre WebP, AVIF y los formatos tradicionales
WebP y AVIF pueden reducir el peso respecto a formatos tradicionales en determinadas imágenes, pero el resultado depende del contenido y de la compresión.
Lo importante es servir un archivo adecuado y compatible, no utilizar un formato por obligación.
Ajusta las dimensiones antes de subir una imagen
WordPress puede generar varios tamaños, pero eso no justifica subir archivos enormes sin necesidad.
Antes de publicar:
- Recorta la imagen.
- Ajusta sus dimensiones.
- Comprímela.
- Comprueba su calidad.
- Añade un texto alternativo descriptivo cuando corresponda.
Comprime sin deteriorar innecesariamente la calidad
La compresión debe mantener un equilibrio.
Una imagen ligeramente más pesada puede ser preferible si representa un producto, un proyecto o un trabajo visual donde la calidad sea importante.
Aplica lazy loading solo donde corresponde
La carga diferida es útil para recursos situados fuera de la zona visible inicial.
No debería retrasar la imagen principal ni otros recursos necesarios para mostrar la primera pantalla.
Evita servir imágenes más grandes de lo necesario
Comprueba que el navegador reciba una versión adecuada para cada tamaño de pantalla.
Una imagen que se muestra a 400 píxeles no debería obligar al usuario a descargar un archivo de 2000 píxeles salvo que exista una justificación clara.
Caché en WordPress: qué puede mejorar y qué no
Uno de los errores más habituales es pensar que mejorar las Core Web Vitals consiste únicamente en instalar un plugin de caché y activar todas sus opciones.
En algunos proyectos puede ayudar mucho, pero no siempre resuelve el problema.
La caché puede actuar en varios niveles.
La caché de página guarda una versión preparada del contenido para evitar generar la misma respuesta en cada visita.
La caché del navegador permite reutilizar recursos que ya se han descargado.
La caché de servidor y de objetos puede reducir procesamiento y consultas.
WordPress reconoce la caché como una de las vías principales para reducir la carga de procesamiento, especialmente en páginas relativamente estáticas.
Por qué instalar un plugin no resuelve todos los problemas
Un plugin de caché no puede corregir automáticamente:
- Una imagen de varios megabytes.
- Un tema sobrecargado.
- JavaScript innecesario.
- Un plugin mal programado.
- Un slider complejo.
- Un aviso que desplaza el contenido.
- Un servidor saturado.
- Una fuente mal configurada.
La caché es una herramienta, no un diagnóstico.
El riesgo de activar todas las opciones sin comprobarlas
En mi experiencia, activar indiscriminadamente minificación, combinación, retraso, eliminación de CSS y carga diferida puede crear problemas nuevos.
Por ejemplo:
- Menús que dejan de abrirse.
- Formularios que no envían.
- Carritos que no se actualizan.
- Estilos que aparecen tarde.
- Elementos que parpadean.
- Errores de JavaScript.
Activa una opción, limpia la caché, revisa la web y vuelve a medir.
Cómo probar la minificación y el retraso de JavaScript
Prueba primero en un entorno seguro.
Después revisa:
- Portada.
- Menús.
- Formularios.
- Cookies.
- Cuenta de usuario.
- Carrito.
- Pago.
- Buscador.
- Filtros.
- Versión móvil.
Cuándo una configuración de caché puede romper la web
Las páginas dinámicas requieren exclusiones.
En tiendas y áreas privadas, determinadas páginas no deberían servirse igual para todos los usuarios.
Una configuración copiada de otra web puede no ser adecuada para tu instalación.
Cómo influyen los plugins y el tema en el rendimiento
Los plugins y el tema determinan gran parte de lo que WordPress carga y ejecuta.
Detecta plugins innecesarios, duplicados o mal optimizados
Empieza con un inventario:
- Qué hace cada plugin.
- Si sigue siendo necesario.
- Si su función se repite.
- En qué páginas carga recursos.
- Cuándo se actualizó.
- Si tiene errores.
- Si añade llamadas externas.
No elimines un plugin únicamente porque una herramienta lo menciona. Investiga qué función cumple.
Revisa el impacto de Elementor, Divi y otros constructores
Los constructores permiten crear diseños complejos sin programar todo desde cero, pero también pueden añadir capas, estilos, scripts y elementos.
No siempre es necesario sustituirlos.
Primero simplifica:
- Estructuras anidadas.
- Animaciones.
- Widgets.
- Fuentes.
- Iconos.
- Sliders.
- Fondos.
- Efectos.
No confundas el número de plugins con su impacto real
La pregunta correcta no es “¿cuántos plugins tengo?”, sino “¿qué trabajo genera cada uno?”.
Un plugin pequeño y bien desarrollado puede tener un impacto mínimo. Una extensión compleja puede afectar a todas las páginas.
Prueba los cambios en un entorno seguro
Antes de eliminar, sustituir o actualizar componentes importantes:
- Realiza una copia.
- Utiliza staging.
- Comprueba las funciones.
- Revisa el diseño.
- Mide antes y después.
- Vigila los errores.
Cómo afecta el hosting a las Core Web Vitals
WordPress necesita ejecutar PHP, consultar la base de datos, leer archivos y generar la respuesta que recibe el visitante.
Si el servidor está saturado, utiliza almacenamiento lento o no dispone de recursos suficientes, cada una de esas operaciones puede tardar más.
Qué ocurre cuando WordPress ejecuta PHP y consulta la base de datos
Cuando llega una solicitud, WordPress debe interpretar qué contenido se necesita, recuperar información y construir la respuesta.
Los plugins y el tema pueden añadir:
- Consultas.
- Llamadas externas.
- Procesamiento.
- Comprobaciones.
- Reglas.
- Personalizaciones.
Un servidor rápido no elimina ese trabajo, pero puede ejecutarlo en mejores condiciones.
Cómo influye el tiempo de respuesta inicial en el LCP
El contenido principal no puede mostrarse hasta que el navegador empieza a recibir la página y descubre sus recursos.
Si el servidor responde tarde, la descarga de imágenes, CSS, JavaScript y fuentes también comienza tarde.
Señales de que el servidor puede estar limitando la web
Algunas señales son:
- Administración lenta.
- Respuestas variables.
- Errores por falta de recursos.
- Procesos que se interrumpen.
- Picos de lentitud.
- Tiempos iniciales elevados en páginas sencillas.
- Mejora notable al servir una versión en caché.
Estas señales no sustituyen a una medición del servidor, pero ayudan a orientar el diagnóstico.
Qué debería ofrecer un hosting preparado para WordPress
Yo revisaría:
- Recursos suficientes.
- Almacenamiento rápido.
- Versiones adecuadas de PHP.
- Caché de servidor.
- Copias de seguridad.
- Certificado SSL.
- Monitorización.
- Soporte técnico.
- Medidas de seguridad.
- Posibilidad de ampliar recursos.
En HostingTG trabajamos con un servicio específico de hosting WordPress para ofrecer una base estable sobre la que optimizar la web.
Por qué un buen servidor tampoco corrige una web mal optimizada
El hosting no puede corregir una imagen de varios megabytes ni un plugin mal programado.
Tampoco elimina automáticamente el JavaScript, reserva espacio para un banner o reorganiza el CSS.
Por eso creo que la optimización debe abordarse de forma conjunta: hay que revisar WordPress, pero también el hosting sobre el que funciona.
Core Web Vitals en WooCommerce y webs con funciones avanzadas
Una tienda, un sistema de reservas o una web con área privada necesitan realizar más tareas que una página estática.
Por qué una tienda online presenta más desafíos
WooCommerce gestiona:
- Productos.
- Variaciones.
- Precios.
- Stock.
- Sesiones.
- Carrito.
- Impuestos.
- Pagos.
- Cuenta del usuario.
El objetivo no debe ser convertir toda la tienda en contenido estático, sino optimizar las partes que puedan almacenarse o simplificarse sin interferir en las funciones dinámicas.
Carrito, proceso de pago y actualizaciones dinámicas
Analiza las interacciones críticas:
- Añadir al carrito.
- Cambiar cantidades.
- Seleccionar variantes.
- Calcular gastos.
- Aplicar cupones.
- Completar el pago.
Una tienda puede tener un buen LCP y, sin embargo, ofrecer un INP deficiente durante estas acciones.
Chats, reservas, mapas y herramientas de seguimiento
Estas herramientas pueden ser necesarias.
Antes de eliminarlas:
- Comprueba su uso.
- Mide su impacto.
- Limita las páginas donde cargan.
- Retrasa su ejecución si es posible.
- Busca una alternativa más ligera.
- Valora el beneficio comercial.
Cómo equilibrar funcionalidad, velocidad y conversión
No tiene sentido eliminar una función que genera ventas únicamente para ganar unos puntos.
La pregunta adecuada es:
¿Podemos mantener esta funcionalidad reduciendo su impacto?
Ese enfoque suele producir decisiones más útiles que perseguir una web técnicamente vacía.
¿Es necesario conseguir 100 puntos en PageSpeed Insights?
También creo que existe cierta obsesión con alcanzar una puntuación de 100.
La puntuación es útil para detectar problemas, comparar configuraciones y orientar el trabajo, pero no debería convertirse en el único objetivo.
Una buena puntuación no siempre significa una buena experiencia
Una prueba de laboratorio analiza unas condiciones concretas.
El usuario real puede utilizar:
- Otro dispositivo.
- Una conexión peor.
- Un navegador diferente.
- Una página distinta.
- Una función no probada.
- Un flujo más largo.
Por eso, una buena nota no garantiza automáticamente una experiencia perfecta.
Por qué no conviene eliminar funciones necesarias
Una web puede obtener una puntuación algo inferior debido a:
- Una tienda.
- Un sistema de reservas.
- Un chat.
- Un formulario.
- Un mapa.
- Una herramienta de analítica.
Eliminarlo todo puede mejorar una cifra y empeorar el negocio.
Qué problemas deberían tener prioridad
Prioriza los problemas que:
- Afectan a la mayoría de los usuarios.
- Bloquean acciones.
- Provocan movimientos.
- Retrasan el contenido principal.
- Se repiten en muchas páginas.
- Pueden corregirse con un riesgo razonable.
Cómo definir un objetivo realista
El objetivo debería ser conseguir buenos valores de Core Web Vitals para la mayoría de las visitas, mantener las funciones importantes y ofrecer una experiencia fluida.
Google también advierte que obtener buenos resultados en los informes de rendimiento no garantiza ocupar las primeras posiciones.
Errores frecuentes al optimizar las Core Web Vitals en WordPress
Instalar varios plugins que realizan la misma función
Dos sistemas de caché, varias herramientas de minificación o diferentes plugins de imágenes pueden entrar en conflicto.
Activar todas las optimizaciones al mismo tiempo
Si algo se rompe o empeora, no sabrás qué opción lo provocó.
Analizar únicamente la portada
Las páginas de producto, servicio, contacto, carrito y pago pueden cargar recursos diferentes.
Optimizar solo para ordenador
Los problemas suelen ser más visibles en teléfonos con menor potencia o conexiones más lentas.
Culpar al hosting sin revisar WordPress
Cambiar de servidor no solucionará automáticamente el código, las imágenes ni los plugins.
Cambiar de hosting esperando que desaparezca todo
Una infraestructura mejor puede reducir tiempos de procesamiento, pero la web seguirá necesitando optimización.
Perseguir una puntuación perfecta
La optimización debería reducir esperas y frustraciones, no producir una captura bonita para compartir.
Cómo evitar que WordPress vuelva a ponerse lento
Las Core Web Vitals no son algo que se revisa una sola vez.
WordPress cambia continuamente.
Revisa el rendimiento después de cada cambio importante
Vuelve a medir después de:
- Cambiar el tema.
- Instalar un plugin.
- Modificar la portada.
- Añadir un chat.
- Incorporar publicidad.
- Cambiar el sistema de cookies.
- Actualizar WooCommerce.
- Añadir una herramienta externa.
Controla las actualizaciones de plugins y del tema
Una actualización puede mejorar el rendimiento, pero también puede añadir funciones, estilos o scripts.
No se trata de evitar las actualizaciones, sino de comprobar el resultado.
Optimiza las nuevas imágenes antes de publicarlas
Una web bien optimizada puede volver a empeorar si se empiezan a subir fotografías enormes.
Conviene establecer un proceso editorial claro.
Elimina herramientas y scripts que ya no se utilizan
Con el tiempo se acumulan:
- Píxeles.
- Formularios antiguos.
- Widgets.
- Plugins desactivados.
- Códigos de campañas.
- Integraciones.
- Fuentes.
Revisa la base de datos, las revisiones y las tareas programadas
No recomiendo limpiar la base de datos de forma agresiva ni automática.
Primero realiza una copia y comprueba qué datos se eliminarán.
Mantén un historial de mediciones y cambios
Anota:
- Qué se modificó.
- Cuándo.
- Qué páginas fueron afectadas.
- Qué valores cambiaron.
- Si apareció algún error.
La monitorización continua en laboratorio y en datos de campo ayuda a detectar tendencias negativas y regresiones de rendimiento.
Dentro de nuestro servicio de mantenimiento web WordPress, revisamos actualizaciones, seguridad y problemas que pueden afectar al funcionamiento general de la página.
Cómo afectan las Core Web Vitals al negocio
Mejorar estas métricas no debería plantearse únicamente como una tarea SEO.
Una web lenta puede hacer que el visitante abandone
Un posible cliente puede salir antes de:
- Conocer el servicio.
- Leer una oferta.
- Consultar un precio.
- Ver un proyecto.
- Completar una compra.
- Enviar un formulario.
No hace falta prometer una mejora concreta de ventas para entender que reducir obstáculos facilita la navegación.
El rendimiento influye en formularios, carritos y compras
En una tienda, una respuesta lenta puede afectar al carrito y al pago.
En una web corporativa, puede dificultar el envío de formularios.
En un blog, puede impedir que el lector continúe navegando.
Una página rápida y estable transmite confianza
Una web que responde bien parece cuidada.
Una página estable evita errores.
Una carga rápida reduce la sensación de espera.
En mi caso, esta es una de las razones principales para prestar atención a las Core Web Vitals: ayudan a detectar problemas que el visitante quizá no sabe explicar, pero sí percibe.
Mejorar la experiencia tiene valor aunque no se piense solo en Google
Las Core Web Vitals deben verse como una oportunidad para mejorar la relación entre la web y sus usuarios.
El SEO es importante, pero la página también debe resultar útil para quien ya ha llegado.
Lista de comprobación para optimizar las Core Web Vitals
Antes de realizar cambios
- Analiza varias plantillas.
- Guarda las mediciones.
- Identifica la métrica afectada.
- Localiza el elemento responsable.
- Revisa móvil y ordenador.
- Crea una copia de seguridad.
- Prepara un entorno de pruebas.
Durante la optimización
- Aplica pocos cambios cada vez.
- Limpia la caché.
- Comprueba el diseño.
- Prueba formularios y menús.
- Revisa el carrito y el pago.
- Comprueba los errores.
- Mide de nuevo.
Después de aplicar las mejoras
- Compara resultados.
- Revisa las páginas principales.
- Comprueba datos de campo cuando estén disponibles.
- Documenta los cambios.
- Vigila posibles regresiones.
- No des por terminado el trabajo tras una única prueba.
En las revisiones periódicas
- Controla actualizaciones.
- Revisa nuevos plugins.
- Optimiza imágenes.
- Elimina scripts antiguos.
- Comprueba las páginas de negocio.
- Repite las mediciones.
- Verifica que no se hayan perdido funciones.
Optimizar WordPress no consiste solo en mejorar una puntuación
Las Core Web Vitals han conseguido que muchas empresas presten atención a un aspecto que durante años se trató como secundario.
No deberían verse como una exigencia técnica impuesta por Google, sino como una forma de analizar la experiencia real de las personas.
Ahora bien, no existen soluciones automáticas que funcionen igual en todos los proyectos.
Cada WordPress utiliza un tema, una combinación de plugins, un servidor y unas funcionalidades diferentes. Por eso, antes de aplicar cambios indiscriminadamente, conviene identificar qué está provocando realmente la lentitud, el bloqueo o la inestabilidad.
Un plugin de caché puede ayudar, pero no lo soluciona todo.
Un buen hosting ofrece una base más estable, pero no corrige una imagen pesada ni un script mal configurado.
Una puntuación alta resulta útil, pero no debería conseguirse a costa de eliminar funciones necesarias.
Y una optimización puntual puede perderse si no existe mantenimiento.
Al final, mejorar las Core Web Vitals en WordPress no consiste únicamente en subir una nota. Consiste en ofrecer una página más rápida, estable y cómoda para que el visitante encuentre lo que busca sin esperas ni obstáculos.
Dudas de la comunidad
¿Qué son las Core Web Vitals en WordPress?
Son tres métricas que permiten evaluar el rendimiento de carga, la capacidad de respuesta y la estabilidad visual de una página creada con WordPress.
¿Cuáles son las tres métricas principales?
Las métricas actuales son LCP, INP y CLS. El LCP mide la carga del contenido principal, el INP evalúa la respuesta a las interacciones y el CLS analiza los desplazamientos inesperados.
¿Las Core Web Vitals afectan al posicionamiento?
Forman parte de los aspectos relacionados con la experiencia de página, pero no son el único elemento que interviene en la búsqueda. Tener buenos resultados no garantiza aparecer en las primeras posiciones.
¿Un plugin de caché puede solucionar todos los problemas?
No. Puede reducir procesamiento y mejorar la entrega de páginas, pero no corrige automáticamente imágenes pesadas, JavaScript excesivo, desplazamientos visuales, temas complejos o servidores saturados.
¿Cómo afecta el hosting al rendimiento de WordPress?
El servidor ejecuta PHP, consulta la base de datos y genera las respuestas. Una infraestructura lenta puede retrasar el comienzo de la carga, aunque cambiar de hosting no sustituye a la optimización de WordPress.
¿Por qué PageSpeed Insights ofrece resultados diferentes?
Porque las pruebas pueden realizarse bajo condiciones distintas y porque los datos de campo y de laboratorio representan situaciones diferentes.
¿Es necesario alcanzar 100 puntos en PageSpeed?
No. Es más importante solucionar los problemas que afectan al usuario y mantener las funciones necesarias que perseguir una puntuación perfecta.
¿Qué páginas de WordPress se deberían analizar?
Además de la portada, conviene revisar páginas de servicios, artículos, categorías, formularios, productos, carrito, pago y cualquier plantilla importante para el negocio.
¿Cada cuánto conviene revisar las Core Web Vitals?
De forma periódica y después de cambios relevantes, como actualizaciones, nuevos plugins, modificaciones del tema o incorporación de herramientas externas.
¿Se deben eliminar chats, reservas o herramientas externas?
No necesariamente. Primero hay que medir su impacto, valorar su utilidad y comprobar si pueden cargarse solo cuando sean necesarias o de una forma más eficiente.
Opinión Personal
Las Core Web Vitals han sido positivas porque han obligado a prestar atención a un aspecto que durante mucho tiempo se dejó en segundo plano: la experiencia real de las personas que visitan una página web.
Antes parecía suficiente con que una web funcionara, mostrara sus contenidos y permitiera completar las acciones básicas. Sin embargo, una página puede funcionar técnicamente y, al mismo tiempo, resultar lenta, incómoda o frustrante. Si el contenido principal tarda en aparecer, los botones no responden con rapidez o los elementos cambian de posición mientras intentamos pulsarlos, la experiencia deja mucho que desear.
Lo que más valoro de estas métricas es que convierten esas sensaciones en datos que podemos analizar. El LCP nos ayuda a comprobar cuándo aparece el contenido principal, el INP permite valorar cómo responde la página ante las interacciones y el CLS refleja si el diseño se mantiene estable durante la carga.
Ahora bien, también creo que se ha generado una obsesión excesiva por conseguir puntuaciones perfectas. Alcanzar 100 puntos en PageSpeed Insights puede resultar satisfactorio, pero no debería convertirse en el objetivo principal de una web.
Una tienda online, un sistema de reservas, un chat o un formulario avanzado pueden añadir carga, pero también cumplen una función importante para el negocio. No tiene sentido eliminar herramientas necesarias únicamente para mejorar una cifra. Lo razonable es medir su impacto, optimizarlas y encontrar un equilibrio entre velocidad, diseño, funcionalidad y facilidad de uso.
Tampoco comparto la idea de que todos los problemas puedan solucionarse instalando un plugin de caché. La caché puede ayudar, pero no corrige por sí sola una imagen de varios megabytes, un tema sobrecargado, un exceso de JavaScript, un plugin mal desarrollado o un servidor lento.
En cada proyecto conviene analizar primero qué está causando el problema. A veces será una imagen principal mal optimizada; otras, un script externo, una fuente, un constructor visual o la propia infraestructura del hosting. Aplicar cambios indiscriminadamente puede generar incompatibilidades sin mejorar realmente la experiencia.
Además, la optimización no debería considerarse un trabajo que se realiza una sola vez. WordPress cambia constantemente: se actualizan los plugins, se añaden nuevas imágenes, se modifican páginas y se incorporan funcionalidades. Cualquiera de estos cambios puede afectar al rendimiento.
Por eso considero que las Core Web Vitals deben formar parte del mantenimiento habitual de una web. No solo por el posicionamiento, sino porque una página rápida, estable y capaz de responder correctamente transmite más confianza y facilita que el usuario continúe navegando.
Al final, optimizar las Core Web Vitals no consiste en superar un examen de Google. Consiste en eliminar esperas, movimientos y bloqueos para que las personas encuentren lo que buscan sin obstáculos.
¿Tú también revisas las Core Web Vitals de tu WordPress? ¿Has conseguido mejorar el rendimiento con algún cambio concreto o sigues teniendo problemas con el LCP, el INP o el CLS? Cuéntame tu experiencia en los comentarios; será interesante conocer qué soluciones te han funcionado y qué dificultades has encontrado.
