WP Rocket para Elementor: cada ajuste medido

El resultado

La misma página de Elementor, ajuste a ajuste, medida cinco veces en móvil y cinco en escritorio. La tabla muestra la mediana. La última columna indica si el menú, el carrusel y la ventana emergente seguían funcionando, comprobado en 12 cargas nuevas.

* Lighthouse nunca toca la página, así que WP Rocket no carga los scripts durante la medición. Los visitantes reales los cargan igualmente al primer toque o desplazamiento. Estas cifras no son una mejora real, y el menor tiempo de carga de esta fila también se debe en parte a ello.

¿Qué precisión tienen las cifras? La misma configuración recomendada dio 4,02 en vez de 3,87 segundos en móvil en una segunda serie el mismo día. Las diferencias por debajo de unos 0,15 segundos no son fiables.

Por qué la caché sola no basta

De serie, WP Rocket guarda la página en caché, minifica el CSS y el JavaScript y precarga los enlaces. La primera respuesta del servidor llega casi el doble de rápido (0,38 en vez de 0,67 segundos). Aun así, en móvil la página no es más rápida (4,54 en vez de 4,53 segundos) y en escritorio solo un poco (1,24 en vez de 1,31). El móvil apenas espera al servidor; lo que espera sobre todo son los archivos CSS y JavaScript, las imágenes y las fuentes. Ahí actúan los siguientes ajustes, cada uno con una pequeña aportación.

Los ajustes paso a paso

Todos los ajustes están en Ajustes → WP Rocket. Después de cada cambio, haz clic abajo en Guardar Cambios y Optimizar.

JavaScript & CSS: Archivos CSS

1. Minificar archivos CSS viene activado de serie. Déjalo así.
2. Activa Optimizar la entrega de CSS y elige Eliminar el CSS no utilizado. En móvil aporta poco en nuestra página (de 4,54 a 4,44 segundos, casi dentro de la variación), en escritorio de 1,24 a 1,19 segundos. A cambio, la página necesita 20 peticiones menos (de 66 a 46), porque WP Rocket sustituye los archivos CSS sueltos por un único CSS limpio incrustado.

Conviene saberlo: WP Rocket no calcula el CSS limpio en tu servidor, sino en sus propios servidores, que para ello acceden a tu página y a sus archivos CSS. El resultado tarda alrededor de un minuto por página. Si tu web está detrás de una protección con contraseña, por ejemplo una web de staging, tienes que dejar que los servidores de WP Rocket accedan no solo a la página, sino también a los archivos CSS, JavaScript y de fuentes. Si no, WP Rocket indica igualmente «completed» y entrega un CSS vacío. Eso es justo lo que nos pasó (ver la corrección de arriba).

Cómo comprobarlo:

1. Abre tu página en una ventana privada.
2. Muestra el código fuente y busca wpr-usedcss.

Si en ese bloque hay mucho CSS (en nuestro caso unos 146 KB), todo ha ido bien. Si está vacío o la página se ve de repente sin estilos, el servicio de WP Rocket no llega a tus archivos.

JavaScript & CSS: Archivos JavaScript

1. Minificar archivos JavaScript viene activado de serie. Déjalo así.
2. Activa Cargar archivos JavaScript de manera diferida. En móvil pasa de 4,44 a 4,09 segundos, en escritorio de 1,19 a 1,07.
3. Importante: en el campo Excluir archivos JavaScript justo debajo, añade esta línea:

/jquery-?[0-9.](.*)(.min|.slim|.slim.min)?.js

Sin esta línea, el menú, el carrusel y la ventana emergente de Elementor Pro fallan más o menos en una de cada dos cargas. En el siguiente apartado explicamos por qué. La exclusión apenas cuesta tiempo: 3,87 en vez de 3,80 segundos en móvil, dentro de la variación de la medición, y 0,86 en vez de 0,79 segundos en escritorio. A cambio, la página funciona de forma fiable.

Retrasar la ejecución de JavaScript lo dejamos desactivado. Más abajo explicamos por qué.

Image & Media

1. En LazyLoad: activa Habilitar para las imágenes, Habilitar para imágenes de fondo en CSS y Habilitar para iframes y vídeos.
2. En Dimensiones de imagen: activa Añadir dimensiones de imagen faltantes.
3. En Fuentes: activa Precargar fuentes y Alojar localmente fuentes de Google.

El LazyLoad y las dimensiones de imagen ahorran algo más de 0,2 segundos en móvil (de 4,09 a 3,86) y hacen la página más ligera: de 713 a 611 KB. Las fuentes apenas cambian algo en móvil (3,80 segundos), pero en escritorio sí se nota: de 1,11 a 0,79 segundos y 10 peticiones menos. El peso de la página vuelve a subir a 730 KB. Y con Alojar localmente fuentes de Google los navegadores de tus visitantes ya no contactan con ningún servidor de Google, algo importante también para la privacidad. Más en Google Fonts en local.

