Cómo acelerar una web WordPress: orden de arreglos

Así es cómo acelerar una web WordPress en la práctica: mide primero, luego arregla según el impacto: tiempo de respuesta del servidor y caché de página, después la imagen hero pesada, después CSS y JavaScript que bloquean el renderizado, después la base de datos y carga de plugins. La mayoría de webs lentas se ralentizan por dos o tres de esos factores, no por todos. Ejecuta PageSpeed Insights en tu plantilla más lenta, anota el elemento Largest Contentful Paint, y trabaja de arriba abajo en esta lista hasta que el número se ponga verde.

Empieza con una línea base, o estarás optimizando lo que no es

El trabajo de velocidad sin una línea base es superstición. Antes de tocar un plugin, registra tres números en tu plantilla real más lenta (habitualmente un artículo con una imagen hero grande, o una página de producto WooCommerce): Largest Contentful Paint, Interaction to Next Paint y Time to First Byte. Prueba en dispositivos móviles, porque ese es el punto donde la brecha entre "rápido en mi máquina" y "rápido para los clientes de tu cliente" se ve con claridad.

Los objetivos están publicados, no son folklore. La guía web.dev de Google sobre LCP considera 2,5 segundos o menos como bueno en el percentil 75 de visitas reales. INP debe mantenerse por debajo de 200 milisegundos y el cambio de diseño por debajo de 0,1. Escribe eso en una nota adhesiva junto a tu pantalla.

Las herramientas de laboratorio como Lighthouse te dan un banco de pruebas repetible. Los datos de campo de Chrome User Experience Report, que aparecen en la parte superior de PageSpeed Insights, te dicen qué visitantes realmente experimentaron. Cuando los dos no coinciden, confía en los datos de campo y usa la ejecución de laboratorio para encontrar la causa.

Nota al margen: este orden de trabajo funciona para WordPress 6.5 y posteriores. Las instalaciones más antiguas tienen más cosas que arreglarse antes de que cualquiera de esto importe.

Arregla el servidor primero: hosting, PHP y Time to First Byte

Cada truco del front-end se asienta sobre la primera respuesta. Si el HTML tarda 1,5 segundos en llegar, ninguna compresión de imagen rescata tu LCP. Time to First Byte es el número que expone un host débil, una rama PHP anticuada o una página que se reconstruye desde cero en cada solicitud.

Comprueba tres cosas en este orden. Ejecuta una rama PHP actualmente soportada, porque cada versión es mediblemente más barata por solicitud que la anterior. Confirma que el host ofrece una caché de objetos persistente (Redis o Memcached), porque elimina lecturas repetidas de la base de datos para opciones, menús y consultas. Y observa el plan en sí: un servidor compartido con cien vecinos te ralentizará exactamente en el momento en que el tráfico repunta.

Si gestionar muchos sitios cliente es tu trabajo, aquí es donde el hosting gestionado se gana su comisión. Una plataforma que agrupa hosting, caché y un objetivo de rendimiento elimina toda una categoría de incertidumbre. 10Web es un ejemplo que aloja WordPress en Google Cloud y apunta a una puntuación PageSpeed de 90+ de serie, lo que es un valor por defecto razonable para una pequeña agencia sin una persona dedicada a operaciones.

Salta la tentación de comprar un plan más grande antes de haber activado la caché. Mejorar el hardware para servir páginas sin caché es pagar más para hacer el mismo trabajo derrochador más rápido.

Activa el caché de página completa y verifica que realmente se activa

WordPress construye cada página con PHP y MySQL cada vez que alguien la solicita. Un caché de página guarda el HTML terminado y sirve ese archivo en su lugar. Para un sitio principalmente de lectura como un blog, un sitio de folletos o un portafolio, este único cambio a menudo mueve TTFB de segundos a decenas de milisegundos.

Elige una sola capa de caché de página y solo una. Apilar un caché a nivel de host, un plugin de caché y un caché de CDN sin saber cuál sirve la solicitud es cómo terminas depurando contenido obsoleto durante una tarde completa. Pregunta a tu host qué ya proporciona antes de instalar algo.

