Cómo mejorar el rendimiento web en WordPress (guía práctica)

Cómo dejo una web WordPress rápida: mido con datos reales, aseguro servidor y caché, pongo a raya el JavaScript de terceros y llevo LCP, INP y CLS a verde. Con checklists y con lo que medimos al quitar Elementor de nuestra propia web.

1)Auditoría exprés: mide antes de tocar (PSI, Lighthouse, GTmetrix, WebPageTest)

Antes de optimizar, necesito una foto «antes». Es el mismo punto de partida de una auditoría web en condiciones: medir para saber qué tocar. Yo sigo este ritual rápido:

Datos de campo y de laboratorio: no son lo mismo

• Campo: lo que viven tus usuarios reales (informe CrUX de Chrome, percentil 75 de los últimos 28 días). Es lo que usa Google. Lo ves arriba del todo en PageSpeed Insights y en el informe «Métricas web principales» de Search Console.
• Laboratorio: una simulación de Lighthouse en un móvil lento. Sirve para encontrar la causa y comparar antes/después, pero varía entre pasadas.
• Si tu web tiene poco tráfico, no habrá datos de campo: trabaja con laboratorio y repite cada prueba.

Entorno de prueba

• Móvil primero, red simulada 4G y sin sesión iniciada.
• Navegador limpio, modo incógnito, desactivo extensiones.
• Tres pasadas mínimas por herramienta para sacar un promedio (PSI, Lighthouse en Chrome, GTmetrix y WebPageTest).

Qué anoto en la línea base

• Core Web Vitals:
  • LCP (Largest Contentful Paint) objetivo ≤ 2,5 s.
  • INP (Interaction to Next Paint) objetivo ≤ 200 ms.
  • CLS (Cumulative Layout Shift) objetivo ≤ 0,1.
• Apoyo: TTFB, FCP, Speed Index, TBT.
• Páginas clave: home, landings principales, post más leído y plantilla de producto si es tienda. En nuestra web miro 10.

Mapa de calor del rendimiento

• Localizo el LCP real (suele ser la imagen hero o el H1).
• Marco scripts de terceros (Analytics, Tag Manager, chat, píxeles) y cuántos KB de JS/CSS cargan por página.
• Compruebo que la página no se desplaza sola al cargar. Si lo hace, el hero sale de pantalla y PageSpeed puede dar «sin LCP».
• Si la web está hecha con un page builder, reviso el anidamiento y los widgets pesados (sliders, formularios complejos, mapas, librerías de iconos enteras).

Umbrales de CWV y métricas de apoyo

• LCP: impacta la sensación de «carga rápida». Ataca servidor, hero y CSS crítico.
• INP: mide cuánto tarda la página en responder a cada clic o toque. Sustituyó a FID en marzo de 2024: si una guía te habla de FID, está desfasada. Culpa típica: JS pesado.
• CLS: saltos de diseño. Culpa típica: imágenes sin dimensiones, fuentes, banners e iframes sin reserva de espacio.
• TTFB: servidor, caché y CDN. FCP, Speed Index y TBT me ayudan a priorizar JavaScript y CSS.

Configurar pruebas: móvil primero y condiciones realistas

• Viewport tipo móvil (por ejemplo, 360 × 640), CPU throttling moderado.
• Red: 4G/rápida en PSI, «Good 4G» en WebPageTest.
• Si usas CDN, prueba desde ubicaciones cercanas al público objetivo (en España me voy a Dublín/Frankfurt).
• Repite tras cada bloque de cambios; si INP empeora al diferir JS, ajusta exclusiones.

2)Base sólida: hosting, PHP y servidor

Con una mala base no hay milagros. Las webs que hacemos van en nuestro hosting administrado: servidor LiteSpeed en España, copia completa en un segundo servidor y seguridad revisada, desde 70 €/año según el tamaño de la web. Sea cual sea tu hosting, estos son los ajustes que más se notan:

• PHP actualizado (8.3 u 8.4) + OPcache activo.
• HTTP/3 + QUIC habilitado, TLS moderno y compresión Brotli/Gzip.
• LiteSpeed como servidor + LiteSpeed Cache (plugin) para caché a nivel servidor.
• DNS rápido (Cloudflare/Route 53) y, si procede, CDN con edge cercana a tu audiencia.
• Object Cache (Redis/Memcached) si tu plan lo soporta.