Precargar

Activar la precarga y Habilitar la precarga de enlaces vienen activados de serie. Déjalos así. Así WP Rocket genera la caché de todas las páginas por su cuenta, en lugar de esperar al primer visitante.

Lo que puede romperse con Elementor

En nuestra prueba, el menú, el carrusel y la ventana emergente dejaron de funcionar en algunos pasos. Sin mensaje de error ni aviso, la página se veía normal. Simplemente, el menú hamburguesa no respondía y el carrusel estaba parado.

La causa: Cargar archivos JavaScript de manera diferida también retrasa jQuery. jQuery avisa entonces de que está «listo» mientras los demás scripts siguen cargándose. Elementor arranca al momento y lanza su señal de inicio. Si Elementor Pro aún no está en ese instante, se pierde la señal. El menú, el carrusel y la ventana emergente vienen de Elementor Pro, así que nunca se activan. Es una carrera: a veces gana Pro y a veces no. Lo comprobamos con marcas de tiempo: en una carga que falló, Elementor arrancó a los 922 milisegundos y Elementor Pro no terminó de cargarse hasta los 927. Cinco milisegundos deciden si tu menú funciona.

Con qué frecuencia funcionaron el menú y el carrusel, 12 cargas nuevas en móvil en cada caso:

En cuanto Cargar archivos JavaScript de manera diferida está activado sin la exclusión de jQuery, falla más o menos una de cada dos cargas. Que el LazyLoad para imágenes de fondo en CSS esté activado o no apenas importa. En 4 de los 7 fallos justo después de activarlo, Elementor Pro aún no se había cargado cuando arrancó Elementor, y lo pudimos comprobar. Lo traicionero es que no falla siempre: cuando lo pruebas tú, todo puede parecer correcto. Con jQuery excluido funcionó en todas las cargas.

Cómo comprobar tu web:

1. Ábrela varias veces en una ventana privada en el móvil, sin desplazarte.
2. Toca primero el menú.

Si no se abre o un carrusel está parado, falta la exclusión.

Por qué no recomendamos «Retrasar la ejecución de JavaScript»

Esta opción solo carga el JavaScript cuando alguien toca la página, se desplaza o mueve el ratón. Lighthouse nunca lo hace, por eso las cifras parecen buenas: 3,32 en vez de 3,80 segundos y 459 en vez de 730 KB. En gran parte es una ilusión. Los visitantes reales cargan los scripts igualmente al primer toque. Y sin exclusiones, Elementor no arrancaba hasta el primer toque y el carrusel estaba parado hasta entonces.

Con las Exclusiones con un clic para Elementor y Elementor Pro todo funcionó, en las 12 cargas. La página mide entonces 3,57 segundos en móvil, 0,3 segundos menos que nuestra recomendación. Pero también aquí Lighthouse deja sin cargar un script retrasado. A cambio, el menú tardaba unos 0,2 segundos en abrirse con el primer toque, en lugar de 0,02. Eso se nota. Para una página de Elementor como la nuestra no merece la pena. Las mediciones exactas del primer toque están en retrasar la ejecución de JavaScript con Elementor.

Lo que WP Rocket envía y recibe

Registramos cada paso con nuestro Connection Monitor:

• De serie: WP Rocket consulta de vez en cuando api.wp-rocket.me para precios y actualizaciones (check_update.php), en nuestro caso dos veces justo después de configurarlo. Durante la medición en sí no hubo ninguna conexión hacia fuera.
• Con «Eliminar el CSS no utilizado»: un encargo por página a saas.wp-rocket.me. Incluye la dirección de la página, el correo electrónico de tu cuenta de WP Rocket y tu clave de licencia. Vuelve el CSS limpio. Según la respuesta, el encargo se procesa en una cola de la UE. Después, un servidor de WP Rocket accede a tu página (en nuestro caso desde 46.30.212.202, agente de usuario «WP-Rocket-SaaS») y a sus archivos CSS.
• Con «Alojar localmente fuentes de Google»: tu servidor descarga las fuentes de Google una sola vez, en nuestro caso 6 peticiones de CSS y 25 archivos de fuentes con alrededor de 1,1 MB en total. Después, los navegadores de tus visitantes no hacen ninguna petición a servidores externos.

WP Rocket no envía datos de los visitantes en el proceso. Aun así, para tu política de privacidad conviene saber que con «Eliminar el CSS no utilizado» un servicio externo accede a tus páginas.

Lista de comprobación