Después verifica que el caché realmente se está activando. Abre el panel de red del navegador, recarga una página pública dos veces, y lee los encabezados de respuesta. La mayoría de cachés anuncian un hit o un miss, y muchos agregan un valor de edad. Si solo ves misses, tu caché se está evitando por una cookie, una cadena de consulta o un estado de conectado, y la "optimización" es solo decoración.

Las tiendas necesitan cuidado extra. Las páginas de carrito, compra y cuenta nunca deben estar en caché, y los sitios WooCommerce generalmente dependen de un plugin de caché que conoce esas exclusiones. Si las exclusiones no son correctas, los clientes ven los carritos los unos de los otros, lo que es un problema peor que una página lenta.

Reduce la imagen hero, la causa LCP más habitual

En la mayoría de páginas WordPress lentas, el elemento LCP es una imagen: un hero, una imagen destacada o un banner de ancho completo. Eso hace que el peso de la imagen sea la causa única más común de una puntuación fallida. Un JPEG de 4000 píxeles de ancho exportado directamente de una cámara, mostrado en una columna de 1200 píxeles, envía varios múltiplos de bytes más de lo que la maquetación puede usar.

Recorre la tubería de imágenes en este orden:

• Cambia el tamaño al tamaño más grande que la maquetación realmente muestra, no el tamaño que el diseñador exportó.

• Sirve WebP o AVIF, ambos los cuales el núcleo de WordPress ha manejado durante varias versiones.

• Deja que el núcleo genere las variantes responsivas de srcset en lugar de codificar un archivo grande.

• No hagas lazy-load del hero. El núcleo ha omitido el lazy loading en la primera imagen de contenido y agregó fetchpriority="high" a ella desde WordPress 6.3, así que verifica que tu tema o plugin no lo haya deshecho.

• Da a cada imagen ancho y alto explícitos para que el navegador reserve espacio y el cambio de diseño se mantenga cerca de cero.

Por debajo del pliegue, lazy loading es correcto y gratuito. Por encima del pliegue, es un retraso auto-infligido, y es el error que aparece más a menudo después de que alguien instala un plugin de "lazy load de todo".

Para el comercio electrónico, el peso a menudo proviene de la fotografía de productos. Producir imágenes visuales consistentes y de tamaño adecuado en la fuente es más barato que comprimir cincuenta archivos sobredimensionados después, y una plataforma de fotografía de productos con IA como Klayn convierte una foto de producto en un conjunto de escenas, para que puedas planificar las dimensiones antes de que cualquier cosa llegue a la biblioteca de medios.

Corta CSS y JavaScript que bloquean el renderizado en la fuente

Una vez que el servidor y el hero están ordenados, el siguiente retraso es lo que el navegador debe descargar y ejecutar antes de que pinte. Cada hoja de estilos en el encabezado bloquea el renderizado. Cada script síncrono bloquea el análisis. Los constructores de páginas y los temas multipropósito son los culpables habituales, porque envían estilos y scripts para cada característica, se use o no.

Los temas de bloques tienen una ventaja estructural aquí. El núcleo carga los estilos para un bloque solo cuando ese bloque aparece en la página, así que un artículo simple no paga por Query Loop o la Galería. Esa es una razón por la cual un tema Full Site Editing magro comienza adelantado de un tema heredado con un slider incluido y una fuente de iconos incluida. Los constructores de páginas clásicos pueden cerrar la brecha, pero solo si desactivas los módulos que no utilizas.

Divi es un caso de prueba justo. Divi 5 fue reconstruido en una arquitectura más moderna y envía cientos de módulos, lo que es exactamente por qué su configuración de rendimiento, como CSS dinámico y CSS crítico, merece una mirada cuidadosa en cada sitio que entregas.

Pasos prácticos, en orden de riesgo:

• Difiere JavaScript no crítico y carga scripts de terceros (widgets de chat, analítica, gestores de etiquetas) después de la interacción donde puedas.

• Alinea el CSS crítico para contenido por encima del pliegue y carga el resto de manera asíncrona, si tu herramienta de caché lo soporta.