Mi checklist de arranque

• Subo a PHP 8.3 u 8.4 y reviso compatibilidades. Las versiones 8.1 y anteriores ya no reciben parches de seguridad.
• Habilito HTTP/3 y confirmo Keep-Alive.
• Activo OPcache y reviso límite de memoria.
• Compruebo que la caché de página acierta de verdad (más abajo te cuento por qué).
• CDN (Cloudflare) con caché de estáticos agresiva y minificación desactivada en Cloudflare si la hago con LiteSpeed (evito duplicidades).
• TTFB: si parte de 800–1200 ms en móvil, tras CDN + caché bien puesta, mi objetivo es < 400–500 ms.

Reducir TTFB: DNS, CDN y caché de objeto

• DNS: usa un proveedor con baja latencia.
• CDN: activa caché de página y de imágenes cuando aplique; habilita HTTP/3 en el borde.
• Object Cache: con WordPress dinámico (tiendas, membresías) marca diferencia. Con Redis suelo bajar queries repetitivas y estabilizar tiempos.

3)Si usas un page builder (Elementor, Divi…): lo que más pesa

Nosotros ya no usamos page builder, pero muchas webs que nos llegan sí. Elementor es potente y permite «hacer de todo»… y eso pesa. Si no vas a cambiar de tema, esto es lo que más rinde:

• Containers en lugar de secciones anidadas: menos niveles, menos HTML.
• Hero sin slider: imagen fija recortada a su tamaño, sin lazy y con fetchpriority="high"; o vídeo con póster y play bajo demanda.
• Sin animaciones de entrada en el hero: un titular que aparece con fundido retrasa el LCP.
• Fuentes: solo los grosores que usas y una sola declaración por fuente. Revisa que el kit del builder no las cargue otra vez.
• Widgets pesados: mapas y vídeos, al hacer clic. En formularios, evita reCAPTCHA v2 (mejor v3 cargado bajo demanda, Turnstile o hCaptcha).
• Ajustes del builder: activa la carga optimizada de CSS y JS por página, desactiva estilos globales y librerías de iconos que no usas.

Si cada cambio pide un parche y una exclusión nueva, quizá toca rehacer la web con un tema a medida. Es lo que hacemos en desarrollo WordPress y lo que hicimos con la nuestra.

4)Lo que medimos al quitar Elementor de nuestra propia web

El 15 de octubre de 2026 pasé sancreate.es a un tema propio, sin page builder. Quitar Elementor ordenó el código, pero los números grandes llegaron al revisar todo lo demás: una caché que no acertaba, Tag Manager cargando al entrar, una fuente de ~115 KB por grosor y un scroll que se comía el LCP.

Del page builder a un tema propio

• Tema propio y un plugin nuestro con lo que antes hacían Elementor y sus añadidos: formulario de contacto, popups y carrusel.
• El carrusel es uno ligero en lugar de Swiper.
• El formulario guarda los envíos en la web. Importamos los 69 envíos antiguos de Elementor para no perder ninguno.
• El 20 de octubre el tema dejó de depender de Hello Biz: ya no tiene tema padre.

La caché que no acertaba: TTFB de 0,13 a 0,05 s

LiteSpeed Cache estaba instalado y activo. Aun así, la caché nunca acertaba: al .htaccess le faltaba su bloque. Al ponerlo, el TTFB bajó de 0,13 a 0,05 s.

Compruébalo en tu web: abre las herramientas del navegador, mira las cabeceras de la página y busca x-litespeed-cache: hit. Si ves miss en la segunda visita, tu caché no está haciendo nada.

Tag Manager, 5 segundos después: PageSpeed móvil de 45–93 a 82–94

Google Tag Manager arrastra Analytics y Ads. Ahora lo cargo 5 segundos después del load o en la primera interacción, lo que llegue antes. En la página de gracias carga al instante, porque ahí se mide la conversión de Ads.

Resultado en PageSpeed móvil, en las 10 páginas clave: de 45–93 a 82–94. El precio es que Analytics no cuenta a quien se va antes de 5 segundos sin tocar nada. Las conversiones no se pierden.

Inter recortada: de ~115 KB a ~36 KB por grosor