• JavaScript & CSS: Minificar archivos CSS activado, Optimizar la entrega de CSS con Eliminar el CSS no utilizado
• JavaScript & CSS: Minificar archivos JavaScript y Cargar archivos JavaScript de manera diferida activados, línea de jQuery en Excluir archivos JavaScript
• JavaScript & CSS: Retrasar la ejecución de JavaScript desactivado
• Image & Media: las tres opciones de LazyLoad, Añadir dimensiones de imagen faltantes, Precargar fuentes, Alojar localmente fuentes de Google
• Precargar: Activar la precarga y Habilitar la precarga de enlaces activados (de serie)
• Después: comprueba en el código fuente que el bloque wpr-usedcss contiene realmente CSS
• Después: abre tu página varias veces en el móvil en una ventana privada y prueba el menú, el carrusel y la ventana emergente sin desplazarte antes

¿Quieres optimizar primero el propio Elementor? Míralo en Elementor más rápido.

Para curiosos de la técnica: montaje y datos en bruto

• Laboratorio: WordPress 7.1.4, PHP 8.4, Hello Elementor 3.5, Elementor 4.3.6, Elementor Pro 4.3.2, WP Rocket 3.24, hosting compartido en All-Inkl. Página de referencia con imagen principal, cajas de iconos, carrusel de opiniones, galería, acordeón, formulario y ventana emergente. Metodología
• Medición: Lighthouse 13.5.0, 5 pasadas en móvil (con limitación) y en escritorio tras una carga de calentamiento. Antes de cada paso, laboratorio restaurado al mismo snapshot y caché vaciada; con «Eliminar el CSS no utilizado» esperamos a que WP Rocket indicara «completed» y comprobamos además que el CSS limpio entregado tuviera al menos 10 KB. En cada paso fueron entre 146 y 147 KB.
• Variación de la medición: la configuración recomendada dio 4,02 en vez de 3,87 segundos en móvil en una segunda serie el mismo día. Por eso no consideramos reales las diferencias por debajo de unos 0,15 segundos. El tiempo de respuesta del servidor (TTFB) en móvil fue de 674 milisegundos sin plugin de caché y de 377 con WP Rocket.
• Punto de partida: WP Rocket con los 79 valores por defecto de una instalación nueva. De serie están activados minify_css, minify_js, manual_preload, preload_links y la caché para móviles.
• Prueba de funcionamiento en cada paso con un navegador automatizado sobre exactamente la URL medida: menú hamburguesa, carrusel, acordeón, formulario, ventana emergente, errores de consola. Además, una prueba sin ninguna interacción (cargar, no tocar nada y luego tocar el menú) y, en cada paso, 12 cargas nuevas con marcas de tiempo del arranque de Elementor y Elementor Pro. En todas las cargas que fallaron, Elementor arrancó antes de que el navegador lanzara DOMContentLoaded; en todas las que funcionaron, después.
• La exclusión: exclude_defer_js = /jquery-?[0-9.](.*)(.min|.slim|.slim.min)?.js. Así jQuery se ejecuta de forma normal en la cabecera y solo lanza «ready» cuando todos los scripts diferidos se han cargado.
• Corrección del 8 de noviembre de 2026: nuestro laboratorio está detrás de una protección con contraseña. Al servicio de WP Rocket solo le habíamos dado acceso a la página, no a sus archivos CSS, JavaScript y de fuentes. Aun así indicaba «completed», pero el CSS limpio que entregaba estaba vacío. Por eso, todos los valores a partir de «Eliminar el CSS no utilizado» procedían de una página sin CSS y eran demasiado buenos. Ahora los archivos estáticos solo son accesibles para las direcciones IP oficiales de WP Rocket, y nuestros scripts de prueba se detienen si el CSS limpio ocupa menos de 10 KB. Volvimos a medir todos los pasos y archivamos los datos antiguos. Nuestra observación anterior de que el fallo de Elementor aparece sobre todo junto con el LazyLoad para imágenes de fondo en CSS no se confirmó con CSS real: aparece en cuanto «Cargar archivos JavaScript de manera diferida» está activado sin la exclusión de jQuery.
• Transparencia: antes ya habíamos descartado dos series de mediciones. En la primera, al snapshot del laboratorio le faltaba el ajuste de caché para móviles y nuestra protección con contraseña bloqueaba los servidores de WP Rocket. En la segunda, la prueba de funcionamiento cargaba la página con un parámetro añadido que WP Rocket no optimiza, así que comprobaba una página distinta a la medida y no detectó el fallo de Elementor. Todos los valores de arriba proceden de la cuarta serie, medida el 8 de noviembre de 2026.
• Datos en bruto: messdaten.csv con todas las pasadas. Medido el 7 y el 8 de noviembre de 2026.