Cómo optimizar un sitio WordPress: por dónde empezar y en qué orden

Busque cómo acelerar WordPress y encontrará listas: treinta trucos, cincuenta plugins, todas las opciones activadas. Siga una y empieza la historia de siempre. La puntuación se mueve, luego un menú deja de abrirse, un formulario deja de enviarse, y nadie sabe cuál de los diez ajustes es el culpable.

Esta guía toma el otro camino. Le da un orden: qué medir primero, cómo encontrar el problema real y qué palanca usar para resolverlo, de la más segura a la más delicada. Cada paso remite a una guía dedicada cuando quiera profundizar.

Qué significa «rápido» para Google

Google juzga la velocidad de una página con tres indicadores, las Core Web Vitals, medidas en sus visitantes reales:

• LCP (Largest Contentful Paint): cuándo se muestra el contenido principal, a menudo la imagen superior o el título. Bueno por debajo de 2,5 s.
• INP (Interaction to Next Paint): cuánto tarda la página en reaccionar a un toque o a un clic. Bueno por debajo de 200 ms.
• CLS (Cumulative Layout Shift): cuánto salta el contenido mientras carga. Bueno por debajo de 0,1.

El veredicto se toma en el percentil 75 de las visitas durante 28 días: tres visitas de cada cuatro deben ser buenas. Una sola prueba lanzada desde su propio ordenador rápido dice poco al respecto.

Paso 1: medir primero el campo, luego el laboratorio

Hay dos tipos de datos, y responden a preguntas distintas:

• Los datos de campo (Search Console, y la sección superior de PageSpeed Insights) vienen de sus visitantes reales. Le dicen si hay un problema, y dónde.
• Los datos de laboratorio (la puntuación de PageSpeed Insights, Lighthouse) vienen de una única carga simulada. Ayudan a entender por qué, y a comprobar un cambio en el acto.

Empiece por el informe de Core Web Vitals de Search Console. Agrupa sus URL por páginas similares, lo que suele significar por plantilla: inicio, artículos, fichas de producto, categorías, páginas de aterrizaje. Esa es la unidad con la que va a trabajar, porque una corrección en una plantilla corrige todas las páginas construidas sobre ella.

Antes de cambiar nada, anote el punto de partida de cada plantilla: las tres métricas de campo y una prueba de laboratorio en móvil. Cuando ambos no coinciden, y es frecuente, nuestra guía sobre datos de laboratorio y de campo explica cómo leerlos.

Paso 2: encontrar qué métrica falla, en qué plantilla

Cada métrica apunta a una familia de causas distinta. Eso es lo que le evita activarlo todo:

• LCP malo: el servidor responde tarde, o la imagen principal llega tarde (demasiado pesada, descubierta tarde, cargada en diferido por error, bloqueada detrás de las hojas de estilo).
• CLS malo: imágenes sin espacio reservado, una fuente web que cambia por el camino, un banner o un bloque insertado después de la primera visualización.
• INP malo: demasiado JavaScript en el hilo principal, del tema, del maquetador o de terceros.

Mire también el tiempo de respuesta del servidor (TTFB, visible en PageSpeed Insights). Si el propio HTML tarda más de unos 0,8 s en llegar, ninguna optimización en el navegador lo compensará: el paso siguiente va primero.

Paso 3: el servidor y la caché de página

WordPress construye cada página en PHP, con consultas a la base de datos, en cada visita. Una caché de página guarda el HTML terminado y lo sirve directamente a los siguientes visitantes: es la palanca con más efecto sobre el tiempo de respuesta, y en un sitio de contenido es segura para los visitantes anónimos.

• Un solo motor de caché, no dos. Muchos alojamientos ya guardan las páginas en caché en el servidor. Apilar encima la caché de un plugin crea dos capas que se purgan en momentos distintos, y acaba sirviendo páginas caducadas. Elija una para gestionar la caché de página.
• Compruebe lo básico del alojamiento: una versión de PHP con soporte, y una caché de objetos (Redis o Memcached) si el sitio es dinámico.
• Los sitios con cuentas o carrito necesitan una frontera entre lo que puede ir a caché y lo que nunca debe ir. En WooCommerce, esa frontera es todo el tema de nuestra guía para acelerar una tienda WooCommerce.

Paso 4: las imágenes y la imagen principal

Las imágenes suelen ser la parte más pesada de una página, y la principal es a menudo el LCP. Los primeros gestos son todos seguros, porque envían la misma imagen en menos bytes: compresión, un formato moderno (WebP o AVIF) y el tamaño adecuado para la pantalla. Si PageSpeed sigue pidiéndole que dimensione correctamente las imágenes pese a un srcset, la causa es casi siempre el atributo sizes: vea nuestra guía de srcset y sizes.

