“Mi WordPress va lento”. He escuchado esta frase miles de veces. Y generalmente la respuesta no es “instala otro plugin”, sino “limpia lo que tienes”. La optimización de rendimiento (WPO, Web Performance Optimization) cruza todo el stack. Comprimir imágenes no es suficiente si la base de datos “tose” en cada consulta. Necesitas un enfoque sistemático que aborde todos los niveles del stack tecnológico.
Descubre más sobre servicios de desarrollo WordPress en WPPoland.
Esta es la hoja de ruta completa de optimización WordPress, desde los fundamentos básicos hasta las técnicas avanzadas que utilizan los profesionales en 2026. La guía recorre cada capa, desde la configuración del servidor hasta el último pintado en pantalla, con cifras reales y código que puedes desplegar hoy.
Cómo afecta la velocidad de WordPress a las conversiones
La velocidad tiene un efecto directo en el negocio. La propia investigación de Google muestra que, cuando el tiempo de carga pasa de 1 a 3 segundos, la probabilidad de rebote aumenta un 32%. Si llega a 5 segundos, esa probabilidad sube un 90%. En comercio electrónico, Amazon midió que cada 100 ms de latencia añadida le costaba un 1% de las ventas (Greg Linden, Amazon, 2006).
Las Core Web Vitals se convirtieron en señal de posicionamiento confirmada por Google en 2021. Los sitios que superan los tres umbrales (LCP por debajo de 2,5 segundos, CLS por debajo de 0,1 e INP por debajo de 200 ms) reciben un impulso en los resultados de búsqueda móvil. Según los datos del Chrome User Experience Report (CrUX) de finales de 2025, solo el 43% de los orígenes WordPress supera las tres Core Web Vitals en móvil. Más de la mitad de los sitios WordPress está dejando potencial de posicionamiento sin aprovechar.
El estudio “Milliseconds Make Millions” de Deloitte encontró que una mejora de 0,1 segundos en la velocidad del sitio móvil aumentó la tasa de conversión un 8,4% en retail y un 10,1% en sitios de viajes. Cuando haces el cálculo con tu propio tráfico, el coste de un sitio lento se vuelve concreto. Una tienda WooCommerce que factura 50.000 € al mes podría estar perdiendo entre 4.000 y 5.000 € cada mes con un sitio que carga en 4 segundos en lugar de 2.
La optimización de velocidad es obligatoria. Es la inversión técnica con mayor retorno que puedes hacer.
Cómo medir la velocidad de un sitio WordPress
No empieces a optimizar sin una línea base. Necesitas datos, no suposiciones.
PageSpeed Insights (PSI) te da datos de laboratorio (Lighthouse) y datos de campo (CrUX). Los datos de laboratorio sirven para depurar, pero los datos de campo, recogidos de usuarios reales de Chrome durante 28 días, son los que Google usa para el posicionamiento. Revisa siempre el “Origin Summary” para ver cómo rinde todo tu dominio y no solo páginas sueltas.
WebPageTest (webpagetest.org) ofrece gráficos de cascada, vistas en tira de fotogramas y pruebas de varios pasos. Lanza las pruebas desde una ubicación cercana a tu público objetivo. Usa la “repeat view” para ver cómo afecta la caché a las cargas siguientes. El gráfico de cascada es la mejor herramienta de diagnóstico para identificar scripts de terceros lentos y recursos que bloquean el renderizado.
La pestaña Performance de Chrome DevTools te permite grabar una carga completa de la página e inspeccionar cada fotograma, cada desplazamiento de diseño y cada tarea larga. Usa la pestaña “Coverage” (Ctrl+Shift+P y escribe “Coverage”) para encontrar CSS y JavaScript sin usar: así identificas candidatos para eliminar o diferir.
CrUX Vis (cruxvis.withgoogle.com) te da datos históricos de tendencia desde la CrUX History API. Google ha retirado el antiguo CrUX Dashboard de Looker Studio en su favor. Sigue tus Core Web Vitals a lo largo del tiempo, porque una puntuación aislada no significa nada sin contexto. Configura una monitorización automática con herramientas como SpeedCurve o Calibre para detectar regresiones antes de que lleguen a producción.
Anota tus valores de partida: TTFB, LCP, CLS, INP, peso total de la página y número de peticiones. Sin estas cifras no puedes demostrar que tus optimizaciones funcionaron.
Hosting, PHP y DNS para acelerar WordPress
Si tu servidor responde lentamente (TTFB > 600ms), ningún plugin te ayudará. El rendimiento comienza en la infraestructura, y no hay cantidad de optimización frontend que compense un hosting inadecuado. El TTFB debería quedar por debajo de 200 ms en páginas cacheadas y por debajo de 600 ms en respuestas dinámicas.
Qué versión de PHP usar en WordPress
WordPress.org recomienda PHP 8.3 o superior. En un sitio con una versión antigua, actualizar PHP suele ser una de las optimizaciones de servidor que más se notan, y cuesta poco. PHP 8.1 y las ramas anteriores ya no reciben parches de seguridad, así que quedarse en ellas cuesta velocidad y seguridad a la vez.
Cuánto se acelera un sitio concreto tras la actualización depende del tema, los plugins y la caché. Mide el TTFB antes y después del cambio en lugar de fiarte de un multiplicador. Comprueba tu versión de PHP con phpinfo() o en Herramientas, Salud del sitio, Información, y prueba la actualización primero en staging: los plugins antiguos son la fuente habitual de errores fatales tras un salto de versión de PHP.
Cómo configurar OPcache para WordPress
OPcache compila los scripts PHP a bytecode y los guarda en memoria compartida. Actívalo y ajusta estos valores en php.ini:
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.jit=1255
opcache.jit_buffer_size=128MEl ajuste jit=1255 activa el JIT de trazado en PHP 8.x, que beneficia a operaciones con mucha carga de CPU, como la construcción de páginas.
Object cache con Redis o Memcached en el servidor
Por defecto, WordPress guarda los transients, los resultados de consultas y los datos de sesión en la tabla wp_options. Redis o Memcached los llevan a memoria, lo que reduce drásticamente las consultas a la base de datos. Una página WordPress típica que lanza entre 50 y 80 consultas puede bajar a 5-10 con un object cache persistente. Instala la extensión PHP redis, añade WP_REDIS_HOST a wp-config.php y usa un drop-in como object-cache.php del plugin Redis Object Cache.
Qué versión de MySQL o MariaDB usar
WordPress.org recomienda MySQL 8.0 o superior, o MariaDB 10.11 o superior. Con cualquiera de las dos, lo que más pesa en sitios con WooCommerce o muchas taxonomías personalizadas es el tamaño del buffer pool de InnoDB y los índices de las tablas de metadatos, no la marca del motor.
HTTP/2 y HTTP/3 en WordPress
HTTP/2 o HTTP/3 (QUIC) es obligatorio. Permite al navegador descargar muchos archivos a la vez sobre una sola conexión. HTTP/3 agrega beneficios adicionales como recuperación más rápida de conexiones perdidas y mejor rendimiento en redes móviles inestables. Verifica que tu CDN y hosting soporten estos protocolos.
El multiplexing de HTTP/2 elimina el antiguo bloqueo de cabeza de línea de HTTP/1.1. HTTP/3 añade el establecimiento de conexión sin ida y vuelta previa. Cloudflare, Fastly y AWS CloudFront ya soportan HTTP/3.
CDN para WordPress
Si tienes tráfico de todo el mundo, usa Cloudflare u otro CDN para servir archivos desde el servidor más cercano al usuario. Cuanto más lejos está el usuario de tu servidor de origen, más tiempo de ida y vuelta ahorra el CDN.
Coloca tus recursos estáticos (imágenes, CSS, JS, fuentes) en servidores edge. En WordPress, configura el CDN para cachear páginas HTML completas para visitantes sin sesión iniciada: solo con esto puedes bajar el TTFB por debajo de 50 ms en todo el mundo.
El hosting compartido es el primer cuello de botella que vemos en wppoland.com. Servidores sobrecargados, versiones de PHP antiguas y la falta de soporte para object cache hacen la optimización casi imposible. Pásate a un hosting WordPress gestionado o a un VPS con una configuración NGINX o LiteSpeed adecuada.
Proveedor DNS rápido para WordPress
Usa un proveedor DNS de alta velocidad como Cloudflare DNS. Un DNS lento agrega cientos de milisegundos a cada petición inicial. El DNS es frecuentemente un cuello de botella invisible que muchos administradores pasan por alto.
Cómo optimizar la base de datos de WordPress
Aquí es donde ocurre la “magia” que no ves pero sientes al trabajar en el panel de administración y en la velocidad de respuesta del servidor.
Las bases de datos de WordPress acumulan basura con el tiempo. Revisiones de entradas, metadatos huérfanos, transients caducados y comentarios spam inflan las tablas y ralentizan las consultas.
Cómo limitar las revisiones en WordPress
WordPress por defecto guarda versiones infinitas de cada publicación. Si editas un artículo 100 veces, tienes 100 copias en la base de datos. Limita esto en wp-config.php:
define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 14 );Cómo borrar los transients caducados
Limpia los “transients” antiguos (datos temporales) de la base de datos. Los plugins frecuentemente dejan basura allí que se acumula con el tiempo. Usa WP-CLI para limpiarlos: wp transient delete --expired.
Cómo reducir el autoload de wp_options
La tabla wp_options es uno de los cuellos de botella más comunes. Audita regularmente los datos autoloaded y elimina opciones de plugins desinstalados. Mantén el tamaño total de datos autoloaded por debajo de 800KB para un TTFB óptimo.
Ejecuta esta consulta SQL para ver cuántas opciones autoloaded cargas:
SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';Si el resultado supera 1 MB, tienes un problema. Identifica las filas más pesadas con:
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;Los culpables habituales son ajustes de plugins abandonados, datos de widgets serializados y opciones de tema sobredimensionadas. Elimina lo que no necesites.
Cómo encontrar consultas lentas en la base de datos
Usa el plugin Query Monitor para identificar consultas lentas durante la carga de la página. Busca consultas sin índices adecuados, consultas que se ejecutan dentro de bucles (el problema N+1) y consultas que cargan datos que nunca se muestran. En consultas personalizadas, usa siempre WP_Query con fields y posts_per_page concretos, y no_found_rows => true cuando no necesites paginación:
$query = new WP_Query( [
'post_type' => 'product',
'posts_per_page' => 10,
'no_found_rows' => true,
'fields' => 'ids',
] );El parámetro no_found_rows se salta la costosa llamada SQL_CALC_FOUND_ROWS, lo que puede reducir a la mitad el tiempo de consulta en tablas grandes.
WP-Optimize o limpieza manual de la base de datos
WP-Optimize es un plugin sólido para la limpieza programada de revisiones, borradores, entradas en la papelera, comentarios spam y transients. En sitios donde necesitas control total, combina una limpieza SQL manual con eventos programados de wp-cron. Lo importante es la constancia: haz mantenimiento de la base de datos cada semana, no una vez al año cuando algo se rompe.
Cómo limitar la Heartbeat API
Limita el “pulso” de WordPress (autoguardado, notificaciones del admin) con el plugin “Heartbeat Control” para reducir la carga de CPU del servidor. En sitios con múltiples editores simultáneos, el Heartbeat puede generar cientos de peticiones AJAX innecesarias por minuto.
Cómo optimizar las imágenes en WordPress
Las imágenes son la partida más grande del peso de la página: el Web Almanac 2025 las sitúa en torno al 37% de la página móvil mediana. Optimizarlas es la mayor mejora individual en tiempo de carga.
Imágenes WebP y AVIF en WordPress
Usa formatos modernos como WebP o AVIF que pesan bastante menos que JPG a la misma calidad (las cifras concretas están en el párrafo siguiente). WordPress 6.5+ soporta AVIF nativamente. Implementa lazy loading para imágenes que no están en el viewport inicial y usa srcset para servir tamaños apropiados según el dispositivo.
WebP ofrece archivos entre un 25 y un 35% más pequeños que JPEG con una calidad visual equivalente. AVIF va más allá: entre un 30 y un 50% más pequeño que WebP en contenido fotográfico. El soporte de WebP en navegadores ya es universal (más del 98% de cobertura global). El de AVIF ronda el 92% y sigue creciendo.
Comparación real de tamaños de archivo en un proyecto de wppoland.com:
| Formato | Tamaño de archivo | Calidad |
|---|---|---|
| JPEG (original) | 285 KB | Referencia |
| WebP | 192 KB | Visualmente idéntica |
| AVIF | 128 KB | Visualmente idéntica |
Es una reducción del 55% solo por cambiar de formato. Multiplícalo por 40 imágenes en una página y ahorras megabytes.
Imágenes responsive y lazy loading
WordPress genera varios tamaños de imagen al subirla. Usa los atributos srcset y sizes para que el navegador descargue la imagen del tamaño adecuado. Desde WordPress 5.5, loading="lazy" se añade automáticamente a las imágenes. En las imágenes hero visibles sin hacer scroll, quita el lazy loading para no retrasar el LCP:
add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
if ( str_contains( $image, 'hero-image' ) ) {
return false; // Desactivar lazy loading para la imagen hero
}
return $value;
}, 10, 3 );CDN de imágenes para WordPress
Servicios como Cloudflare Images, imgix y Bunny Optimizer transforman las imágenes al vuelo en el edge: las redimensionan, las convierten a WebP/AVIF y eliminan los metadatos. Así no necesitas generar decenas de tamaños de miniatura en tu servidor. Añade fetchpriority="high" al elemento de imagen LCP para que el navegador priorice su descarga:
<img src="hero.webp" fetchpriority="high" width="1200" height="630"
alt="WordPress performance optimization dashboard">Cómo bloquear el hotlinking de imágenes
No permitas que otros sitios roben tu ancho de banda mostrando tus imágenes en sus páginas. Configura reglas en .htaccess o en tu CDN para prevenir el hotlinking de assets.
Lazy loading de iframes y vídeos
Más allá de las imágenes, aplica lazy loading a iframes, videos embebidos y componentes de página que no son visibles inicialmente. Esto reduce el tiempo de carga inicial y el consumo de datos móviles.
Cómo optimizar el frontend de WordPress
Aquí luchamos por la puntuación de PageSpeed Insights y Core Web Vitals. Estas métricas afectan directamente tu posicionamiento en Google y la experiencia del usuario.
Los recursos que bloquean el renderizado son la causa más común de una mala puntuación LCP. El navegador no puede pintar ningún píxel hasta que ha procesado todo el CSS y el JavaScript síncronos del <head>.
Cómo minificar CSS, JS y HTML
Elimina espacios, comentarios y caracteres innecesarios de CSS/JS/HTML. Plugins como Autoptimize o WP Rocket hacen esto automáticamente. La minificación reduce el tamaño de los archivos: las mediciones publicadas dan en torno al 20-50% para JavaScript y al 15-30% para CSS, así que el resultado depende mucho de qué estés minificando, lo que se traduce en tiempos de transferencia significativamente menores.
Cómo diferir JavaScript en WordPress
Empuja la carga de JavaScript al final (después de que se cargue el HTML) para que no bloquee el renderizado de la página. El atributo defer permite al navegador descargar el script sin bloquear el parsing HTML, ejecutándolo solo después de que el documento esté completamente parseado.
Usa defer para los scripts que necesitan acceder al DOM y async para scripts independientes como la analítica:
add_filter( 'script_loader_tag', function( $tag, $handle ) {
$defer_scripts = [ 'comment-reply', 'contact-form', 'analytics' ];
if ( in_array( $handle, $defer_scripts, true ) ) {
return str_replace( ' src=', ' defer src=', $tag );
}
return $tag;
}, 10, 2 );Cómo cargar el CSS no crítico de forma asíncrona
Saca el CSS no crítico del <head> y cárgalo de forma asíncrona:
<link rel="preload" href="/css/below-fold.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/below-fold.css"></noscript>Critical CSS
Extrae y sirve inline el CSS necesario para renderizar el contenido above-the-fold. Esto permite al navegador pintar la parte visible de la página sin esperar a que se descargue toda la hoja de estilos. El resto del CSS se carga de forma asíncrona.
Herramientas como Critical (de Addy Osmani) o el generador de CSS crítico de WP Rocket automatizan este paso. El CSS inline debería pesar menos de 14 KB (el tamaño de la primera ventana de congestión TCP), para que el navegador pueda mostrar contenido útil con la primera respuesta del servidor.
Cómo eliminar el CSS sin usar con PurgeCSS
Usa PurgeCSS o UnCSS para analizar tus páginas renderizadas y quitar las reglas CSS que no se usan. Un sitio WordPress típico con un page builder carga entre 300 y 500 KB de CSS, de los que entre el 70 y el 80% no se usa en una página concreta. Tras la limpieza:
# Ejemplo de configuración de PurgeCSS
purgecss --css ./style.css \
--content ./**/*.php ./**/*.html \
--output ./style.purged.cssVemos con frecuencia cómo el CSS baja de 400 KB a menos de 60 KB tras un tree shaking correcto. Combínalo con minificación (cssnano) y compresión Brotli para ahorrar el máximo.
Cómo desactivar scripts y estilos de plugins con dequeue
Muchos plugins cargan sus recursos en todas las páginas, también donde no hacen falta. Desactívalos de forma condicional:
add_action( 'wp_enqueue_scripts', function() {
if ( ! is_page( 'contact' ) ) {
wp_dequeue_style( 'contact-form-7-css' );
wp_dequeue_script( 'contact-form-7-js' );
}
}, 100 );Capas de caché en WordPress, del CDN al navegador
La caché es la técnica de rendimiento más eficaz porque elimina el trabajo por completo.
Caché de página y object cache con Redis
Tu sitio no debería generar PHP para cada visitante. Implementa un sistema de cache a múltiples niveles:
- Page Cache: Guarda HTML listo en disco del servidor, sirviendo páginas completas sin ejecutar PHP.
- Object Cache (Redis): Guarda resultados de consultas SQL en RAM. Crucial para tiendas WooCommerce y sitios grandes donde las mismas consultas se repiten constantemente.
La caché de NGINX FastCGI, la caché de LiteSpeed o plugins como WP Super Cache y WP Rocket sirven HTML estático a los visitantes sin sesión iniciada. Una página que tarda 800 ms en generarse de forma dinámica puede servirse en 10 ms desde la caché.
Redis o Memcached guardan en memoria los resultados de consultas a la base de datos, llamadas a APIs y valores calculados. El object cache persistente es la capa de caché con más impacto para usuarios con sesión iniciada y páginas dinámicas que no se pueden cachear enteras.
Cabeceras Cache-Control para recursos estáticos
Configura cabeceras Cache-Control adecuadas para los recursos estáticos. Los recursos inmutables (archivos CSS/JS versionados) deben cachearse de forma agresiva:
location ~* \.(css|js|woff2|avif|webp|jpg|png|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}En las páginas HTML, usa tiempos de caché más cortos o stale-while-revalidate para equilibrar frescura y velocidad:
Cache-Control: public, max-age=300, stale-while-revalidate=86400Caché del CDN para WordPress
Tu CDN debería cachear los recursos estáticos en ubicaciones edge de todo el mundo. Configura la purga de caché para que se active al actualizar contenido. APO (Automatic Platform Optimization) de Cloudflare para WordPress cachea páginas HTML completas en el edge y las purga automáticamente cuando publicas o actualizas contenido.
Las capas funcionan en este orden: caché edge del CDN, luego caché de página en el servidor, luego object cache y por último caché del navegador. Cada capa recoge lo que se le escapa a la anterior.
Cómo optimizar la carga de fuentes web en WordPress
Las fuentes web frenan el sitio sin que se note. Una sola petición a Google Fonts puede añadir entre 200 y 500 ms a la ruta de renderizado crítica por la búsqueda DNS, la conexión y la descarga desde un origen de terceros.
Fuentes locales y font-display swap
Carga las fuentes de Google localmente o usa font-display: swap para que el texto sea visible inmediatamente, antes de que la fuente decorativa cargue. Las fuentes web son una de las causas más comunes de CLS (Cumulative Layout Shift) y FOIT (Flash of Invisible Text). Alojar las fuentes localmente también mejora la privacidad y elimina peticiones a servidores externos.
Descarga los archivos de fuente y sírvelos desde tu propio dominio, así tu CDN también puede cachearlos. Usa solo el formato woff2: tiene más del 99% de soporte en navegadores y ofrece la mejor compresión.
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2');
font-weight: 100 900;
font-display: swap;
unicode-range: U+0000-024F; /* Subconjunto latino */
}La declaración font-display: swap indica al navegador que muestre el texto de inmediato con una fuente de reserva y que cambie a la fuente personalizada cuando termine de cargar. Así evitas el texto invisible (FOIT) y mejoras el LCP.
Cómo precargar las fuentes en WordPress
Precarga tu fuente principal para priorizar su descarga:
<link rel="preload" href="/fonts/inter-var.woff2" as="font"
type="font/woff2" crossorigin>Fuentes variables y subsetting
Las fuentes variables contienen varios pesos y estilos en un único archivo. En lugar de cargar archivos separados para regular (400), medium (500), semibold (600) y bold (700), un solo archivo de fuente variable cubre todo el rango. La fuente variable Inter pesa 97 KB en woff2, frente a 4 archivos estáticos que suman 180 KB.
Recorta tus fuentes para incluir solo los rangos de caracteres que necesitas. El subsetting solo latino puede reducir el tamaño del archivo entre un 40 y un 60% respecto a la cobertura Unicode completa. Herramientas como glyphhanger o el parámetro &text= de la API de Google Fonts lo ponen fácil.
Cómo mejorar LCP, CLS e INP en WordPress
Las Core Web Vitals de Google son las tres métricas que influyen directamente en tu posicionamiento. Saber qué hace fallar cada una te permite optimizar con precisión.
Cómo mejorar el LCP en WordPress
El LCP mide lo rápido que se renderiza el elemento visible más grande (normalmente una imagen hero o un titular). El objetivo es menos de 2,5 segundos.
Causas habituales de un mal LCP:
- Respuesta lenta del servidor (TTFB alto)
- CSS y JavaScript que bloquean el renderizado
- Imágenes hero sin optimizar y sin
fetchpriority="high" - Imágenes LCP con lazy loading (quita
loading="lazy"de las imágenes visibles sin hacer scroll) - Fuentes web que bloquean el renderizado del texto
Corrige el LCP reduciendo el TTFB con caché, poniendo inline el CSS crítico, precargando la imagen LCP y usando fetchpriority="high" en el elemento hero.
Cómo reducir el CLS en WordPress
El CLS mide la estabilidad visual, es decir, cuánto se desplaza el diseño de la página de forma inesperada durante la carga. El objetivo es menos de 0,1.
Causas habituales de un mal CLS:
- Imágenes e iframes sin atributos
widthyheightexplícitos - Contenido inyectado dinámicamente (anuncios, embeds, banners de cookies)
- Fuentes web que provocan reflujo del texto (FOUT)
- CSS que carga tarde y cambia las dimensiones de los elementos
Define siempre las dimensiones de los elementos multimedia. Usa aspect-ratio en CSS para los contenedores responsive. Reserva espacio para anuncios y contenido dinámico con marcadores de posición con min-height.
Cómo mejorar el INP en WordPress
El INP sustituyó al FID en marzo de 2024 y mide la capacidad de respuesta durante todo el ciclo de vida de la página, no solo en la primera interacción. El objetivo es menos de 200 ms.
Causas habituales de un mal INP:
- Tareas largas de JavaScript que bloquean el hilo principal
- Manejadores de eventos pesados en click, scroll o input
- DOM excesivo (más de 1.500 nodos)
- Scripts de terceros que compiten por el tiempo del hilo principal
Divide las tareas largas en partes más pequeñas con requestIdleCallback o scheduler.yield(). Usa delegación de eventos en lugar de añadir listeners a cientos de elementos individuales. Audita sin contemplaciones los scripts de terceros: cada uno que quitas devuelve tiempo al hilo principal.
// Dividir tareas largas con puntos de cesión
async function processItems(items) {
for (const item of items) {
processItem(item);
// Ceder el control al navegador entre elementos
await scheduler.yield();
}
}Precargar páginas con Speculation Rules API
Implementa Speculation Rules API para precargar páginas en segundo plano antes de que el usuario haga clic. Esta técnica puede hacer que la navegación se sienta instantánea sin cambios de infraestructura.
Qué optimizaciones reducen más el TTFB y el LCP
Los impactos en TTFB/LCP abajo son nuestros propios rangos observados en auditorías, no un estudio publicado de terceros.
| Optimización | Impacto en TTFB | Impacto en LCP | Dificultad |
|---|---|---|---|
| PHP 8.3+ | -30% | -15% | Baja |
| Redis Object Cache | -50% | -20% | Media |
| CDN Edge Caching | -70% | -40% | Baja |
| AVIF Imágenes | - | -25% | Baja |
| Critical CSS | - | -35% | Media |
| Speculation Rules | - | -60% (percibido) | Media |
Checklist para acelerar WordPress
Usa esta checklist paso a paso en cada proyecto WordPress. El orden importa: empieza por el servidor y avanza hacia el navegador.
Capa de servidor
- Actualiza a PHP 8.3+ con OPcache y JIT activados
- Configura MySQL/MariaDB con un tamaño de buffer pool adecuado
- HTTP/2 o HTTP/3 habilitado
- Redis/Memcached instalado
- Sal del hosting compartido hacia un hosting gestionado o un VPS
Capa de base de datos
- Revisiones limitadas a 5
- Transients limpios
- Borra los metadatos huérfanos
- Audita las opciones autoloaded (por debajo de 800 KB)
- Añade índices para las consultas de meta personalizadas
Capa de recursos
- Imágenes en WebP/AVIF
- Prevé alternativas adecuadas para formatos no soportados
- Añade
width,heightyfetchpriority="high"a las imágenes LCP - Quita
loading="lazy"de las imágenes visibles sin hacer scroll - Aloja las fuentes en tu servidor en formato woff2 con
font-display: swap - Precarga las fuentes críticas y las imágenes LCP
Capa de código
- CSS crítico inline
- Mantén el CSS crítico por debajo de 14 KB
- JavaScript diferido
- Aplica defer o async a todo el JavaScript no crítico
- Desactiva el CSS/JS de plugins en las páginas donde no se usa
- Elimina el CSS sin usar con PurgeCSS
- Minifica y comprime todos los recursos con Brotli
Capa de caché
- Page Cache activo
- Caché de página completa para visitantes sin sesión iniciada
- CDN configurado
- Configura el CDN con cabeceras de caché adecuadas
- Define
Cache-Control: immutablepara los recursos estáticos versionados - Aplica
stale-while-revalidatea las respuestas HTML
Monitorización
- Sigue las tendencias de datos de campo de 28 días en CrUX Vis
- Vigila las Core Web Vitals en Search Console
- Ejecuta Lighthouse CI en tu pipeline de despliegue
- Fija presupuestos de rendimiento (peso de página, número de peticiones, objetivo de LCP)
Recuerda: Un sitio rápido no es un objetivo en sí mismo. Es una herramienta para mayor conversión y mejor SEO. Cada 100ms de retraso te cuesta clientes perdidos. La optimización de rendimiento es una inversión continua que genera retornos medibles en tráfico, engagement y ventas.
La optimización del rendimiento no es un proyecto puntual. Cada plugin nuevo, cada actualización del tema y cada script de terceros es una posible regresión. Mide de forma continua, optimiza con método y trata la velocidad como una función central del producto desde el principio.
Consulta nuestros servicios de optimización de velocidad WordPress y auditoría de seguridad para una revisión profesional de tu sitio. También ofrecemos mantenimiento WordPress para mantener tu sitio rápido y seguro de forma continua.