• Cada grosor de Inter pesaba unos 115 KB. Recortada, se queda en unos 36 KB, servida desde el propio tema.
• Había dos @font-face para la misma fuente: una era la copia que dejó el kit de Elementor. Ahora hay una.
• Precargo solo los grosores del principio de la página (400 y 700).
• Quité los preconnect y dns-prefetch a Google Fonts que ya no se usaban.

El «sin LCP» de PageSpeed era un scroll

En la landing de diseño web, PageSpeed móvil daba nota 0 y el aviso «sin LCP». La causa: unas pestañas llamaban a scrollIntoView al cargar y en móvil la página bajaba sola unos 15.000 px. Ahora solo se desplaza la tira de pestañas, y solo al pulsar. Nota en móvil: 91–94.

Si PageSpeed te dice que no hay LCP, mira primero si algo mueve la página al cargar: pestañas, carruseles o un focus() mal puesto.

Imágenes del hero a su tamaño

En «Sobre nosotros», los retratos pasaron a 768 px con srcset. La imagen del LCP bajó de unos 650 KB a 135 KB.

5)Caché de verdad con LiteSpeed Cache

Lo que mejor me funciona (y lo que no conviene mezclar):

A) Caché (Settings → Cache)

• Enable Cache: ON
• Cache Mobile: ON (con device group si tu tema varía por dispositivo)
• TTL por defecto: OK (ajusto si hay contenido muy dinámico)
• Purge on Update: ON
• Browser Cache: ON
• Comprobación: cabecera x-litespeed-cache: hit en la segunda visita. Si no aparece, revisa el bloque del plugin en el .htaccess.

B) Object Cache

• Redis si está disponible; tiempo de vida por defecto de 3600–7200 s.
• No activo si el hosting no lo soporta bien (evita latencia añadida).

C) Page Optimization

• CSS: Minify ON, Combine OFF (no combino si uso UCSS).
• UCSS (Unused CSS): ON + Per-page si hay roturas. Se genera en QUIC.cloud, que tiene cuota.
• Critical CSS: ON (regenero tras grandes cambios).
• JS: Minify ON, Combine OFF, carga diferida (Deferred o Delayed) con exclusiones: menús, carruseles above-the-fold y, si usas Elementor, jquery.js y elementorFrontend.
• HTML Minify: ON (si no rompe nada).

D) Media

• Lazy Load de imágenes ON con umbral (hero sin lazy). Comprueba que el plugin no reescribe la imagen del hero.
• Conversión a WebP (o AVIF si estable).
• Responsive Placeholder para evitar CLS.

E) CDN

• Integra con Cloudflare (API) pero evita minificar en dos sitios. Minificación y combinación, en una sola capa (LiteSpeed o CDN, no ambos).

Critical CSS, UCSS y delay/defer de JS sin romper la web

• Genera Critical CSS global y revisa plantillas clave (home, post, producto).
• Si UCSS rompe estilos, añade exclusiones por selector.
• Al diferir JS, excluye lo imprescindible para el above-the-fold (menú, hero interactivo). Haz una prueba visual rápida tras limpiar cachés.

Caché de objeto (Redis/Memcached) y ESI

• ESI (Edge Side Includes) en LiteSpeed te permite no cachear solo el trozo dinámico (por ejemplo, el minicarrito) manteniendo la página cacheada.
• Con tiendas y membresías, ESI + Object Cache suele estabilizar tanto TTFB como INP.

6)Medios optimizados: imágenes, vídeo y fuentes

Imágenes (reglas cortas que aplico)

• Exporto WebP/AVIF con calidad 60–80; nada de PNG salvo logos/elementos con transparencia que lo necesiten.
• Tamaños responsivos: genero variantes y uso srcset/sizes; evito subir a 3000 px si el contenedor es 1200 px.
• Lazy-load en todo menos el hero; width y height siempre, para evitar CLS.
• WordPress ya pone fetchpriority="high" a la imagen que cree principal. Comprueba que acierta; si no, márcala tú.
• CDN de imágenes si el proyecto lo justifica (transformaciones en el edge = menos CPU en el servidor).

Vídeo

• Evita autoplay/loop en el hero; usa miniatura + botón (carga bajo demanda).
• YouTube con lite-embed: iframe solo al hacer clic.
• Si el vídeo es vital, optimiza el póster y define dimensiones siempre.

