La primera vez que un cliente WooCommerce alojado en Webempresa abrió PageSpeed Insights y vio un LCP de 4,0 s junto a un hero PNG de 200 KB, el diagnóstico llevó treinta segundos y el arreglo una tarde. La conversión del hero a AVIF (Webempresa lleva años con AVIF activo en sus planes LiteSpeed) más fetchpriority="high" llevó la página a 1,4 s de LCP. El lado del CSS fue más difícil: una hoja de estilos de 800 KB de un tema page-builder bloqueaba el renderizado en móvil, y solo la extracción de critical CSS con 12 KB inline bajó el FCP por debajo de un segundo. Estos dos patrones se repiten en casi todos los sitios WordPress españoles que auditamos.
Esta guía recorre la pipeline que realmente mueve los Core Web Vitals en una instalación WordPress española: elección de formato entre AVIF, WebP y JPEG XL frente a la realidad actual de los navegadores (Safari 16+ entrega AVIF, Chrome decodifica JPEG XL solo tras una flag, Firefox aparcó JPEG XL en 2024); selección de plugin entre ShortPixel, Imagify, Smush y EWWW con los límites de API y particularidades de DPA que cada uno trae bajo RGPD y supervisión de la AEPD; la regla de los 14 KB above-the-fold que viene del TCP slow start, no de una diapositiva de marketing; y los ajustes de LiteSpeed Cache que producen un delta medible de LCP en lugar de placebo. Hosts españoles como Webempresa, Raiola Networks y SiteGround-ES ya soportan AVIF nativamente en planes LiteSpeed, lo cual cambia el cálculo de adopción.
De dónde vienen realmente las pérdidas de LCP y FCP
Abre el panel Network en un sitio WordPress español típico alojado en Webempresa, Raiola Networks o Hostalia y verás dos culpables comerse el presupuesto de LCP: una imagen hero de 1-2 MB entregada como JPEG o PNG, y una hoja de estilos principal de 300-800 KB marcada como bloqueante de renderizado. El tercer culpable, fuentes web cargadas sin font-display: swap, es menor en bytes pero bloquea el paint hasta que llegan.
La imagen hero es el objetivo obvio porque LCP, por definición, es el elemento visible más grande sobre el pliegue, y en la mayoría de portadas WordPress españolas ese elemento es un JPEG. WebP corta ese archivo aproximadamente un 25-35% con calidad visual equivalente, y AVIF lo corta de nuevo, aterrizando frecuentemente un 40-55% más pequeño que el JPEG original según el contenido. El soporte AVIF es ahora amplio: Chrome desde la 85, Firefox desde la 93, Safari desde la 16. JPEG XL es el ausente ruidoso: Chromium retiró el flag de decodificación, Firefox lo aparcó indefinidamente, solo Safari lo entrega nativamente, así que para audiencia española no es un formato de producción en 2026.
El lado del CSS es donde la regla de los 14 KB importa. TCP slow start abre una conexión con unos diez paquetes, alrededor de 14 KB después de cabeceras, antes del primer round-trip de ACK. Inlinea más que eso en tu <head> y estiras el primer paint un RTT completo. Esa es toda la razón por la que los extractores de critical CSS apuntan a un techo de 14 KB y no a un número redondo de una checklist. En operaciones de retail anonimizadas que conocemos (un grupo textil de moda con LCP móvil de 4,2 s antes de la auditoría) cada RTT en 4G español equivalía a una caída medible en la tasa de añadir al carrito.
Elección del plugin de optimización de imágenes
Cuatro plugins hacen la mayor parte del trabajo en optimización de imágenes WordPress en 2026, y la elección entre ellos rara vez se reduce solo a la calidad de compresión. Los límites de API, dónde se ejecuta la conversión y qué datos salen de tu servidor importan tanto bajo RGPD y supervisión de la AEPD como el tamaño final del archivo.
ShortPixel Image Optimizer
ShortPixel comprime a través de su API en la nube y entrega WebP más AVIF como estándar. Tres modos: lossy, glossy, lossless. En sitios con muchas fotografías, el preset glossy aterriza normalmente dentro de unos pocos puntos porcentuales de la calidad visual lossless con la mitad de bytes. La trampa en ejecuciones masivas es el techo de rate de la API: empujar 10 000+ imágenes en un día en un plan pequeño dispara throttling, y el procesador en lote del plugin se repliega en lugar de fallar visiblemente, lo que hace que un lote estancado parezca un lote roto. Ángulo AEPD: ShortPixel tiene encargado de tratamiento publicado, pero los endpoints están parcialmente fuera de la UE, así que el proveedor entra en el registro de actividades de tratamiento.
Fortalezas principales:
- Generación de AVIF en producción desde 2023
- Procesamiento masivo con cola en segundo plano
- Preset glossy como predeterminado práctico para editorial y comercio electrónico
- Precios por cuota e individuales
Imagify
Construido por el equipo detrás de WP Rocket, Imagify se integra perfectamente con ese plugin de caché. Ofrece tres modos de compresión (normal, agresivo, ultra) y genera archivos WebP automáticamente.
Fortalezas principales:
- Integración profunda con WP Rocket para optimización combinada
- Herramienta de comparación visual para previsualizar resultados de compresión
- Redimensionamiento automático de subidas sobredimensionadas
- Generación de WebP con un clic
- Precios basados en cuota (individual, varía según el uso)
Smush
Smush de WPMU DEV es la opción más amigable para principiantes. La versión gratuita maneja compresión básica y lazy loading. La versión Pro añade conversión WebP, entrega CDN y optimización más agresiva.
Fortalezas principales:
- Nivel gratuito con imágenes ilimitadas (hasta 5 MB cada una)
- Lazy loading integrado
- CDN incluido con Pro
- Smush a nivel de directorio para imágenes fuera de la biblioteca de medios
- Precios Pro varían según el plan
EWWW Image Optimizer
EWWW es el único plugin de esta lista que puede correr enteramente en el servidor sin un API externo. Eso cuenta bajo RGPD: ninguna transferencia a tercer país de imágenes subidas, ningún encargado de tratamiento adicional necesario, ninguna entrada en el registro de actividades de tratamiento por un procesador SaaS de imágenes, una ventaja clara en revisiones de la AEPD. El modo local usa jpegoptim, optipng, pngquant y cwebp invocados desde PHP, así que los binarios deben estar en disco; en hosts españoles compartidos como Webempresa y Raiola Networks es una conversación corta con soporte.
Fortalezas principales:
- Modo de compresión local sin viaje de ida y vuelta a la nube
- Conversión WebP y AVIF
- Opción CDN ExactDN con entrega por negociación de contenido
- Comandos WP-CLI para ejecuciones masivas via cron
- Precios varían según el modo, local es gratuito, planes API son individuales
Comparación de plugins de un vistazo
| Funcionalidad | ShortPixel | Imagify | Smush | EWWW |
|---|---|---|---|---|
| Soporte WebP | Sí | Sí | Solo Pro | Sí |
| Soporte AVIF | Sí | No | No | Sí |
| Compresión local | No | No | No | Sí |
| Procesamiento masivo | Sí | Sí | Sí | Sí |
| Integración WP Rocket | Básica | Nativa | No | Básica |
| Nivel gratuito | 100 imágenes/mes | 20 MB/mes | Ilimitado (limitado) | Modo local |
Para la mayoría de los sitios WordPress profesionales, ShortPixel o EWWW ofrecen la mejor combinación de soporte de formatos, calidad de compresión y flexibilidad.
Configurar la entrega de WebP y AVIF
Instalar un plugin de optimización es solo la mitad del trabajo. También necesitas asegurar que los navegadores realmente reciban el formato moderno en lugar del JPEG o PNG original.
Método 1: Reescritura del elemento picture
El enfoque más fiable usa el elemento HTML <picture> para ofrecer múltiples formatos con respaldo automático:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Descripción" width="800" height="600" loading="lazy">
</picture>La mayoría de los plugins de optimización gestionan esta reescritura automáticamente. ShortPixel y EWWW insertan etiquetas <picture> cuando se configuran para ello.
Método 2: Negociación de contenido vía .htaccess
Si tu servidor ejecuta Apache o LiteSpeed, puedes servir archivos WebP de forma transparente usando negociación de contenido. El navegador envía una cabecera Accept listando formatos soportados, y el servidor responde con el mejor archivo disponible:
<IfModule mod_rewrite.c>
RewriteEngine On
# Servir AVIF si está disponible y soportado
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME}.avif -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.avif [T=image/avif,E=REQUEST_image,L]
# Servir WebP si está disponible y soportado
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.webp [T=image/webp,E=REQUEST_image,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=REQUEST_image
</IfModule>Este enfoque es invisible para tu HTML y funciona con cualquier tema o constructor de páginas.
Método 3: Filtro WordPress para control programático
Para desarrolladores que desean control preciso, puedes filtrar la salida de imágenes a nivel de PHP:
<?php
declare(strict_types=1);
add_filter('wp_get_attachment_image_attributes', function (array $attr, WP_Post $attachment): array {
$webp_url = preg_replace('/\.(jpe?g|png)$/i', '.webp', $attr['src']);
$upload_dir = wp_get_upload_dir();
$webp_path = str_replace($upload_dir['baseurl'], $upload_dir['basedir'], $webp_url);
if (file_exists($webp_path)) {
$attr['src'] = $webp_url;
if (isset($attr['srcset'])) {
$attr['srcset'] = preg_replace('/\.(jpe?g|png)/i', '.webp', $attr['srcset']);
}
}
return $attr;
}, 10, 2);Limpiar los tamaños de imagen de WordPress
WordPress y WooCommerce registran númerosos tamaños de imagen por defecto. Cada imagen subida genera una copia en cada tamaño registrado, consumiendo almacenamiento y ralentizando la optimización masiva. Eliminar tamaños que no usas es una victoria rápida.
Eliminar tamaños predeterminados no utilizados
<?php
declare(strict_types=1);
add_action('after_setup_theme', function (): void {
// Eliminar tamaños que no utilizas
remove_image_size('1536x1536');
remove_image_size('2048x2048');
});
add_filter('intermediate_image_sizes_advanced', function (array $sizes): array {
// Conservar solo los tamaños que tu tema realmente usa
$remove = ['medium_large'];
foreach ($remove as $size) {
unset($sizes[$size]);
}
return $sizes;
});Registrar solo lo que necesitas
<?php
declare(strict_types=1);
add_action('after_setup_theme', function (): void {
add_image_size('hero-banner', 1200, 630, true);
add_image_size('card-thumb', 400, 300, true);
add_image_size('logo-small', 200, 0, false);
});Establecer dimensiones máximás de subida
Evita que los usuarios suban originales de 6000 px que desperdician almacenamiento y tiempo de procesamiento:
<?php
declare(strict_types=1);
add_filter('wp_handle_upload', function (array $upload): array {
$max_width = 2400;
$max_height = 2400;
if (!str_starts_with($upload['type'], 'image/')) {
return $upload;
}
$image = wp_get_image_editor($upload['file']);
if (is_wp_error($image)) {
return $upload;
}
$size = $image->get_size();
if ($size['width'] > $max_width || $size['height'] > $max_height) {
$image->resize($max_width, $max_height, false);
$image->save($upload['file']);
}
return $upload;
});Entender el critical CSS y los recursos que bloquean el renderizado
Cuando un navegador carga una página WordPress, debe descargar y analizar la hoja de estilos CSS completa antes de renderizar cualquier cosa en pantalla. En un sitio WordPress típico con un tema de constructor de páginas, esa hoja de estilos puede ser de 300-500 KB de CSS, la mayor parte del cual se aplica a elementos debajo del pliegue o en páginas completamente diferentes.
El critical CSS resuelve esto extrayendo solo los estilos necesarios para el contenido visible sin desplazamiento e insertándolos directamente inline en el <head> del HTML. La hoja de estilos completa se carga entonces de forma asíncrona, eliminándola de la ruta crítica de renderizado.
Cómo funciona la extracción de critical CSS
- Una herramienta renderiza la página en un navegador headless a un tamaño de viewport estándar (típicamente 1300x900 para escritorio, 375x812 para móvil).
- Identifica qué reglas CSS se aplican a los elementos visibles en ese viewport.
- Esas reglas se extraen y minifican.
- El CSS extraído se inserta inline en etiquetas
<style>en el head del documento. - La hoja de estilos original se carga con
media="print"y se cambia amedia="all"al cargar.
Patrón manual de precarga de critical CSS
Si no estás usando un plugin que gestióne esto automáticamente, puedes implementar el patrón con un filtro WordPress:
<?php
declare(strict_types=1);
add_action('wp_head', function (): void {
$critical_css_file = get_template_directory() . '/critical.css';
if (!file_exists($critical_css_file)) {
return;
}
$critical_css = file_get_contents($critical_css_file);
if ($critical_css === false) {
return;
}
echo '<style id="critical-css">' . $critical_css . '</style>' . "\n";
}, 1);
add_filter('style_loader_tag', function (string $html, string $handle): string {
// Diferir hojas de estilos no críticas
$defer_handles = ['theme-style', 'woocommerce-layout', 'woocommerce-general'];
if (in_array($handle, $defer_handles, true)) {
$html = str_replace(
"media='all'",
"media='print' onload=\"this.media='all'\"",
$html
);
}
return $html;
}, 10, 2);Precargar recursos críticos con etiquetas link
Para recursos que el navegador necesita inmediatamente, las pistas de preload le indican que comience la descarga antes de descubrir el recurso naturalmente en el HTML:
<!-- Precargar la imagen hero -->
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" type="image/webp">
<!-- Precargar fuente crítica -->
<link rel="preload" as="font" href="/wp-content/themes/theme/fonts/main.woff2"
type="font/woff2" crossorigin>En WordPress, añádelos programáticamente:
<?php
declare(strict_types=1);
add_action('wp_head', function (): void {
if (!is_front_page()) {
return;
}
$hero_image = get_template_directory_uri() . '/images/hero.webp';
echo '<link rel="preload" as="image" href="' . esc_url($hero_image) . '" type="image/webp">' . "\n";
}, 1);Configurar LiteSpeed Cache para WordPress
LiteSpeed Cache es el plugin de caché más rápido disponible para WordPress porque opera a nivel de servidor web en lugar de a través de PHP. Si tu alojamiento ejecuta OpenLiteSpeed o LiteSpeed Enterprise, este plugin se comunica directamente con el motor de caché integrado del servidor, evitando PHP por completo para las solicitudes en caché.
Configuración esencial de LiteSpeed Cache
Caché de página (pestaña Cache):
- Activar caché: Activo
- Caché de usuarios autenticados: Inactivo (a menos que tengas contenido de membresía)
- Caché móvil: Activo (con caché separada para móviles si tu tema sirve markup diferente)
- TTL: 604800 (7 días para sitios con contenido estático), 86400 (1 día para sitios actualizados frecuentemente)
Caché del navegador (pestaña Cache):
- Caché del navegador: Activo
- TTL de caché del navegador: 31557600 (1 año, confía en nombres de archivo versiónados para invalidar caché)
Caché de objetos (pestaña Cache):
- Caché de objetos: Activo (requiere Redis o Memcached en tu servidor)
- TTL de caché de objetos: 3600
Configuración de optimización CSS/JS
Navega a LiteSpeed Cache, luego Optimización:
- Minificación CSS: Activo
- Combinación CSS: Activo (prueba cuidadosamente, puede romper algunos temas)
- Generar critical CSS: Activo
- Carga asíncrona CSS: Activo
- Minificación JS: Activo
- Combinación JS: Inactivo (causa problemas frecuentemente, prueba antes de activar)
- Diferimiento JS: Activo
- Inline JS después de DOM Ready: Activo
Optimización de imágenes en LiteSpeed Cache
LiteSpeed Cache incluye su propio servicio de optimización de imágenes a través de QUIC.cloud:
- Reemplazo de imágenes WebP: Activo
- Lazy load de imágenes: Activo
- Placeholder responsivo: Activo
- Imágenes del viewport (primeras N imágenes excluidas del lazy load): 2-3
Reglas .htaccess de LiteSpeed para caché del navegador
Añade estas reglas a tu .htaccess para cabeceras de caché a nivel de servidor:
# LiteSpeed caché del navegador y compresión
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE font/woff
</IfModule>
# Cabeceras de seguridad que también mejoran el rendimiento
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "interest-cohort=()"
</IfModule>Configuración del crawler de LiteSpeed
El crawler mantiene la caché caliente visitando páginas antes que los usuarios reales:
- Crawler: Activo
- Duración de ejecución: 200 (segundos)
- Intervalo entre ejecuciones: 600 (segundos)
- Retraso de crawl: 500 (milisegundos)
- Límite de carga del servidor: 1
Establece estos valores de forma conservadora en alojamiento compartido. En un servidor dedicado o VPS, puedes aumentar la duración y reducir el intervalo.
Medir resultados con PageSpeed Insights
Optimización sin medición es adivinanza. Google PageSpeed Insights proporciona tanto datos de laboratorio (pruebas simuladas) como datos de campo (métricas reales de usuarios del Chrome User Experience Report).
Qué verificar después de la optimización
Ejecuta PageSpeed Insights en tus páginas clave y verifica estos elementos:
Auditorías aprobadas (verde):
- “Servir imágenes en formatos de nueva generación” debería aprobarse si WebP/AVIF está configurado
- “Codificar imágenes eficientemente” debería aprobarse después de la compresión
- “Dimensionar imágenes correctamente” debería aprobarse si eliminaste tamaños no utilizados
- “Eliminar recursos que bloquean el renderizado” debería aprobarse con critical CSS
Core Web Vitals:
- Objetivo LCP: por debajo de 2,5 segundos
- Objetivo CLS: por debajo de 0,1
- Objetivo INP: por debajo de 200 milisegundos
Usar Chrome DevTools para verificar la entrega de formatos
Abre DevTools (F12), ve a la pestaña Network y filtra por “Img”. Verifica la columna “Type”: deberías ver webp o avif en lugar de jpeg o png. Si aún ves formatos originales, tus reglas de reescritura o la configuración del plugin necesita ajuste.
Presupuesto de rendimiento de Lighthouse
Configura un presupuesto de rendimiento para detectar regresiones:
[
{
"resourceSizes": [
{ "resourceType": "image", "budget": 300 },
{ "resourceType": "stylesheet", "budget": 50 },
{ "resourceType": "script", "budget": 200 },
{ "resourceType": "total", "budget": 800 }
]
}
]Los valores están en kilobytes. Este presupuesto asegura que el peso total de la página se mantiene por debajo de 800 KB, con imágenes limitadas a 300 KB.
Técnicas avanzadas para 2026
Fetchpriority para imágenes hero
El atributo fetchpriority indica al navegador qué imágenes priorizar durante la carga. Aplícalo a tu imagen LCP:
<img src="hero.webp" alt="Banner hero" width="1200" height="630"
fetchpriority="high" decoding="async">En WordPress, puedes añadir este atributo con un filtro:
<?php
declare(strict_types=1);
add_filter('wp_get_attachment_image_attributes', function (array $attr, WP_Post $attachment, string $size): array {
if ($size === 'hero-banner' && is_front_page()) {
$attr['fetchpriority'] = 'high';
$attr['decoding'] = 'async';
unset($attr['loading']); // Eliminar lazy loading del hero
}
return $attr;
}, 10, 3);Content-visibility para secciones debajo del pliegue
La propiedad CSS content-visibility permite al navegador saltar el renderizado de secciones fuera de pantalla hasta que sean necesarias:
.below-fold-section {
content-visibility: auto;
contain-intrinsic-size: auto 500px;
}Esto reduce significativamente el trabajo inicial de renderizado en páginas largas con muchas imágenes.
Imágenes responsivas con art direction
Para imágenes que necesitan diferentes recortes en diferentes breakpoints, usa el elemento <picture> con media queries:
<picture>
<source media="(max-width: 640px)" srcset="hero-mobile.avif" type="image/avif">
<source media="(max-width: 640px)" srcset="hero-mobile.webp" type="image/webp">
<source srcset="hero-desktop.avif" type="image/avif">
<source srcset="hero-desktop.webp" type="image/webp">
<img src="hero-desktop.jpg" alt="Imagen hero" width="1200" height="630">
</picture>Lista de verificación de rendimiento
Usa esta lista de verificación para confirmar que tu implementación está completa:
- Plugin de optimización de imágenes instalado y configurado
- Generación WebP activada para todas las subidas nuevas
- Generación AVIF activada (si el plugin lo soporta)
- Optimización masiva ejecutada en la biblioteca de medios existente
- Tamaños de imagen no utilizados eliminados
- Dimensiones máximás de subida establecidas
- Reglas de reescritura WebP/AVIF en .htaccess implementadas
- Extracción de critical CSS activada
- Hojas de estilos no críticas diferidas
- Imagen hero precargada con
<link rel="preload"> - Imagen hero marcada con
fetchpriority="high" - Caché de página de LiteSpeed Cache activada
- Caché del navegador de LiteSpeed Cache activada
- Optimización CSS/JS de LiteSpeed Cache configurada
- Crawler configurado y en ejecución
- Puntuación PageSpeed Insights verificada en 90+
- Entrega WebP/AVIF confirmada en DevTools
Dos casos que mapean la pipeline a números
El primer caso fue una tienda WooCommerce de un grupo textil de moda anonimizado en hosting compartido español que servía un hero PNG de 200 KB, un carrusel de 1,2 MB de JPEGs no optimizados, y una hoja de estilos de page-builder de unos 600 KB en cada página. Los datos de campo mostraban LCP móvil en 4,0 s, FCP en 2,8 s, y la tienda perdía conversiones del tráfico de campañas Google Shopping en rebajas porque las páginas de producto tardaban demasiado. Convertimos el hero a AVIF (28 KB después de compresión glossy en ShortPixel), añadimos fetchpriority="high" y un <link rel="preload"> correspondiente, regeneramos miniaturas en los tamaños que el tema realmente usaba, y corrimos el bulk de ShortPixel sobre el catálogo. El LCP bajó a 1,4 s sin tocar CSS, y el porcentaje de añadir al carrito en móvil se recuperó dentro de la primera semana.
El segundo caso era el opuesto: las imágenes ya eran AVIF, pero el FCP se negaba a bajar de 2,4 s en móvil. El único culpable bloqueador de renderizado era un main.css de 800 KB que contenía cada módulo de page-builder que el sitio nunca usó. Extrajimos critical CSS para la portada y tres plantillas de landing con Penthouse, inlineamos 12 KB en el head, deferimos el resto con el patrón de intercambio media="print", y añadimos font-display: swap a las declaraciones WOFF2. El FCP bajó unos 600 ms en un perfil Android mid-tier limitado, y el panel de WP Rocket dejó de marcar “elimina recursos bloqueadores de renderizado”.
El patrón merece nombre explícito: cuando el LCP es la métrica que falla, el arreglo es casi siempre del lado de la imagen; cuando el FCP falla mientras el LCP es aceptable, el arreglo es del lado del CSS. Las herramientas que juntan los dos producen mejoras vagas; tratarlos como cuellos de botella separados produce mejoras medibles.
Qué hacen realmente WP Rocket, FlyingPress y Perfmatters
Estos tres plugins no son intercambiables, y las páginas de marketing tienden a oscurecer eso. WP Rocket agrupa caché de página, concatenación y defer de CSS/JS, lazy loading y un hook de integración para Imagify; su extracción de critical CSS (RUCSS) corre en el lado del servidor en SaaSWP y se repliega graciosamente si la extracción falla. FlyingPress se enfoca en servir fuentes localmente, inline critical CSS por plantilla y eliminar CSS no utilizado al nivel de URL en lugar de al nivel del sitio, que es el mejor modelo para sitios con layouts variados. Perfmatters no cachea: desactiva funcionalidades de WordPress que el sitio no necesita (heartbeat polling, scripts de emoji, embed.js, endpoints REST) y añade hints preconnect, prefetch y DNS-prefetch. Los tres se apilan limpiamente: Perfmatters poda, FlyingPress o WP Rocket manejan CSS y caché, un plugin de imágenes maneja AVIF.
Si el host es OpenLiteSpeed o LiteSpeed Enterprise (planes LiteSpeed de Webempresa y Raiola Networks), la cuenta cambia. LiteSpeed Cache se comunica con el módulo de caché incorporado en el servidor y se salta PHP enteramente en cache hits, lo cual es más rápido que cualquier plugin corriendo dentro de PHP puede ser. La contrapartida es que QUIC.cloud maneja critical CSS y conversión de imágenes off-site, lo cual tiene sus propias implicaciones bajo RGPD: encargado de tratamiento con QUIC.cloud, entrada en el registro de actividades, y evaluación de transferencia si el tráfico sale de la UE.
Para CDNs de imagen con presencia española: Cloudinary publica encargado de tratamiento con cláusulas contractuales tipo, pero el endpoint por defecto está fuera de la UE; ImageKit ofrece un endpoint de región UE con encargado de tratamiento, lo que reduce el esfuerzo de transferencia a tercer país bajo la guía de la AEPD. La AEPD también ha publicado criterios sobre el uso de cookies de CDN de terceros, así que conviene revisar la categorización de cookies de los CDN de imagen antes de habilitarlos en producción.
Resultados de la pipeline
En trabajo reciente con clientes el patrón aterriza en este rango. Trata los números como un sobre aproximado en lugar de garantía, dado que la condición inicial importa más que la intervención.
| Métrica | Antes | Después |
|---|---|---|
| Puntuación PageSpeed móvil | 35-55 | 90-98 |
| LCP | 4,5-8 s | 1,2-2,0 s |
| Peso total de la página | 3-6 MB | 400-800 KB |
| Número de solicitudes | 80-120 | 25-40 |
| TTFB | 800 ms+ | 150-300 ms |
La combinación de formatos de imagen modernos, critical CSS y configuración adecuada de caché aborda tres cuellos de botella independientes: tamaño de archivo, bloqueo del renderizado y tiempo de respuesta del servidor. Ninguno sustituye a los otros.
Dónde encaja wppoland.com
Corremos esta pipeline en sitios WordPress y WooCommerce en producción: configuración de LiteSpeed a nivel de servidor, extracción de critical CSS con limpieza manual desde la pestaña Coverage donde Penthouse pierde un selector, entrega AVIF con negociación de contenido, y un rastro de auditoría en los datos de campo de PageSpeed Insights para que los cambios aguanten bajo tráfico real de CrUX. Los precios son individuales y dependen del tamaño de la biblioteca de medios, la huella del page-builder y cuánto del trabajo es migración frente a optimización en sitio. Si las puntuaciones de PageSpeed están bloqueando las posiciones de los sitios, contacta con nosotros para una auditoría de rendimiento.