Ocúpese después de la propia imagen principal:

• no la cargue nunca en diferido: el lazy loading es para las imágenes por debajo del pliegue;
• ayude al navegador a encontrarla pronto con un preload y una prioridad de carga alta, y si difiere entre móvil y escritorio, precargue una por dispositivo;
• si es un fondo CSS puesto por un maquetador, el navegador la descubre tarde: nuestra guía sobre heros con imagen de fondo muestra las soluciones;
• y mantenga las ilustraciones grandes fuera del SVG inline, que pesa sobre el propio HTML: el SVG inline es para iconos.

Paso 5: el CSS

El navegador no muestra nada hasta haber descargado y leído las hojas de estilo del <head>. En un tema con maquetador, pueden ser varios cientos de kilobytes, la mayoría sin uso en la página actual. Dos técnicas se ocupan de ello:

• El Critical CSS: los estilos de lo que es visible al cargar se insertan en la página, y la hoja completa se carga sin bloquear.
• El CSS utilizado (a menudo llamado «Eliminar el CSS no utilizado»): se retiran las reglas que la página no usa.

Las dos son muy eficaces, y las dos pueden romper algo, porque juzgan a partir de una sola captura de la página. Un menú, una ventana modal o un minicarrito cerrados en ese momento parecen inútiles, y pierden sus estilos. Cómo encontrar la regla que falta y devolverla: nuestra guía sobre estilos que faltan, con dos casos frecuentes: el menú que aparece abierto y el minicarrito que desaparece.

Paso 6: el JavaScript y la capacidad de respuesta

El JavaScript pesa sobre todo: compite con la imagen principal por la red, y mantiene ocupado el hilo principal cuando el visitante toca la pantalla. La palanca más fuerte es retrasar los scripts que no hacen falta al cargar hasta la primera interacción. También es la palanca que rompe más sitios:

• un menú que solo se abre al segundo toque: nuestra guía sobre el menú hamburguesa;
• un slider, un formulario o un banner de consentimiento que deja de funcionar: cómo encontrar el script culpable;
• un banner de consentimiento que llega tarde y retiene el resto: nuestra guía sobre banners de consentimiento.

No retrase nunca lo que el visitante necesita enseguida: la herramienta de consentimiento, el menú, los scripts de añadir al carrito y de pago. Y conozca el límite del ejercicio: algunos temas entregan todo su código en un único archivo grande, lo que pone un techo a cualquier optimización. Cómo detectarlos.

Paso 7: la estabilidad del diseño

Un contenido que salta rara vez tiene una sola gran causa, sino varias pequeñas: imágenes sin width ni height, una fuente web que cambia el tamaño del texto al llegar, un banner de cookies o una barra promocional que empuja la página hacia abajo, un slider que empieza en un estado y termina en otro. Reserve el espacio, y elija a propósito el font-display de sus fuentes: swap muestra el texto enseguida pero puede moverlo cuando llega la fuente, optional nunca lo mueve pero a veces se queda con la fuente de reserva. Los maquetadores añaden sus propias causas, tratadas en nuestra guía de CLS para Divi y Elementor.

Su maquetador, su tienda

El orden anterior vale para cualquier sitio WordPress. Algunas configuraciones tienen sus propias trampas, con una guía dedicada:

• Divi: mucho CSS e imágenes de fondo de serie, y opciones que se solapan con cualquier plugin de optimización. Acelerar un sitio Divi, paso a paso.
• Elementor y Divi: desplazamientos de diseño propios de los maquetadores. Corregir el CLS en temas con maquetador.
• WooCommerce: caché, fragmentos del carrito, imágenes de producto y scripts de pago. Acelerar una tienda WooCommerce.

El método que mantiene el sitio funcionando

No todas las palancas son iguales. Algunas solo reducen el peso de los archivos o dan una pista al navegador, y no pueden romper nada. Otras cambian lo que se ejecuta, en qué orden o lo que se sirve, y necesitan una prueba. Nuestra guía sobre optimizaciones sin riesgo las clasifica una a una.

Con Mantys Core

En resumen

• Lea primero los datos de campo, plantilla por plantilla: le dicen si hay un problema y dónde.
• Asocie la métrica que falla a su familia de causas: LCP a servidor e imágenes, CLS a espacio reservado, INP a JavaScript.
• Corrija en orden: servidor y caché de página, imágenes, CSS, JavaScript, estabilidad.
• Active primero las palancas seguras, luego las delicadas una a una, probando en móvil y escritorio, sin sesión iniciada.
• Confirme en laboratorio enseguida, y en el campo cuatro semanas después.