Fuentes: subset, preload y swap

• Sírvelas desde tu propio dominio y en woff2.
• Recorta a los glifos que usas (subset latin) y carga solo los grosores que aparecen en la web.
• Precarga una o dos, las del principio de la página, y revisa que el preload apunte al archivo que se usa de verdad.
• Usa font-display: swap.

7)Menos es más: plugins, scripts de terceros y bloat

Mi protocolo de «dieta de plugins»

• Inventario: lista de todos los plugins y por qué existen.
• Duplicidades: caché + optimización (quédate con LiteSpeed); varios constructores a la vez, fuera.
• Sustituciones: formularios más ligeros, galerías nativas, bloques cuando procede.
• Desinstalación limpia: borra datos residuales y cron jobs.

Terceros (Analytics, Tag Manager, chat, ads, mapas, píxeles)

• Consentimiento primero: no cargues nada sin permiso (además de legal, mejora INP).
• Cargar al clic: chatbots y mapas, solo cuando el usuario los pide.
• Tag Manager, diferido: tras el load o la primera interacción, salvo en la página donde mides conversiones.
• preconnect solo a los dominios que cargan arriba del todo. Los que sobran, fuera.

CSS/JS por página

• Con LiteSpeed (o con las opciones de tu builder), desactiva assets no usados en páginas concretas.
• Mide peso de JS: si pasas de 250–300 KB minificados en móvil, revisa librerías e iconos.

8)Checklist por métrica: LCP, INP y CLS

Playbook LCP (qué atacar primero)

• TTFB < 500 ms: base, CDN y caché listas (y comprobadas).
• Hero optimizado: WebP/AVIF, tamaño correcto, sin lazy, con fetchpriority="high" y sin animación de entrada.
• Critical CSS: above-the-fold estable; UCSS para el resto.
• Fuentes: recortadas, display: swap y preload de la principal.
• JS render-blocking: quítalo del above-the-fold (delay/defer).
• Sin scroll al cargar: nada que mueva la página antes de que el usuario la toque.

Playbook INP (interacción y JS)

• Delay JS a todo lo no crítico (terceros incluidos).
• Exclusiones mínimas: menú, carrusel visible, búsqueda.
• Reduce listeners pesados y evita bibliotecas duplicadas.
• Parte las tareas largas: si un clic dispara mucho trabajo, pinta primero la respuesta y haz el resto después.
• Object Cache activo en sitios dinámicos.

Playbook CLS (layout estable)

• Dimensiones en imágenes/iframes; placeholder con relación de aspecto correcta.
• Fuentes: display: swap y, si el cambio de fuente mueve el texto, ajusta la de reserva con size-adjust en el @font-face.
• Banners (cookies, barras): reserva espacio o muéstralos sobrepuestos sin empujar contenido.
• Ads/embeds: contenedores con altura fija o responsive bien calculada.
• Evita insertar elementos por encima del contenido ya renderizado.

9)Control de calidad continuo

• Budgets de rendimiento: por ejemplo, LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1 en datos de campo; ≤ 1 MB de transferencia y ≤ 70 peticiones en la home móvil.
• Alertas: paso PageSpeed por las páginas clave tras cada despliegue y miro cada semana el informe de Search Console.
• Regresiones: si un editor añade un bloque pesado, la caché no lo arregla; detecta con comparativas (antes/después).
• Informe al cliente: incluyo capturas antes/después, nota de cambios y listado de tareas pendientes (p. ej., sustituir un chat invasivo por otro ligero).

Conclusión

Mejorar el rendimiento en WordPress no va de instalar un plugin mágico: es método. Mide (móvil primero y con datos de campo), asegura servidor y caché, aligera el diseño, afina LiteSpeed, optimiza medios y pon a dieta plugins y terceros. Con esa secuencia he llevado sitios lentos que no pasaban Core Web Vitals a verdes estables.

Y no des nada por hecho. En nuestra propia web, la caché que creíamos activa no acertaba y Tag Manager se comía la nota de PageSpeed. Lo encontramos porque lo medimos.

Si prefieres no pelearte con todo esto, es justo lo que hacemos en optimización de rendimiento web: te dejamos los Core Web Vitals en verde y tú a lo tuyo.

Quiero los Core Web Vitals en verde

Preguntas frecuentes