• Auto-aloja fuentes, limita su conjunto, y usa font-display: swap para que el texto sea visible mientras se carga la fuente.

• Elimina o reemplaza cualquier plugin que cargue un script grande en cada página para una característica usada en una.

• Prueba después de cada cambio. La deferencia agresiva de JavaScript es la causa número uno de un menú roto o un botón de compra muerto.

Poda la pila de plugins y deja que la base de datos respire

El conteo de plugins es una métrica pobre. Lo que importa es lo que cada plugin carga en el front-end y lo que hace en cada solicitud. Un plugin mal escrito con una consulta pesada puede costar más que treinta bien comportados. Usa Query Monitor en una copia de staging para ver consultas lentas, el plugin que las disparó, y los scripts que cada uno encola.

Luego observa la tabla de opciones. Los plugins que fueron removidos hace años a menudo dejan filas detrás marcadas para autocargar, lo que significa que WordPress las lee en memoria en cada solicitud. Site Health comienza a marcar opciones autocargadas una vez que alcanzan aproximadamente 800 KB. Si ves esa advertencia, audita las filas más grandes y limpia los restos de plugins que ya no ejecutas.

Las revisiones de posts, los transitorios expirados y los metadatos huérfanos agregan peso con el tiempo, pero trata esto como mantenimiento en lugar de una corrección titulada. Realiza una copia de seguridad primero, ejecuta la limpieza en staging, y mide de nuevo. La ganancia a menudo es modesta en un sitio pequeño y significativa en una tienda con años de pedidos y sesiones.

Usa un CDN y carga especulativa para el último tramo

Una red de entrega de contenidos sirve archivos estáticos, y a menudo también el HTML en caché, desde una ubicación cerca del visitante. Para una audiencia dispersa en regiones, como un sitio en árabe leído desde el Golfo y el Norte de África mientras el servidor de origen se sienta en Europa, la latencia ahorrada no es cosmética. La distancia es un costo, y un CDN es la forma más barata de acortarla.

WordPress 6.8 añadió algo que no cuesta nada: carga especulativa. Usa la API de Speculation Rules para hacer prefetch de una página mientras el visitante comienza a hacer clic, para que la siguiente navegación se sienta casi instantánea. El equipo principal reporta que sitios usando la versión anterior del plugin mejoraron su tasa de aprobación de LCP en aproximadamente 1,9% en la mediana, como se describe en la nota de desarrollo de carga especulativa de WordPress 6.8. Eso es pequeño por sitio, y viene sin configuración.

El núcleo lo habilita para visitantes conectados en sitios con enlaces permanentes bonitos. Si un plugin usa URLs de acción que cambian el estado en una solicitud GET simple, excluye esos caminos con el filtro wp_speculation_rules_href_exclude_paths antes de hacer la configuración más lista. Mantente en el valor por defecto hasta que hayas revisado tus carritos y tu analítica.

Cuándo dejar de ajustar, y qué arreglo ejecutar primero

Hay un punto donde más ajuste de WordPress cuesta más de lo que devuelve. Si una pequeña tienda gasta cada mes luchando contra exclusiones de caché, conflictos de plugins y actualizaciones de hosting, la pregunta honesta es si la pila se adapta al negocio. Una plataforma alojada como WiziShop intercambia algo de flexibilidad por una tienda cuya velocidad es trabajo de alguien más, y vale la pena cotizar en comparación con las horas que facturas por mantenimiento.

Para sitios de contenido, agencias y proyectos RTL, WordPress sigue siendo la herramienta correcta, y todo lo anterior sigue siendo digno de hacer. El punto es saber en qué lado de la línea se sienta cada cliente.

Ejecuta la línea base en tu plantilla más lenta hoy. Si TTFB está por encima de 800 milisegundos, comienza con hosting, PHP y caché. Si TTFB es saludable pero LCP falla, abre el gráfico de cascada y encuentra la imagen hero. Si ambos pasan e la interacción es lenta, mira JavaScript y la pila de plugins. ¿Cuál de esos tres falla en tu página peor?